Multiple Levels and No More Removing Objects (potential performance issues?)

Games
#1

Hello,

As of Beta 7 there is no more removeSelf() of objects if you plan on using them later within the same app, so instead, you should set the isVisible property to false…

I am currently using Game Edition and know that the new Beta 7 rules are also going to be implemented within that, and I had no problems just setting all objects’ visibility within a group to false when going to another screen, however, I just thought of a potential problem that hopefully someone could put my mind at ease about.

Say you had a game where there were 10 different levels, which is very conservative, and the player is taken to a level selection screen and can play whichever levels they want as long as they “unlocked” them. Meaning, the user can go back and play level 1 or 2 even if they made it to level 10.

Now, if you can’t removeSelf() any of the objects, then wouldn’t it cause MAJOR performance issues having up to 10 levels loaded into memory with 9 of them set to isVisible=false while they are playing the current level? (assuming they unlocked all 10 levels and want to play between them)

Please let me know what the best practices regarding the no removeSelf() rule and switching between game “scenes” or “levels” would be?

Thank you very much. [import]uid: 7849 topic_id: 1665 reply_id: 301665[/import]

#2

Can anyone at Ansca shed some light on this “issue” for me?

To re-phrase and simplify things, my question is…

Because you cannot remove objects that you need to re-use as of Beta 7, how would I load/unload levels without affecting performance when I have a game where users may need to access prior levels again in the same game session?

For example, if the user has made it to level 10, but goes on the level selection screen and wants to play level 1, that means all of the levels would need to be loaded into memory because they might need to be re-accessed again right?

Or is there a better way to do this, where you CAN in fact remove group objects and re-create them later? [import]uid: 7849 topic_id: 1665 reply_id: 4845[/import]

#3

object:removeSelf (in Beta 7 and now in GE Alpha 3) removes an object and free up the display resources. Depending on the objects used, you could have major performance and resource issues if you create levels and hide them instead of removing the objects. One you delete objects (or groups), you are free to recreate the objects again if the user decides to go back to a previous level. If you knew your user may go up one level or down one level in the normal course of playing, you could keep those levels “in memory” for faster performance.

-Tom [import]uid: 7559 topic_id: 1665 reply_id: 4857[/import]

#4

Hi Tom, thanks for the reply, but I’m a little confused about this statement you made:

“One you delete objects (or groups), you are free to recreate the objects again if the user decides to go back to a previous level.”

I thought that as of Beta 7 and GE Alpha 3, you can’t re-create objects if you already object:removeSelf()'d it.

Here’s a small scenario, perhaps you can tell me if it would work alright:

– Level 1 has a forest terrain, so within the Level 1 group is a tree object.

– Level 2 has a desert terrain, so there is no need for the tree object.

When the player completes Level 1, all of the level 1 objects are removed to free up resources and Level 2 is loaded up. Once the player completes Level 2 and is taken to the level section screen again, am I free to recreate the Level 1 objects (such as the tree that wasn’t needed for Level 2) even though I removed them?

Thanks again for your response, if you can clarify the above, I think that will give me a much greater understanding. [import]uid: 7849 topic_id: 1665 reply_id: 4859[/import]

#5

I think I see the confusion here: to be clear, you can ALWAYS re-create an object you have removed, if by “recreate” you mean “loading the graphic again”. There is no restriction on that.

In the older system, graphic memory (aka “texture memory”) wasn’t freed immediately when you removed a display object in Corona. Instead, it was held for several seconds, in case you happened to re-use the same graphic. This saved on reloading time, since the graphics loading pipeline on iPhone is slow. However, it led to using up all available texture memory if there were a lot of objects being rapidly created and removed, because you could outrun the memory freeing process.

In the new system, texture memory is retained only until the end of a code chunk (such as a function call). So you can remove and reinsert an object immediately, such as when restacking objects in a group, but if you remove an object and wait any longer than “immediately”, the texture memory is freed and the image will have to be loaded from scratch again next time.

This isn’t a problem, since you can always load the image again whenever you want. It just means that behind the scenes it will have to go through the texture loading process each time, rather than having an automatic short-term “cache” for the images.

In most cases, the new behavior is better, since texture memory is the most precious and limited resource on mobile devices: usually there’s only 10MB - 20MB in total. [import]uid: 3007 topic_id: 1665 reply_id: 4865[/import]

#6

@evank: this line summed it up for me:

“…but if you remove an object and wait any longer than ‘immediately’, the texture memory is freed and the image will have to be loaded from scratch again next time.”
The fact that you CAN load an image from scratch basically confirms to me that I can completely remove all objects in a level that’s not being used, and reload them later if the user plans on returning to that level.

Thank you very much for the clarification… I feel much better now! [import]uid: 7849 topic_id: 1665 reply_id: 4866[/import]

#7

Thanks Evan for clearer clarification.

I would like to point out that if you remove an object, you MUST recreate it again. The documentation for pre-beta 7 shows removing the object and assigning it to a variable that could be used to re-insert the same object later. That’s no longer the case. Removing an object strips it of it’s display properties as well as any texture memory it was using. The display object may still exists (until Lua’s garbage collection removes it) but it will look like a normal “table” object without consuming any display resources. This was done to help manage memory consumption.

Again to restart what Evan said, you are free to re-create objects that were previously removed. You should always assume that if you remove an object, it’s no longer available for use and you need to re-create if you need to use the object again.

-Tom [import]uid: 7559 topic_id: 1665 reply_id: 4871[/import]

#8

So this wasn’t really an “issue” for me at all come to find out. Before the Beta 7 features were announced, I always assumed that if you removed an object it would be unusable until you created it again.

I guess all the Beta 7 stuff somehow just got me confused… now things just make sense lol

Thanks for the clarification guys and for sticking with me through it. [import]uid: 7849 topic_id: 1665 reply_id: 4877[/import]

#9

Right – I think we used to use the term “re-create” in our documentation to mean “storing in a temporary 5-second cache and restoring it again”. Now that cache is gone, essentially. [import]uid: 3007 topic_id: 1665 reply_id: 4891[/import]