[SDL] SDL_image and memory

Waltzer George george.waltzer at gmail.com
Tue Sep 19 05:52:21 PDT 2006


Hi 2u,

I'm also new, newetheless I think I can answer to your question:
NO.

It's a great thing to try using png, I also looked for a format that permits
me freedom, no licence stuff.. but:

regardless of your picture format, you will want in the end to have a plain
uncompresed picture in memory in order to work with it. So, you wil gain a
lot of space economy, but on HDD.
not on RAM.

If you want, you may load them into memory and afterwards when you need to
work on one of them, decompres it with reading the PNG file from memory.

You could read as many png pics into memory as you want (or have) with
SDL_RWFromFile() and afterwars, use IMG_LoadPNG_RW() when you need it
decompresed.

So, as a summary: If you want all your pics in memory, available to work on
them, then you gain nothing, just lower hdd space for your program.

However, if you process one at a time, read them how they are in memory,
compresed.. and just before using/working on one/each of them,
decompres(IMG_LoadPNG_RW) it before and release the memory(or reuse it for
another png..)

Hope it helps.

george.


On 9/19/06, benang at cs.its.ac.id <benang at cs.its.ac.id> wrote:
>
> Hi, I wanted to ask about SDL_image. Currently my application didn't use
> SDL_image so the image were loaded from a bmp file. I'm just wondering if
> I used png and loaded it with SDL_image, would the memory allocated for
> the surfaces be much fewer than if I used bmp? The reason I'm trying to
> switch to SDL_image is because my images now are more than 600 megs in bmp
> format. So, if all were to be loaded into the memory, I think it's not too
> efficient.
>
> Thanks in advance.
>
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
>



-- 
george
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060919/d209f5eb/attachment-0008.htm>


More information about the SDL mailing list