RE: [AD] Allegro 5's new graphics core

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Laurence Withers writes:
> I don't think this is what Shawn was getting at. He was saying don't 
> reimplement OpenGL in Allegro; you are saying writing an Allegro video 
> driver that can map onto OpenGL calls. I think I can safely say that 
> both ideas are great, and would like to see them happen :-) 

Actually I think that mapping Allegro graphics called onto GL calls 
would be just as much a waste of time as reimplementing GL itself 
inside Allegro. It just doesn't fit well. Even if you make the screen
a radically different thing to bitmaps (which would be a great shame
for people doing regular 2D work, as it would remove a huge amount
of flexibility and capabilities).

I really like the "everything is a bitmap" concept: it is easy to
understand, flexible, and a good way of doing fast 2D graphics.

In 3D, even if the screen was different to regular bitmaps, it would
still be impossible to provide an efficient version of something
like al_draw_bitmap_to_screen(bmp, x, y), because functions like 
glDrawPixels() or glTexImage2D() are not the optimised path in most 
hardware/drivers. On a lot of cards it will be impossible to even 
just draw everything to a memory surface and then blit that result 
across to a 3D display at anything approaching a decent framerate.

The optimal 3D hardware approach wants textures to be read-only to
the CPU, and to be loaded into video memory (or in some cases
uncached physically contiguous AGP memory) at program startup,
using things like glBindTexture(). A very different fundamental
approach to any 2D graphics system.

I would far rather have a good (fast, flexible, easy to use) 2D
API, alongside a totally separate but equally good 3D API. 
Anything that tries to combine these two worlds will inevitably 
have to sacrifice much of the power that the current system can 
express in a pure 2D world, yet can still never be even remotely 
competitive with other, more native 3D approaches.

This hardware difference is too fundamental to be hidden by 
drivers (or at least, not without huge performance penalties).
The choice between doing 2D graphics in true 2D, or as textures
mapped onto 3D polygons viewed from a straight-on camera, is
so basic and far-reaching that it needs to be decided at the
very start of making a game, and pretty much everything will
then be designed in very different ways depending on which
approach has been chosen. Either method is valid and useful
in the right circumstances, but a compromise design is always 
going to be slow and limited at both. 

Today, Allegro is fast and good at true 2D. So by all means make 
something different that is fast and good at 3D, but be careful
not to undo the existing good 2D support in the process...



-- 
Shawn