Best way to use local variables in the main chunk" area of a Storyboard module?

Solar2D Composer
#21

Here is why there is a difference between Director and Storyboard.

When Lua “require”'s a module, the main chunk is executed once and only once until the module is unloaded completely.  This is a very important feature as it’s how modules retain their data and state throughout your app. Both Directory and storyboard behave this way.  The difference is when Director does a complete unload after it changes the scene.  That it is does an un-require on the scene so the next it it loads it, you get a fresh start.

Storyboard treats scenes a bit differently in that it want’s to keep the scene required and manage it’s assets as memory dictates.  When you leave a scene and it gets purged (either by you purging it using storyboard.purgeScene() or storyboard.purgeAll() or by the system running low on memory)  it just removes assets, it does not un-require the scene.

That is what…  storyboard.removeScene() does.   It un-requires the scene.  If you use removeScene() then your main chunk will re-load from scratch each time.

But this creates extra load on the app to have to dump and reload the scene every time.  You are better off initializing variables in createScene or enterScene where appropriate.

#22

Thank you guys! I appreciate the help. @Larry: so both options would make the app start from scratch at every scene changes. This should allow me to put all my local variables at the top of the module. Correct? @Rob: cool! If I decide to ease up the load on the memory (so using purge instead of remove scene) where is it best to put all those variables use in the game loop? (Create or enter scene) OR does it depend? I will think as Naomi suggested, enter scene since to be best since create scene event will not be called if the scene exist already. Sorry for all these newbie question :frowning: THANKS for taking the time. Mo

#23

It depends.

#24

Cool! Mo

#25

OK, there is still one thing I still don’t understand about all of this.

Suppose I create a local foward reference called ‘enemy’ at the top of a storyboard scene.  Then I assign to enemy a display object.  Then upon exiting the scene I call “enemy:removeSelf().”

Here’s what I don’t get: if I were to then set enemy to nil to clear the lua table, then upon re-entering the scene, enemy would no longer exist (not at all, but particularly not as a local varaible), correct?  Then if I were to once again assign a display object to enemy, I would be creating enemy as a global variable, which would be very bad.

If i do not set enemy to nil, then I carry on with enemy stuck in memory holding a lua table (not as bad as above, but not desirable).  Also, this guide (http://www.coronalabs.com/blog/2013/04/02/cleaning-up-display-objects-andlisteners/)  seems to suggest that if I were to overwrite enemy then I would lose some memory that cannot be regained. (or is this specific to global variables?)

So what is the best practice here?

#26

The variable still exists.  It just contains the value nil instead of a pointer to a table.  That variable is still local.  Still scoped in your module’s main chunk.

Of course  you have to create a new enemy and assign it to your enemy variable.

#27

Awesome, thank you.

#28

…finishing an unfinished thought from earlier…

so storyboard has two (primary) ways you can use it:

don’t purge/remove:  create “static” content and initialize such stuff in createScene once, create or re-initialize dynamic content in enterScene (or willEnterScene - if you want that dynamic content to ready for a transition, if used) which happens each time you revisit, in exitScene you free the dynamic content after each visit, in destroyScene you free the static content once.

do purge/remove:  createScene happens each time you revisit, so both static/dynamic content created/init’d here, willEnterScene typically not needed, exitScene typically not needed, free everything in destroyScene.

benefit of the former is you can potentially keep some stuff like background images, sprite sheets, perhaps some data structures, ui stuff, etc in memory between visits to improve performance.  benefit of the latter is much simpler overall code structure and potentially “cleaner” memory for other scenes due to complete create/destroy cycle.

but there’s a middle ground, because you can do your own caching.  if you have a splash scene, for example, load up those big background images (and etc) into an invisible group stored somewhere “safe” (like globally).  (and similarly for spritesheets/imagesheets if you wish, tho they don’t need to be “in” the display, just referenced)  then, in scenes, instead of calling display.newImage(“bigImage.png”), just group:insert(cache.bigImage), and return it to the cache when done (so that it’s never actually removed/free from the display).

then you’re free to purge/remove your scenes as you wish, while retaining some cached benefits.  but of course, that’s the real trick - figuring out what exactly benefits you most in the memory/speed tradeoff between cached data vs reloading/recreating - neither of storyboard’s two “built-in” extremes are rarely the perfect choice.

just my two cents, hth

#29

…finishing an unfinished thought from earlier…

so storyboard has two (primary) ways you can use it:

don’t purge/remove:  create “static” content and initialize such stuff in createScene once, create or re-initialize dynamic content in enterScene (or willEnterScene - if you want that dynamic content to ready for a transition, if used) which happens each time you revisit, in exitScene you free the dynamic content after each visit, in destroyScene you free the static content once.

do purge/remove:  createScene happens each time you revisit, so both static/dynamic content created/init’d here, willEnterScene typically not needed, exitScene typically not needed, free everything in destroyScene.

benefit of the former is you can potentially keep some stuff like background images, sprite sheets, perhaps some data structures, ui stuff, etc in memory between visits to improve performance.  benefit of the latter is much simpler overall code structure and potentially “cleaner” memory for other scenes due to complete create/destroy cycle.

but there’s a middle ground, because you can do your own caching.  if you have a splash scene, for example, load up those big background images (and etc) into an invisible group stored somewhere “safe” (like globally).  (and similarly for spritesheets/imagesheets if you wish, tho they don’t need to be “in” the display, just referenced)  then, in scenes, instead of calling display.newImage(“bigImage.png”), just group:insert(cache.bigImage), and return it to the cache when done (so that it’s never actually removed/free from the display).

then you’re free to purge/remove your scenes as you wish, while retaining some cached benefits.  but of course, that’s the real trick - figuring out what exactly benefits you most in the memory/speed tradeoff between cached data vs reloading/recreating - neither of storyboard’s two “built-in” extremes are rarely the perfect choice.

just my two cents, hth