Next Game Edition Version and Beta 7 New Features

Games
#1

I noticed in the Corona SDK 2.0 Beta 7 there is no longer the ability to removeSelf() and then re-create that same object later on. Instead, it is recommended to set the .isVisible property to false if you plan on re-using objects.

I was wondering, are future versions of Game Edition going to include that rule as well?

My concern is that in many games, removing and re-creating objects is a VERY common task (e.g. respawning enemies and/or projectiles). If that will be included in future Game Edition builds, what is the recommended path for spawning/respawning enemies?

Currently, when a player touches an enemy, it is set to :removeSelf() and I have a timer that is continuously spawning them. If the ability to re-create the same objects is removed, then do you recommend just having a fixed amount of enemies on-field (using separate variables) and then just setting them to [isVisible=false] and moving them to where they would normally respawn?

I just need to know if re-insert()ing is going to be removed from Game Edition as well because if so, I have a lot of preparation to do with my Game Edition app.

Thank you very much… [import]uid: 7849 topic_id: 1568 reply_id: 301568[/import]

#2

The short answer is that yes, Game Edition will inherit all the current SDK Beta features, and we’ll do our best to keep both products synchronized.

Regarding your case, the reason you could re-create objects after a removeSelf() was that the texture cleanup was previously only happening every few seconds or so. As of Beta 7, the texture cleanup happens immediately, which leads to much better memory management. This also leads to more logical behavior overall, since removed objects now actually go away, rather than just going away from the Lua point of view and doing actual “heavy data” removal at some later time.

However, if you literally just want to remove and respawn the same game object, then shouldn’t the isVisible switch basically do what you want? Maybe I’m misunderstanding – does the object reappear immediately, or is there some down time where it shouldn’t be anywhere?

Also note that multiple objects with the SAME graphics will share the original texture memory, so it should also be possible to create brand-new copies on the fly, without any real penalty. See the “ManyCrates” sample code for a quick example.

[import]uid: 3007 topic_id: 1568 reply_id: 4474[/import]

#3

Thank you very much for the clarification, it’s not that I had a problem with it–in fact, if it helps with memory management and all then I’m all for it, I just wanted to know ahead of time so I know what direction to take my code.

But to answer your question, the enemies sort of come in “waves” and come up based on a “spawn rate” so yeah there are periods AFTER the enemies are destroyed that they aren’t anywhere on the screen. I’ll just have to come up with a pre-defined number of enemies and set them to .isVisible=false when they are “destroyed” and just have some kind of switch that determines when they appear again.

I do have a few more questions though:

  1. How do you make new “copies” of an object, especially an indefinite amount of copies, without re-using the same variable for that object? Or are you just talking about completely different objects that use the same image?

and the more IMPORTANT question…

  1. When you set an object to isVisible=false, does it still use memory? For example, if I have a group called gameGroup that holds all objects for in-game, and I have a gameOverScreen group that holds all the objects (buttons, etc) for a “retry” screen… When I set all the objects in the gameGroup to isVisible=false, wouldn’t it still be using a lot of memory for all of those objects? Or does isVisible=false somehow free up memory so it doesn’t slow the program down?

I guess the reason why I was removing objects and re-creating them before was mainly for when I switch between screens in the game… I thought it would slow down the screen that’s showing having a lot of objects that need to be re-used still loaded… Unless isVisible=false really does free up available memory and doesn’t slow things down…

If that’s confusing I can explain more, but thanks again for your response to my previous questions… [import]uid: 7849 topic_id: 1568 reply_id: 4514[/import]

#4

  1. You can’t directly copy an object… you create other objects with the same image (texture memory) or specs (parameters for vector objects for example)

  2. If you set visibility to false it still uses the same amount of memory as before.

And more general:

Using memory does not necessarily mean that somethings slows down. Usually the opposite is the case! It is pretty common nowadays to trade space for processing time.

Desktop computers slow down because they use virtual memory which gets swapped to the harddrive eventually. The mobile devices may get slow because you may have to free and reallocate memory because your objects does not fit into memory at once.

Having objects in the display hierarchy and just “isVisible=false” may slow down processing because even if it does only need to check “isVisible” it still has more objects to traverse than without them.

BUT… I have all my objects “invisible” off screen usually and do not notice a slow down. I think you need a looooot of objects for such engine to really slow down. Traversing a list and checking a flag is lightning fast and a basic approach in every gui and game system. This is “Corona” and what they excel to expose to us for usage!

At the same time… destroying and recreation of object may be very fast and with less overall overhead than complicated “object reusage” you write yourself in Lua…

Actually I think the change in Beta 7 does not change the overall performance but brings a lot more stability and… make people think about the different kinds of objects they use and what to reuse and what to allocate/deallocate.

The old system did even “harm” programmers which plan exactly what to do because it was uncertain how stuff works and was problematic in certain cases.

I remember that looooong discussion about the memory problem I posted as problem and how hard it was to proof and explain what I thought is a problem. I am glad that I did, because I believe that was part of the reasons to change to a more stable and transparent system regarding background memory (de)allocation. [import]uid: 6928 topic_id: 1568 reply_id: 4535[/import]

#5

To be clear, objects where isVisible=false won’t usually slow the program down, since they aren’t part of the drawing cycle, which is the most likely bottleneck for a complex application.

As OderWat says, just taking up more available RAM doesn’t cause slowdown (until you run out of texture memory and start swapping textures back and forth between texture memory and main memory, which will slow everything down A LOT). So you definitely want to manage how many graphics you have loaded at once, including invisible objects, but assuming that’s under control, an invisible object should be basically “free” from a performance standpoint.

The same goes for offscreen objects, which also aren’t part of the drawing cycle.

Also, in the case where different objects use the same image, things get a lot easier, since your most important resource (texture memory) is already being conserved by re-using the same texture data. That makes memory issues a lot less urgent in general. [import]uid: 3007 topic_id: 1568 reply_id: 4548[/import]

#6

Wow thanks a lot for the great responses, I learned a lot from them (and I’m sure at least a few other people did too).

Based on what you both said, I’ll start changing my code to “prepare” for the Beta 7 changes to occur in Game Edition and I’ll even load the textures I’m going to use over and over from the very beginning.

Thanks again! [import]uid: 7849 topic_id: 1568 reply_id: 4550[/import]