You might want to look into OGRE.
It seems to be what you're looking for.

(Small note: this is to discuss "allegro.cc" the site, not "allegro" the library. You might have wnated to post in the "Allegro Development" forum).

The only thing I'd really like to see in Allegro is:

IDirect3D9 *al_Direct3DCreate9(UINT SDKVersion);

So true!

Ariesnl: Are you asking permission for making a new style allegro library? You don't need permission for that, just go right ahead. No problem.

I think Korval wasn't going to include a full 3d engine though.

isn't allegro in full c ?

I think someting I'd really like to see in allegro is more GPU usage.

hum allegro has support for DirectX hardware .. hum how about OpenGL hardware ? on some com's OpenGL HW is faster

I think it was directDraw, not Direct3D. There is quite a big difference.

We're not `ignoring' it, we know it's there. But someone has to write the driver for that. Someone with OS X, that is. Of active developers, I think that implies Pete Hull.

Who ever said it was easy? I tried to integrate AllegroGL as an OpenGL driver on my sandbox copy of the new API branch a few weeks ago to get an idea for how the OpenGL driver would work and how some of Allegro's internals would have to be modified. I couldn't figure out how to integrate it `properly' (as a new driver), but I admittedly stopped trying after a short while (I had other things to do). If I take a day or two to look things over and sit down for it, I should be able to do it without too much problems.

The most confusing part, at first, as that most Allegro functions are really wrappers around calls to vtable functions. Once you know if a function is implemented in a vtable you can probably find it easily enough by opening the associated driver file (there's some logic to the naming of these, fortunately).

Allegro's internals are very poorly documented and that will need to be remedied in the new api, but right now there's not much we can do about it.

Ok, let me rephrase that and put it into context.
That Allegro doesn't do blitting operations in hardware is in itself easy to fix in that it doesn't require (in principle) a massive rewrite or change of internal code (though that will be needed to make things a bit cleaner than they are now), it requires an extension of the driver. The operation of adding hardware acceleration to Allegro is trivial in the sense that it's a matter of filling in the missing vtable entries. It's a matter of someone supplying the function and someone plugging it into the vtable.

The hard part is figuring out how an existing driver works, where it is and writing a new driver from scratch. This isn't always obvious, but you don't always need to know either.

Well, that was meant to be implicit. Obviously, it's not easy to change something in sourcecode you have never seen before.

Anyway, hypothetical situation, if I told you the function prototype that a hardware accelerated blit function (say) should have, could you write it assuming you knew how to acces data from a source bitmap? When it comes down to it, that's all that is required for adding a vtable function.

Well, they're not. Some tasks are easy in principle, like the example above, but not for someone unfamiliar with the code.
It also makes quite a difference what piece of code you're working on. The xwin driver is a nightmare, as is the mouse handler. The Windows code I can barely make heads or tails of. The datafile and font code is reasonably straightforward, as are most drawing primitives from what I remember. The GUI isn't too bad.

Yes, that would be very useful. I intended to edit my post to point to the wiki, but somehow I only got gibberish when I tried to load the page.
It would be very useful if it were added to.