[ Thread Index |
| More lists.liballeg.org/allegro-developers Archives
On 2011-07-19, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Tue, Jul 19, 2011 at 1:27 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > Is al_get_fslice_size different from al_fsize?
> Err, no... it's exactly the same function. It used to be something
> else, but obviously it's not needed anymore.
> > This seems like a good idea, for keeping the code simpler (although, if
> > you have written the code already..).
> I already wrote the code, but as I was writing it and keeping a list
> of all the "gotchas," it started to seem less and less useful.
> > Does this mean if you want to layer a random access file on top
> > of a sequential file, you will need to manually read from the
> > sequential file and copy the bytes into a memfile?
> Yes, but I was considering a new memfile function. I keep going back
> and forth with myself while writing this email ... Perhaps a single
> function is okay, but I should just make it more simple:
> * If unbuffered, then it must be read-only. The file interface must
> support random access. This is still perfectly useful when loading,
> say, a TGA file from within a larger block of data on a local file.
> * If buffered, then it may be written / appended to, BUT, the data is
> never actually sent to the underlying file.
That still sounds complicated. I prefer your previous suggestion
to remove any buffering from file slices. Then file slices are
analogous to sub-bitmaps, and memfiles are analogous to memory bitmaps.
Regarding al_get_fslice_buffer (or whatever). If the buffer is
expandable then the pointer can be moved, so I guess the pointer will
only be valid until the next write. The implementation can use multiple
buffer fragments or whatever, up until the user wants a pointer to the