[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SDL] Why using resources by file names? (fwd)
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
>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
* 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).
Efficient programers save hex at every opportunity.