Woohooo!!

I'll be hoping that this leads to a version where some keyboard issues are gone.

Great work guys!

Congrats

One would hope that it gets merged into 4.3 at some point. Hopefully that would bring more eyes to AllegroGL and keeping it synced with allegro.

It seems to follow a consistent pattern of: al_module_verb_noun, where module is optional. The noun-verb versions, while maybe more "orderly," aren't as nice to type or say.

A J: Exactly. Those were some of the ideas behind it. The other goal was to attempt to make the code as potentially modular as possible, while retaining a common interface.

Then again, it is my opinion that as much as possible should be put into addons (whether or not these addons are distributed with standard distribution is a non-issue). From a design standpoint, streamlining the seams in the library is advantegous because it reduces undesired conflicts, and allows us to update addons independantly of the "core" library with minimal breaks. I mean, pretty much all (if not all) of the input, graphics, geometric primatives, audio, config, datafile, gui, 3d, fixed point, etc. routines could be seperated from the core, allowing updates of them individually (to a certain point, at least) without requiring all of the other modules to be updated.

This is one reason (the main reason), IMHO, that the current allegro release cycle is at least a year between major versions; no matter the changes to the module, you have to wait for the updates on all of the other modules to be completed in order to have the library rolled up to the next stable version. I might be wrong, but this is my opinion. Through better modularity you also gain the ability to completely exclude portions of the library that are not being used. Don't need FOO support? Don't #include them, link against them, al_install(ALA_FOO) (ALeggro Addon FOO), whatever.

I am sorry for my "critical" post, but I still have troubles in compiling Allegro with DJGPP under DOS. Now I trying lastest Allegro 4.3.0 from SVN (revision 7395) and lastest DJGPP packets:
djdev 2.03
gcc 4.1.0
g++ 4.1.0
make 3.79.1
binutils 2.16.1
Texinfo 4.8
sed 4.1.5
But unfortunately I get error and warning messages again.
For this time they are:
==============================================================================
In file included from ./include/allegro/internal/alconfig.h:65,
from ./include/allegro/base.h:39,
from ./include/allegro.h:25,
from src/allegro.c:23:
./include/allegro/platform/astdbool.h:29: error: two or more data types in declaration specifiers
./include/allegro/platform/astdbool.h:29: warning: useless type name in empty declaration
make.exe: *** [obj/djgpp/alleg/allegro.o] Error 1
==============================================================================
Can anybody help me to build any version of Allegro without any error or warning messages at last? Thanks a lot.

Weeee. I'm gonna test it right away.

When you state it in such terms, of course the "independent" addons are going to be viewed in a better light. But if they aren't really independent there's actually more work involved because now you have to maintain an unofficial interface as well. Consider AllegroGL and what they have to go through.

In MINGW i had to copy some include files manually, but its just minor thing.
Except that, it work good for now, thanks a lot for this release

It turned out to be just one (first time i copied all files that wasn't there >.<)

allegro\platform\astdbool.h

How is it not consistent?

Ack!
Am I really the only one who finds the latter completely backward? The first reads more or less like natural language, afterall, you say `create me a bitmap', not `a bitmap create for me', right?
I understand that the latter reads more like bitmap.create(), which I personally don't find a convincing argument because that reads equally unnatural.

Have a look at al_blit() and your question will be answered.
(Which reminds me, there was some discussion for putting the flags as the first parameter; after playing around with that, I find that I like the idea and it does feel more natural. Did we reach a consensus when discussing this?)

That's the idea. Not in the least so that a change to the graphics driver doesn't affect the GUI (say), or such that programmes don't pull in all code.
Takes time though, so patience!

You are indeed wrong, and it's not clear to me how you can have an opinion on something that is falsifiable.
As Peter said, the problem is workload. We all have work and lives outside from work and programming. I seriously hope no one is willing to compromise their social life for working on Allegro; that means, however, that things sometimes go a bit slower than one would want. In addition, doing an Allegro release is more work than just tar -cvfz allegro.tar.gz allegro/*. The directory tree has to be cleaned, pending patches have to be commited, the result has to be tested (more so for stable versions than for WIP releases), the change log and credits need to be updated, packages need to be made for Windows and *nix and uploaded, an announcement has to be written and posted. This is all rather tedious and when taken together, time consuming as well.

I don't think the graphic VTABLEs have cchanged at all, which means that the current display API is sitting on the old drivers, that don't really accomodate the new API nicely. So that will have to be changed.
Anyway, merging AllegroGL with Allegro 4.3 should take care of that problem.

Unless of course you're Yoda or something But yes, I like it the way it is. It sounds exactly how you'd actually say it.