Re: [AD] Custom packfiles |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] Custom packfiles
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Fri, 31 Dec 2004 16:43:14 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Tlkz4ubYixM0FLtAaRV9shJdmA/oyABfeH91fZ1cQHPTmvH04/wh5XJVNcuSOFJKNK4Ba/NSEw2aLgLNL0MVZNpOC7k/z/jMEyYvzX3dBmd1kMbHYTR1YesZowuzSkZaVw4rbFwPqd2ZEqPyVgFCWI2Age/65qJzSKOzTwTGsXk=
Peter Wang wrote:
nor can you use pack_fopen_chunk() on
vtable-packfiles.
Well, as has been mentioned before, I think Allegro's default pack_*
functions should be implemented as a vtable that's always used for
pack_fopen(). pack_fopen_chunk can simply check that the vtable is
Allegro's, and fail if it isn't. Yeah, this would mean the pack_*_chunk
would be "special", but since they're of limited use outside of
Allegro's datafiles anyway, I can deal with that. People can easilly
support zips or their own archive format anyway.
However, one thing I would like is for the vtable to contain pf_open and
pf_close methods. That would potentially cut down on a lot of duplicate
code. So the user could do, for instance:
struct mystruct data = {
"myfile.wad", 0
};
PACKFILE *pf = pack_fopen_vtable(&my_vtable, &data);
Then the my_vtable.pf_fopen function would do the actual opening of the
specified file "myfile.wad and could seek to a specific object
(specified through an index 0 in this case) in the file.