Custom objects, step #1: display object customization points #283
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nd buffer and assignment logic Next up, prepare details from graphics.defineEffect()
…from Program Slight redesign of TimeTransform with caching (to synchronize multiple invocations with a frame) and slightly less heavyweight call site
Err, was calling Modulo for sine method, heh That said, time transform seems to work in basic test
Fixed error detection for positive number time transform inputs Relaxed amplitude positivity requirement
…ed APIs, SendMessage() Custom display object factory support CoronaObjects API with revised store / extract features (versus hacky globals-heavy approach from CoronaObjects branch), still untested
…ed type Various types' factories and display APIs updated to rig everything up Support for non-drawing iteration in groups
…e cpp file Forward declaring CoronaObject derivatives rather than pointers to same and as Handles Somewhat more verbose macros for store and extract
…of some design flaws, in particular how stack-based values would become junk in their lists Beginnings of some documentation for CoronaObjects machinery
…the public types) Some bugfixes for the same, where the object and box were mixed up A good chunk of docs for CoronaObjects
…E CHANGE notes Related doc stuff Fix for store of group objects as display objects, now internally stored as group type (fix for GetChild() etc.) Added new APIs to simulator-specific list to avoid symbol stripping
Some redesign of object types, along with auto-promotion of group objects that were only added as display objects (will be handled appropriately when loaded), needed for various group objects handling
… passed through void pointers: virtual calls were botched and causing stack overflows on Android
…vents OnCreate action takes an in-out userdata parameter now
Added new files to iPhone and tvos projects
Added BoxObjectList to file list
Added CoronaObjectValidate() Renamed CoronaObjectsSetHasDummyStageBounds() to use Object rather than Objects Updated Mac and Windows simulator functions
|
Update: A few CoronaObject pointers were non- I realized something I'm hoping to add in PR 3 will want a "command buffer" type available. It seemed least intrusive to add it to this PR while it's still open. |
…g woes) Notes in that same file
Shchvova
approved these changes
Jan 24, 2023
Shchvova
approved these changes
Jan 24, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A “custom" object is added to the display hierarchy like any other display object, and by default will behave exactly like its underlying object, e.g. a rect or circle.
The objects API, however, lets us modify how an object handles various situations, such as being drawn. This means plugins can introduce new display object types, or even "commands" that don't render at all but require specific timing.
I'm basically making a second sweep over some stuff from last summer:
Demo
Monolithic repo
Test "plugins"
I had set this aside to work on Vulkan and get an idea of how a different API might affect things—and it will, a bit. The original branch was pretty heavyweight, so I'm also trying to break it up into four or five digestible PRs.
The submissions should go roughly like:
(3D is not the only goal here. I think PR 1 would lend itself well to introducing compute buffers to Solar, for instance.)
This is PR 1.
The details:
Display objects have several virtual methods. With the API defined in this PR, we can instantiate a derived class-based version of any of Solar’s display object types (the
PushAPIs). These subclasses provides the “magic”, with all of the customization points in their overridden methods.For the most part, we can suppress methods and / or add before / after logic to them. There’s also creation and finalization support. In addition, a new
SendMessage()method has been added to display objects, which we can also handle.This customization is all provided by making a “method stream”, a list of methods we want to augment. This can be a one-shot affair, or we can cook the stream and reuse it.
Each of the
new*functions, such asdisplay.newRect()and so on, invoke some "factory" logic that actually produces the main resource. These are all amended to search for a replacement "factory" and use that if provided. In this way the new APIs can make custom objects but reuse the rest of the underlying original logic.In practice, probably only a small handful of methods will be popular, e.g.
Draw(),HitTest(), andSetValue(), but I tried to be exhaustive anyway. 😃(N.B. The
Draw()method is NOT the actual rendering, but rather happens when the object is visited in the hierarchy and Issues the appropriate commands. The fancier stuff will call for PR 2. 😄 )Solar objects are exposed through some opaque pointers to intermediate "box" objects. These boxes get invalidated when not in use, e.g. when the current method call finishes.
As of this PR, only some of these opaque pointers see any use, although a few more are listed in the public types, since they’re used in upcoming stuff.
Also, while I have a number of revisions in mind, a rough approximation of what the remaining PRs introduce is here.
The comments throughout
CoronaObjects.hare probably a good first approximation of what would wind up in the docs.I tested it with this plugin. There are some notes in
Solar2D/main.luaabout what’s being demonstrated. It’s not terribly exciting—everything happens in the console or output pane—but several non-drawing objects do get plugged into the hierarchy and "drawn".There's probably a little bit left to do for web (also Linux and Switch, I suppose), to add the files to the build and so on; I'll see if I can puzzle out the process there.
Also, in the physics contact file I'm just removing some "work in progress" stuff I forgot in a previous (accpted) PR. 😄
Also also—and the cause of several noisy commits, unfortunately—I seem to have expunged a couple rogue files that crept in from the luafilesystem and emscripten submodules.