Re: [AD] Custom packfiles

[Chris <chris.kcat@xxxxxxxxxx>]

Peter Wang wrote:
> Here's a patch that implements custom packfiles, i.e. PACKFILEs where 
> the user supplies the methods for reading, writing, etc.  No 
> documentation yet.  I think the changes are simple enough for 4.2.
>
> The relevant API additions are summarised below:
>
> AL_FUNC(PACKFILE *, pack_fopen_vtable, (AL_CONST PACKFILE_VTABLE 
> *vtable, void *userdata));
> AL_FUNC(void *, pack_get_userdata, (PACKFILE *f));
>
> struct PACKFILE_VTABLE
> {
>   AL_METHOD(int, pf_getc, (void *userdata));
>   AL_METHOD(int, pf_putc, (int c, void *userdata));
>   AL_METHOD(long, pf_fread, (void *p, long n, void *userdata));
>   AL_METHOD(long, pf_fwrite, (AL_CONST void *p, long n, void *userdata));
>   AL_METHOD(int, pf_fseek, (void *userdata, int offset));
>   AL_METHOD(int, pf_fclose, (void *userdata));
> };
>
> AL_FUNC(struct BITMAP *, load_bmp_pf, (PACKFILE *f, struct RGB *pal));
> AL_FUNC(struct BITMAP *, load_pcx_pf, (PACKFILE *f, struct RGB *pal));
> AL_FUNC(struct BITMAP *, load_tga_pf, (PACKFILE *f, struct RGB *pal));
> AL_FUNC(int, save_bmp_pf, (PACKFILE *f, struct BITMAP *bmp, AL_CONST 
> struct RGB *pal));
> AL_FUNC(int, save_pcx_pf, (PACKFILE *f, struct BITMAP *bmp, AL_CONST 
> struct RGB *pal));
> AL_FUNC(int, save_tga_pf, (PACKFILE *f, struct BITMAP *bmp, AL_CONST 
> struct RGB *pal));
> AL_FUNC(SAMPLE *, load_wav_pf, (struct PACKFILE *f));
> AL_FUNC(SAMPLE *, load_voc_pf, (struct PACKFILE *f));

Mm.. I'm not sure, honestly. I think if we're going to do something like 
this, it should be as integrated as possible. The PACKFILE_VTABLE is a 
good idea, but I think it'd be better if the user could supply callbacks 
that'd effect the normal pack_* routines. So you could have:

struct PACKFILE_VTABLE
{
  AL_METHOD(int open, (char *ptr, const char *mode, PACKFILE *pf));
  /* 'ptr' is effectively what was passed as the filename to 
pack_fopen. 'pf' is a pre-allocated PACKFILE struct. It returns a set of 
flags with its capabilities: CAN_SEEK_REL_FORWARD, 
CAN_SEEK_REL_BACKWARDS, CAN_SEEK_ABSOLUTE, etc. A return of -1 means 
failure. */

  AL_METHOD(void close, (PACKFILE *pf));
  /* Closes the packfile and frees any necessary resources created in 
'open'. Do *not* free the 'pf' pointer! */

  AL_METHOD(int, getc, (PACKFILE *pf));
  AL_METHOD(long, fread, (void *p, long n, PACKFILE *pf));
  /* Self-explanitory. If either is NULL, the packfile is write-only */

  AL_METHOD(int, putc, (int c, PACKFILE *pf));
  AL_METHOD(long, fwrite, (AL_CONST void *p, long n, PACKFILE *pf));
  /* Self-explanitory. If either is NULL, the packfile is read-only */

  AL_METHOD(int, pf_fseek, (PACKFILE *pf, int offset, int whence));
  /* Seeks through the packfile. You will never get a request for a 
type of seeking you did not specify when returning from 'open'. If open 
returned no seek flags or if this is NULL, seeking is not possible. */

  /* Followed with additional "chunk" functions. I don't know what's 
needed, but if there's insufficient entries (too many NULLs), packfile 
chunks are not possible. */
};

So basically, if you had a PACKFILE_VTABLE to read from memory instead 
of disk, you could do:

SAMPLE *smp = load_sample((const char*)memptr);

and as long as the VTABLE is properly setup, it'd convert a wave/voc/etc 
in memory into an Allegro SAMPLE. Of course you'd need to be careful 
about the length of the memory, but that'd be up to the user to worry about.

Whatever we do though, I think the current packfile routines should be 
fully implementable in a vtable (and be the default vtable used).