I've noticed that on the OS X port the function al_load_bitmap_f() is not completely implemented. It currently reads in the entire file, making it not work with my custom formats. Often I will have a PNG or set of PNGs embedded in a larger file and with the current native image loader all data past the first embedded image is skipped, causing my loaders to break.

Are there any plans to fix this? If not it would be good to mention somewhere that this functionality is broken in the native image loader so someone what wants to use it on OS X will know to turn WANT_NATIVE_IMAGE_LOADER off.

I'm not sure I understand what the problem is and so I'm not sure what to suggest (but if you're putting multiple resources in a single file, the proper way to deal with that is to write an I/O interface for it, but the easiest thing to do is go through PhysFS).However, if there's a problem and you have a way to fix it, we gladly accept patches.

This works perfectly with the Allegro image loaders but fails on the OS X native loader (haven't tried the Windows native loader). I already looked at the code for the native loader and I can't see any obvious way to fix it. It would require knowing the size of the embedded image file ahead of time and there's no way of knowing that without adding some extra code to read to the end of the image. I didn't see anything in the CGImage API that would be useful for this.

I already looked at the code for the native loader and I can't see any obvious way to fix it. It would require knowing the size of the embedded image file ahead of time and there's no way of knowing that without adding some extra code to read to the end of the image. I didn't see anything in the CGImage API that would be useful for this.

That's what I was afraid of.Is it possible to figure out after the fact and seek to that location in the file?

Since the function exists and doesn't work then it needs to be fixed. There is no note of "not gauranteed to work" in the manual. If the al_load_*_f() functions are meant to be used with memfiles then it should be noted somewhere.

Since the function exists and doesn't work then it needs to be fixed. There is no note of "not gauranteed to work" in the manual. If the al_load_*_f() functions are meant to be used with memfiles then it should be noted somewhere.

They aren't meant to work only with memfiles, but they do require a full random access I/O interface that represents a single file.

The native loaders (that we didn't write and have no control over) might do something like seek(SEEK_SET, 0) or seek(SEEK_END, 16). If you supply a pointer to a something that represents more than a single file, there's no way for Allegro to guarantee that it works.

I don't think the proper solution is to try to hack Allegro to work around those limitations in every single loader and saver (images, sounds, fonts, etc). Instead, file slices could be used over top any underlying interface.

In this case, the slice is opened with an initial length of 0 for read (r) and write (w) and is expandable (+).

A slice is always opened up at the current position of the file. (Opening two slices on the same file at the same time is undefined.) When closing the slice, the original file is moved to the end of the slice.

I was also considering a "memory buffer" (m) option that would automatically store everything in memory so that it could be used for write only streams. For example:

The native loaders (that we didn't write and have no control over) might do something like seek(SEEK_SET, 0) or seek(SEEK_END, 16). If you supply a pointer to a something that represents more than a single file, there's no way for Allegro to guarantee that it works.

The docs should mention that the stream passed to the al_load_*_f() functions should represent a single file or else the behavior is undefined. Maybe even suggest using a memfile (or slices if those are implemented) so people can understand how to use them. I know I am not the only one who assumes you can just pass an open ALLEGRO_FILE stream. I can see the writer of the OS X loader was assuming this, too, based on the comments in the code.