I’m getting started on rolling some code for sprite animations (finally, oyie), and a question occurred to me that I’m not experienced enough to answer.
So, I’m going to have sprites, with a possibility of maybe 5-10, 2048x2048 textures for sprite sheets. - I haven’t ironed out how I’m lining up sheets just yet, but I’m just going to consider this maximum case first. Now, it’s not going to be super-crazy on screen, so maybe 5-20 sprites on the screen at any given moment. This starts to add up pretty quickly if I pre-load the textures, with that math, I’d be sitting around 200 textures in the worst case.
Would I be better off loading textures on demand? As in, store the animations with a reference to a texture location and just grab a new sheet when it’s needed? Or can the engine (heh, or hardware), even handle this many textures in memory?
The only thing I’m worried about with the first answer is possible delay on disk access grabbing the texture when it’s needed, since that operation is costly…
Mah sprites are too detailed heh! Makes me wonder how they did large detailed sprites back in the SF2 or Mortal Kombat days…
10, 2048x2048 sprites is about 160 MB. If you’re using all 10 of them in any one frame at a time, you’ll hit the limit when it comes to sprite size with GPUs with 128 MB memory or less.
With DXT1 texture compression you can reduce that size to 20 MB (it has 1:8 compression ratio).
hmmm. And with DXT1 I’d likely need a decoder I presume? *Goes to look at what craziness that entails… ;p
Actually, does it help at all if the textures are indexed color or are they converted to a higher palette when they hit the hardware? In otherwords, most of the sprite textures will have low color palettes and I should be able to fit them into GIF if I really wanted to (256 colors) with no compression or color loss as the sprites are hand-drawn, so I’ve got total control over the palette size. Does that make any difference on the memory hit?
You don’t need anything for DXT1, you can use a free ATI tool called “Compressonator” to generate DDS images which contain DXT data, those can be loaded directly by jME3. The data is stored and used as-is on the GPU so there’s no need to decompress it when sending, this is why its a lot more efficient to use them.