Static images from sprite sheet?

No big surprise, I am also new to this SDK and am trying to build an iPhone application. Hopefully someone can point me in the right direction here as I presume this is a fairly newbie question.

I am particularly interested in the use of sprite sheets to supply some of the graphical elements in my application. I do not intend- at the moment- to use animations or animated sequences but rather, to place smaller UI elements and other interface graphics (buttons, logos, pictures, etc) onto a sprite sheet and display them when necessary. Keeping best practices and memory management in mind, I suppose my question is two-fold:

  1. Is it better to load a single larger image and use single-frame non-animating sprites to display them when needed?

  2. If so, what is the most efficient code to accomplish this?

Since it’s not my intention animate these elements, we can assume the graphics are arranged on the sprite sheet but possess different and varying frame sizes. Ultimately, my goal is to provide a retina-quality user interface and minimize texture memory, especially since memory issues seem to be quite a trending topic around here.

Any guidance is appreciated.
[import]uid: 15934 topic_id: 5979 reply_id: 305979[/import]

  1. better than what?

[import]uid: 6645 topic_id: 5979 reply_id: 21054[/import]

…better than using separate images for each graphical element? Since posting this thread, I have switched to and implemented a sprite based solution utilizing the SpriteGrabber library. Since I can pack a ton of images into a sprite sheet, this seems the more logical way. I’m still open to advice to the contrary as I want to produce a memory and texture efficient application. Would be nice to avoid some of the memory management and performance issues I’ve read about around here. [import]uid: 15934 topic_id: 5979 reply_id: 21069[/import]

@MrMooseAZ

  1. 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]

Thank you for your very thorough response. I appreciate everyone’s willingness to share and exchange ideas. That said, I already have the director class in place but plan to add a simple memory test, per your suggestion, to ensure there aren’t any leaks. As for the graphics, it seems I fall somewhere in between your examples. I certainly have a strong case to use sprite sheets though and will probably stay that course. Thanks.

[import]uid: 15934 topic_id: 5979 reply_id: 21182[/import]

Heya,

I’m at the same place you were. My experience tells me that using sprite sheets is probably the more efficient approach over loading lots of individual graphics. How did it work out for you?
[import]uid: 11757 topic_id: 5979 reply_id: 25482[/import]