First of all, do you even know what pixel shaders are? It seems that you do not, since you seem to ascribe some performance benifit to using them when, in fact, writing any significant pixel shader incurs a performance penalty

Secondly, AMD and Intel are not working on CPU pixel shaders; that doesn't even make since (which furthers the notion that you don't understand them). If they are working on anything in terms of shader programs, they are working on some kind of shader-capable embedded GPU for some of their motherboards. Where in the DX9 docs (specific page title or search string) does it say that Intel and AMD are adding pixel shader functionality to their CPU's?

Thirdly, how would pixel shaders "help alot" in terms of a primarily 2D graphics API? The primary use of pixel shaders is to perform per-pixel blending/arbiturary computation on incoming texels. That requires incoming texels; plurality is important. The usefulness of pixel shaders on a primarily 2D graphics API is pretty low.

Now there are ways to use shaders for 2D graphics. However, these do not mesh well at all with any normal 2D API. These concepts tend to involve taking multiple textures and applying a shader program to them; effectively, blitting them all at once to a destination. This is certainly possible, given an underlying 3D API, but specifying it in a traditional 2D API is just not possible.

Maybe I just don't optimize my code very well, but I started learning direct-x 7 from an "Andre' LaMothe" book and I tried to write a game than ran under direct-x and not only did it run slow compared to anything I wrote in allegro, but allegro also just seems to be easier to use, and more portable than direct-x too... it also has all the primitives and everything built in -- compared to direct-x which lets you basically plot pixels, and blit (as far as I could tell in 2D anyways...)

Maybe somebody should write a DOC about how to add new video drivers to allegro?

isn't allegro 2D?

i can't think of another way to prove my point.

JaTeR

Here's a question; if Allegro starts using OpenGL for stuff like drawing sprites, I assume they'll be textured quads, right? Does that mean all sprites will have to use dimensions that are a power of two?

Bearing in mind that Allegro does not allow for the sort of sprite co-ordinate wrapping that is used quite frequently with textures, surely AllegroGL dealing with this is a trivial matter of allocating textures at the board's maximum size until they stop being resident and then fitting sprites onto the textures (obviously more than one sprite per texture...) where possible using whatever algorithm? How does NV_texture_rectangle help?

But it would probably be slower? Plus I guess it might be a while before it becomes a standard thing ...

I never actually benchmarked it, so I can't tell you. I'm assuming that the speed should be the same.

As long as I'm being an inquisitive noob ...

I assume a 2D game could be made drawing textured quads with the Painter's Algorithm and the depth buffer turned off, or just keeping track of each image's "depth" (I do that anyway; sorting before drawing). Would a game using OpenGL (or AllegGL) run much faster than Allegro, even with no hardware acceleration? Since I assume Allegro gets a boost in hardware via DirectX, if nothing else ... just wondering. I'd try it, but it would take me a month

Remember that the 3D pipeline is the pipeline that driver writers spend their time augmenting more than anything. Certainly more than the 2D API.

Also, it is important to note that even a TNT2 has a 3D fillrate of something like 500 MegaPixels or so. Even at 75frames per second, a TNT2's 3D path can draw to the entire screen 22 times per frame. True, it never gets this in practice with actual textured polys, since it is bandwidth limitted. However, even within bandwidth limits, I imagine a TNT2's 3D path could get around 10 full screen draws per frame.

The key, especially on older hardware, to getting good 3D performance is sub-bitmaps. That is, for each layer, you have one gigantic texture that you render from. You want to minimize texture swapping as much as possible. You can't do much about sprites, but your tilemap should be easy enough to make efficient.

So yeah. I think a 3D pipeline would probably be faster than even an accelerated 2D pipe. When I finish my uber-tilemap library, I can do some performance analysis to find out for sure (though I run a Ti4200, not a TNT2).

To get precision problems, you'd have to have a texture with a 7-digit width. And, even then, you could get some of that back with denormalized floats (assuming the hardware supports them).

I switched my project from DX8.1 (2D in 3D) to allegro because I wanted to support the older systems. I moved to allegro because it was a 2D graphics platform that would run on old win95 machines. I didn't want to cut my market in half by enforcing people who download my game demo to install a 20mb DX driver.