RE: [AD] Possible new features for Allegro?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Title: RE: [AD] Possible new features for Allegro?

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

The only one I know of than can be used with Allegro is JGMOD,
and I believe its author is no longer maintaining it, and was
not cross platform (though I think someone made it work on
Linux). If we set aside the fact that MOD is more and more
getting passe', I see such things as making sense to be in
a lib like Allegro. There definitely is some advantages of
a music lib being on top of Allegro's voice system. Sharing,
prioritization, and direct control on voice parameters come
to mind. I'm not suggesting for a MOD player to be included
right now though :)

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

Agreed. The main concern I have with this is that it mostly
doesn't work. *IF* it was working, then it would be cool to
have something like CPAN (which I never used), which is a
directory of modules for Perl. That would be cool, but can
only work because there are enough people to do the work.

> 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

Huh ?
It's so much easier to split stuff! The dist files are in a
separate directory, and you just add -lfoo to the link command.
You point out the flaw in this yourself there:

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

Installing the library is actually simpler in another directory
than directory in your own source tree, especially if you have
several projects using it!

--
Vincent Penquerc'h



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/