Elysian Shadows

So I have been getting back into my programming and have set up the better half of my C++ wrapper/game development framework for the iPhone. The framework is going to be designed to help me create 2d games quickly and as I am using openGL ES creating a sprite system for loading/storing/animating images is pretty important.

I have created a working, if slightly shotty animated sprite system however I'm trying to suss out what sort of approach is better when tackling this sort of things. The two approaches for this sort of a problem I have come up with and implemented are as follows;
*Loading a large series of sprites, each representing a different frame of the animation. Storing and displaying these appropriately (whether by indexing or otherwise placing them in arrays).
*Loading a sprite sheet, then adjusting the texture coordinates so only 1 frame is shown at a time. Then adjusting the texture coordinates being displayed upon going to the next frame in the animation.

The other solution is to load the sprite sheet and then store each frame individualy as in the first example.

Could someone give me a few tips of the kind of logic I should use to create a sprite class that is going to run fast and cost little in memory. I would assume simply shifting the texture coordinates is more costly at runtime, while having a large number of seperate images is more costly on memory and inconvenient.

Thanks in advance for any help you guys can provide.

I'm going to have to recommend the Elysian Shadows approach (of course). Have your sprites belonging to a sheet all be a single image. When you load this image, have some sort of descriptor file (or hardcoded) with the dimensions of each sprite. Using these dimensions (spritesize and sheetsize), precalculate all of your UV coordinates, and put them into a table.

So now you can have a single variable called "frame" which is set depending on the current sprite that you wish to index. So when you are setting your UV coordinates for each quad, you have:

This approach sounds interesting. The current way I was doing the texture coordinates was as followed (note this includes some functionality I haven't yet finished/is hardcoded in):

*You load the sprite sheet with 1 line of code;
loadSprite(id, cellCount, width, height);

*Then you create the animation by creating an array, like so;
int spriteName[3][2] =
{{id, cellCurrent},
{id, cellCurrent},
{id, cellCurrent}};

Then to work out the current sprite to show it cycles through the row currently being viewed selects the id number and finds the equivelent spritesheet. After choosing this sprite sheet it uses the sprites known cellCount, width and height to in comparison with the cellCurrent number to adjust the texture coordinants accordingly.

The advantages of this system are you can load in a few spritesheets that share frames and save memory. But at the same time you are dissadvantaged, as you get somewhat dissorganised sprite sheets if you take advantage of this feature. Theres also some calculation costs, etc. Not to mention that the proportions of one cell and another can be completely different, however the sprite sheet can be accessed regardless.

Do you use some kind of 'animation builder' for creating your descriptor files? Your approach sounds interesting and fast, but at the same time potentially costly to memory if many sprite sheets are used given these things could be calculated on the fly. (That's if I'm understanding your approach right)

I'm sort of getting the impression there isn't a right way to do this from all my research. It seems you will always be trading something else depending on how you base your approach.