Hi,
I’m looking for a good Linux Game lib. So that took me here.
I browsed around a little bit of the API docs, and thought “cool”. Then
I came to the image part, and it said “Windows BMP” everywhere.
Although I understand that BMP support is the easiest way to port
Windows games, I am not very fond of using non-compressed images on
disk. In the current docs, there are no alternatives available, however.
Are there any in the make? Do you think it is useful/ may be added?
I think about PNG (lossless, but not yet fully supported on non-Linux
platforms. OTOH that could be arranged using libpng code, I guess) and
JPG (lossy, but generally supported).
Greets,
Stefan
Use the SDL_Image library, found in the library’s section on the SDL web
page.
It supports other file types.–
Brian
On Fri, 31 Mar 2000, Stefan Rieken wrote:
Hi,
I’m looking for a good Linux Game lib. So that took me here.
I browsed around a little bit of the API docs, and thought “cool”. Then
I came to the image part, and it said “Windows BMP” everywhere.
Although I understand that BMP support is the easiest way to port
Windows games, I am not very fond of using non-compressed images on
disk. In the current docs, there are no alternatives available, however.
Are there any in the make? Do you think it is useful/ may be added?
I think about PNG (lossless, but not yet fully supported on non-Linux
platforms. OTOH that could be arranged using libpng code, I guess) and
JPG (lossy, but generally supported).
Greets,
Stefan
Although I understand that BMP support is the easiest way to port
Windows games, I am not very fond of using non-compressed images on
disk. In the current docs, there are no alternatives available, however.
Use SDL_Image, it’s a library that can load GIF, PNG, JPG (I think) and I think
some other formats. See the SDL website.
-bill!
Generally compressed images aren’t usually used in game since you have to
uncompress them to actually be able to use them. All compressed images will
do is save you some disk space. Best thing to do is just get some basic
uncompressed images and stick them all in one big compressed file to use
for your game.
At 06:52 PM 3/31/00 +0200, you wrote:
Hi,
I’m looking for a good Linux Game lib. So that took me here.
I browsed around a little bit of the API docs, and thought “cool”. Then
I came to the image part, and it said “Windows BMP” everywhere.
Although I understand that BMP support is the easiest way to port
Windows games, I am not very fond of using non-compressed images on
disk. In the current docs, there are no alternatives available, however.
Are there any in the make? Do you think it is useful/ may be added?
I think about PNG (lossless, but not yet fully supported on non-Linux
platforms. OTOH that could be arranged using libpng code, I guess) and
JPG (lossy, but generally supported).
Greets,
Stefan
-Garrett WPI student majoring in Computer Science.
“The fastest way to succeed is to look as if you’re playing by somebody
else’s rules, while quietly playing by your own.” -Michael Konda
Sorry Garrett, I have to disagree 
Generally compressed images aren’t usually used in game
- which I find very strange -
since you have to uncompress them to actually be able to use them.
That’s right. But I don’t see a problem there. The time it takes to
uncompress them should be insignificant. And if you don’t compress them
you have to read more data off the harddisk, which also takes time.
Of course we’re talking “compressed-on-disk”, not in memory here.
All compressed images will do is save you some disk space.
Yes and bandwidth too. I’m always puzzled at games which use several
megabyte worth of bmps. Perhaps sometimes you don’t even want to accept
the tiny losses incurred by jpg, but why not png ? PNG’s are smaller
than gzip’d bmps, and jpgs are even smaller.
And, well, are there any other reasons for compressed data-formats
besides saving space ? None that I’m aware of, yet they seem very popular
Bandwidth and harddisks all cost money. Waiting half a second before a game
starts up does not.
Best thing to do is just get some basic uncompressed images and stick them
all in one big compressed file to use for your game.
What exactly do you mean by that ?
All the best,
robOn Fri, Mar 31, 2000 at 12:37:31PM -0500, Garrett Banuk wrote:
I meant putting them all in one big compressed file, like a tarball. Any
good game is going to have all the images and small files in one big file
anyways since lots of little files will waste alot of harddrive space. I hate
it when people release a product with hundreds of less than 1K files. Look at
the netscape cache, it less then 5megs worth of data yet all the small files
take up 50 megs or so of space.On Fri, 31 Mar 2000, you wrote:
Best thing to do is just get some basic uncompressed images and stick them
all in one big compressed file to use for your game.
What exactly do you mean by that ?
I think he means either:
- create a compressed version of all of the image
files (eg, ZIP the data directory and uncompress it into memory somehow
during startup of the game),
… or …
- make one giant image that contains all of the pictures used in the game
(then either break it up into a bunch of SDL_Surfaces internally [although
that doubles the RAM requirement for the surfaces during startup], or simply
be clever with your source SDL_Rects when blitting 
)
-bill!
–
-Garrett, WPI student majoring in Computer Science
"The fastest way to succeed is to look as if you’re playing by somebody
else’s rules, while quietly playing by your own." -Michael Konda
- create a compressed version of all of the image
files (eg, ZIP the data directory and uncompress it into memory somehow
during startup of the game),
[Before I say anything, I’m going to say this is very "game dependant"
and I’m talking from my own perspective here. I may be overlooking
certain games that this will be feasible to do in.]
This is unreasonable for recent games, because of the sheer size required
for 2D art to provide the quality expected in todays major game releases.
You couldn’t just uncompress a single file into memory.
Heck, I’m finding memory requirements are too high to even maintain a
single area in a 2D game all in memory at the same time. I’m going to
have to do some dynamic loading and freeing of stuff “as needed”, even
within the same area.
Maybe having it in one file that is compressed would work, but you’re
going to have to manipulate it on disk, not load it all into memory and
manipulate it there.
- make one giant image that contains all of the pictures used in the game
(then either break it up into a bunch of SDL_Surfaces internally [although
that doubles the RAM requirement for the surfaces during startup], or simply
be clever with your source SDL_Rects when blitting )
Same problem, once again. You can’t do this with games like Diablo,
Star Craft, Baulders Gate, Quake 2,and other serious commercial titles
these days. It just isn’t feasible to load everything into memory for the
game at once.–
Brian
Check out the SDL_Image library. Here’s a link to it (it can also be found
off the main SDL page)
http://www.devolution.com/~slouken/SDL/projects/SDL_image/index.html
It supports tons of different file formats.
cheers,
Dave “PenguinDude” ArchboldOn Friday, March 31, 2000 10:52 AM, Stefan Rieken [SMTP:StefanRieken at SoftHome.net] wrote:
Hi,
I’m looking for a good Linux Game lib. So that took me here.
I browsed around a little bit of the API docs, and thought “cool”. Then
I came to the image part, and it said “Windows BMP” everywhere.
Although I understand that BMP support is the easiest way to port
Windows games, I am not very fond of using non-compressed images on
disk. In the current docs, there are no alternatives available, however.
Are there any in the make? Do you think it is useful/ may be added?
If you look at the quake games they all use a .pak file. Its not
compressed, probably because as the previous person said, you can’t load
the while thing in mem. You can only load parts of it, so its faster to
take stuff out of a non compressed file than a compressed on. Also putting
all the files into one big file does save space.
At 01:32 PM 3/31/00 -0600, you wrote:
- create a compressed version of all of the image
files (eg, ZIP the data directory and uncompress it into memory somehow
during startup of the game),
[Before I say anything, I’m going to say this is very "game dependant"
and I’m talking from my own perspective here. I may be overlooking
certain games that this will be feasible to do in.]
This is unreasonable for recent games, because of the sheer size required
for 2D art to provide the quality expected in todays major game releases.
You couldn’t just uncompress a single file into memory.
Heck, I’m finding memory requirements are too high to even maintain a
single area in a 2D game all in memory at the same time. I’m going to
have to do some dynamic loading and freeing of stuff “as needed”, even
within the same area.
Maybe having it in one file that is compressed would work, but you’re
going to have to manipulate it on disk, not load it all into memory and
manipulate it there.
- make one giant image that contains all of the pictures used in the game
(then either break it up into a bunch of SDL_Surfaces internally [although
that doubles the RAM requirement for the surfaces during startup], or
simply
be clever with your source SDL_Rects when blitting )
Same problem, once again. You can’t do this with games like Diablo,
Star Craft, Baulders Gate, Quake 2,and other serious commercial titles
these days. It just isn’t feasible to load everything into memory for the
game at once.
–
Brian
-Garrett WPI student majoring in Computer Science.
“The fastest way to succeed is to look as if you’re playing by somebody
else’s rules, while quietly playing by your own.” -Michael Konda
I meant putting them all in one big compressed file, like a tarball.
Ok, I understand.
Any good game is going to have all the images and small files in one big
file anyways since lots of little files will waste alot of harddrive
space.
Agreed (although I wouln’t go so far as to call that a requierement for any
good game ;), but YOU said compressed images are not that importand because
they “only” save space
I hate it when people release a product with hundreds of less than
1K files. Look at the netscape cache, it less then 5megs worth of data yet
all the small files take up 50 megs or so of space.
Yes, that’s crappy.
But unless you have a good library to handle those archives for you it’ll be
a pain, especialy on different platforms. Compressing pictures on the other
hand is no effort at all. And I also think it saves more space. Just as an
example, take Bill Kendricks madbomber (no real reason, only that it’s the
first I remember to have bmps ;). It has > 3.3MB worth of bmp’s, and <200
files. With a hypothetical blocksize of 8k you waste less than 1.6MB in the
worst case. The graphics can be cut down at least 75%, which would save
2.4MB. Ok, the difference in this example is not that big, but it will be
in the real world.
And, just that A (file-archives) is good doesn’t mean that B (compress images)
is bad. You can do both, or just one or the other.
So, two questions remain for me. Is there any reason for using bmps
(apart from not relying on IMGLib) ? Are there any good file-archive-libs,
that work well with SDL ? (perhaps penguinplay ?)
All the best,
robOn Fri, Mar 31, 2000 at 02:19:25PM -0500, Garrett wrote:
If you look at the quake games they all use a .pak file. Its not
compressed, probably because as the previous person said, you can’t load
the while thing in mem. You can only load parts of it, so its faster to
take stuff out of a non compressed file than a compressed on. Also putting
all the files into one big file does save space.
Yes, it does save space to put them all into one big file.
If you are going to put all of the files into a single file, it is
probably not too feasible to compress the file itself. Because that would
require uncompressing it into memory everytime you want to access it.
Making a single file that is comprised of compressed images might be a
decent solution, but it is still slow if it’s not randomly accessible.
For example, tar is “linear” access, meaning you have to read past all of
the initial data to get to your requested file.
It will have to be some sort of database/indexed format to be reasonable,
for loading images “as needed” and “on the fly”. This way you can jump
right to the beginning of the image to read it.
Does anyone know of a good solution to do something like this? I know
gdbm/dbm is a possible database format, but is it useful for a situation
like this? I know the original dbm had a bytes limit. I’m of course
looking for an LGPL open database.
If it comes down to implementing this from scratch, or using single png
files, I will probably use single png files… :-)–
Brian
If you look at the quake games they all use a .pak file. Its not
compressed, probably because as the previous person said, you can’t load
the while thing in mem. You can only load parts of it, so its faster to
take stuff out of a non compressed file than a compressed on. Also putting
all the files into one big file does save space.
Probably uses something like mmap()?
-bill!
Any good game is going to have all the images and small files in one big
file anyways since lots of little files will waste alot of harddrive
space.
I hate it when people release a product with hundreds of less than
1K files. Look at the netscape cache, it less then 5megs worth of data yet
all the small files take up 50 megs or so of space.
Maybe, but release != develop. Keeping images (and sound samples etc) in small
files in a standard format is very nice when developing, and the internal
fragmentation in the file tree is usually not much to make a fuss about.
It is only disk space, not the much more expensive net bandwidth (since there
is no space wasted in a tarball).
Most common file systems won’t read-ahead across related files. In other
words, when the game is started for the first time, the disk is hit for
each file, so a single file (if cleverly packed) will be faster to load.
(This was one of the motivations behind reiserfs, as I understand it.)
Arguably the Right Solution is to access game assets through a library,
which can either read files scattered over a file tree or a packed
file-system-in-a-file, like a (t)ar archive. I really like being able to
frobble 1000 image files with a shell or perl script, without having to
re-pack them into a package file at each change.
I hate it when people release a product with hundreds of less than
1K files. Look at the netscape cache, it less then 5megs
worth of data yet
all the small files take up 50 megs or so of space.
Yes, that’s crappy.
But unless you have a good library to handle those archives
for you it’ll be
a pain, especialy on different platforms.
In the contrib folder of the ZLIB archive there are files for
using ZIP archives. Pretty simple to grab that code and get
something working.
LibAsset and the VFS class in crystal space use this code to
handle ZIP archives.
–Dave McClurg
LibAsset and the VFS class in crystal space use this code to
handle ZIP archives.
Does this support dynamic access of particular files within the archive,
without uncompressing the whole thing into memory?
–Brian
Probably, you’d have to make your own routine for getting an image from
the .pak (or whatever you want to call it) to an SDL surface, unless you
extract the file out of the .pak and create a new file and load that, which
would be very inefficient.
At 12:43 PM 3/31/00 -0800, you wrote:
If you look at the quake games they all use a .pak file. Its not
compressed, probably because as the previous person said, you can’t load
the while thing in mem. You can only load parts of it, so its faster to
take stuff out of a non compressed file than a compressed on. Also putting
all the files into one big file does save space.
Probably uses something like mmap()?
-bill!
-Garrett WPI student majoring in Computer Science.
“The fastest way to succeed is to look as if you’re playing by somebody
else’s rules, while quietly playing by your own.” -Michael Konda
If you are going to put all of the files into a single file, it is
probably not too feasible to compress the file itself. Because that would
require uncompressing it into memory everytime you want to access it.
Many games only read stuff at startup, and if you arrange the files
in the correct order, compression is easy.
Does anyone know of a good solution to do something like this? I know
gdbm/dbm is a possible database format, but is it useful for a situation
like this? I know the original dbm had a bytes limit. I’m of course
looking for an LGPL open database.
*dbm files would work but are a severe overkill, at least if you can do
without incremental changes. You could perhaps abuse the symbol table of
ar archives.
Another solution is to put everything into your binary. You don’t have to
load anything, just access it. The downside is that you have to relink
each time anything changes.
If it comes down to implementing this from scratch, or using single png
files, I will probably use single png files…
I bet you and I could have done it in the time we’ve wasted posting to
this silly list
LibAsset and the VFS class in crystal space use this code to
handle ZIP archives.
ClanLib also has a datafile format using gzip.
-Matt