Compressing/decompressing Image Data In Real-time

[hessiess]

I have a 2D game which is currently written using Irrlicht, and am thinking of re-writing in SDL. An ongoing problem Ive had with it is the very high ram usage(around a gig), this is partly caused by Irrlichts power of 2 limitation(hence re-writing in SDL), requiring the use of a large amount of padding on some images. The other problem is that I want everything to be non-pixalated and have smooth animations, which means that I have a lot(800~900) of large alpha-channel images. currently the game renders at 1280*800.

I was wondering is if it would be possible to store the images compressed in ram, and only decompress the images relevant to the current frame in real time. What would be the easiest way to implement this(zlib?) and how would it effect the performance on less powerful devices sutch as the Pandora.

Also, what video decompression libs will be available on pandora? I assume FFmpeg?

 

[sinoth]

I'm not sure why you would store the compressed images in RAM. Why not just store it on disk and load when necessary, and be sure to unload when no longer needed? As you've mentioned, you may not have to worry about the power-of-two limitation with SDL on Pandora, but it all depends on the GPU. If for some reason you can't escape the problem, you could always restructure your images to be a larger power-of-two and shove all the animations in one image. Not a wonderful solution but definitely works

If you do decide to use the compression, zlib is definitely the way to go. I've used it before and it works quickly and easily, just not sure how much of a drain it is on a weaker system.

 

[Zoxc]

If you want to use compressed textures, you should use some format supported by the GPU. Compressed textures is supported by OpenGL and it's also handy for rotations. If you still get memory problems you should try dynamically loading and unloading the textures.

SDL could be used if the removal of the padding alone solves you memory problems and you don't need hardware rotations.

 

[Svartalf]

If you want to use compressed textures, you should use some format supported by the GPU. Compressed textures is supported by OpenGL and it's also handy for rotations. If you still get memory problems you should try dynamically loading and unloading the textures.

SDL could be used if the removal of the padding alone solves you memory problems and you don't need hardware rotations.

I'd have to concur with Zoxc here. Compression does not come without price to it. If you want to limit what your memory profile is with the compression stuff, I'd recommend looking at liblzo. Unfortunately, for many people, LZO, while impressive (Low memory consumption, near Zip-like compression levels, etc.), is GPLed instead of BSDed or LGPLed, with all the consequences thereof. Anything else will require much more RAM and CPU use than is probably practical.

The truth be known, your resolution and your NPOT issue combined is probably the real source of your problems. Lower it to 800x480 and find other answers for the NPOT issue, and you will probably fit nicely within the 256Mb profile on the Pandora.

As for video compression, right now it's up in the air what'll be there and what won't- we don't want to be violating people's patents with the baseline stuff (What people do with it past the baseline firmware is their own lookout...). ffmpeg is easy enough to move over and it's library is something you could encapsulate as an LD_PRELOAD or an LD_LIBRARY_PATH link-up if it's not there on the firmware.

 

[hessiess]

If you want to use compressed textures, you should use some format supported by the GPU. Compressed textures is supported by OpenGL and it's also handy for rotations. If you still get memory problems you should try dynamically loading and unloading the textures.

SDL could be used if the removal of the padding alone solves you memory problems and you don't need hardware rotations.

I'd have to concur with Zoxc here. Compression does not come without price to it. If you want to limit what your memory profile is with the compression stuff, I'd recommend looking at liblzo. Unfortunately, for many people, LZO, while impressive (Low memory consumption, near Zip-like compression levels, etc.), is GPLed instead of BSDed or LGPLed, with all the consequences thereof. Anything else will require much more RAM and CPU use than is probably practical.

The truth be known, your resolution and your NPOT issue combined is probably the real source of your problems. Lower it to 800x480 and find other answers for the NPOT issue, and you will probably fit nicely within the 256Mb profile on the Pandora.

As for video compression, right now it's up in the air what'll be there and what won't- we don't want to be violating people's patents with the baseline stuff (What people do with it past the baseline firmware is their own lookout...). ffmpeg is easy enough to move over and it's library is something you could encapsulate as an LD_PRELOAD or an LD_LIBRARY_PATH link-up if it's not there on the firmware.


I don't mind using GPL libs, as im intending to relece the game under the GPL anyway, that's if I ever get around to finishing the darn thing of course .

Sticking all the frames if an animation into one image would reduce the memory needed if all the images were crammed in as close as possible, but this may make extracting the images hard because they are unlickly to be in any regular grid. which would require a bunch of extra co-ordinate data for storing the location of each frame.

Wouldn't dynamically loading the images cause the game to pause every time an image is loaded?

I don't need rotation, but scaling would be necessary if i re-rote it in SDL, as it would ether have to render at a fixed resolution then resize to fit the screen. or resize all of the images to fit the resolution.

 

[sinoth]

Wouldn't dynamically loading the images cause the game to pause every time an image is loaded?

If the load function is blocking it would. However, if you wanted to get fancy you could do a sort of 'lazy' texture loading by spawning a separate thread specifically for loading textures so your game logic doesn't suffer. Not sure if this would work for your game though, as it would require some prediction on when a texture is needed or else you'd have to stick an ugly placeholder image on screen while the real one is loaded.

 

[Svartalf]

I don't mind using GPL libs, as im intending to relece the game under the GPL anyway, that's if I ever get around to finishing the darn thing of course .

Then you should look at the lossless algorithm there in liblzo- it's going to be the closest thing to bringing most of what you're looking for without the penalties you're going to find with memory footprint and overall speed if you use gzip or bzip2. While you can get "higher" compressions with those two, they have a higher memory overhead and burn vastly more cycles, which can cause it's own set of pain on things.

QUOTE

Sticking all the frames if an animation into one image would reduce the memory needed if all the images were crammed in as close as possible, but this may make extracting the images hard because they are unlickly to be in any regular grid. which would require a bunch of extra co-ordinate data for storing the location of each frame.



Yeah, that'd make it messy.

QUOTE

Wouldn't dynamically loading the images cause the game to pause every time an image is loaded?



Depends on how you load and if you cache portions of the decompressed stuff in a RAM pool that's what's rendered from.

QUOTE

I don't need rotation, but scaling would be necessary if i re-rote it in SDL, as it would ether have to render at a fixed resolution then resize to fit the screen. or resize all of the images to fit the resolution.


Scaling's going to be needed on the Pandora for your title if you're at the screensize you're claiming. Your resolution doesn't fit the native one on the Pandora for starters.