| Re: [AD] Custom packfiles |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
t's not possible to use the Allegro's packfile compression with
pack_fopen_vtable(), nor can you use pack_fopen_chunk() on
vtable-packfiles. That also explains why there is no load_datafile_pf().
Without looking at the code - what are the problems?
At least the following:
(1) The chunk code requires the `flags' field in the PACKFILE structure
to be properly set.
(2) The chunk code uses the `hndl' field in the PACKFILE structure
(which is a file descriptor) and does some dup'ing and seeking and
stuff. I didn't look at it too hard, but basically it assumes the
packfile is a file underneath.
I think support
for pack_fopen_chunk should be there - else we can drop the feature of
file chunks completely.
Can't, they are used for datafiles.
At least, i would stop using them if it would
mean my custom file format using them can't be read from memory, for
example.
You can easily implement a similar thing using vtable packfiles if you
have to, at least for reading and no Allegro compression.
I'm not sure I understand the state-based issue completely, but I
think it should be like Chris said. A function like load_bitmap should
use load_bitmap_pf internally. And the built-in packfile-vtable should
take no precedence over other vtables. Just like I can change the
packfile password right now, I should be able to change to the .gz
file reader.
If it's anything like packfile_password(), well, you've seen the
problems we've had with that interface. It's asking for trouble.
If I understand correctly, the patch
only adds the vtable packfiles additionally, on top of the old
packfiles, which are unmodified. But instead, I think the old packfile
routines should be moved into a vtable as well, and then all packfile
functions should use the current vtable (which by default would be the
one with the old functions). Seems to be much cleaner than to allow
new vtables, but fall back to the old non-vtable ones otherwise.
Yes, that would be nice. I might try it later. From a user's POV it
should make no difference.
Peter