What I failed to mention is that in almost all cases, one would compile Level1 as official "current" distro. That way, if people want to just use the core hardware libraries, they can compile a core version of the library (something like alcore40.dll and liballegcore4x) so the already existing "user friendlier" functions are not clogging their programming. Of course, one could also create an official allegro-full distro that has all of the level2 addons in it as well. (something like alfull4x.dll and liballegfull4x). Level one would be the standard liballeg and alleg4x.dll. This way, one has the option to download the entire full-blown prepackaged monster. This pleases people like me that want it all in one nice, neat package, while at the same time pleasing those who want their current packaging system. It also allows for people to compile programs in a much smaller blueprint than previously possible as well. For example, a person could install the core, then use the static-link version of their level 1 and level 2 libraries (which is the current system right now).

As for X-G's comment about "now we have a 40mb library." That is just dumb. The distro itself is a little bit over 2.5mb right now, and that is including demos, examples, documentation, and tools. For our 56k modem friends out there, that is still relatively decent download size. If the demo was completely ripped out and placed as a seperate download, as well as the examples, documentation and tools, the library size that is required to get started is even less. True, it still needs to be available in an all-encompassing package for those who want it.

I'm going to write up a pdf proposal on what exactly I'm saying here.

Eww...

So, if I download AllegroFull (core+level 1 and level 2 addons), and somebody uses AllegroCore (core and nothing else), I'll have to get core, too? Or if I have the core and someone uses full, I'll have to scrap what I have and get full?

And don't even suggest allegxx.dll, allegxx-level1.dll, allegxx-level2.dll, etc. That is just plain ugly in WIndows.

I just don't see it as a good solution. I think it's pretty obvious that the core-only distribution is mostly worthless. You can get the same functionality, plus some nice useable extras, by getting the standard at no real extra cost other than a few minutes extra download time (if that). It would just be a waste of time to support.

A similar thing would be true between standard and full. Either people will use the full distro, requiring others to use full if they want to use others' programs, and basically make standard worthless.. or not have many people use full, and make that worthless to package up.

Well, I guess a modification on that scheme would be a to just distribute full and have those distictions only internally, just to expidate development in various areas.

I don't know. All I know it is dang annoying that I have to download packages A to do B, C to do D, E to do F, each with their own little itiosecrecies, build problems, differing build methods, seperate downloads, varying quality documentation, and bugs. Especially when the features provided by A, C, and E could reasonably be integrated into a single Allegro Distribution that could be used to do it all.

Maybe we could do this: We could have allegro, than someone else could maintain allegro: bloat edition that has every single concievable addon, library, etc. within it.

All I know is that it is dang annoying to have to download all sorts of weird crap just to get one thing to work quickly and the way you want it to. Not fatally annoying, just annoying.

Just one remark, as I was thinking about that: Instead of having one dll for each level - alcore, allevel1, alfull - I would prefer alcore, aladdon1, aladdonfull or somthing, which means that for the full thing you would need all 3 dlls. That way programs can remain compatible like requested by somebody above.

Hi,

We had a burning discussion on this in #allegro yesterday ....

These were my views in the discussion:

1. Allegro currently puts certain implementation specific code into the same distribution. So why not separate the base from the extensions part? For instance, when bitmapping routines may be part of the base library, the bitmap file loading code and the driver specific code could be put into the extension libraries ... People who need a single binary distributable could link statically with the extensions. The whole point in removing the core part is, if there's a major patch in the one part of the library, the other one can be used as-is. It solves problems of big DLL overhead for those developers who don't want all the functionality.

2. About having many DLLs, your system already has too many of them. Think of it, Allegro uses DDraw, DInput and DSound!!! So why not put it separately when it can be beneficial for the development process? As such, the newbie doesn't bother if the re has to be a -lalleg or -l albase -lalstddext -lalmp3ext -lalaviext .. he just follows the manual and things are OK.. For other *nix platforms, there can be appropriate .so files instead of the DLLs ..

3. The Allegro core system currently has so many restrictions on how to plug newer things into it, and it becomes a mighty hack as to which extension library uses the core how .. each one has it's own separate code. Now, some developers do agree that it would be useful to put in certain things like PNG and MP3/Ogg decoding ino the core library and not as an extension. But then, they are already out there as extensions. So, the point here is, if the base of the library could be tweaked to remove the implementation specific file loading parts out, it might be easier to add on a BITMAP * loadPNG() or a SAMPLE* loadOV() into Allegro's extension library ...
It wouldn't lead to a new base release then. Only an extension release... (agreed that the WIP versions may not be backward compatible)

Frankly, I don't know. But it's marked as deprecated in recent XFree86 versions and X.org, so...

Yes, Allegro needs more modularity and it needs new things too. This has been discussed and agreed on. It `just' needs to be done.
Personally, I think a dedicated networking addon would be better than something hacked into Allegro, but maybe it's something to bring up again a bit further down the 4.3 branch.

The idea behind Allegro's proposed plugin/addon system is to make it more of a homogeneous whole. Ideally, Allegro's installer/makefile would be able to detect plugins and build them automatically for the current platform:
`Oh, I need Allegro-png.' - download into allegro/plugins - run fix/make/whatever from Allegro's base directory and allegro-png gets build and installed correctly for your platform.
Someone needs to do work for this though.

No, but the question to ask is if it is worthwhile to do: if there is already a freely available library out there (HawkNL is, last I knew, GPL, so you may not want to use it for licensing reasons) do you spend valuable developer time on making yet another network library? I don't think we should want to reinvent the wheel if someone else already figured out how to make a round one.
I would also like to point out that it is not nescessarily less likely that Allegro is abandoned than HawkNL is.
What I would really like is to have libnet resurrected and brought up to date: it's license is like Allegro's license and it's documentation, if not like Allegro's, is fairly decent. More so than HawkNL's, although that may have changed since I last looked at it.

Will do, when I have time.

is better than:

"W00t! Thing does every darn thing: BMP, PNG, JPG, XCF, GIF.. what not?!! And every time there's a bug in one of these loaders, we get a new release!!! COOL!! "

There won't be a problem the way I see it. As it is, the user will only be interacting with the implementation specific code more than the base... I don't see how this is going to affect him much

Probably all future EXEs will carry an allegro-runtime installer, just like every commercial game ships with DirectX. Face it, it's also easier if runtime installers are available for platforms like Linux, which can make it far easier for users to install and play Allegro game binaries..

Is FLIC code all that common? Or LBM loaders? Face it, time changes. Yeah, probably all this helped people develop the games of yesterday.. and probably it will help, for a few more days.. And then, all of a sudden, you'll just trash Allegro away when you realize that this framework is too rigid and you need to get more and more extra libraries than just Allegro? No way! If Allegro needs everything, you'll have to put it in without affecting the core of the library. That's the whole point.

Well, I didn't mean that these extensions should be kept separate from the main library.. as such, the whole distribution will contain the allegro base plus its standard extensions (say BMP, LBM, PCX) .. it's supposed to work just like in OpenGL 2 .. when GLSL 1.0 became part of the core..

When you know that your whole core is wrong, you wouldn't expect ur alleg41.dll (4.1.18) to work with something done with Allegro 4.1.16 .. So I don't see why a set of Allegro DLLs or a single DLL could be a issue Also, if the core is stable, it might never need any update at all Or if the PNG whomsoever decides that it's time for a new PNG2 format and then probably an alleg-myext-png2-4.4.7 wouldn't be wrong a all

It won't be versioned this badly, I assure you.. I'm only talking about few major DLLs than one:

allegro base, allegro implementations and allegro standard extensions..

If user needs, let him/her put on more of thse extensions .. or choose a whole new implementation whatsoever (let's say he wants to use Miles3D Allegro sound driver rather than a DSound or Allegro Mixer ...) it should just be easy to plug it in..

If user doesn't need the BMP code anyway, it will still be part of the standard extensions (if this is an issue, KCat!!) .. or let him not use that at all!!

the whole point is to give everybody a "clean interface" to poke Allegro in the right places.. that's why we need a good clean pluggable base.. and the implementation part can just be kept in another container binary file. that's the difference.

hi..

i drew up one image .. hope this gives an idea of what i meant