RE: [AD] Allegro 4.2 todos

[Charles Wardlaw <kattkieru@xxxxxxxxxx>]

> Trouble is, you'd end up doing a lot of work behind the scenes.
> You'd have to deal with textures (BITMAPs transparently being
> converted and uploaded), binding them, etc. Being in software,
> triangles are probably not sent sorted by state, etc.

BITMAPs as textures would be an issue, but not an insurmountable one. 
IIRC OpenGL calls use raw image data (uncompressed strings of pixels),
which is basically what software BITMAPs are.  Internally,  Allegro
could just pass those pointers.

(That *is* how the software BITMAPS work, right?  Not like hardware DX
bitmaps, where the resolution may or may not be larger than expected?)

As for hardware, video-memory bitmaps, well, if install_3d's been
called and OpenGL hardware support detected, then video memory BITMAPs
would somewhat automagically become usable by the 3D system.  (IE,
changes to a video-memory bitmap would be updated by Allegro so that
OpenGL could use them immediately.)
 
> And, the most important: emptying the pipe each time you switch
> between 3D and 3D. I know I *constantly* switch between the two
> in my own game (because there is no slowdown involved in doing
> so with Allegro's software rasterizer). You'd have to target
> OpenGL anyway to have a use for an OpenGL driver, so in this
> case you'd better be using AllegroGL directly.

Mmm...  This is partially true.  2D can be mixed in with 3D, in some
ways, almost transparently; sprites and the like used for HUD interface
items are just 2D textures mapped to special quads, generally speaking.
 So the user would need to be aware of this, and draw HUD items using
3D primitives.

As for lower-level 2D editing, like pixels, lines, and circles, well,
that'd be a toughie.  You could probably fake it by accumulating all 2D
edits on one particular buffer (which happens to be screen-sized), and
then draw that buffer as a texture above all else.  However, I'm sure
that'd result in a massive performance hit (just as too much texture
streaming of any type can kill framerates).  The simple answer would be
to warn the user that using hardware 3D routines is far different from
software and would require a lot of work on their part, bringing their
engines up to spec.  This is the reason the software routines would
still be readily available to anyone who wanted to use them - no break
in compatibility, and engines would still run under DOS.  At the same
time, the hardware routines are there for people who don't mind putting
in the extra effort in their rendering code.

> Then again, maybe not, I don't code 3D hardware.

Heh, I only dabble.  Matrix math gives me a headache, and don't get me
started on collisions... ^_^;;
- Charles