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

["Kirk Black" <runesabre@xxxxxxxxxx>]

This is my personal viewpoint as an Allegro user.

I'm starting an MMO company (my lawyers tell me it was officially formed
this week!).  Allegro is the cornerstone of my client application.  I
selected Allegro back in Sept 2005 for the reasons below:

1.  Built-in GUI system.  I'm predominately a server / systems programmer.
While I will probably eventually roll my own UI system, the built-in Allegro
GUI system was an enormous leg up for me in the beginning.

2.  Built-in image loading for several formats.  I'm several months away
from going Live.  Allegro gives me a lot of flexibility to play around with
various image formats before I have to decide which format I will use.  

3.  Built-in text output, dynamic font and Unicode support.  I intend to
support other languages including Japanese, Korean, Chinese.  Knowing I will
be able to fully handle all my localization needs was a MAJOR plus for me
deciding to go with Allegro.  This will allow me to increase my distribution
possibilities which in turns increases my total potential subscriber base.

4.  Cross-platform.  Much like #3, Allegro's slick and easy cross-platform
allows me to release on more platforms which in turns increases my potential
subscriber base.  Allegro completely takes care of the cross-platform tasks
leaving me to completely focus on the game.  I've never programmed a game on
Linux or Mac and yet I've got a fully functioning game client running on
both of those platforms as well as Windows.

As mentioned in #1, I started this whole venture as a server/systems
programmer.  I've learned graphics programming along the way, much to the
credit of Allegro being easy to use and generally doing the right thing when
the need arises.  It's been quite a joy using Allegro because I know when
the time comes to implement something different, Allegro will be there with
minimal fuss.

I doubt I would have been as enthusiastic selecting Allegro if it were
broken up into pieces and required me to understand how to configure it
every time I needed some new functionality.  I might have passed it over
completely or given up on it.  I'm already hesitant to use PNG or any
hardware acceleration library that would get me better performance on Mac OS
X because it's not built-in.

If it is decided to break Allegro up, perhaps it can be done in a way that
maintains the ease of use of Allegro for new users, while, allowing more
experienced Allegro users to later decide to turn off features rather than
forcing new Allegro users to figure out what features to turn on before
using it.

With that said, if significant effort were to be expended on Allegro, these
are the things that would thrill me as an Allegro user and have a real
impact on my use of Allegro:

1.  More hardware acceleration for Linux and Mac.  Currently, only my
Windows application seems to be getting any hardware acceleration.  My Linux
and Mac clients don't seem to be getting any acceleration.  It's mostly
noticeable on my Mini Mac which struggles to keep itself going above 50
frames a second.

2.  More platforms, particular PDA and cellphone platforms such as Windows
Mobile PC.  The thought of being able to run Allegro applications on mobile
platforms is really tantalizing.  I also hear there is an XBox port for
FreeBSD.  Running Allegro on Xbox would be pretty big.

3.  A non-modal UI system.  The current UI system is good to get things
started for non-game UI screens such as login or character selection but not
really useful for in-game UI.

The greatest thing about Allegro is it's easy to use and it has everything
one needs to create a complete game application and not simply just a
graphics library.  It's truly an incredible library.

Kirk Black 

 
-----Original Message-----
From: alleg-developers-admin@xxxxxxxxxx
[mailto:alleg-developers-admin@xxxxxxxxxx] On Behalf Of Victor
Sent: Friday, March 24, 2006 3:28 PM
To: alleg-developers@xxxxxxxxxx
Subject: [AD] Allegro plug-in system (was: Is there a licensing reason why
PNG isn't built-in to Allegro?)

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/


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
-- 
https://lists.sourceforge.net/lists/listinfo/alleg-developers