Fast IMG Load

SDL Development
1

Hi everybody!
I need to load a lot of images using too much memory space when loaded:
152 images, 35kb each but in memory they are much bigger because of
image uncompression and byte alignment.
My idea is to read all the image data compressed in png format in memory
and load the images from memory instead of disk.
Thanks!

2

I need to load a lot of images using too much memory space when loaded:
152 images, 35kb each but in memory they are much bigger because of image
uncompression and byte alignment.
My idea is to read all the image data compressed in png format in memory
and load the images from memory instead of disk.

The only way this would take less space than just loading the images
would be keeping the compressed data in memory and decompress it on the
fly while blitting. I bet that’s too slow to be of any practical value :
(

3

i think he means it would be faster if the raw file was loaded into ram and
decompressed there.> ----- Original Message -----

From: mystml@adinet.com.uy (Gabriel Gambetta)
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Thursday, January 13, 2005 9:59 AM
Subject: Re: [SDL] Fast IMG Load

I need to load a lot of images using too much memory space when loaded:
152 images, 35kb each but in memory they are much bigger because of
image

uncompression and byte alignment.
My idea is to read all the image data compressed in png format in memory
and load the images from memory instead of disk.

The only way this would take less space than just loading the images
would be keeping the compressed data in memory and decompress it on the
fly while blitting. I bet that’s too slow to be of any practical value :
(

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

4

Alan Wolfe schrieb:

i think he means it would be faster if the raw file was loaded into ram and
decompressed there.

That might be worth trying, and might even work out if the decompressed
images are cached, i.e. some, but not all decompressed images are kept.

If a lot of images are used, this technique of course uses more memory
than loading them from disk.>

----- Original Message -----
From: “Gabriel”
To: "A list for developers using the SDL library. (includes SDL-announce)"

Sent: Thursday, January 13, 2005 9:59 AM
Subject: Re: [SDL] Fast IMG Load

I need to load a lot of images using too much memory space when loaded:
152 images, 35kb each but in memory they are much bigger because of

image

uncompression and byte alignment.
My idea is to read all the image data compressed in png format in memory
and load the images from memory instead of disk.

The only way this would take less space than just loading the images
would be keeping the compressed data in memory and decompress it on the
fly while blitting. I bet that’s too slow to be of any practical value :
(

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

5

Hi,

I need to load a lot of images using too much memory space when loaded:
152 images, 35kb each but in memory they are much bigger because of image
uncompression and byte alignment.
My idea is to read all the image data compressed in png format in memory
and load the images from memory instead of disk.

Try the following:

However:

The only way this would take less space than just loading the images
would be keeping the compressed data in memory and decompress it on the
fly while blitting. I bet that’s too slow to be of any practical value :frowning:

i think he means it would be faster if the raw file was loaded into ram and
decompressed there.

I must agree here, without further information, we don’t know what you
mean or whether this will actually help.

On the other hand, I’ve been daydreaming about converting a .png file to
a .o file, maybe through a .c file that contained

unsigned char *my_image = {
0, 0, 0, 42, …

and then having my image embedded in my binary. The benefits and
drawbacks of embedded images aside, is this already possible somehow?

Hope the above helps, though,

Benjamin

6

On the other hand, I’ve been daydreaming about converting a .png file to
a .o file, maybe through a .c file that contained

unsigned char *my_image = {
0, 0, 0, 42, …

and then having my image embedded in my binary. The benefits and
drawbacks of embedded images aside, is this already possible somehow?

Sure you can. Load it using SDL_Image, get access to the pixel data, and
generate your .c file. To use it, link with the corresponding .o
defining my_image, and create a SDL_Surface from that. You may want to
save the pixel format as well as the raw data.

7

Hello again,

On the other hand, I’ve been daydreaming about converting a .png file to
a .o file, maybe through a .c file that contained

unsigned char *my_image = {
0, 0, 0, 42, …

and then having my image embedded in my binary. The benefits and
drawbacks of embedded images aside, is this already possible somehow?

Sure you can. Load it using SDL_Image, get access to the pixel data, and
generate your .c file. To use it, link with the corresponding .o
defining my_image, and create a SDL_Surface from that. You may want to
save the pixel format as well as the raw data.

Sorry, actually I meant “has someone alreay written a program or script
that does this, so I won’t have to write one, or does gcc even come with
a hidden flag for such purposes?”

And I would probably not embed the decompressed image, but the
compressed PNG. Though it is intriguing to say “disk space is cheaper
than RAM”, I’d bet the extra time taken for loading the uncompressed vs.
compressed image is longer than decompression time. On the other hand,
Having the compressed image still stick around sounds like a waste of
memory…

Bye,
Benjamin

8

Hi,

I need to load a lot of images using too much memory space when loaded:
152 images, 35kb each but in memory they are much bigger because of image
uncompression and byte alignment.
My idea is to read all the image data compressed in png format in memory
and load the images from memory instead of disk.

Try the following:

However:

The only way this would take less space than just loading the images
would be keeping the compressed data in memory and decompress it on the
fly while blitting. I bet that’s too slow to be of any practical value :frowning:

i think he means it would be faster if the raw file was loaded into ram and
decompressed there.

I must agree here, without further information, we don’t know what you
mean or whether this will actually help.

On the other hand, I’ve been daydreaming about converting a .png file to
a .o file, maybe through a .c file that contained

unsigned char *my_image = {
0, 0, 0, 42, …

and then having my image embedded in my binary. The benefits and
drawbacks of embedded images aside, is this already possible somehow?

Sure, I do it all the time. I have a little utility (call toch) that
converts any file, binary or otherwise, to a .c and .h file. There are
utilities like that available all over the net. If you want mine just
let me know. I can send it or post it along with an example make file
that uses it. It is good for including small numbers of images and
sounds in a program.

	Bob PendletonOn Thu, 2005-01-13 at 19:21 +0100, Benjamin Deutsch wrote:

Hope the above helps, though,

Benjamin

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

9

Benjamin Deutsch wrote:

Sorry, actually I meant “has someone alreay written a program or script
that does this, so I won’t have to write one, or does gcc even come with
a hidden flag for such purposes?”

Yes, I have: http://delirare.com/files/bin2c.c

The source is somewhat deranged, but hey. It’s got an embedded makefile,
so you can run “make -f bin2c.c” to make it. Run bin2c without any
arguments for usage info.

The program can be used for any type of file, not just images, but it’s
probably a good idea to only use it for small-ish files. I’ve used it
for icons and such.

  • Gerry
10

Hi everybody!
I need to load a lot of images using too much memory space when loaded:
152 images, 35kb each but in memory they are much bigger because of
image uncompression and byte alignment.
My idea is to read all the image data compressed in png format in memory
and load the images from memory instead of disk.
Thanks!

How much bigger? 152*35 = 5320K or about 5.2 megabytes. Even if they are
5 times bigger in ram that isn’t that much memory. On a newer video card
you could just push them all off to a corner of the video ram and hardly
notice the memory usage.

It might be a lot cheaper to just buy some more RAM than to waste time
trying to cram 10 pounds of potatoes into a 5 pound bag.On Thu, 2005-01-13 at 17:47 +0100, Agust? Puertas Carbonell wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

11

Gabriel wrote:

On the other hand, I’ve been daydreaming about converting a .png file to
a .o file, maybe through a .c file that contained

unsigned char *my_image = {
0, 0, 0, 42, …

and then having my image embedded in my binary. The benefits and
drawbacks of embedded images aside, is this already possible somehow?

Sure you can. Load it using SDL_Image, get access to the pixel data, and
generate your .c file. To use it, link with the corresponding .o
defining my_image, and create a SDL_Surface from that. You may want to
save the pixel format as well as the raw data.

Or, the GIMP (gimp.org) allready has support for exporting to C files.
Instead of using unsigned chars, it uses normal character literals
escaped as needed. I’m not sure if this is easily automated though, you
may need to create a converter if you want to do:

my_image.png.o : my_image.png.c
my_image.png.c : my_image.png
convert $^ -o $@ --export=C

… or the like. This may allready have been done however, so I suggest
google.

12

Hi again,

Sorry, actually I meant “has someone alreay written a program or script
that does this, so I won’t have to write one, or does gcc even come with
a hidden flag for such purposes?”

Yes, I have: http://delirare.com/files/bin2c.c

The source is somewhat deranged, but hey. It’s got an embedded makefile,
so you can run “make -f bin2c.c” to make it. Run bin2c without any
arguments for usage info.

The program can be used for any type of file, not just images, but it’s
probably a good idea to only use it for small-ish files. I’ve used it
for icons and such.

Yes! Exactly what I what I was thinking of. Plenty of nice options, too.
Now nothing can stop me from filling a CD with only the program binary
itself!-D

Just two thoughts:

  • Why not link it from your page? I checked, and you link to other
    "Stuff", but not to this. Shame, really.

  • The usage of -d and -p should be documented a bit better. A single
    paragraph with an example would suffice. I’d offer to write it for you,
    but I’d just get it wrong !-)

Bye,
Benjamin

13

Benjamin Deutsch wrote:

Yes! Exactly what I what I was thinking of. Plenty of nice options, too.
Now nothing can stop me from filling a CD with only the program binary
itself!-D

Glad I could be of help =)

Just two thoughts:

  • Why not link it from your page? I checked, and you link to other
    "Stuff", but not to this. Shame, really.

Well, mainly it’s because I just uploaded it a few seconds before I sent
the mail. I don’t have much time to update the site at the moment, but
I’ll make a page for it eventually (I’ll probably find some time for it
sometime next week).

  • The usage of -d and -p should be documented a bit better. A single
    paragraph with an example would suffice. I’d offer to write it for you,
    but I’d just get it wrong !-)

-p just adds standard include file protection, so that you can include
the file several times from the same source file without getting
redefinition errors. Same thing you do in headers to stop them being
included more than once.

-d adds a declaration/definition selector, so that you can use the data
file both as a header (declaration) and as a “source” file (definition).
You’ll want this if you want access to the data from several different
source files and/or headers – otherwise each source file that included
the data would get its own copy of it, and waste space. To use this, you
basically just include the data normally in all your source files. In
one (and only one) of the source files, the one you want the data to
actually be defined in, you #define DEFINE_BIN_INCLUDES before including
the data file. (The output of -d could use some tweaking, and maybe
DEFINE_BIN_INCLUDES should be renamed, but it does work as it should as is).

Note that although bin2c currently accepts both the -d and -s switches
simultaneously, that combination doesn’t actually make sense (there’s no
such thing as static external data).

  • Gerry
14

En/na Benjamin Deutsch ha escrit:

Hi,

I need to load a lot of images using too much memory space when
loaded:
152 images, 35kb each but in memory they are much bigger because of
image
uncompression and byte alignment.
My idea is to read all the image data compressed in png format in
memory
and load the images from memory instead of disk.

Try the following:

However:

The only way this would take less space than just loading the images
would be keeping the compressed data in memory and decompress it on the
fly while blitting. I bet that’s too slow to be of any practical
value :frowning:

i think he means it would be faster if the raw file was loaded into
ram and
decompressed there.

I must agree here, without further information, we don’t know what you
mean or whether this will actually help.

On the other hand, I’ve been daydreaming about converting a .png file
to a .o file, maybe through a .c file that contained

unsigned char *my_image = {
0, 0, 0, 42, …

and then having my image embedded in my binary. The benefits and
drawbacks of embedded images aside, is this already possible somehow?

Hope the above helps, though,

Benjamin

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Thank you very much for your help. It worked perfectly.