Re: [AD] native image loaders

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2010-04-10, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> On Fri, 2010-04-09 at 17:33 -0500, Matthew Leverton wrote:
> > I'm ready to integrate the GDI+ image loading and saving routines.
> > However, first I think we need to come to a final determination on how
> > images should be handled. The main question is whether or not the
> > image addon should be modular like the audio codec one. e.g., should
> > there be:
> > 
> > allegro_image (any native format that requires no external dependencies)
> > allegro_jpeg => libjpeg or apple loader or GDI+
> > allegro_png => libpng or apple loader or GDI+
> > allegro_gif => GDI+
> > allegro_tiff => GDI+
> > ...
> 
> I wouldn't see it as a big problem... and it would be consistent with
> how our audio addons work. But then again I don't think it's necessary.

I think it would be annoying.  I definitely want to see PNG/JPEG in the
main allegro_image addon.  allegro_image can support further formats on
different platform if they come "for free", though we should strongly
encourage developers to stick to PNG/JPEG/BMP/TGA/PCX for portability.

Guaranteed support of other formats (GIF/TIFF/JP2K/etc) would go into
separate addons.

> > That could get ugly, especially as there is overlap between back-end
> > libraries. And if you had allegro_gdi, that would duplicate
> > functionality of allegro_jpeg. (I think there are fewer commonly used
> > audio codecs... or at least, their differences are more well defined.)
> > 
> > Right now, it's less than ideal because (e.g.) al_load_jpg is always
> > present in the header, even if it's not compiled in. But that can be
> > fixed regardless.

I was thinking that (e.g.) al_load_jpg should always have a valid
implementation, even if you are not using libjpeg.

> > Or even:
> > 
> > al_load_bitmap_type(filename, const char *type)
> > 
> > and keep al_load_bitmap() as is.
> 
> I think I prefer that.

Me too.

> > Personally, I never use the direct functions and find the myriad of
> > function names to be rather ugly.

About the only use for them is if you want to avoid the extension
registration table for some reason.  I don't know why.

> What about the save functions? I guess we could just have the same three
> functions you suggested for loading:
> 
> al_save_bitmap(bitmap, name)
> al_save_bitmap_type(bitmap, name, type)
> al_save_bitmap_f(bitmap, name, type, file)
> 
> (Also, why do our current al_save_bitmap functions have the parameters
> swapped?)

The current order makes sense as well.

Peter