Re: [AD] Custom packfiles

[Chris <chris.kcat@xxxxxxxxxx>]

Peter Wang wrote:
> I only put in the prefix because getc and putc from stdio.h can be 
> macros and cause problems (which they did).

Okay.

> > and I'd think normal Allegro convention for the functions would be to 
> > put the pf_ first, so it'd be pf_load_wav, pf_load_bmp, etc.
>
> I based it on the _ex naming convention, substituting pf instead.

And of course, wel /all/ just love the _ex convention, right? ;) I think 
it should follow the voice_*, gui_*, etc routines where the subsystem 
name is first (in this case packfile: pf_*).

> > This does bring up one question for me, though.. what would we do 
> > about seeking? pack_fseek doesn't have a 'whence' parameter, and we 
> > can't add one. I think the best thing to do would be to allow negative 
> > seeking (at least pass on negativee values to the vtable function, and 
> > let that worry about failing ot succeeding). Either that, or create a 
> > new function, but I'm not too sure that'd be worth it for this.
>
> I don't see any real need to add backwards seeking just because we're 
> letting the user override pack_fseek.  None of the current Allegro code 
> needs it, and the main reason for adding packfile vtables is for the 
> user to take advantage of existing file format loaders.

I haven't really looked over your patch too well, but I don't see any 
reason to *not* support backwards seeking, at least at the core level. I 
don't mean to allow Allegro's default pf_fseek to seek backwards, but 
for user-supplied pf_fseek entries to be able to. Allegro's pf_fseek can 
fail on negative positions like it always has, but the user's should be 
given the choice to allow it.