The real advantage of a sprite atlas is that, if you're smart in implementing them, you can end up with 3 or 4 texture binds per draw step instead of 50 or 100 or more. Texture binds have a high overhead, so keeping everything in as few textures as possible is a large advantage.
That's what I thought about atlas mode. Indeed, it'll end up in one big texture for a animation set... But that means the bigger the single sprite frame is, the biggest will be an atlas texture.
I mean I have 200 sprites I'd store in one big atlas file. The texture will be 100x256 squared, which leads to a 25k texture, hence impossible to fit in the gl standard cache (limit is 4096 squared texture size on a geforce 6200). lol ! An animation of 1 sec long, at 24 fps would be 12x256 squared ≃ 2400 px large... that may be thinkable.. but 2400 is a 2Mpx texture, which should be raw-tiled in say 128px² tiles and behave like decoding 24 small png to textures.
I'm currently using a so-called Sprite cache to store the data from one run to the other, not actually to use it in a real-time render. yet I cannot use the atlas mode for it .. .(
maybe I should use the atlas for small sprite stores, like menu icons or small background patterns. As you said, a mix of both worlds would be fine..
thank you demonpants !