@MrMooseAZ
- About SpriteSheets
Spritesheets are a best practice for most of the games, but not for all of them. Use spritesheets if you don’t have “levels” in your game (e.g. Flight Control, Fruit Ninja) or if you have levels that last for some seconds of gameplay (e.g. Angry Birds) and involve a significant subset of your total assets (>5%).
Don’t use spritesheets if your game has micro-levels with minimal graphics (e.g. Moron Test) and a demand for very quick transitions among them (no loading screens). In this case your spritesheet(s) would be the total of all your assets (to avoid loading screens) and should be loaded in memory for the whole session: pure waste of memory! So, you would prefer to have traditional images that would keep the texture-memory low in-play and this way you would retain the option to have as many levels (assets) as you want, without being constrained by the total memory-size of your spritesheet(s).
2) About Memory Management
Corona has no memory issues by its own, but you should be very careful with your Lua code. Except of selecting the proper graphics presentation method for your assets (images/spritesheets) I would advice you to use the following technique:
a) Make a scene management module or use the Director class (but be sure to understand the code and if necessary to change it according to your needs)
b) Make a testing project with 3 scenes. Write some code to your main or ideally to a “controller” module so that you can manage the flow between the 3 levels. Make them empty in the beginning and just place a button to proceed to the next one (with calling a “nextLevel()” function from the controller.
c) When changing screens (levels) have a print message that outputs the Lua memory used. Make some cycles through your levels (with tapping the buttons in them). Collect prints for about 4-5 cycles at least. Spot the number for the first level.
YOU WANT THIS NUMBER TO BE THE SAME IN ALL YOUR CYCLES
…or at least to flunctuate around a value (but not to be increasing!).
The method above is a guarantee that your code doesn’t leave garbages that the Garbage Collector cannot delete (memory leaks).
Throughout your development cycle, test your code within this sort of cyclical memory testbed. Don’t abandon it!
In case you opt for using spritesheets (which is the most probable) you can be sure that SpriteGrabber passes this cyclical test without leaving garbages.
[import]uid: 7356 topic_id: 5979 reply_id: 21169[/import]