I suspect there's more to it than that. For example, I seem to recall that PNG uses deflate compression, which copes with repeated blocks of data very well. So if you have an animation of ten frames in which only 50% of the sprite changes, then you have 50% of the sprite remaining the same from frame to frame; if you're packing all those frames into the same image, then it can back-reference the previous frame's data when it gets to some of that similar data and not repeat it; something it can't do if the repeated section is in an entirely different file.
Yeah, that's absolutely true. If you had very redundant sprites you could easily see huge savings from that. I haven't really quantified how much savings is due to capitalizing on redundancy on the sprite sets I tested with, but in any case packing seems to modestly reduce the space used for images on disk, not increase it. Of course, this isn't really a side effect of packing as much as just putting all of your images in one PNG file.
Not necessarily! OpenGL tends to demand texture sizes are powers of 2, for example - so it you have a 65x65 sprite, then OGL will need a 128x128 texture to keep it in, 'cause it's just too big for the next size down, 64x64. If you use a 512 texture size and pack as many 65x65 textures as you can, you get 49 sprites on that one texture (7 < 512/65 <
. 49 sprites as separate textures would normally occupy (49*128*128=) 802816 * bpp bytes of memory; a single 512x512 texture occupies (512*512=) 262144 * bpp bytes of memory. That's a two-thirds saving!
Of course, that's an extreme example, a sprite one pixel too large in each direction to fit into a power-of-two size, but it illustrates the point nicely. ;-)
Yes. if you're padding your frames to be able to load them into a power-of-two textures you can stop doing that with this. I was assuming the sprites were already in some square power-of-two format like 64x64 -- i.e., you were previously loading them directly into textures without padding, and then switched over to this. Basically, any runtime memory savings will come from reducing redundant padding, whether it's being excised from the source frames, or whether you're removing the need to pad textures out to power-of-two sizes.
That said, modern graphics cards cope well with rectangular, non-power-of-two textures, from what I understand, but you have to fiddle with extensions (in GL at least) and maybe get a runtime performance hit -- I'm not sure what the cost is since I've managed to avoid having to use them. I think the support is mainly there for things like video rendering.
Anyway, thanks, you just gave me a couple more "marketing" bullet points