[AD] Allegro plug-in system (was: Is there a licensing reason why PNG isn't built-in to Allegro?)

[Victor <vwss1984@xxxxxxxxxx>]

So, It looks likes that allegro should:

1. Have a very light basic stuff core.
2. Put BMP, PCX, WAV, MID, FLC/FLI, joystick stuff apart of allegro
core in something like a "allegro standard plug-ins package". (Probably
a few non-core things would still left in the core, but this should be
keeped in the minimum).
3. Create some type of simple, effeciently (and if possible backward
compatible) plug-in structure.

After that, allegro would be more mainteneable. Some already well-known
plugins, like Allogg and AllegroGL will benefit from this plug-in
system and will no more get out of sync with allegro version (and
eventually they'll be found in the standard plug-ins package). The
creation and implementation of other types, alternative and/or third
party plug-ins would get easier.

So someone who thinks in creating a game which use just some part of
allegro, don't need to get all the other things around.

On the negative side, this could increase the complexity of the
implementation and the user would get multiple DLLs (one for the core
and one for each dependency), which isn't good, specially when their
versions get out of sync. But i think that it wouldn't be hard to
workaround this.

Just a idea...

Victor Williams Stafusa da Silva

--- Elias Pschernig <elias@xxxxxxxxxx> escreveu:

> On Fri, 2006-03-24 at 19:02 +0200, Siarhei Siamashka wrote:
> 
> > > It would add more dependencies.
> > > I think we're about pulling all bitmap format stuff out of
> allegro core.
> > 
> > One of the reasons to use allegro is that is packs all the needed
> > functionality for developing games in it and avoids extra
> dependencies.
> > As allegro is not a 'mainstream' library, stripping it into parts
> will
> > make using it much more complicated.
> 
> I think, it's mainly a question of packaging. Already now someone
> could
> distribute a version which has useful addons included.
> 
> I'd like something like SDL-image for allegro 4.3, so all the image
> format loaders would be a separate package (also the useless formats
> that are now built into the core, like BMP, TGA, PCX), and then it
> would
> make a lot of sense to specify at configure time that you want e.g.
> PNG
> or JPG support included. Again, packages could contain both
> allegro-4.3-core (with no image formats at all) and
> allegro-4.3-imageformats, to form a complete and easy to use library.
> 
> One small problem is licensing, probably would just require the
> packager
> to read through the zlib license though if it is possible.
> 
> > 
> > Why not intergating loadpng and jpgalleg into allegro with the
> > possibility to disable them on configure step? Linux kernel does
> not
> > seem to suffer from bundling lots of device drivers with it as only
> > those that are needed by the end user are really compiled and they
> do
> > not add any 'bloat'.
> 
> Yes, the linux kernel approach might also work. Then we would simply
> pull the libpng sources into the allegro SVN. But I don't know,
> somehow
> I dislike it.
> 
> > The reason for this suggestion is simple, as far as I know, current
> > jpgalleg is NOT amd64 compatible. If it was a part of allegro
> library,
> > that portability issue would have been resolved long ago.
> 
> Well, the developer situation is not good at all for allegro, and
> jpgalleg is a very special library (Angelo wrote his own decoder
> instead
> of simply using libjpeg) - so not sure one of the allegro devs would
> like to debug that code.
> 
> -- 
> Elias Pschernig
> 



		
_______________________________________________________ 
Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. 
http://br.messenger.yahoo.com/