What features should we add to Corona?

Custom display objects

A number of possibilities would open up if we could invoke our own logic when an object's turn comes around for rendering.

This might involve deriving from some "custom object prototype" class, where you supply a few methods, say:

Object:Create() -- instantiate one of the objects, possibly redundant
Object:Destroy() -- clean up any resources
Object:Draw() -- perform custom rendering
Object:Resume() -- recover from device loss or app suspend...
Object:Suspend() -- ...handle the loss / suspend itself

You then create your object and stuff it in a group as usual.

I'm probably overlooking a detail or two, but the above ought to let a motivated developer do quite a lot, knowing some OpenGL and how to create and update resources. This would open up a new range of plugins.

Any unimplemented methods could be no-ops. The critical part which needs a bit of SDK support is WHEN they're triggered, the rest being up to the developer. Draw() would be the workhorse, of course.

Possible uses:

- Meshes
- Vector graphics
- Dynamic textures (forgo some of the power of snapshots for per-pixel operations)
- 3D scene graph (huge plugin possibilities)
- OpenCL / CUDA -> OpenGL integration (ditto)...
- ...maybe even RenderScript or Metal
- Use of cubemaps, volume textures, etc. when available
- Early snapshot updates, using object as a "signal"
- Bespoke "native" widgets that live in OpenGL land

I think some orthogonal support to detect binding / unbinding shader kernels (along with custom properties) would make this more powerful still, but isn't make-or-break.

This is the sort of feature that could grow organically over time. Even provisional support, say a few hooks in Enterprise, would make for a great start.

15 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Steven Johnson shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Steven Johnson commented  ·   ·  Flag as inappropriate

    It was a bit sloppy on my part to phrase this in terms of methods (implying that the user would be calling these manually), rather than listeners. (Retained vs. immediate mode.) This is NOT what was being proposed! :)

    The gist of it, rather, is that some graphics operations are difficult or impossible in stock Corona, but perfectly feasible, sometimes even easy, in OpenGL. (Actually implementing these, which would entail native plugins and such, is a separate concern.) The obstacle lies in the timing, since user events don't fire during rendering. The proposal strives toward removing this obstacle.

    Usage might go something like follows.

    At startup:

    local MyObjectType = display.newObjectType{
    onCreate = MyCreateFunc,
    onDestroy = MyDestroyFunc,
    onDraw = MyDrawFunc,
    -- etc

    then later you use the returned factory function to instantiate an object:

    local new_instance = MyObjectType()


    and tada, it's in the hierarchy! No magic apart from the bare necessities. The onus is on the developer to supply appropriate and consistent methods.

    Finally, this is to enable rather than encourage such things. For the most part you'd still prefer standard display objects.

  • stewart bracken commented  ·   ·  Flag as inappropriate

    This seems like a divergent pattern to Corona Sdk. Where you are introducing on the fly style drawing, corona works by setting up draw objects once then letting the engine draw it each frame. This would require a lot of new draw methods.

Feedback and Knowledge Base