[AD] native image loaders

[Matthew Leverton <meffer@xxxxxxxxxx>]

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+
...

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.

What about just getting rid of the functions like al_load_png,
al_load_jpg, etc in favor of simply:

al_load_bitmap(filename, const char *type)

* if type is null, auto detect based on extension

al_load_bitmap_f(filename, const char *type)

* type is required

Or even:

al_load_bitmap_type(filename, const char *type)

and keep al_load_bitmap() as is.

GDI+ supports PNG, JPEG, TIFF, GIF, and BMP.

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

---

Would it be possible to give people the choice of a) including
JPEG/PNG as part of the core image or b) as a separate addon? e.g.,
allegro_image would always have the same, well-defined external
symbols: al_init_image_addon, al_load/save_bitmap, and
al_load/save_bitmap_f. Support for JPEG may or may not be included.
Same could go for audio. But you could always create allegro_jpeg,
allegro_modaudio, etc if you wanted those features to be optional.

Just throwing out ideas...

--
Matthew Leverton