What about a "packer" for SDL?

First I’d like to thank Sam for his great job with SDL.

Then, what about a “packer” (to be released with the SDL lib)
to stores for example all images and programs data in a single
.dat file ?

I think it will be better to put game images and sounds file
in single file…

Bye.–

  • @G.Gabriele ---------------+
    | Linux |
    ±--------------- the free philosophy -+

You know, I asked the exact same question a little while ago. I think
Sam suggested that it be written as an external lib like SDL_mixer and
SDL_image. That and the actual packer utility - I don’t know if anyone
is familiar with Allegro for DJGPP, but something like the Grabber would
be perfect. I’m not a master lib programmer - anyone up for the project?
You’ll have our eternal gratitude… :slight_smile:

“G.Gabriele” wrote:>

First I’d like to thank Sam for his great job with SDL.

Then, what about a “packer” (to be released with the SDL lib)
to stores for example all images and programs data in a single
.dat file ?

I think it will be better to put game images and sounds file
in single file…

Bye.

  • g.gabriele at europe.com ---------------+
    | Linux |
    ±--------------- the free philosophy -+

Maybe PenguinPlay is worth a look, as it includes PenguinFile which, if I’m
not extremely mistaken, is about exactly this kind of stuff:
http://sunsite.auc.dk/penguinplay/libpplay/

All the best,
robOn Wed, Feb 02, 2000 at 10:47:14AM -0600, Michael Vanecek wrote:

You know, I asked the exact same question a little while ago. I think
Sam suggested that it be written as an external lib like SDL_mixer and
SDL_image. That and the actual packer utility - I don’t know if anyone
is familiar with Allegro for DJGPP, but something like the Grabber would
be perfect. I’m not a master lib programmer - anyone up for the project?
You’ll have our eternal gratitude… :slight_smile:

You know, I asked the exact same question a little while ago. I think
Sam suggested that it be written as an external lib like SDL_mixer and
SDL_image. That and the actual packer utility - I don’t know if anyone
is familiar with Allegro for DJGPP, but something like the Grabber would
be perfect. I’m not a master lib programmer - anyone up for the project?

I have to write one for something else… if enough people want me to, I can
do things slightly neater and release it under the SDL label.

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: mike@mjv.com (Michael Vanecek)
To: sdl at lokigames.com
Date: Wednesday, February 02, 2000 9:10 AM
Subject: Re: [SDL] What about a “packer” for SDL ?

You know, I asked the exact same question a little while ago. I think
Sam suggested that it be written as an external lib like SDL_mixer and
SDL_image. That and the actual packer utility - I don’t know if anyone
is familiar with Allegro for DJGPP, but something like the Grabber would
be perfect. I’m not a master lib programmer - anyone up for the project?
You’ll have our eternal gratitude… :slight_smile:

I wrote a bunch of .PAK file tools for command line and Gtk+ that did
this in the quake format. If anyone wants the tarball, let me know.

The Gtk+ front end had an ‘Explorer’ like interface, it was pretty
neat.

Or you could just use zip like Quake3 does.

m.On Wed, Feb 02, 2000 at 10:47:14AM -0600, Michael Vanecek wrote:


Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC

Nicholas Vining wrote:

You know, I asked the exact same question a little while ago. I think
Sam suggested that it be written as an external lib like SDL_mixer and
SDL_image. That and the actual packer utility - I don’t know if anyone
is familiar with Allegro for DJGPP, but something like the Grabber would
be perfect. I’m not a master lib programmer - anyone up for the project?

I have to write one for something else… if enough people want me to, I can
do things slightly neater and release it under the SDL label.

I guess that there are quite some ‘file handling/ management’ libs out
there that handle files in one big file, so a nice additional feature
would be automatic resource initialization. Like you only specify that
you want ‘surface A’ and it automatically creates a SDL surface and
loads the data from the file. Well, that’s nothing new, but something
very cool to use.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

Cool. I vote yes with much appreciation… Maybe you and Mr. Vance can
colaborate - sounds like he has a neat front end.

Nicholas Vining wrote:> >You know, I asked the exact same question a little while ago. I think

Sam suggested that it be written as an external lib like SDL_mixer and
SDL_image. That and the actual packer utility - I don’t know if anyone
is familiar with Allegro for DJGPP, but something like the Grabber would
be perfect. I’m not a master lib programmer - anyone up for the project?

I have to write one for something else… if enough people want me to, I can
do things slightly neater and release it under the SDL label.

Nicholas

“G.Gabriele” wrote:

First I’d like to thank Sam for his great job with SDL.

Then, what about a “packer” (to be released with the SDL lib)
to stores for example all images and programs data in a single
.dat file ?

I think it will be better to put game images and sounds file
in single file…

I’ve been trying to write something on these lines, based on the
Compressed Archive Manager program in Mark Nelson’s Data Compression
Book. I’m still trying to come up with a good file/directory structure
scheme for it and need a few ideas. Right now, my code is fairly
inflexible; I limit the total number of files packed to 255 (the
directory header), and it is very difficult to replace files in a data
file: you have to rebuild the entire data file in order to replace a
single file! If people out there have more knowledge of file structures
out there I’m listening…–

| Rafael R. Sevilla @Rafael_R_Sevilla |
| Instrumentation, Robotics, and Control Laboratory |

College of Engineering, University of the Philippines, Diliman

I’ve been trying to write something on these lines, based on the
Compressed Archive Manager program in Mark Nelson’s Data Compression
Book. I’m still trying to come up with a good file/directory structure
scheme for it and need a few ideas. Right now, my code is fairly
inflexible; I limit the total number of files packed to 255 (the
directory header), and it is very difficult to replace files in a data
file: you have to rebuild the entire data file in order to replace a
single file! If people out there have more knowledge of file structures
out there I’m listening…

Here’s how SDL_Pack works (i’ll send a version to Sam to maul/put up tomorrow):

– you have a linked list of packfiles currently loaded. Each linked list
contains a list of the files in that pack file. It can include directory
structures internally, as well it does include the offset of the “real”
(included) file in the data file.
– You’ve also got a hash table in each linked list.
– Upon requesting a file, F, you use SDLPack_fOpen(char *filename, char
*mode). This will return a SDLPack_filePointer to the data, using the hash
table. If it’s compressed data, you expand it into the appropriate filePointer.
If not, you just get a file pointer to the packfile, set to the offset of the
file in the packfile. (Flags are set internally) Following that, you use
SDLPack_fRead, SDLPack_fSeek, SDLPack_fClose.
– adding a new file isn’t so bad. You take the table at the end of the
packfile with offsets, file names, etc., etc., stick the new file before it,
and then put the table in. Expanding a previously existing file sucks, though.
There must be some way around this… I’ll have to take a look at some Zip
sources.

On a side note, anybody have any idea on how to best optimize a 3D engine
(topdown RTS style perspective) for Mesa 3.1?>| Rafael R. Sevilla dido at pacific.net.ph |

On a side note, anybody have any idea on how to best optimize a 3D engine
(topdown RTS style perspective) for Mesa 3.1?

What aspects of your engine will utilize the 3d stuff? Basically, can you
change your view orientation? Is your landscape true 3d? Or are you more
just doing some sfx, ala Baldur’s Gate II’s use of OpenGL?

Bret

What aspects of your engine will utilize the 3d stuff? Basically, can you
change your view orientation? Is your landscape true 3d? Or are you more
just doing some sfx, ala Baldur’s Gate II’s use of OpenGL?

OK, here’s how it currently works: Your world is defined as a standard sort
of world… (X,Y,Z), rotated 90 degrees along the X axis to go into a top
down mode, then rotated according to the player angle. You can move your
camera orientation down and laterally. The landscape is true 3D, while not
(since I’m using a MCA (multiple client architecture), the world is composed
of “blocks” with “building instructions”)… I’m mainly concerned about
getting the rendering as fast as possible… there’s no way that I should
be getting lag with 60 texture mapped (not even linear!) polygons on a P/233
with a Voodoo Graphics, and I am forced to wonder if I’m doing something
wrong. Regardless of which, lightmapping (which I tossed in experimentally
yesterday, it was the work of half an hour, no ARB_multitexture) seems to be
ridiculously slow. So, it looks kind of like Diablo, sort of, except closer
zoomed and at a higher resolution.

I’m currently clipping by dividing the world into “zones”, calculating the
bounding boxes for each zone, and each frame converting them with gluProject
and seeing if they show up on screen. I might be forced to take the rotation
and translation code out of GL and hand-optimize it with some good old FPU
routines, since at present they seem to be VERY slow… probably because
they’re using 3 matrices instead of one :wink:

Bret

Nicholas

Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert

----- Original Message -----
From: brm@duke.edu (Bret McMillan)
To: sdl at lokigames.com
Date: Thursday, February 03, 2000 11:05 AM
Subject: Re: Re: [SDL] What about a “packer” for SDL ?