Re: [AD] implementing seek

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2010-04-07, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> How does seeking work with Allegro file streams? For instance, say you
> have a binary blob file that contains three consecutive images. Is the
> following supposed to work (guaranteed)? (Let's assume that byte size
> of each bitmap can be determined exactly while reading.)
> 
> ALLEGRO_FILE *f = fopen("images.blob", "rb");
> ALLEGRO_BITMAP *bmp1 = al_load_bmp_f(f);
> ALLEGRO_BITMAP *bmp2 = al_load_bmp_f(f);
> ALLEGRO_BITMAP *bmp3 = al_load_bmp_f(f);

No, I don't think so, because some formats are be arbitrarily long
with no indication of the length until you hit the end.

> I ask because the GDI+ load routines do a lot of seeking forward and
> backward. When loading mysha2.bmp, it appears to load it from end of
> file to beginning of file with a seek from set before every read.

Probably because BMPs are stored upside-down.

> I haven't tested it, but I assume that with my crude GDI+ loader, it
> would actually load the first image three times. (I know how I could
> work around it at the gdi loading level... that's not an issue.)
> 
> So, basically, is there any type of function like:
> 
> al_fopen_f(ALLEGRO_FILE *f, size_t length)  ???

No.

> And secondly, should a call to al_load_whatever_f() always set the
> current position to the end of the data chunk (if it can be
> determined)? e.g., I know that in the DUMB readme, Ben specifically
> mentions that he cannot (or does not) determine the actual length of
> the mod file, so if you want to consecutively load them from packfiles
> (allegro 4), you have to manually seek to the next spot after
> finishing reading.

I think it's a good idea, when possible, but not mandatory.

> And finally, do I (as a writer of an image / audio loader) need to be
> concerned about any forward-only seeking files?
> 
> Maybe I'm just over analyzing things, but it seems like people
> wouldn't expect an image loader to fail due to it seeking backward on
> a handle that only can seek forward.

Probably.  Maybe we need a type of ALLEGRO_FILE that implements a memory
buffer over the top of a seek-forward-only ALLEGRO_FILE.

Peter




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/