Having 200 Sprites of 256x256 RGBA for one character in my game, I meant a Sprite Cache that loads up in ~40 seconds from the cache to openGL cache.
Do you think a Sprite Atlas would break down the load time ?
One constraint is that the java heap should not be increased more than one or two RGBA sprites (that’s 2⁸⁺⁸⁺² = 2¹⁸ bytes / sprite ≃ 256kb / sprite) at a time. Then the cache is max 50 MB uncompressed per character.
Well seems like you could use them in tandem, although in my experience caching raw sprite data (as it appears you might be doing?) ends up being slower than just decoding a PNG. Neither of your two options will break down load time in a significant amount, in my opinion, although with an Atlas you’re only decoding one image so that will help a bit. 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…
Well, in general, as long as all the images in your atlas will be used together (all the images from the same level, all the frames of an animation, etc.), then it is in fact the best to make your Atlas as large as possible. It obviously becomes a waste if you have a lot of dead space in your applet or you have a lot of images that you won’t be using at the same time, but otherwise even if you have a massive texture it’s a better option than a lot of small ones. It will take up the same amount of memory but you’ll have less texture binds.
Another approach is to use the atlas to contain the animating sprite images that are currently being used. I doubt all 200 sprites are going to be onscreen at once, so just move them from disk to cache to atlas as they go into the viewport.
That’s true. I do wonder how they manage to do that sort of thing well, because there’s no question in my mind that at least ImageIO is really quite slow, so that streaming would probably not be very feasible. Then again, who knows? One thing I’m sure you couldn’t do would be loading and unloading some images every single timestep - that would definitely be too slow. But you could probably get away with not loading offscreen tiles and instead pulling them in when you go near.
