If you're working on a 2D game and just use 3D hardware for accelerated rotations, blending and scaling, you don't need more than the bare minimum, though, do you?

The codes already done, I'm looking for a walk-through on how to add a driver to allegro the way allegroGL has.

There is some minimal information on the wiki: http://awiki.tomasu.org/bin/view/Main/AllegroDev

However, there is no walk-through how to do it, the relevant parts of the code you have to touch are very few and easy to follow - but you will need to understand how it works, to add a driver.

You could start by grepping for "set_gfx_mode", and it should lead you to the driver selection, which should lead to the structures used for gfx drivers, with their vtables and all. AllegroGL will then somewhere define and register its own version of that structure, probably you also will want to copy the way AllegroGL destroys the current Allegro window in its set_gfx_mode, and then connects its own window to keyboard/mouse and so on.

If you need any hints where to find things in the source code or can't figure out how something is supposed to work, just ask (here or on the ML or in #allegro, if you happen to catch someone who knows in the latter case).

Sounds good to me. Never used OL though

This list is quite long. The biggest reason being because it does not take control of page flips / buffer swaps.

That is really the right attitude when it comes to designing and implementing the new graphics API. You did know that's being worked on, right?

Well, you could start making the to-be official C++ wrapper for Allegro

Fladimir: only human brain can handle multiple complex operations at the same time ;-p

I was thinking AllegroGL could help to handle those things. I am also thinking that some things are tried to help merging AllegroGL && Allegro.

But correct me if I am wrong !

Allowing threading or OpenGL programming is not a C++ only spell ;-)

You could view OpenLayer as my vision of that. Originally, it was intended to support software rendering as well, but I thought that there was really no reason for that - the software routines would run far too slow. If a computer can't support hardware rendering, it's usually too slow to do the same routines in software as well.

Eh, there is a driver system, but it's just for different OpenGL libraries. The SVN repository is located in Berlios (the first link in my sig). It's best to discuss the plan throughoutly...

One way would be to implement all the drawing functions separately for OpenGL and Direct3D (or at least the parts that differ), using #ifdef OL_USE_D3D everywhere. It'd be possible to make OL to use Direct3D by default when compiling the library for Windows.

I know almost nothing about D3D, so seeing the code could help a bit to see what should be done. For example, I have the impression that D3D isn't state-based like OpenGL is...

Not really... and you have to make a DirectGraphics9 object which is probably the closest thing you have to the OpenGL 'state'.

I don't know for sure if it's possible or not. For my own game project, which will be 2D (iso), I have looked into those 3D libs and decided to use the simpler approach, i.e. allegro-based. OpenLayer has the advantage that it uses hw acceleration, but has a simple interface, so I decided to go for this.

That doesn't mean of course that OL cannot be implemented using one of those libraries, but someone has to dig into the relevant data models and find out if it can be done (most probably it can), and what effort it would be (not too easy, I guess). I must say that I would do this if I had any time for it. But as it is, my spare time is way too limited (especially towards the end of the year), so my personal preference is to work on my game...

Edit: As an additional remark I would say that changing OL to use e.g. OGRE is not harder than changing it to use both OpenGL and D3D. Changes have to be made in any case. But I also would say that it's not easy and straightforward to make such changes, and it might turn out that the overall design of OL (using AllegroGL and other libs) is not suited too well to use D3D or OGRE or something really different from OpenGL. I might be wrong with this though, because I'm not (yet) an expert with OL or OGRE...

OpenGL commands are currently directly integrated, but Allegro isn't. Any abstraction layer might make the results a bit better readability-wise and editing the code easier, but would also add overhead which would slow down the results.