For me texture packer is obselete since 2014, I have done a lot of test and it’s very hard to optimize the texture memory because we need to remove some imagesheet when they are not use for long…
If we want to reduce the memory size we need to use APNG. APNG is a very good thing and it’s improve quite often. It’s a long time I follow APNG and a lot of system use it now as Google chrome since April
Proper multi-threading or at the very least some form of independent background threads that doesn’t lock the main UI thread. This would be really useful for background saving, game state recalculations, etc.
Currently the “can only do work on a frame” means we are wasting CPU cycles until the next 16 (or 33) ms code slot. It would be useful, for large complicated apps and games to be able to run code continually - this relates to point 1.
“Masked” images to not be such a performance hit.
Simple polygons to be more optimised - like rects are.
A single 1024x1024 icon: the build process creates all the different sizes and automatically creates Images.xcassets.
A way of detecting other packages installed on a device - specifically app crackers like “Lucky Patcher”, etc. Ideally an API to return true is known suspects are installed.
Sublime debugging to actually work (not sure where the responsibility lies there).
Phone manufacturers to stop making sill thin and tall devices. Oh and iPads not to be so square… 16:9 works just fine so why change it?
More resources at Corona to get more cool stuff into Core.
Timer and listener work as transition for pause, stop… with tag and other thing very useful
Listener with low priority, some listener/function who are call/run when the frame rate is at the maximum (30 fps or 60 fps). It’s help to hide the loading and do heavy computation
Have a new clock, one identical for everything (enterframe, timer, transition…) base on a the framerate. Actually when we have timer, transition, sprite, enterframe listener who run at the same time if the app lag(the frame rate go down), the game don’t totally run properly. There will be things who will go very slow and some will run properly.
Sprite could work as transition with call function at the beginning, repeat and end of the animation, with a delay…
I have my own library for all points below and I use them every day. The efficiency of my library are probably very bad and I think it would help a lot of corona user to have them as native corona function. And it will be more intuitive to have transition and sprite who can be run by the same way and also for timer and listener.
Have doc about efficiency of every line of code. For example how much consume a :play() instruction, =display.newImage(…
I do have a luaproc binding, with a basic example here. (Disclaimer mentioned in other thread for another plugin: some of my plugins are due for some maintenance, which I’ll try to scrounge up time for next week. Been carried away with a rather involved side project of late.)
Seen as this is something causing me issues at the moment (and multiple hacky code solutions)
Particle emitters to respect their group when absolutely positioned (see Slack chat on this).
Particles to be automatically resized when their container group is resized.
Whilst we are at it… a particle emitter editor in Core (other environments have this), we shouldn’t have to guess values and/or use websites other apps to simulate what is a core part of modern dev.
More code snippets/modules available. I always start to write them, bit then they blow up into something too big. Things to get people started like open a database, write data, get data, close database.
Looking forward to Marketplace V2
Official map support would be nice, but I get that its tricky when things like Tiled change! On top of that, isometric support would be nice
What I’d really like to make is a live-editor that would allow you to tweak values in-game… but that would require a whole pipeline around it for level creation, reloading, et al. So I think that won’t be happening soon.
If I had this sort of thing available, I could easily see myself making a 3D framework (I did, after all, mention it among the possibilities). I’ve implemented them before; it’s a matter of display hierarchy timing and use of the hardware, rather than know-how.
I do have a software-based polygon renderer (z-buffer and all), but haven’t submitted it as a plugin since it seems to cause simulator crashes on some relaunches (but only on Windows 7, not Mac or Windows 10… or maybe it’s a laptop issue). (I did file a bug report but haven’t heard back on it. Might be ticket #10434840, though I seem to remember the numbers being lower.) I brought this up in some post a long time back, but don’t remember which one.
Of course, if the timing and integration with the display hierarchy isn’t an issue, approaches like Scott Harrison’s SceneKit wrapper are a fine way to go.
that’s all my fault, I only want to prevent developer to loose time with texture packer or other packer software
