Re: [AD] native image loaders

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2010-04-09, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Fri, Apr 9, 2010 at 9:16 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > On 2010-04-09, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> > The current plan is not fully consistent, but I think it's simple:
> >
> > - link with allegro_image => you get PNG/JPEG/BMP/TGA/PCX [*]
> > - link with allegro_flac => you get FLAC support
> > - link with allegro_vorbis => you get Ogg Vorbis support
> > - link with allegro_modaudio => you get XM/IT/S3M/etc support
> > - link with allegro_jp2k (hypothetical) => you get JPEG2000 support
> >
> > [*] on all platforms these are essentially "free"
> >
> Then you'd need to make PNG and JPEG absolute requirements for
> building Allegro image, even on Windows. Otherwise, you have the same
> problem: your program may or may not be able to load the images. And
> if you don't want to make them requirements, then they have to be in
> their own add-ons to ensure that everything works.

Right.  That was my intention since suggesting the GDI+ backend.

> GDI+ should help for Windows, but currently it is buggy on Vista. Even
> assuming that can be fixed, MinGW doesn't have native support for it,
> so those people would still most likely have to get libpng and
> libjpeg.

Hmm, I didn't know that.  It's a bit unfortunate, though we can't build
Allegro with the DirectX headers as distributed with MinGW either.
Can we find/provide a minimal header?

Hopefully the problem on Vista can be solved.  I notice that the
problems seem to only concern BMP files.  There is no reason we can't
still use our native BMP routines.

> I'm not particularly opposed to what you've detailed above, but I
> think it lends itself to arbitrary inclusions and exclusions based on
> what we think is popular today.

No doubt.  Popularity will always play a role here, otherwise we have
little reason to reject anything.

> Your concerns are valid, but I'm not
> sure they have any significance in the common-use sense.
> 
> Basically, you won't ever be able to guarantee that anything works
> unless you provide a complete binary package, core Allegro and all.
> 
> On Linux, people would have no reason to disable libpng, etc. But even
> if they did, on the first program they got that said, "Sorry, you need
> to add PNG support," they would recompile Allegro with PNG. Never more
> a problem. Say it happened with MOD files, which is something less
> likely to be installed. Regardless of modular vs monolithic, you'd
> have to recompile/compile *something* to add support. It's no less
> trivial to go back and build modaudio as a stand alone add-on. It
> might be of some concern if a package maintainer decided to not
> include support for something, but dynamic loading of dependencies
> could help with that.

Ok, true.  If we had dynamic loading then it wouldn't be an issue.

> What are your thoughts regarding the usefulness of explicit loader
> functions (e.g. al_load_bmp)?

I don't see much reason for them.  I think they are there because A4 had
them, and I think the only reason to use them in A4 was to load/save
with non-standard extensions.  But that's achievable with the _f
functions anyway.

Peter