Re: [AD] Miscelaneous issues

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2005-04-01 at 00:46 +1000, Peter Wang wrote:

> That's a text file that looks like this:
> 
>     unsigned char pcx_block[] = "...";
>     unsigned char tga_block[] = "...";
> 
> where the string are octal codes generated with this little hack:
> 
> /* begin */
> #include <stdio.h>
> 
> int main(void)
> {
>     int c;
>     while ((c = getc(stdin)) != EOF) {
>         printf("\\%03o", c);
>     }
>     return 0;
> }
> /* end */
> 
> Hope that helps.

Yes. Also, which bitmaps should be used? Or maybe the generation should
be done at runtime..


> >-   int hndl;                   - System file handle
> >-   int flags;                  - PACKFILE_FLAG_* constants
> >-   char *filename;             - name of the file
> >+   AL_CONST PACKFILE_VTABLE *vtable;  - The PACKFILE_VTABLE for this packfile.
> >+   void *userdata;                    - The user data.
> >+   int is_normal_packfile;            - Flag telling if this is a normal Allegro
> >+                                        packfile.
> > <endblock>
> >    A packfile structure, similar to a stdio.h FILE structure. Read chapter
> >    "File and compression routines" for a description on how to obtain/use
> >    this structure.
> >  
> >
> 
> Don't have time to check, but should we really be exposing this kind of 
> thing in the documentation?

Hm. I guess not. Also, the old, documented fields were removed. But
there's nothing that can be done about it, and they shouldn't have been
used by any code despite being documented. So, the best thing is
probably to just make it an opaque structure. Evert: Should I create a
new patch, or apply with the change? 


> Ah, you skimped out :-)  In a later version we ought to have detailed 
> descriptions of the intended semantics of each of the vtable methods 
> (more detailed than what we have currently for the pack_* functions).
> 

Yes, that's why I called it "quick docs" :P I completely agree though :)

> [snip]
> 
> >+@@BITMAP *@load_wav_pf(PACKFILE *f);
> >+@xref load_wav
> >+@shortdesc Packfile version of load_wav.
> >+   A version of load_wav which reads from a packfile.
> >+
> >  
> >
> 
> It may be important to state which of the load_*_pf variants need 
> pack_feof() to know when to stop reading.  IIRC load_wav_pf is one.  On 
> the other hand, if you just concatenate all your files without imposing 
> a chunk structure and expect the loaders to stop at the right places, 
> you're asking for trouble.
> 
> Thanks for doing the leg-work.
> 

Hm, I think I understand. But generally, pack_feof can always be
provided, so then there never should be a problem, right? Still,
wouldn't hurt to document it - but I'm not sure how I can find out where
it is needed, besides reading through the code of all the loaders.

-- 
Elias Pschernig