Ok...it's me again.::) Some things that would be nice to see in a future Allegro version:

• Better sound recording routines (With better docs on this subject).

• An animation structure w/ flexible support for differant techniques.

• Better overall library layout (See below).

• And others (Too tired to think clearly right now).

Ok...for the better layout, I was thinking of something like:

/*
Allegro
 |->GFX
    |->Handles video operations
 |->SFX
    |->Handles sound operations
 |->SYS
    |->Handles timers, interrupts, keyboard, ect.
*/

Each entry such as GFX is a class. You create the class(es) that you need. You then use these classes to do the operations you want / need to preform. Example:
pGFX->SetVideoMode(GFX_DIRECTX,1024,768,32);
OR
pSFX->RecordSound(SFX_RECORD_MIKE,&rSFXBuffer);
OR
pSYS->CreateTimer(SomeTimerFunction,MSEC_TO_TIMER());

Just some ideas any who...::)

AFAIK allegro will stay as a C library.

Well classes are out of the question since it will be a C library and there is no need for a class system anyway. Why wrap up functions in an object and waste time doing method delegation when you can just prepend the GFX_/SFX_ to the function name?

A better naming scheme might be fairly good, though.

Ok...what about the other two ?:

1.Better sound recording routines (With better docs on this subject).
2.An animation structure w/ flexible support for differant techniques.

Way too high-level. And animation isn't hard to do, people.

I know! For one, I was thinking of newbies. For two, It's fun to write animation code!

Still:
What about better sound recording routines?

You can use other libraries for that if you need such functionality. They will probably always do a far better job than what would be hacked into Allegro...

Sound recording is likely to be removed.

Please not, unless it's likely to interfere with something. Many games are able to transmit player voices that are captured from a mic, and I think it'd be usefuil to have a cross-platform way of doing this.

as an add-on library, it does not need to be in allegro.

I don't see the point in making it an add-on. It should be small enough, and fit nicely in the sound vtable. Externalizing it into an add-on will just cause that portion to bloat more. IMO, it should only be an add-on if it can be done on top of Allegro's other functions (such as the GUI) and it's not the main forte, so to speak, of the lib. It's neither, as far as I'm concerned.

Exactly!:D I use Allegro because it's easy to use...not to mention cross-platform. That's the main reason I'm not using DirectX. I don't like all the crappy interfaces and the even more crappy documentation! We already don't have network support!!!>:( I think network support SHOULD be in allegro! Many of today's games have some sort of network play. I would like to implement this to, especially if it can continue to be cross-platform! I love Allegro, but I may be forced to use the dreaded DirectX...:'( I've tryed several of the network libs, but could not get any to work for me using allegro and msvc! I want something easy to use! I don't want to search for 4 months at every web site under the sun, just to get the DAMN thing to work! What would be wrong in adding a small network section that could be used for those who want to use it, and it could be compiled out if you don't want to use it? Hell...let's just throw out all of the sound section from allegro. There are several librarys out there. I think not! Yes, I'm sure there are better librarys for everything. Allegro is not better than any other library in only one area. What makes allegro great is it's ease of use and such a broad base. Let us keep the tradition alive...keep allegro easy to use, cross-platform, AND multipurpose! Let us also make allegro something more than what it is. Let us make allegro truely great! Make Microsoft tremble at our greatness...our resolve....our...our...Boo thinks I'm rambling to much!::) Anyway, Allegro is great because of it's simplicity and it's deversity. Let's not destroy what Allegro is, but instead make it something truely great!;)

I'm fine without network support. There's Berkley sockets, which is used practically everywhere, and Winsock which is mostly compatible (save a typedef or two and a few init/exit functions you can #ifdef/#endif in).

There are plenty of networking libraries out there for Allegro, personally I would suggest GNE made by gillius...

As for sound recording, even if this were to be improved in Allegro, I'll still continue to use PortAudio which is portable and works perfectly in my experience. There are other libraries/wrappers with this functionality too of course, so there's no need to go use plain DirectX...

Every thing that Allegro does, something else does as well. It's dangerous to define Allegro to be that which others aren't.

This is true, I know. It would just be nice to have all of the functionality needed for todays games under one hood.:-/ I mean allegro IS a game programming library. I could see not including network support or sound recording support to a normal application framework...because these don't normally NEED this. A lot of todays games have network support and to some degree, the ability to send voice over the net. Maybe it will NEVER be included in allegro, I'm just saying it would be nice to have things that todays GAMES need in one package. I still love allegro and I will continue to use it for the same reason I'm sure everyone else that uses allegro does: It's simple and easy to get your game up and running....without having to read endless books and countless online articles just to setup the engine, BEFORE you can even THINK about making your game! And this is what makes allegro so great, even better than directx and other librarys.8-) Long live ALLEGRO...may you blossom into greatness and remain a true GAME PROGRAMMING LIBRARY!:D

I think allegro is a great library too.. But.. I'd really appreciate more hardware acceleration (is this going to be added in later versions of the lib?)

I'm not really sure sound input is needed...

Well, I'm not opposed to the idea of sound input, even if I've never found it useful personally. As long as someone writes the code for it it's fine with me.

It'll be added when someone takes the time to fill in the required vtable entries. I think the AllegroGL team is working on this for the OpenGL driver (well for AllegroGL, but that will become the OpenGL driver when at some point Allegro and AllegroGL are merged).
Someone else needs to do it for the DirectX and/or DGA drivers (and I'm not sure if the latter is worth it).

I don't think the former would be worth it.. unless you mean an accelerated DX7 driver. OpenGL works in Windows and is just as capable as Direct3D, so there's no need for two drivers that basically offer the same functionality (with the exception that one of said drivers is platform-specific).

As for DGA.. what kind of hardware acceleration does that provide, beyond direct access? If nothing/not much, it may not be worth it.

Personally, I think whatever doesn't break the library only makes it stronger. While I may not personally have much use for sound recording, it is nice to have that capability right there in a single library. No need to include another library that you have to learn all of the little quirks of.

I think I'm agreeing more with Don Freeman right now. Allegro is, at heart, a game programming library. It can be used for other things, some people won't use some features, etc. But that does not mean that those features should be removed entirely, just because they don't seem that useful at the moment.

Networking would be a nice addition to allegro, even if it is little more than a socket wrapper. The whole idea behind allegro, IMHO, is that all of the nitty gritty stuff that must be done for crossplatform capability is pushed behind the scenes. You don't worry about DirectX initialization code, or X initialization code, or Sound Initialization code. You just do one call and it does all of the little annoying system calls for you. Yes, it is a lazy way to program, but this is what allegro does.

That said, I would be for a networking addition, even if it is little more than frosting on an already overcomplicated networking cake. Allegro isn't necessarily about providing entire interfaces for behaviors (entire networking libraries that abstract everything for you and such), however; a nice common way to use network functions would be a great addition to the library, even though they would be little more than wrappers. The more under one hood, the better.

EDIT:

Not always true. Some video cards (older ATI Radeons, to be specific) have serious problems with OpenGL when compared to their relative support for direct3d interfaces. Just a FYI.

I definitely disagree with the "what doesn't break it makes it stronger" comment.

If we're adding sound input (I know it's already there, but bear with me), why not also add MP3 playback? And if we're adding that, why not add MPEG playback? And if we're adding that, why not add MPEG encoding? And if we're adding that, why not add a raytracing engine? And if we're adding that, why not add an inverse kinematics module? And if we're adding that, why not add a Laplace/Fourier/Z-transform module? Because now our library is 40 megabytes large and we've spent time on implementing features that could have been better spent adding hardware acceleration.

That which isn't useful only bloats the library. That which isn't useful to everyone doesn't belong in the core library.

The reverse of X-G's argument is to have nothing. Nobody finds everything useful.

Why include primitive graphics functions? I don't think SDL does. Why include WAV playback? Why include anything?

To be included in Allegro, a feature should simply pass the tests of:

1. Has someone written the code?

2. Does it solve a low-level problem in such a way that additional features can be built upon it (as an add-on lib)?

3. Does it make cross platform coding easier?

4. Is it useful to most games or "simple" enough that bloat is not an issue and it won't be a problem to maintain?

5. Are there any licensing/legal/patent issues?

I don't claim my list above should be authoritative, but something like that should be written to solve this recurring argument.

And if you go through X-G's list with a clear mind (that is, not playing the role of an impossible skeptic), you'll quite easily be able to draw the line in most cases.

Some issues become gray because of usefulness, but that is where I would fall to the "if it's small enough and no hassle to maintain, then it's ok" argument. If it doesn't add bloat and it's not a maintenance issue, then it shouldn't bother the person who doesn't need it to see it included.

Sound recording becomes unclear on the 4th issue, but I think passes admirably on the others (assuming the code is written...).

As I see it, Allegro (or any other lib) should not be just a heap of code, that passed some criteria. OK, someone has written the code, and it's solving some problems, etc... But there is one more thing to consider: it is integrity, or consistency.

A library (especially big one like Allegro) should have a clear idea and a scope, to hold it together. The Allegro's main idea so far was game programming, and it's good for it, especially for 2d games. When you are going to start a 2d game project it's good to know that you'll find everything you need in one lib (perhaps with some addons:)). Also, some things are naturally related to each other and should come together, for example, graphics driver and mouse handling. While some things just don't feel natural in the context, like Allegro's 3D stuff. Allegro's 3D may be useful for some applications, but it doesn't fit in the scope, it damages the lib's integrity by giving the impression that Allegro can actually do 3d, which is mostly wrong.

Same thing with network, which Allegro doesn't have, fortunately. Same thing I can say about sound. Sound playback and recording is a delicate thing, it should either be done right or not at all. Also, there is no any natural clue between Allegro's normal stuff (2d graphics, input, timers etc..) and sound. I could understand if there were no such lib available, but there are some good ones (like BASS or FMOD). Also still more important things can be done for Allegro, like thread-safety.

You know, when you are buying a brand computer you never know if the maker was saving on PSU, memory and so on, they may put there some crap, wich will work most of time. But if you buy a brand PSU alone, you know that it is probably a nice PSU, because it competes with other PSUs on the market, and manufacturer will try to design it right, so it wount burn and kill your RAID.

Licensing Issues

Severe dependancy on another library/Licensing Issues

See Above

All things considered, allegro sorta already has a "raytracing" engine. Well, technically it isn't raytracing, but it can be used to achieve the same effect. (3d routines)

To specific of code to be of general use for most applications. These verge on the edge of "RPG maker"-izing allegro in some respects.

EDIT:

Plugins and Third Party Libraries are great. However, they should not be required to get what some consider "basic functionality" out of the library. Personally, as long as the library keeps within it's own "low level wrapping" scope, most anything would be good in the core library.

Some things I would consider:

Moving GUI code to an optional 1st-party addon
Moving 3d rendering code to an optional 1st-party addon
Moving Datafile handling code to an optional 1st-party addon (maybe)
Moving ALL but the most basic of file loading routines into an optional addon. (PCX and such come to mind)

Adding low-level networking support (BSD Socket wrappers) to the core
Adding better hardware acceleration support

Thus, we would have a couple distro packages:

Core: All of the low-level hardware and os interfaces wrapped into a nice extensible system

Level 1 Addons: Addons that currently exist in the librarys current distribution (GUI, Drawing Primatives, 3d rendering functions, more basic file loaders, etc.)

Level 2 Addons (Larger, Not-so-easily integratable addons): AllegroGL, Allegro OGG support, DUMB, etc. (Things that might be integratable into the allegro "all-in-one" distro, but not necessarily maintained by the core team)

Level 3 Addons (3rd party): Not officially supported by allegro because of incompatable licensing or some other questionable behavior.

Level 1 and Level 2 are "official" allegro addon classes. Level 1 however is designed to be a slight "overlay" over the core, providing additional functionality that some might consider basic. Level 2 addons are much larger, more "dedicated" addons that have their own independant development team(s). Level 3 is everything else.

Edit 2:

Of course, modules could be moved up/down in the scheme freely. An example would be the possiblity of integrating allegroGL into the core graphics system (AllegroGL would fall very nicely under the guise of "hardware interfaces"). FBlend might fall in here as well, assuming it can be eventually tweaked to perform all of the functions that the current blending routines perform.

That's what my point #4 covers.

The more vital it is toward Allegro's goal (whatever that is), the less concern for bloat. As the benefits of a feature becomes more doubtful, then the impact it has on the library (bloat & maintenance) should become less minimal.

I cannot really tell if you are saying whether or not sound playback should be part of Allegro or not...

Why are graphics any more natural than sound? The only thing a game requires is input and output.

There are already people out there creating a million little libraries that do a million different things. If your idea of a perfect Allegro is one that has no overlap, then Allegro shouldn't even exist.

There already is a lib for graphics (SDL). There already is a lib for sound playback (FMOD). There already is a lib for networking (HawkNL). And so forth.

I'd much prefer having one library (Allegro) that has all the low level gaming routines needed to create a modern game (emphasis in 2D) bundled together in the nice Allegro license.

What irony the name Allegro would be if it contained no audio functions...

I don't really get this "official" addon.. thing. If it's something useful, and the Allegro developers are willing to work on it, why keep it seperate? It'll just add to the list of dependancies that a program using Allegro would need.

"You need Allegro, and you also need to get the official Allegro Ogg addon, the official Allegro GL addon, and the official Allegro PNG addon, etc..." isn't much different than "You need Allegro, and you also need to get the AllegroOgg addon, and the AllegroGL addon, and the loadpng addon, etc..." The only difference is that one uses the word "official".

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.

hm, right. approximately..

What I was trying to say is that not the bloat is the problem (who cares these days, also what not used will be not linked), but incomplete or imperfect features. For example Allegro's 2d and input is pretty much perfect (except the lack of event-based input). But fixed point math is more like a joke these days.

It may stay, since it's there already. I agree, it's convenient to have all stuff ready in one lib. But sound recording is not too badly needed feature for a normal game..

Yeah, but it's like saying that VESA is API for graphics. SDL just gives you the screen pointer (well a little more than that) and you're on our own. Allegro way is so much more friedly!

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.

KC, no, AllegroFull includes core, level 1, and level 2 (DLLs and libraries). Thus, if anyone develops with these libraries, they are all backwards compatable with each other. As for core developers using "full" programs, that is ineveitable no matter what you do: you have to have the proper libraries to run the program.

Example:

User A has full
Developer B has core

User A can run anything developed with a proper version of core, standard, or full.
Developer B can develop programs for anyone who has core, standard, or full installed.

Developer B can only run core programs, however, because he only has core installed.

EDIT:

Attached is a very rough start of a PDF (well, actually it is a converted openoffice document) that describes in somewhat more depth what I am thinking of. It needs more polish (buckets of polish, actually), but I'm to dang tired to work on it anymore. Feel free to read it if you so wish.

EDIT: Fixed typo in PDF

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.

I think the emphasis should be on consistency resp. integrity in allegro. Actually, being able to use it very easily, getting a lot of work done behind the scenes is precisely what I like about allegro. I would certainly wish that the areas which are covered by allegro would contain networking, maybe sound input and other stuff, but IF any of these would be to be moved into allegro, then it has to be consistent and seamlessly integrated into the usual way allegro is used.

Well, I think hereÄs the difficult part. I have been thinking about collecting a few addons together with allegro and package that as allegro molto. I'm also seriously considering this, and I'll be working on this as my project makes progress. But there's one inportant problem: allegro itself does not rely on other libraries, so that's easy. Extensions like algif or alpng do rely on other libraries, which have to be incorporated somehow. But then either you have to continuously update to developments of the other libraries, or refer to maybe outdates versions.

For me, simplicity would be a major issue as well. That would mean that I don't want to change anything in zlib or libpng (as an example). That again would violate consistency with allegro. Another more technical point: Do you want to have all extensions be included with allegro.h? If so, you would have to make major changes, not only to allegro.h but probably also to the incorporated libraries. Including the while build process. Or, the simpler way, which I would prefer in the first steps, is to just place all libraries next to each other, each with its own way to be used. The main advantage would be that the distributor would have verified that 1) all versions work together and 2) all libraries are complete. That's actually a bit of work, because you would need a decent test program which calls into each library and tries to do some little things with it. Not having such a program is my main reason for not already haing this collection ready...

But then, the design question remains. Putting all together into allegro.h would require major code changes, which generates a lot of reworking when components are to be updated. Leaving everything next to each other would violate allegro's consistency.

I'll be on vacation next week, so I plan to implement some advancements here.

Maybe I'll also add some accelerated versions of bitmap functions, as I have seen from my tests that only draw_sprite() using a system bitmap is actually accelerated, but the draw_sprite_*_flip functions are not, though the entries in the vtable are already there.

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.

Exactly!!! Allegro is a GAME programming library, and today more and more games use some sort of networking. I do sincerly beleive that this would benefeit allegro. The possiblities are endless. One thing I HATE is using several differant libraries. But what I HATE EVEN MORE is having to learn all of the quirks of their's. Some might not even be in active developement, or just totally abandoned. Say you wrote your game and had to use the Hawk network lib....then the project is abandoned and doesn't work with a newer version of allegro. Now you are stuck either rehacking a library you might not know...or abandoning your project all together! Would it really be that hard to include net support for us poor people who would like to just use one library? Even if it was a simple wrapper over sockets or something would be better than no support except by using a seperate lib! I love the ease of use of allegro...network support would just be the icing on the cake for me, and I would finially be in heaven...::)

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)

"Yeah, Allegro can blit bitmap images easilly. ... Oh, you want to load images? Sorry, you'll need an extension for that."

But this isn't beneficial for the development process. It just adds more seperation where there doesn't need to be. And yeah, Allegro uses ddraw, et al.. but you only need to package your exe and the dll (and maybe data, if it's not in the exe). Not the exe, alleg.dll, ddraw.dll, dsound.dll, dinput.dll. The user more than likely has DirectX already. They probably don't have Allegro already.

Well, some Allegro developers think it'd be useful for Allegro to have sound, but there's no need since it's already available with FMOD/OpenAL/etc. The point is to have an all-in-one library of commonly useful features so you don't need to hunt down a million general dependancies. Any dependancies should be specific to the game.

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.

I really really don't like this.

"Oh, this game uses Allegro." downloads Allegro and game "What? I need Allegro-png, Allegro-Ogg, Allegro-dat, Allegro-insound, and Allegro-GL too?! Forget this..."

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 see your point. I was thinking more of the technical aspect of the installer/configuration programme though. It would be nice if Allegro's installer could detect and build common extensions and plugins so that you needn't install all of them seperately and in different ways.
What you describe could happen now too: the person who wrote the game failed to mention several dependencies that are needed to compile the game. But you bring up a good point: there would be a danger of having a big download or `Allegro+' version that includes everything: people may forget that they have several dependencies that are masked by the larger Allegro distribution and not mention them.

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

I would disagree. I would rather have Allegro do a little more than I want, than a little less than I need. Allegro wouldn't be updated for every little bug, and you'd only need to update if the update offers functionality you want or need.

I don't generally like having a bunch of files in a main game directory. And the more seperate DLLs there are, the greater the chance of incompatibilities between them. "core 4.4.6, a-png 4.4.4, a-ogg 4.4.5 is alright.. but core 4.4.6, a-png 4.4.5, a-ogg 4.4.6 isn't.. though core 4.4.6, a-png 4.4.5, a-ogg 4.4.5 is..." shivers

I'd think hardly any Allegro games are commercial quality. While it'd be nice, most people probably wouldn't bother.

What does that got to do with anything?

You'd trash Allegro just because it has a few outdated features?

I could add PNG and Ogg (Vorbis and Theora) right now without it affecting the rest of the library. The reason why we don't is because it'd create dependancies for Allegro (which some of us are trying to find ways around).
And all it'd do is bump one revision number.

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

I have no idea what you're getting at.

Something like this is already possible now. Write a driver vtable, init the sound stuff and set digi/midi_driver to your vtable. Allegro will now use your vtable for sound functions (granted the vtable isn't documented, and is subject to change.. which is why it's not a real "feature"). But that's basically what AllegroGL does with graphics (though it does poke a little more at the internals of Allegro).

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.

That would be up to the developrs to decide/implement. The font vtable is getting a clean (possibly public) interface. Packfiles are. Perhaps more vtables will.

hi..

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

I'd wager it is you who are dumb. Please refer to this dictionary definition of hyperbole:

My point is that adding things that do not explicitly break the library can still be very, very bad, as they only add bloat that most people won't even find useful. Damn it, has no one heard of figures of speech these days?

That it's a hyperbole doesn't make it less dumb. Allegro is a pretty llarge lib right now as well, but I'd rather have a 500k dll than an extremly modularaized system.
If you want to reduce your size, you can always static link. And most of the time the allegro DLL wouldn't be the best point of optimization.

Allegro should be more than a lib. It should be a solution. As it is right now. The only thing that really should be added is support for a "modern" image format (PNG comes to mind) and hardware accel.
GUI and Video support (FLI at the momemt, hopefully something better for later versions) should be made add-ons.
If we want audio support, we should take a look at fmod and consider to get some inspiration from it. Outsourcing audio completely would be a bad idea, making the support too basic isn't that clever either. If we have basic support, the user can either use plug-ins which try to do their best using the given allegro interface, or use a specialized lib (OpenAL or FMod) which can handle all they need.
If allegro wants to stay a all-in-one solution, we need good audio support, including a way to play streaming (pseudo) CD quality music.

Input device support should be modelled after DInput mainly because that is the Defacto standard right now. And we should support force feedback in both the down-to-the-metal version that dinput supports and a high level version that simply "rumbles".

While a FVS would be nice, if we do it, we should try to use something that is already tried and proven - like the zip interface. Which would fit perfectly the suggested PNG support.

So would I, but I'm objecting to the "whatever doesn't break the library only makes it stronger" statement. Nothing else. I'd love to see PNG and OGG support in the core library as well, but that statement up there is just asinine. That's the kind of statement that leads to Allegro having Fourier transform functions, because it "doesn't break the library".

hey guys.. i'm not sure where the real issue of splitting up is, because already Allegro has dependancies.. like, they do not have a single directx.dll or a windows.dll that Allegro uses.. and there's a separate DLL for the dx GUIDs as well ... Why can't we split it up if it becomes easy to make major updates to the core? And to the implementations as well?

Most users would already have the Windows and DirectX DLLs. Most won't already have the extra Allegro DLLs.

Right... about that..

1. It ideally can be a redistributable Allegro distribution which can make things easier for the developer.. And about the point on not so many commercial Allegro games, I don't think that's fair. People would like to have a feel that Allegro is a standard for making commercial quality games.. And whether it's used to that extent or not is solely dependant on the developer..

2. If you are releasing the game, you wouldn't be bother about releasing a version of MSVCRT.DLL that's already assumed to be there... In any way, it's either going to be one binary (static linked), or not one binary.. So What's the issue is the question? It's not going to make your distribution cluttered.. You just have to package the re-distributable installer with the game installation ... or keep ur DLLs in a separate bin folder ..

But, on the other hand, look at it this way: the development process of Allegro will become much easier. You are going to distribute all the three subprojects/DLLs/.libs in the same package after all.. Updation of subprojects is easier .. and just that the organization of code is more modular.. Hey, think about it..

Redistributable Allegro distribution? The current Allegro distro is redistributable already...

Having many seperate DLLs for one library doesn't make a game feel more commercial. If anything, just the opposite.

"game.exe + data.dat + allegxx.dll" vs "game.exe + data.dat + alleg-xx-core.dll + alleg-xx-imgldrs.dll + alleg-xx-sndldrs.dll + ..."
or for source distribution:
"You need Allegro version x or better" vs "You need Allegro core version x, Allegro image-loaders version y, Allegro sound-loaders version z, ..."

Splitting up the library will make more DLLs, which will cause more DLLs to be in the game's directory, which is clutter.

Not everyone is (I'd say most aren't) going to bother with an installer. Especially for source distributions.

Windows doesn't allow that. If the DLLs aren't somewhere in %PATH% or the current working directory, it won't be loaded.

hey look.. you know that.. setting an evironment variable is not a "big" thing
and, if you don't want clutter, go and link ur EXE statically, and append the data.dat to it using exexedat it still doesn't give you a valid reason to say why splitting the library is wrong in the first place

Rule of thumb: If you have to ask a Windows user to do something more than double click here and there, they aren't going to do it. Yes I know they're not all like that, but it's a nice rule of thumb to go by. And you do not want to modify a user's system settings on them.

Which defeats the entire purpose of DLLs, which is shared code and ease of upgrading the lib without recompiling the exe.

Then splitting it up to re-use the base and implementation isn't breaking the rule of making the DLLs.. and, putting it together may involve recompilation of implementations even if the base isn't modified. So why have DLLs in the first place? The sharing concept didn't go ka-put! it went: poof!

If you want the generalized re-usability, go for DLLs. If you don't want file clutter.. why bother wasting space for an alleg41.dll? Link statically. End of story.

Um, why are we even putting the DLL code in the program directory then, KC? If every program that uses allegro includes its own copy of the DLL, then we are defeating the purpose of "sharing" the code to begin with. The point is that the allegro dlls are and should be handled behind the scenes; aka, in the c:\windows\system32 directory. This way all allegro programs use the same DLL. This ensures that the DLL is in a commonly accessable location. It also prevents windows users from having to mess with pathing or having a cluttered directory; just copy the dlls to the system32 folder with the installer if they don't already exist, and viola! you're done. No more clutter, no more duplicated DLLs.

EDIT:
And even this definition of the reason allegro is in a DLL is rather flawed. True, you can try to use a new DLL with an older version of the executable, but so many things are changing (especially with WIP releases) they are bound to be broken.

The multiple DLL clutter issue is really a moot point. Most users never even look at the programs directory to begin with; they just extract and run a shortcut. Who cares what the dlls look like in the directory? If it makes updating easier for us, the developers, then I say go for it.

I mean, here, lets look at some more "common" programs and their DLLs in their directories:

Starcraft w/ Broodwar - 5 Dlls in the root directory
Battlefield 1942 - 4 DLLs in root
Total Annialation - 9 DLLs
Valve's Steam - 5 DLLs
Blender - 3 DLLs
GIMP - 17 DLLs in the Bin Directory (where gimp.exe is located)
OpenOffice.org - 200 DLLs in Program directory (where soffice.exe is located).

DLL clutter is VERY common, and really isn't a problem, unless you like to browse your program directory daily and on a regular basis. Here, try this for a rule of thumb: if the user has to be messing around in the program directory to get things working, there is something wrong besides the DLLs in the directory.

Never said it was.

I hardly think Allegro is large enough to make this a cause for concern.

Which is why we put Allegro into a DLL, so it can be reused by multiple programs.

You're not making sense anymore. Linking staticly will waste more space than dynamicly. And splitting the library isn't going to have any effect on code re-use since Allegro is already all inside a DLL.

And how will this change with multiple DLLs? It'll make more work for the program developer to keep track of more than one DLL, and it'll make more work for the library developers to keep track of seperate packages.

That's the thing though. It won't. Either you now have to download/install/use multiple packagaes instead of just one, or you get the all-in-one package which defeats the whole seperate-packages issue.

The problem is not code reuse, it is the fact that some portions of the library may become "more stable" at a more rapid rate than others. Thus, these portions of the library would be upgradable independantly of any other "lesser" sections. The problem right now is that while certain parts of the library are maturing at a decent rate, other parts are lagging behind, pushing back "stable" release dates for other features.

Splitting was never designed to increase code re-use; it is designed to prevent redundant updates and to expidite development of the library in various areas. (Not to mention it helps remove the libraries dependancy on all sections of itself. If a person wants to use allegro for nothing more than a hardware wrapper (no "frosting" functions), they only include one, much smaller DLL, instead of including one much larger dll in their installer.)

More DLLs = more problems. Either you keep it simple and release all DLLs together, then there no advantage over having one DLL. Or you release the parts separately, then you'll get into versioning-hell. So I would prefer to stay with one single DLL here.

@KCat.. look at the point:

1. Linking statically doesn't share the common code. (agreed)
2. Linking dynamically doesn't make a difference when there is one DLL or two DLLs or 200 (agreed)
3. DLLs increase file clutter : you mean to say, I have 300 Allegro games and there will be 300x alleg4x.dlls or 300 x 3 = 900 DLLs? So where did all that code sharing go?
(flame here)
4. Splitting the library isn't going to cost the developer/producer/publisher (flame here)
5. The gamer (user) doesn't bother if there are some 3000 DLLs in that directory. He just double clicks the EXE file, plays the game and stays happy. (agreed)
6. Splitting the library does make it easy for Allegro-Developers. (agreed)
7. The developers are going to get the whole package, just more organized. They don't lose anything. They'll gain when Allegro gets more loaders into the extensions package... Their code won'tt not need any re-compilation.. Coz updating the alleg-stdext.dll will cause a load_bitmap() to load a PNG file in the future. it's just like updating to a newer version of alleg41.dll .. No difference, see?!!

seriously, give me good reasons as to what makes it too hard to follow? And a good reason is not like:

"it's been like this all this years, and I don't like it"

@Tobing:

Versioning hell is a problem, eh? Try running a 4.1.18 compiled game with a 4.1.16 dll, did it make any difference? These arguments are just lame. DLL hell with one DLL, DLL hell with 10 DLLs

P.S.: I, as an Allegro user am ready to change my makefile if it's going to help Allegro in the long run.

"Yes, the image loaders are all fully stable now. But you need to upgrade to the WIP core to use it. Sorry." or "Yeah, we got Ogg support in the latest sound loader module. Unfortunately, you need to temporirlly downgrade the core until we get a problem fixed. Oh yeah, that means you won't be able to use the fully stable image loaders, either. Oops."

You can have all that, and more, without even getting to the issue of compatibility with your programs.

Okay, as mentioned, this is a moot point for the end user. However, you now need to keep track of what DLLs to ship with your game, instead of just one.

Oh, yes it will. "Oops, I forgot to package a DLL or two." ... "I'm sorry, your allegro-core is incompatible with our allegro-sound-loaders. Downgrade/upgrade your Allegro core, please. Beware, down/upgrading my break your other Allegro programs."

Where did I say this? It most certainly would not.

4.odd is not compatible across versions. Only 4.even is. Since most development is done in 4.odd, and compiled for release in 4.even, you still fall into versioning hell.

Eh, frankly, I don't care. As long as allegro either A) eventually supports automatic compilation and detection of plugins (evert's idea sounds really cool) or B) includes all of the features any decent modern gaming library solution should contain, I'm happy. The problem is that it gets, as stated previously, very annoying to get everything setup and working properly when all of the libraries have their own build systems, quirks, dependancies, bugs...

Now, if the makefile could somehow be tweaked to automatically detect the plugins and compile them, that would be one sweet setup. I could go for that.

Something like

1) You copy a standardized plugin directory into the allegro\plugin directory.
2) Run make in the root allegro directory.
3) Run make install to install all of the necessary libraries, DLLs, headers, etc.

This would have some unique implications as well. We could provide a standard method for plugins to add features to the grabber utility, for instance; or add new pages to the documentation; or add more libraries to the *nix command `allegro-config --libs`.

I could really go for a system like this. At the very least we would be providing a common framework for plugins to be built upon.

EDIT:

Although, I think we can all agree that the allegro core could be a bit more modularized. The unneeded functions could be moved into the plugin system that evert mentioned. That way, they could be "removed" without destroying the rest of the system. Of course, this complicates things because either we have to A) statically link these functions, B) create a dll for all of the plugins seperately (version hell), C) create a single Allegro DLL with all of the plugins (version hell), D) create an individual DLL for each plugin (slightly less version hell)

I'm sorry.. because it's the core. When the core changes, the whole library changes. And, you don't need to update the core when it's the image loaders which have the problem. If they follow the same vtable interface, then the core won't need any updates ever

you don't update ur core unless you've gotten the whole idea of core wrong.. try another argument

No need to flame here. I'm working in a project involving a bunch of DLLs, so I DO know what the versioning problem is. That's the reason why we decided to only deliver complete packages to our customers: You have to verify correctness of every combination of DLLs you're going to release. The sheer number of possibilities to get strange errors with multiple DLLs of different versions is endless, and nobody would like to try to debug those bugs.

Yeah man.. i do know what you're talking about The whole idea was to deliver a solid core so it is easy to debug and add on to certain parts of the library without affecting it's base functionality

[edit]
Btw.. the current vtable interface does have that compliancy .. so all GFX drivers that are/will be released shall be tested with the base for bugs
[/edit]

It depends on what the problem was. Maybe to fix the problem there had to be an addition to the core.

What if we don't get the vtable interface just right the first time? Or something comes along in the future that'd require core changes?

I'd consider something as simple as the BITMAP struct to be core-worthy. Do you have any idea how much that struct has changed throughout Allegro's development?

It's not a matter of something wrong. It's a matter of fixing incompatilibilities or adding, or removing redundant, functionality.

And see my edit in my previous post (you people post too fast )..

@KC:

Please elaborate your point on how splitting the DLLs could be a pain to the Allegro Developers themselves..

and, as for the allegro-users who develop the games, it is their responsilibity to read the fine manual before publishing the games. of course the documentation will be updated... and you don't release a game before ou test it right, or give people the instructions for running it. this isn't correct at all.. when you make the game, you should be aware of what happens, where and when. that includes knowing what DLLs are and how exactly your allegro program works.

yeah KittyCat, agreed that splitting will now have to be monitored carefully .. but, it has to be done sometime.. else the whole library still remains the hack it was 5 years ago!!

and, the BITMAP definition would be part of the core

"Hey, I just found a way to add JPG2000 support!" "Cool! But we just released imgldrs version x.y with PNG support. Perhaps the next version." "Wait, didn't you just release core version x.y? I thought we were on imgldrs version a.b?" "No, we're on sndldrs version a.b. The core is version u.v and imgldrs is x.y." "Hey guys, what about my patch? "

Reading the manual doesn't take away from the fact that'll it'll still be a pain to keep track of everything.

You can only reliably keep track of what you use. Say you have a game working with core-4.3.5 and imgldrs-4.3.2. The user already has core-4.3.6, imgldrs-4.3.1, and sndldrs-4.3.3. Now you run the risk of updating his imgldrs, which is incompatible with his core. He can downgrade his core, but now it may be incompatible with his sndldrs.

Why would it have to be split to update to more modern times? You can internally split the code (eg. modularize) without creating multiple DLLs. Some things are already like this.

Isn't it already agreed that the core and loader interface is function compatible? And this just "appears" to be looking complicated, but it's not. If version a.b or x.y are both compatible with core c.d or e.f, it should'nt be any problem because they all work

And yeah, probably in ur example, the imageloaders might have a newer release so people can check out JPG2000 support along with PNG support, which will work with the same core [:P] And soundloaders is part of the same package too [:P] So, if it's in the same DLL, the patch applied is only to the extensions, which include:
JPG2000 and Soundloader patch a.b [:P] So nothing gets mised out and evrybody is happy

And, as developers, they are expected to be more responsible about versioning and patching up... and developers aren't downright silly as you make it appear.

You down downgrade cores, you upgrade them. When cores are updated they are only bug fixes, not vtable structure updates. If they are major structural updates, your imagehelpers won't do any good it'll just be like saying: i'm downgrading my WIP alleg41.dll to make it work with AllegGL having agreed that WIP DLLs are not compatible people using these older DLLs are doing so at their own risk.

Unless the user happens to have core g.h, which may or may not be compatible. The only way to know that would be to test (ie. more work).

It was an example. Of course developers would be able toi keep better track of versions, but that doesn't mean it'd be a huge pain in the ass to keep track of (which is, after all, what we're trying to avoid).

What if the bugfix implies a vtable structure update? You can't be implying that vtable structures won't change..

Currently, as is KittyCat, when updating the definition of the BITMAP vtable, won't the loader also change? Yes, they will Then anyway, the binary compatiblity is "lost" in the WIP releases.. won't they?

Also, how many times do we test the blit() and loadBMP() code when we update the BITMAP vtable definitions? If we do that, then doing the testing here won't be a big issue as well, let me assure you

So, if we release imgldrs-4.4.0 (first stable), then release core-4.5.5 (5th WIP), we'd have to imediately upgrade to imgldrs-4.5.0. However, something breaks in imgldrs, causing us to bump to 4.5.1. The core is stablized and we release core-4.6.0 (first stable). But, we just found out how to fix imgldrs right! We'll have to change the core vtable a bit, though.. so we release imgldrs-4.5.2 and core-4.7.0 (first WIP; can't reuse 4.6 since it wouldn't be ABI compatibile). Now, imgldrs is stable so we release imgldrs-4.6 and core-4.8. But crap, now something in sndldrs isn't working, so we upgrade to core-4.9...

Watch as those version numbers fly from constantly fighting over inter-compatiblity, all the while breaking ABI compatibility left and right. Fun...

Well, according to your argument, there's just one little thing:

You don't update your core to make it compatible with the loaders, which use the core-interface You only update the loaders and enrich their functionality because you've realized that the base format lacks something and it needs an update. Then, the image loaders that you currently fixed till now (4.5.0) aren't suitable enough to make full-use of the new vtables u created in struct BITMAP (for instance) and definitely need a fix or a workaround.

That's what I called versioning-hell.

versioning hell exists in WIP releases. that's why we removed the ABi section out of the manual, didn't we?

Surely you're not naive enough to think that any and every problem that pops up in image loaders won't require changes in the core. Or that when you update the core to add the potential for future expandability will require an update in the effected extension modules (even if nothing is actually added to the modules). It would be so much easier if it was all in one library.

Versioning hell isn't compatilbity problems with multiple versions of one DLL. It's compatibility problems with multiple versions of multiple DLLs.

True between different branches (4.0 vs 4.2) and for WIP releases (4.1.x/4.3.x). Not true for releases within one stable branch, 4.0.x or 4.2.x.

I don't think this is true. If major changes in one part of the library warrant a new release, there is a new release. The need to do as much as possible from one WIP to the next is that releasing and testing a WIP takes a fair bit of time, something none of us have in abundance.

So tell people not to always distribute the DLL already, especially if it's a stable release.

Read the bloody manual. WIP releases are not intended to be ABI compatible. If they were, we couldn't add new features to the WIP releases. If you care about ABI compatibility, stick with a stable release. If you want or have to use a WIP, staticlink.

Yeah, I'll try to have a look at that for the 4.2 release, but I may not have enough time to resolve all the difficulties. What it would need is a well-defined Allegro plugin buildsystem interface: files that need to be there to describe how the plugin should be build. In a UNIX system, I suppose Allegro's top level configure script could take care of that... but that leaves Windows. Maybe the best platform-neutral approach would be a seperate programme that is build by Allegro's makefile (a la makedoc) and then run to configure and build the addons. Hmm... yeah, that could work.

load_bmp() doesn't care, blit() is inside the vtable and you get a warning if you somehow messed up the vtable because functionpointers are initialized with an incompatible function pointer. The real pain is checking this for all drivers, which involves recompiling Allegro on all supported platforms. Ideally, we would have a programme/script that scans Allegro's source tree for all instances of a driver/vtable and checks that it has the correct number of initializers and function prototypes.

@Evert: that 4.1.16 thing, I was telling the people who mentioned WIP specific DLL problems.

lemme join the versione manic..

@carrus85

Ok as far as ur thumb rule DLLs can be cluttered !!!.. how??
here is the answer.. u told that a normal windows user doesnt know anything more than double-clik.. so he wouldn't be messin around to the program dir. so cluttering doesnt cast a problem over there. then u said some users will .. who r power users.. so what do u think power users dont know what a DLL is ?? dont u think they will check their pockets before fingering that DLL??

and do u think openoffice.org is developed my amatures?? and if it would have been a problem if the Dlls of this suite been located at the program dir??

Um. You seem to miss some characters. You can copy and paste them from mine:
yoyo'cgyoaeyo'yoyo

Also, most of the time one punctuation mark is perfectly fine. Just remember to hold down the shift key for the character following such a mark. This will result in a so called "upper case letter".

That being said, having just a single lib for the stuff almost everbody will need is a very good thing. I would even go so far and remove the DLL completely and make static linking the default on windows platforms. You'll normally provide the DLL with your game anyway so you'll actually save size by static linking. This will also make distributing the windows binary more easy. The normal overhead by a statically linked allegro lib is in the 100k area, in other words, it's not that big in comparison to your gfx and sound/music anyway.

The question shouldn't be how many DLLs do we need? The question should be what are the benefits of a single / multiple DLL distribution for the user (as in coder of the game). The answer is: Most won't care. Allegro should be an easy to use, quick to learn library. Installation seems to a problem for many window users right now anyway, if you now start to add multiple libraries (leading to a couple of libs that need to be linked in the correct order) I see a lot of trouble ahead.

Easy of use is the big strength of allegro (once it has been installed, that is) so we should try to focus on that aspect. IMHO that is, of course.

ok.. about that ease of use.. static linking or not, i'm just insisting that the library be split up so it's easy to maintain a generic, robust extensible interface for all other libraries and itself .. no other point was touched. this internal architecture may not make much of a difference to the end user as-is

Again: multiple libs -> multiple libs the user needs to link against in the correct order.
If you think that you want multiple modules that are distributed as a single lib, sure.

well yeah spellcaster.. the link order is to be maintained.. on Linux, there's no problem ( we can re-do the allegro-config file) .. but on Windows, for static linking, there's already one particular order followed it wouldn't add a lot of difficulty, the way i see it.

But it won't. It'll make things more complicated and harder to keep track of as I have been saying and shown.

Well, distribution of the final product isn't the #1 main concern here. There is a difference between 1 exe and 1 exe plus 5 dlls plus game data files, yes.. but having 1 exe and 1 (or even 2) dlls and game data files isn't that big a deal.

Funny thing.. I once thought this too, but after doing some testing, I found that the entire lib does get included in the exe when you staticlink, even when using the -s option. The reason, I'd guess, is that because even exe's can be dynamicly loaded, all the functions and symbols need to be there in case something tries to (in Unix, you can pass NULL to dlopen to get a handle to the program and use dlsym to get the address of any symbol you wish; I'm pretty sure Windows has a similar method). In DOS this may not be true since there isn't really any dynamic linking, but this isn't DOS..

ohh? when was it shown?

look at Ogg Vorbis: libogg, libvorbisfile, libvorbisenc and libvorbis !!!

Read the thread. Specificly, my posts.

Yes, look at Ogg Vorbis:
libogg = library to demux/multiplex ogg containers (does not need to contain vorbis audio)
libvorbis = library to decode vorbis audio (does not need to be from an ogg file)
libvorbisenc = library to encode vorbis audio (doesn't need to be written to ogg files)
libvorbisfile = a wrapper library to blend libogg and libvorbis (quite poorly, I might add, and is in no way required to play vorbis audio .. the use I'd actively discourage as well )

Each library handles completely seperate tasks that do not depend on any of the others to operate (with the exception of the last, which I never was fond of).

yeah i did. i never felt that it was "reason" enough

and, it isn't a matter whether you liked it or not, but for the fact that they did put autonomous parts of Ogg Vorbis into different sub libraries proves my point

it's ideal that there's a certain level of abstraction, and it's easier when separating implementions from generic routines.

(I'd like to quote Elias' e-mail to AD in here.. but I won't do that!!)

Well, I'm not going to catch up on this thread, but yes, I think different from Chris that more modules are better. For example, look at something like glyph keeper. It's much better to be on its own, so someone completely independent of the Allegro devs can develop it.

The same would be possible e.g. with other drawing primitives, e.g. there might be a library for lines/circles/arcs and so on. They are less basic functionality than display of text in a game, many games actually don't need them. Of course, they should be in the standard download (as should be the possibility to render text) - but there's no need to have it all inside Allegro.

Creating more problems by having to keep track of multiple packages, each with its own version and compatibility issues, isn't reason enough?

You didn't read my post. With the exception of 1 (libvorbisfile, which is nothing more than a simple helper lib; it doesn't do anything you can't easilly do yourself, and better), those libs are completely seperate from each other and do not require any of the others to be used to full potential. Meaning, there is no reason to mix them together since they work 100% independant of each other.

Except, he's talking about Allegro itself. Others wouldn't be independantly developing it. It would all be worked on by the Allegro developers.

Why externalize it? What will putting it into a seperate library accomplish to make the package seperation worth it? "Why yes, Allegro is very good with graphics. Oh, you want to draw circles and lines? You'll need this external lib for that."

Yes, I see the dependencies problem, so there should be a distribution containing it all. But it just feels cleaner to me to have it separate. There could be different developers, different mailing lists and so on, all just would be more organized and more progress could be made. That's how I feel at least.

Something else - we simply won't be able to put everything into Allegro, so there will always need to be addons. But since Allegro would contain a lot of stuff, the things that are outside get a disadvantage. If things are separated, then it would be easy to switch e.g. from one official GUI addon to another at some point (the end-user distribution just would contain the other). If one would be fixed in Allegro, then all others would have a disadvantage. And if you look at the current addons, there are many that aren't developed anymore and were replaces by others, e.g. ogg or ttf addons. Now if we would have put ogg and ttf support into Allegro - Allegro users would be shut out from using the new ones.

I think we need to seperate the idea of having modular code and seperate libraries here.

Having modular code would mean that for all intend and purposes, graphic primitives (say) are an addon and could be build and seperated as such, except that it is build into Allegro automatically. That means graphics primitives are logically and internally a seperate entity from the rest of the library. This, I think, is good. I think this is also what Elias is refering to.

The second issue is if this would mean that the graphics primitives should be a seperate library, irrespective of wether or not this gets distributed with Allegro. This, I think, is a `no' for the reason Kitty Cat has pointed out: there isn't much of a point to it and it has the danger of suffering from bitrot if the rest of Allegro is updated but the graphics primitives are not (except if Allegro's build mechanism would automatically compile all subsystems as seperate libraries - then there would be no difference from a developer point of view). Regardless, cluttering things up with too many DLLs is a bad idea IMO.

I think we will eventually want to discuss what to do with the 4.0/4.2 compatibility layer in 4.3: will it be in the `normal' Allegro library so that everyone is forced to have it and use it? I think not, because that defeats the purpose of Allegro's new namespace cleanup due to al_ prefixes and is just unnescessary weight for people who don't want the compatibility. At that point, I'd consider having an alleg-new-44.dll/so and an alleg-compat-44.dll/so (names just given for illustrative purposes and not meant to be taken literally or as a serious suggestion), where the latter contains the backward compatibility API. Linking against -lalleg would make the old API available (and link in the new one, obviously) and linking against -lalleg-whatever-we-want-to-call-it-that-hasn't-got-the-old-api will only include the new API and not cause the user code to pick up a dependence on alleg-compat44.dll/so.
This is for further down the line though, and not really relevant to the present discussion.

So, in short, my thoughts on the subject:
Modular code and code seperation into logically independent packages: yes.
Seperate libraries/dlls for different components (alleg-gfx, alleg-snd, alleg-core,...): no.

PS: I disagree that primitives should be an addon because the average game doesn't need them anyway: I tend to use rect and rectfill fairly often, and putpixel() is quite useful for some particle effects. In any case, I use them for making a quick interface before I plug in bitmaps and things like that. Well, different discussion again.

But again, having a distro that has all the packages (which more than likely most people would use) defeats the seperate packages argument. You want seperate packages, but you want them all packaged together?

I agree with Evert. Write modular code in a way that it could be seperated. But that doesn't mean it should be seperated.

Hi,

I don't see where this is getting anyway...

@Evert: If you can just trash away with the current DLL system, why not do away with any DLL system? agreed that the current system isn't flexible enough to give us the in-library addons ...

@KC: It isn't enough. Separation of libraries enables us to strongly resist an impulse to play with global variables and function vtables. It is strongly condemned.

People, the method of maintaining different routines should be kept independantly... It becomes easier to fix and improve certain parts of the library. If i'm not using the Allegro 3D routines, why should I bother to link it up? I noticed there were lots of dependancies in the symbols and compilation when I tried to remove the 3D out of the library (I shoved out 200 kb in my static executable that way) .... If i'm not using the LBM or VOC routines, why should it be part of load_sample()? As such, these things only contribute unnecessary overhead for the library. The base library system is best left clean, powerful and fast.

You don't need to seperate the library to not use global variables (and there's nothing stopping you from using global variables with multiple libraries). Plus, global variables are fine.. it's cross-object global (ie. non-static) variables that you have to watch out for. And what's wrong with function vtables?

Because it's part of Allegro. If you're so worried about linking functions you don't use, why don't you just put every function in it's own library? That way you only link with the functions you use.

Because some people may (or used to; no one's arguing certain functions aren't "dead weight", but we can't remove them yet for compatibility reasons), and the extra code is negligible, as well as it doesn't get in the way of anything else by being there.

Which has nothing to do with the library being in one file or ten files.

Inference: for non const variables, use local variables in files, and if there's an external dependancy, use functions / attach functions to vtable and execute.

Why don't you separate the not-so-dead-weight code out? Abstract it to the base. That's all anyone wants to use the Allegro system minimally, nothing more. This is what we are asking for.

As for DOS, there's no hope that there might be any DL mechanism .. But, if it's real sharing of code you want, it would be easy to put the implementation part out.. let me give you an idea: Let's say I just want to use my very own DDraw7 / Dinput8/ DSound9 driver.. I wouldn't want to have anything more than just the base, to which I can plug in my own implementation/drivers .... The others will just be dead-weight to me..

Ok, agreed that a certain level of controversy is in determining what the "not so needed" stuff are ... But what is being proposed reduces these things to a good extent...

BTW, can we start a general poll for getting feedback on Allegro (multiple questions on how far they rate the features of Allegro, what people use it for etc..) ? One example of such a poll:

[url http://www.zoomerang.com/survey-start.zgi?p=WEB2244Z7UMEDS]

It is abstracted. ALl you'd have to do is remove the function, the line that "locks" the function (which is only needed because of DOS), and the line that "installs" it. Nothing else in Allegro is bothered.

Write vtable entries for them, and put it into a struct for Allegro.

That's just you, though. Most everybody else will still need/want it. The cost in seperating the library as such would be too great for a few people that may want to do something like that.

No it doesn't. Because if Allegro's going to support it, Allegro's going to support it. Even if the packages was seperated, the developers would still maintain it and release it with the "full" package.

That's fine.. the point in separation is not to make things inaccessible. It it to make the framework more compact and extensible.

Which can be done just fine and just as easilly (moreso, actually) if things are in the same lib.

Agreed that all the functionality are going to be distributed [:)]

1. it would reduce file sizes for so many people who don't use all the routines..
2. it would be easy to update/enhance certain parts of the library without affecting the rest, more easily.
3. it gives more choice
4. it's primarily for helping the developers. (no, they won't face lots of problems. trust me!)

The size difference will be negligible.

And if you needed the extra space that badly, you can compile a custom version.

Debateable. You can modularize the library without having to split it up.

It would still offer the same exact functionality...

You haven't shown how, nor have you countered my and tobing's arguments that it will. All you've basically said is "No, it won't."

Well, you really haven't justified that it will make things tougher for the developers either ...

Yeah.. I replied to both of them... these WIP arguments don't really work out.

You replied by saying that we'd just have to keep better track of these things.. which is exactly the argument that it'd just make more work for the developers.

It's not like an expense of time.. The maintenance will be fairly easy after the split-up.. It's more like the investment kind

I disagree that it'll be easy.Instead of maintaining 1 package, you'd be maintaining and coordinating multiple package. It implicitly increases work load.

The developers will have to decide about the maintenance issues.. Probably more maintainers, more committers.. Or just into different packages. That's it.. Change was never easy anyway.. The point is, if making it, why not do it up the first time? (WRT upcoming stable releases)

Perhaps something more along the lines of the following could be done:

Make the allegro core (as I described earlier) either static linkable or dynamically linkable. Your allegro dll would come from this.

Default the extensions (plugins) to being statically linkable. The user can create a dynamically linkable dll if they so wish, but the resultant dll is 100% custom to the user, not allegro specific (aka, the dll can contain any number of functions that the user desires).

This way, the developer has a couple options: there is only one, core, allegro DLL. The timer routines, bitmap routines, and all of the standard goodies go into this. Anything else that is considered a "plugin" (and thus automatically available by some magic allegro\plugins\fill_in_the_blank.h header) is therefore optionally linkable.

There could even be a compatability dll that has these "potentially unnecessary" functions compiled into it. (True, users would not be required to generate or use such a dll unless the developers use it, and a depriciation warning could be thrown on that).

This helps prevent versioning-hell (from our end, anyway), and allows the user to create versioning hell if he so desires (make his own dlls though some magical makefile system). It also has the added advantage that the plugin would be required to play nice with the library core. No more dirty hacks, no more unpredictable side effects from a plugin altering something it shouldn't.

This could be a potential comprimise. The problem is that currently a) there needs to be a way to NOT (keyword, NOT) compile certain features into an allegro application if you have absolutely no need for them. b) the current library code has too many cross-refrences to other pieces of code to be easily "hacked" to the point that this can be achieved.

I think this would be a reasonable comprimise:

1) Use the allegro dll that contains only the core code (anything else is staticly linked or done with a custom dll)

2) Create a custom allegro dll that contains anything and everything you want (this dll would have to be managed and maintained by the developer in question, however).

3) Create a compatability dll that contains the current interfaces for backwards compatability reasons.

Carrus, that's an interesting idea. However, given what may or may not be part of the core, you could end up making most of the library staticlinked.

Though it may be nice for "Allegro Developer-sanctioned" addons that could get packaged in some Allegro Uber-package (not maintained by the developers), that Allegro's build process could detect and build for you. Allegro itself, however, would remain one single package.

As long as everything isn't rigidly statically linked, it's fine.. Ideally it's up to the user if he/she chooses to have the font routines in a DLL or statically linked ..

So post a patch on the mailinglist to remove unnescesary dependencies and make the library more modular.

Just remove the loaders and the call to register_bitmap_file_type() and register_sample_file_type() that registers them. The loaders are no more than addons that are registered when Allegro starts as opposed to PNG files which first need to be registered explicitly.

KC: Yeah, that was kindof the generic Idea. The idea behind the whole theory I posted in the last post is that A) most devs end up shipping an allegro dll anyway, so it might as well be static linked, and B) it provides an interesting method for "compilable" custom dlls.

Of course, it would be possible to have an "uber" dll that has everything officially supported by allegro in one single DLL, assuming that all of the proper "offical" allegro pacakges are in the addons directory.

You could even have one unofficial "uber" dll if you want (assuming you have someone else who dictates what exactly is and isn't part of that uber dll).

I think I like the way this discussion is heading. Any other comments?

The way I understood it was, Allegro would still be a DLL, but the add-on packages would be static-linked. Only it would be shipped, built, and installed with Allegro in an "unofficial" package.

I don't like the idea of multiple type of Allegro DLLs, even if they are unofficial. Something like that should be done on a per-project basis, and would only lead to having conflicting Allegro DLLs around.