Things I'd like to see in Corona (feel free to add sensible ideas)

Solar2D General Questions/Discussion
#1

Posting here for @Rob

  1. No performance hit from masked images.  Currently I have to add an invisible rect over the top for hit testing which adds some 20k additional display objects.

  2. We can alpha a group but not apply fills/effects to a group.  This seems like a simple thing to add.  The amount of times I have to iterate a group applying fills is silly.

  3. Generic polygons to not suffer in performance compared to rects.

  4. Access to the frame buffer to apply effects to the entire scene - much like a snapshot does.  It is not practical for me to render my entire game to a snapshot for this - I have tried and performance was terrible.

  5. Have Facebook work on sim - Unity has managed this.

  6. A shader editor would be amazing.  I mean in game not on web.  I am sure most games could benefit from some eye-candy but this is really difficult in Corona due to the bespoke values (like CoronaTotalTime, etc).  Failing that use standardized shader language so we can copy and paste from other languages/shadertoys/etc

7.  Why can we not set maxParticles (for an emitter) in code?  I have so many definitions for different values! 

  1. Fix the Facebook bug that breaks builds every so often
#2

I only have a few minor annoyances.

  1. Ability to easily delete system preferences. I had to revert to text files for things like ‘hasRunBefore’ because even if you cleared out ApplicationSupport to simulate a new install, the preferences would still be hanging around. So you’d have to do a build with a flag to clear it out, then another to take the flag out.

  2. Fix TableViews/ScrollViews crashing on builds uploaded to Steam. It’s good that the bugs in the built-in widget library were fixed but I still have to use the Github version, which makes for an untidy project structure. You can make a build, run it and it works fine, upload to Steam, download again and it will be broken. 

  3. Better control over resolutions/window resizing on desktop builds. A little dialog that pops up like on Unity games would be fantastic, currently there’s so many things users can do to screw up their window that I have no control over, but I still need to support resolutions anywhere from 1024 x 768 to 3440 x 1440.

#3

I’m with Nick concerning his #3 point and I have a few other things I’d need for desktop builds.

I have a few desktop games in mind, but before I get to them, I NEED the ability to control things such as:
 

  1. have the ability to limit the movement of the mouse to within the app window. This’d be self-explanatory with FPS games, but imagine a tile based game with massive maps, e.g. 1000 by 1000 tiles that are 64 pixels by 64 pixels each. If the game had a rudimentary camera that tracked the mouse’s location and moved the tiles accordingly, you couldn’t move far because the mouse would move outside of the app window. This becomes especially annoying when playing fullscreen or windowed fullscreen and when your mouse slides to another display without you realising it. Some games simply require the ability to keep the mouse locked inside the app window.

  2. have the ability to change resolution via code. Being able to offer the user certain predetermined resolutions from the aforementioned 1024 x 768 to 3440 x 1440 range, for instance, and then having the app use it would be essential. I dislike the idea of letting my users drag and resize the window freely. I’d just want to let them pick from predetermined ones.

There may be some Windows/MacOS limitations that prevent this from happening during runtime, but in such cases we could always fall back on the good old “You’ve made some changes. You need to restart the game for the changes to take effect.” dialogue box. Change the app from windowed to fullscreen and from 1024 x 768 to 1920 x 1080? Just restart the app and enjoy!

 

#4

re nick’s 3) and xedur’s 2):  a “foundational” piece that’s missing is the ability to change content dimensions at runtime.

because once you “get” that content coordinates just define a scaling factor between virtual content pixels and physical device pixels, you’ll realize that IFF you were able to change window size programatically, you might also then want/need to change content dimensions dynamically as well.

granted that simple letterbox-extending will handle the vast majority of use-cases, but it cannot handle them all.  this is particularly true when doing “pixel” -type displays where you really want an integer scaling factor.  if you go to the trouble of calculating those magic values before run (in config.lua), it’s based on the assumption that device dimensions will remain static*.

* or, at least, not change on more than one axis.   fe, as happens with android immersive, which can be accommodated as long as the other axis remains fixed, and one just “extends” – retains same integer scaling factor overall.

as we’re all painfully aware, not all devices are 4:3, 3:2 or 16:9 aspect ratio.  and all bets are off with resizable windows.

so if you change the device (aka window) dimensions you may want/need to recalc your content dimensions to again end up with an integer scaling factor.  (it really depends on each individual app as to exactly what it’s capable of responding to)

…and, once you’ve pondered that, you might even come up with a desire to be able to change the scaling mode at runtime.  (start thinking about drastic aspect ratio changes - where your “portrait” design is now running in a “landscape” window - in one case you might want letterbox to bleed new content space into your “long” axis, but in the other case you might prefer scaleEven to bleed excess space off your “short” axis)

…and, once you’ve pondered that, you might even come up with a desire to be able to change the x/y alignment at runtime.

…and, the ability to programatically set full screen, enable/disable min/max buttons (if still windowed at full screen), etc

basically, everything that you can setup in config.lua would be useful to be able to alter at runtime, in support of being able to change window dimensions at runtime.  otherwise, the ability to change window dimensions alone would be a mixed blessing at best.

essentially, if you offer something like:

  system.setWindowSize(w,h)

then you need (at least) something like

  display.setContentSize(w,h)

to go along with it.

fwiw

#5

Just give me a non-background text box in Windows and I will be happy

#6

I only have a few minor annoyances.

  1. Ability to easily delete system preferences. I had to revert to text files for things like ‘hasRunBefore’ because even if you cleared out ApplicationSupport to simulate a new install, the preferences would still be hanging around. So you’d have to do a build with a flag to clear it out, then another to take the flag out.

  2. Fix TableViews/ScrollViews crashing on builds uploaded to Steam. It’s good that the bugs in the built-in widget library were fixed but I still have to use the Github version, which makes for an untidy project structure. You can make a build, run it and it works fine, upload to Steam, download again and it will be broken. 

  3. Better control over resolutions/window resizing on desktop builds. A little dialog that pops up like on Unity games would be fantastic, currently there’s so many things users can do to screw up their window that I have no control over, but I still need to support resolutions anywhere from 1024 x 768 to 3440 x 1440.

#7

I’m with Nick concerning his #3 point and I have a few other things I’d need for desktop builds.

I have a few desktop games in mind, but before I get to them, I NEED the ability to control things such as:
 

  1. have the ability to limit the movement of the mouse to within the app window. This’d be self-explanatory with FPS games, but imagine a tile based game with massive maps, e.g. 1000 by 1000 tiles that are 64 pixels by 64 pixels each. If the game had a rudimentary camera that tracked the mouse’s location and moved the tiles accordingly, you couldn’t move far because the mouse would move outside of the app window. This becomes especially annoying when playing fullscreen or windowed fullscreen and when your mouse slides to another display without you realising it. Some games simply require the ability to keep the mouse locked inside the app window.

  2. have the ability to change resolution via code. Being able to offer the user certain predetermined resolutions from the aforementioned 1024 x 768 to 3440 x 1440 range, for instance, and then having the app use it would be essential. I dislike the idea of letting my users drag and resize the window freely. I’d just want to let them pick from predetermined ones.

There may be some Windows/MacOS limitations that prevent this from happening during runtime, but in such cases we could always fall back on the good old “You’ve made some changes. You need to restart the game for the changes to take effect.” dialogue box. Change the app from windowed to fullscreen and from 1024 x 768 to 1920 x 1080? Just restart the app and enjoy!

 

#8

re nick’s 3) and xedur’s 2):  a “foundational” piece that’s missing is the ability to change content dimensions at runtime.

because once you “get” that content coordinates just define a scaling factor between virtual content pixels and physical device pixels, you’ll realize that IFF you were able to change window size programatically, you might also then want/need to change content dimensions dynamically as well.

granted that simple letterbox-extending will handle the vast majority of use-cases, but it cannot handle them all.  this is particularly true when doing “pixel” -type displays where you really want an integer scaling factor.  if you go to the trouble of calculating those magic values before run (in config.lua), it’s based on the assumption that device dimensions will remain static*.

* or, at least, not change on more than one axis.   fe, as happens with android immersive, which can be accommodated as long as the other axis remains fixed, and one just “extends” – retains same integer scaling factor overall.

as we’re all painfully aware, not all devices are 4:3, 3:2 or 16:9 aspect ratio.  and all bets are off with resizable windows.

so if you change the device (aka window) dimensions you may want/need to recalc your content dimensions to again end up with an integer scaling factor.  (it really depends on each individual app as to exactly what it’s capable of responding to)

…and, once you’ve pondered that, you might even come up with a desire to be able to change the scaling mode at runtime.  (start thinking about drastic aspect ratio changes - where your “portrait” design is now running in a “landscape” window - in one case you might want letterbox to bleed new content space into your “long” axis, but in the other case you might prefer scaleEven to bleed excess space off your “short” axis)

…and, once you’ve pondered that, you might even come up with a desire to be able to change the x/y alignment at runtime.

…and, the ability to programatically set full screen, enable/disable min/max buttons (if still windowed at full screen), etc

basically, everything that you can setup in config.lua would be useful to be able to alter at runtime, in support of being able to change window dimensions at runtime.  otherwise, the ability to change window dimensions alone would be a mixed blessing at best.

essentially, if you offer something like:

  system.setWindowSize(w,h)

then you need (at least) something like

  display.setContentSize(w,h)

to go along with it.

fwiw

#9

Just give me a non-background text box in Windows and I will be happy