Handling a large number of image files

Hi all,

I have been trying to figure out how to deal with this issue for a little
while and am stuck. I basically would like to get some input on how to
handle image files for applications. The simplest method is just to
keep every image is a .png or whatever, and have the application load
it. However this has several drawbacks, such as the user would be
able to modify the files themselves (which we may not want), and it
becomes difficult to handle and load a whole lot of individual files. I am
toying with writing a little program that stores a number of SDL_Surfaces
in a binary file, but this is trickier than I had anticipated due to the
complexity of the surface structure (since it contains pointers to other
structures that contain pointers to other structures …). However this
still seems like the best method to do it in the absence of any other
pre-built libraries that I can find. Using pygame it was a lot simpler,
since the sprite object had a tostring function that I could just write to a
file, but there isn’t really anything equivalent that I can find with
regular SDL. If anyone has any input on how to achieve this, or if I am
totally going about this in the wrong way, I really apprecaite it.
Thanks,
Tom.

** I really am good at this email business sorry to minor sp*m but here is the
same message with the correct subject line **
such as the user would be

able to modify the files themselves (which we may not want), and it
becomes difficult to handle and load a whole lot of individual files. I am
toying with writing a little program that stores a number of SDL_Surfaces
in a binary file,

to prevent the end user from altering image files, you can either use .xpm
fromat and store them in a header file they are compiled into the final binary,
also i havnt tried this myself, but by using a bin to hex program you can keep
your files in png format in a header file and use SDL_Rwops to retrive them in
the code.

I have used the .xpm method alot, just use the gimp to re-save them as xpms,
then put them all into a header file and use XPM_Readfromarray to get them. or
you can use imagemajick but that puts pure colors as thier names which the
readfromarray function cant cope ie ‘’=“white” instead of '’=#ffffff (or at
least didnt cope last time i checked )

hope this makes sence and is a little help!

Hi
Its a good question, for other games i have carefully laid out my images
on one large PNG and used the cords (Rects) of the images, but i am
currently developing a game where that’s a bit trickier, and i found that if
i rename my PNGs head.png to like 000.dat and legs.png to 001.dat which i am
going to do when its built then the images will still load, as SDL only uses
the file format and not the extension for loading images, this should put
off the people who would see loads of images to play with. not the solution
your looking for but its a handy cheat.

Trish x

Thanks for the tips. I am playing around with IMG_ReadXPMFromArray, and so
far
everything compiles okay but it crashes as soon as I call that function and
I can’t
figure out why. I will continue to play around with it and try and debug the
problem
though. Thanks!On 5/14/07, neil at cloudsprinter.com wrote:

** I really am good at this email business sorry to minor sp*m but here is
the
same message with the correct subject line **
such as the user would be

able to modify the files themselves (which we may not want), and it
becomes difficult to handle and load a whole lot of individual files. I
am
toying with writing a little program that stores a number of
SDL_Surfaces
in a binary file,

to prevent the end user from altering image files, you can either use .xpm
fromat and store them in a header file they are compiled into the final
binary,
also i havnt tried this myself, but by using a bin to hex program you can
keep
your files in png format in a header file and use SDL_Rwops to retrive
them in
the code.

I have used the .xpm method alot, just use the gimp to re-save them as
xpms,
then put them all into a header file and use XPM_Readfromarray to get
them. or
you can use imagemajick but that puts pure colors as thier names which the
readfromarray function cant cope ie ‘’=“white” instead of '’=#ffffff (or
at
least didnt cope last time i checked )

hope this makes sence and is a little help!


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I had this same problem with SDL_image and IMG_ReadXPMFromArray. I had to
revert to version 1.2.4. I use openSUSE, so the exact version I had to revert
to is 1.2.4-16.

I cannot recall the exact details of the problem, but I do remember that
IMG_ReadXPMFromArray calls another function that does all the work
(IMG_ReadXPMFromArray is just a wrapper). Anyway, the “other” function that
is called is called with NULL as its 2nd parameter. The 2nd parameter is then
used with RWops which is where the crash comes from.

With SDL_image 1.2.4, the implementation of this “other” function is different
and so the 2nd parameter being NULL doesn’t cause a crash.

Well, having said all this I decided not to be so lazy, so I checked
SDL_image’s SVN. Sure enough, it looks like icculus (Ryan G?) fixed the bug
in February 2007. Try upgrading your version of SDL_image. If that doesn’t
work and you do not want to install from SVN (i.e. want distro RPMs), then
you can try to downgrade to SDL_image version 1.2.4.

AlvinOn Monday 14 May 2007 18:57:43 Tom Davies wrote:

Thanks for the tips. I am playing around with IMG_ReadXPMFromArray, and so
far
everything compiles okay but it crashes as soon as I call that function and
I can’t
figure out why. I will continue to play around with it and try and debug
the problem
though. Thanks!

Hi all,

In our game, all data files are wrapped inside one big file, it’s
like a tar archive but with some tricks to avoid any “unarchiving”.

We simply have a little lib wich replace fopen, and return a stream
to the data. (the api looks like fopenInArchive(archivePath,
filenPathInArchive, mode):wink:

If you don’t want to create your own format, I suggest you use zip
with a password. Then you hardcode the password in a disturbing way
(read, not char *pass = “foo” in your code, but something like char
*pass = getpass() and getpass do some calculations based on the age
of the captain and such (you will find plenty of information about
that if you search the web for hiding serial numbers logic in your
code or something like that)).

There are OpenSource zip lib around, some in regular zip format,
others with variations.

RegardsOn 14 May 2007, at 5:38 PM, Tom Davies wrote:


Kuon

"Don’t press that button."
http://goyman.com/