Re: [AD] native image loaders

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2010-04-10, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> There is actually a C++ class that is defined in the GDI+ headers, so
> it's not as trivial as simple function declarations. But technically,
> it should be possible to build a working version for MinGW.

I think the preferred solution for MinGW will be to build with
libpng/libjpeg.  For distribution the allegro_image DLL can be replaced
with one produced with MSVC which uses GDI+.

> > Hopefully the problem on Vista can be solved.
> >
> I think I fixed it now.

Great!


On 2010-04-10, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Sat, Apr 10, 2010 at 1:51 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > On 2010-04-09, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> >> 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.
> >>
> > Ok, true.  If we had dynamic loading then it wouldn't be an issue.
> >
> I don't mind writing the dynamic loading code myself if that means we
> can do away with allegro_flac, allegro_ogg, and allegro_modaudio, etc.
> I assume that only image/audio loading routines are candidates for
> dynamic loading, since the rest of Allegro is pretty much well
> defined. The benefit of dynamic linking would basically be for Linux
> distro packages, as you could then build Allegro without absolutely
> depending on something as trivial as libdumb. I don't particularly see
> it as useful on Windows.

I thought it would be more useful on Windows, to avoid the problem where
the game developer distributes DLLs irrelevant to his game.  Basically
people on A.cc posting little demos bloated by an extra MB.

On Linux, the only potential hiccup is DUMB (at least for now).

> I guess it wouldn't hurt to make dynamic coding optional... that is,
> you can either link at Allegro compile time, or defer it to run time.

Disabling dynamic loading is also useful for Allegro developers.

> I wouldn't object to certain formats being made mandatory by the build
> process: PNG and JPEG to guarantee a minimal subset of behavior. It
> might actually give people incentive to not use BMPs for everything.
> :P (Plus, it's something that is easy to change in the future.)

> I don't see any reason to make any audio codec mandatory (other than
> trivial ones like WAV). Within the regular scope of Allegro, audio is
> never "required." Obviously people would have to check for NULL
> pointers.
> 
> I suppose it would look like:
> 
> int acodecs = al_init_acodec_addon(ALLEGRO_ACODEC_VORBIS | ALLEGRO_ACODEC_FLAC);
> // int acodecs = al_init_acodec_addon(ALLEGRO_ACODEC_ALL);
> if (acodecs & ALLEGRO_ACODEC_VORBIS) { /* vorbis is available */ }
> 
> At init time, the external libraries could be dynamically loaded if needed.

I suppose the parameter to al_init_acodec_addon is so the user can load
only the formats that are required.

I was thinking that we would defer loading until the particular format
was actually required.  The user wouldn't need to state upfront which
formats are required.  It should be only slightly more complicated.
Control over which modules are loaded could go in the Allegro config
file, if necessary.

I would also like to remove the parameter to al_install_audio(), if
there are no objections.

Peter