Hi,
I mean, after all, I’m a paying customer now so I have a right to throw my items in the mixer too 
I’m sure many, even most maybe, of these won’t be particularly original, but here goes anyway…
-
Direct pixel-level manipulations. This is required for more advanced effects. Many moons ago I developed my own graphics library for PocketPC… there I of course had direct access to images and the library exposed that via the usual sorts of getPixel()/setPixel()-type functions, but I also implemented a simple shader model: as an image was being blit’d each pixel was passed through an attached shader, which was just an arbitrarily complex function that could manipulate the pixel data before it hit the screen buffer (the function actually got passed the pixel data as well as the immediately adjacent pixels’ data as I recall). Something like this would be pretty sweet too, but there’s a lot of performance implications there. Still, something to consider… but just bitplane access to the screen buffer, if nothing else (like individual DisplayObjects) is a must for things like blurs and whatnot.
-
Pixel-perfect collision detection WITHOUT the physics engine. While bounding boxes are perfectly adequate for many situations, pixel-perfect detection is necessary in many others and having to invoke physics bodies and all that complexity (assuming you don’t need the physics engine otherwise of course) is a bit of a hassle.
-
A package of common built-in image transformations. Having simple methods to do common things like flip, mirror, greyscale, blur, and so on, would be a convenient thing to have.
-
Add clipping abilities to DisplayGroups. In other words, if I set up a DisplayGroup, allow me to specify a width and height and then clip any children to those bounds. That would make a lot of tasks quite a bit easier.
-
A high-level API for multitouch and gestures. I know there’s some third-party support for some of this, and a certain degree of support for it in the Corona API, but building it into the API in a more robust, rich way would be phenomenal. Ideally, an API for gestures where I could feed it something along the lines of a physics body definition, vis a vis basically a series of polygon vertices, along with some key information about direct along the resultant lines, and the API could trigger an event when a matching gesture is detected, would be perfect (but I’ll take just about anything you come up with!)
-
Some minor simulator improvements: (a) allow the app to continue after a build so I don’t have to reload it, (b) an option to reload the last project automatically on startup, © allow for the key events to be usable in the simulator so that during development you could have triggers for various things you want to test (I’d like the key events to be able to use ANY key on my keyboard too… I understand that would only be for the simulator, but that’s all I’m looking for).
-
I know this is more a function of Lua than Corona, but a robust runtime error-handling mechanism is a MUST. This has been one of my biggest headaches moving to Corona, not being able to show some sort of user-friendly error message when problems occur. Yes, we need to write robust, crash-proof code… but if nothing else, during development, when you hand an app to testers, it’s one thing to be able to write info to a debug log (which of course I do) but it’s quite another to be able to show them that something went wrong rather than things just Not Working Right All Of A Sudden™ because the app just continued on its merry way because at that point you’re effectively further away from the root cause, and what’s in the debug log probably doesn’t even help as much as you’d like unless you were pcall’ing the function where the problem occurred (you can of course narrow down where the problem occurred if you’re logging function entries and exits and some important points within functions, but that’s trying to hammer a nail in with a screwdriver: doable, but not fun). We really do need some sort of try…catch, or just a simple “on error goto X” sort of mechanism, if for no other reason than debugging… I’d be OK with it if you told me this could only be used in some sort of “debug” build even, that would be a big help alone.
I think that’s it for me at the moment. Thanks for listening!
Frank W. Zammetti
Author of “Practical Palm Pre webOS Projects”
and “Practical Ext JS Projects with Gears”
and “Practical Dojo Projects”
and “Practical DWR 2 Projects”
and “Practical JavaScript, DOM Scripting and Ajax Projects”
and “Practical Ajax Projects with Java Technology”
For info on books and a lot more visit zammetti.com
[import]uid: 10600 topic_id: 27138 reply_id: 327138[/import]