Re: [SDL] Why using resources by file names? (fwd)

[Christian Reiniger <warewolf@mayn.de>]

Sam Lantinga wrote:

>Chris, you might want to plug your "wad" loader here, if it's mature enough...

Well, I suggest the "wad" *writer* is mature enough, but we haven't started
implementing the reading stuff. Perhaps someone on the SDL list wants to
help? ;)

>Just reply to me, and I'll forward the messages, if you're not already on the
>SDL mailing list.

Erm, no, I'm not.

>> internals of the SDL media formats.  Personally, I'd like to see
>> something that can be dropped into SDL that will load arbitrary files
>> from other files (Perhaps using a callback function to handle the
>> nitty-gritty of file encryption/compression), but I don't have the
>> talent to write it myself.  It's a catch-22.

Well, actually writing that stuff shouldn't be difficult for someone who
likes writing C code. Our problem is mainly that we're almost all C++ /
ObjC lovers ;)

>trying to do things like create general file loading routines and so forth.
>They are a work in progress, so as far as I know they don't have any usable
>code yet, but I'll CC this to the PenguinPlay list and let them comment. :)

Ok, this is the current state:

* The PakFile format is standing. I only expect minor fixes to that in the
near future

* The PakFile writing utility is in a usable state. It compiles at least on
my Linux system with egcs 1.1 and it seems to do what it should.
Compression/encryption, support for symlinks and checksums for vital data
structures are not implemented yet, but everything else is fine.

* The File access API is defined except for 2-3 functions (explicit PakFile
mounting/unmounting, initialization). It will be a direct clone of the
stdio API (for the C version) and the fstream API (for the C++ version).

* the behavior of the File access functions is partly defined. Finishing
this should be a matter of about 1 hour. Perhaps I'll do that soon.

* The file access functions is not implemented yet. We're looking for
people to do that (or to help with it).


Cu
	Christian
--

Efficient programers save hex at every opportunity.