Re: [AD] Possible new features for Allegro?

[George Foot <gfoot@xxxxxxxxxx>]

On Thu, Dec 13, 2001 at 10:27:25AM -0000, Vincent Penquerc'h wrote:
> In reply to the thread in general:
> 
> I'm sounding like the devil's advocate, but I don't see the
> problem with what some call the "Allegro bloat". The trouble
> I have with bloat is when stuff is interdependant, or slows
> down the main stuff. You shouldn't pay for what you don't
> use, but that's no reason to put everything aside because
> you think the number of things you already have in the lib
> is too high. It would matter only if these things were so
> entangled that changing one would require changing the others.

I can see your point.  Download sizes are possibly my main issue
with including things hardly anyone uses.  Other people seem to
object to including a MIDI player if we don't also include a MOD
player (despite the fact that many different good MOD players
exist, and their authors enjoy writing them).  Similarly (and
especially) for graphics file formats.

Here's another option, apart from splitting off this stuff:
Provide the requested additional drivers, for jpg, gif, mod,
it, s3m, etc, but put them all into one addon, officially
maintained, but under a different license (to suit whichever of
these things don't work in the Allegro license).  We could just
put certain source files under different licenses; maybe that
would be most appropriate.  People can leave out files they
don't want, if they don't like the licenses.

Overall though, for small things like image loaders, I lean
towards having drop-in files rather than separate libraries (and
DLLs).  These get staticly linked, are registered with Allegro
by a function call (maybe automatically via a constructor), and
then behave exactly like part of the library itself.

I kind of like the idea of small libraries (more than one source
file and headers but not too many) being statically linked
anyway, not even as a library -- in many cases, the simplest way
to use a library is just to link its source files with your
binary.  Potentially AllegroGL could work like this, though it's
perhaps a bit big.  The main worry with this is upgrading the
library, which is simple for one project (delete the files,
relpace with new versions) and complex for many projects (need
to do it to each one individually).  But you don't need to
distribute more DLLs, don't need to worry about library build
problems, installing, etc, and can just zip up your favourite
version of the library along with your source code when you
distribute that.  So people using your source also don't need to
install the library.

Obviously that would be hell for large libraries, because it
would seriously bloat the download of your source code, but for
small ones I think it makes sense.  Note however that the linker
does not strip unused code if you do this (only if you use -l).

> Sure, there is quite a bit of interdependant stuff at the
> moment, but it doesn't mean adding, say, networking, would
> add more. Networking would get dependant on some of Allegro's
> stuff, but not vice versa. De-entangling stuff would be nice,
> but, as long as candidates for addition are not too esoteric
> or non-standard or similar "qualities", and that they are
> useful for game programming, I see no reason to deny them
> without another reason.

As someone who (on and off) maintains a couple of kind-of addons
(AllegroGL is an addon; Libnet isn't really as it doesn't use
Allegro), I find it *much* simpler to do this when they're not
part of Allegro.  Basically, in these packages I have a lot more
freedom to do what I like; there are less policies to worry
about, less people using them who would be affected by a broken
release, and so on.  But I know Bob would like to merge
AllegroGL, so he'd obviously prefer it that way around. :)

George