-
Notifications
You must be signed in to change notification settings - Fork 0
CoronaGraphics.h
TODO: Fill this in!
Details about how to achieve custom display objects with some generality. (Would these be "external display objects"?)
There should be some way to provide a Lua interface for the object; this can probably use the built-ins as guidance. However, this is predominantly C++-side machinery. Following the lead of external textures is probably the way to go.
The most promising approach seems to be taking advantage of the command buffer. This would entail adding our own commands, so adhering to some signature. Should this be required? In theory emitting multiple commands has its place, but that just as well suggests the ability to emit none... In fact we might want this at times, e.g. when referencing another object that has since disappeared.
Anything graphical tends to involve platform-specific cases, so exposing some constants or tags / traits would be useful.
Display objects are members of groups, and many of the suggested use cases involve on / off states, so some balancing can be automated (at the very least go guard against forgetting to switch back, but it's a useful default anyhow). This suggests a method to opt-in to this cleanup state and have it peeled off in reverse order. (Should this also be a zero, one, or many thing?)
As with external textures, lifetime issues are a matter here, plus suspend / resume in some cases.
Some object might only entail a minimum of up-front work for creation / destruction and otherwise behave similarly to the current set of built-ins. Maybe some careful work here would make those easier or even plugin-ifiable?
This is high-priority.