Lossless RGBA video compression or other way to process pre-rendered animations

Started by
2 comments, last by krippy2k8 11 years, 10 months ago
So I've got a 2D game that needs to run some large (close to full screen) pre-rendered animations on top of the game graphics periodically.

Currently I just have them as a series of PNG images that are loaded and decompressed when the level is loaded, and then when we need to render them we just flip through the images. This works, but it is far from ideal for our application; we are targeting embedded systems with embedded Intel graphics adapters, relatively slow memory buses and Compact Flash drives, so both the load times and runtime performance is a bit prohibitive for our platform. i.e. a 1024x1024 RGBA animation with 100 frames requires over 400MB of memory, and we have to blit 120+MB per second to achieve 30fps just for the animation, plus it takes 15-20 seconds to load the PNGs from the CF drive and decompress them.

The animations are not dramatic, so I think they would work well with a lossless video compression of some sort. There is not a whole lot of change from frame to frame, and we have plenty of CPU cycles to spare. I have looked at a few codecs like HuffYUV, but the ones I've seen only really seem to work with RGB or YCbCr.

Does anybody know of any RGBA lossless video compression (preferably with a free or inexpensive cross-platform library support)? Or know of another way to accomplish this?
Advertisement
Well... apparently I was wrong and HuffYUV CAN support RGBA. Still open to other suggestions if anybody has any, while I take a look at this ;)
Only store the difference between the frames? That may help the compression algorithm a lot (more likelihood of huge areas filled with 0). It won't help with space usage in VRAM though, assuming you're decompressing the frames in the CPU and not the GPU. Also requires to keep track of the previous frame.

Any reason why it needs to be lossless?
Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.
Technically I didn't necessarily need lossless but it has to be really high quality. I ended up rolling my own very simple system though. The animations are broken down into 64x64 pixel blocks and I only store the blocks that change for each frame. It works good for the animations i have and does save a lot of VRAM because I just modify the texture each frame with the changed blocks. The runtime performance is just as good as storing the entire 400mb animation in VRAM, but I only need a single 4mb texture in VRAM and about 50mb of data in RAM.

This topic is closed to new replies.

Advertisement