RE: [AD] Possible new features for Allegro? |
[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]
> 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/ |