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