Embedded Images

How would I use IMG_Load() or the like using embedded images. I don’t want to
have a separate folder with my images that need to be loaded into memory
everytime the application starts.

Thanks for any help

Hints:
SDL_RWops
IMG_Load_RW()

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Tuesday 10 October 2006 15:48, Chris Weed wrote:

How would I use IMG_Load() or the like using embedded images. I
don’t want to have a separate folder with my images that need to be
loaded into memory everytime the application starts.

David Olofson wrote:

Hints:
SDL_RWops
IMG_Load_RW()

There is still the problem to link the image in your source code. It’s
an easy task if it’s an XPM (you can include it with #include), but not
that easy if you want to use a binary format. There is a portable way to
do this without external programs that convert images in source files?

I’ve been able to use this trick to include a binary file in my source
with objdump, but it’s not portable at all :slight_smile: (but it was for a firmware
so it was ok :slight_smile: )

[from Makefile]

firmware.o:
objcopy -I binary -O elf32-i386 -B i386 --rename-section
.data=.rodata,alloc,load,readonly,data,contents firmware.bin firmware.o

[from the source code using it]
extern char _binary_firmware_bin_start;
extern char _binary_firmware_bin_end;

#define firmware_ptr &_binary_firmware_bin_start
#define firmware_end_byte &_binary_firmware_bin_end
#define firmware_length ((unsigned long)(firmware_end_byte) - (unsigned
long)(firmware_ptr))

Bye,
Gabry

Convert your image files into plain C char arrays (not talking about
XPMs here), and use what David mentionned to load them as SDL surfaces
during execution. It’s really easy to do, and can be included in your
compilation process.

Quick pseudocode for converting a binary file to an array:On 10/10/06, Gabriele Greco <gabriele.greco at darts.it> wrote:

David Olofson wrote:

Hints:
SDL_RWops
IMG_Load_RW()

There is still the problem to link the image in your source code. It’s
an easy task if it’s an XPM (you can include it with #include), but not
that easy if you want to use a binary format. There is a portable way to
do this without external programs that convert images in source files?


open binary.png for reading
open array.h for writing
write to array.h: "static const char binary[] = {"
while not at end of file of binary.png
get one byte from binary.png
write to array.h: (string)byte + ","
end while
write to array.h: “};”

This is fully portable, and you do not lose any aspect of the original
image file, it’s really embedded “as-is” inside your program.

  • SR

Well, unless you’re relying on build tools (like GNU autotools) that
come with a scripting language or something you can use for this,
there’s always the option of implementing your own tool in whatever
language you’re using for the “real” code of the project.

The downside of this approach is that it can result in trouble with
cross compilers. Having a cross compiler for some language doesn’t
automatically mean you have a native compiler for that language!

Of course, if you’re only releasing binaries, you can use whatever
tools that work for you, as no one else is going to have any problems
with missing tools or anything.

Another approach is to simply append the data files at the end of your
executable, after compiling and linking it. Most loaders will just
ignore anything beyond the chunks mentioned in the header, so the
appended data will be ignored.

Mark the start of the data with some reasonably long string that won’t
appear in the binary. (Oh, and if you pass a constant to you search
function, keep in mind where that constant goes… :wink:

Alternatively, check the size of the data, compile that into the
executable, and seek from EOF to find your data.

The potential portability issue here is that some platforms may have
loaders that either try to load the whole file before parsing it,
resulting in waste of memory and/or long load times. There may also
be issues with loaders being nervous about finding anything
unexpected in executable files.

Another potential issue is that some platforms, or sysadmins, may
prevent ordinary users from reading or writing executable files. (On
platforms with dedicated “execute” flags, you normally don’t need
read permission to execute a file.)

Finally, antivirus software tends to have rather strong opinions about
messing with executables. Logically, they should only react on actual
write operations, but I wouldn’t be surprised if some antiviruses
complain about applications trying to read or even open executables.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Tuesday 10 October 2006 18:21, Gabriele Greco wrote:

David Olofson wrote:

Hints:
SDL_RWops
IMG_Load_RW()

There is still the problem to link the image in your source code.
It’s an easy task if it’s an XPM (you can include it with #include),
but not that easy if you want to use a binary format. There is a
portable way to do this without external programs that convert
images in source files?

Well, yes, this is the easy, solid and mostly portable way. There is
the issue I mentioned in the last mail, with cross compilers and
custom build tools like this, but that’s usually no major
showstopper. (Just make sure you actually have a native compiler as
well, and use whatever means your build tools provide for compiling
the tool for the host, rather than the target platform.)

Another problem, if you have lots of data, is that all of it will be
loaded right away, before the application starts. That could be very
annoying, at least when running directly from CDs or other slow
media.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Tuesday 10 October 2006 18:44, Simon Roby wrote:

On 10/10/06, Gabriele Greco <gabriele.greco at darts.it> wrote:

David Olofson wrote:

Hints:
SDL_RWops
IMG_Load_RW()

There is still the problem to link the image in your source code.
It’s an easy task if it’s an XPM (you can include it with
#include), but not that easy if you want to use a binary format.
There is a portable way to do this without external programs that
convert images in source files?

Convert your image files into plain C char arrays (not talking about
XPMs here), and use what David mentionned to load them as SDL
surfaces during execution. It’s really easy to do, and can be
included in your compilation process.

Quick pseudocode for converting a binary file to an array:

open binary.png for reading
open array.h for writing
write to array.h: "static const char binary[] = {"
while not at end of file of binary.png
get one byte from binary.png
write to array.h: (string)byte + ","
end while
write to array.h: “};”

This is fully portable, and you do not lose any aspect of the
original image file, it’s really embedded “as-is” inside your
program.

David Olofson <david olofson.net> writes:

How would I use IMG_Load() or the like using embedded images. I
don’t want to have a separate folder with my images that need to be
loaded into memory everytime the application starts.

Hints:
SDL_RWops
IMG_Load_RW()

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’

Thank you for all the information (everyone).
I like the idea of using IMG_Load_RW(), and I’m assuming that avoids these
"double loaded" problems where the image is loaded into ram twice.

This seems rather complicated though, converting my images to C files. I could
only find one tool that would do this, and it’s kind of tricky. I think I might
just leave the system the way it is, it’s part of an embedded system and
currently only used by me… so I don’t think there will be much problem.> On Tuesday 10 October 2006 15:48, Chris Weed wrote:

Thank you for all the information (everyone).
I like the idea of using IMG_Load_RW(), and I’m assuming that avoids these
"double loaded" problems where the image is loaded into ram twice.

No. It wouldn’t.

This seems rather complicated though, converting my images to C files. I could
only find one tool that would do this, and it’s kind of tricky.

You could write a C program to do it yourself in less than 20 lines.
More appropriate languages like perl could probably do it in one line
comfortably. The GIMP will do it for you, but it will not preserve
your file format / image encoding.

I think I might
just leave the system the way it is, it’s part of an embedded system and
currently only used by me… so I don’t think there will be much problem.

GOOD THINKING. There is no good reason to stuff your images into your
program binary.On 10/10/06, Chris Weed wrote: