After I have no success with BUILD (you can remember my misery with the input handling...), I decided to give Allegro's 3D engine a try. My goal is to make a System Shock 2-like game for DOS (with software rendering, of course). Is the Allegro 3D engine good enough for this duty? It has some very nice features not present in the most DOS based 3D engines, like true color texture support, but can it do:

-basic lightmapping (not as good as in Quake, but something like in SS2),
-colored lightning,
-transparent objects (windows, water surface, etc.),
-transparent models,
-some kind of visibility determination,
-bilboarding,
-skyboxes,
-a true 6DOF, 3D environment?

And is there any 3D engine which has these features and built upon Allegro?

I think there was once a source port of Doom which uses Allegro's 3D routines for the software renderer module. It's probably still on the depot. I could be wrong though...

Doom isn't a raycaster. It just renders polygonal sectors. As for lack of 6 DOF, Build engine has exactly the same problem - up/down camera movement is just a fake. The same effect was added to Doom engine later (in Heretic or Hexen).

Yes, it's possible.

It certainly is possible to use Allegro 3d routines to write a real 3d game. But I'm quite sure that Quake has about 10x faster polygon rasterizer so playing your game would need a lot of computing power.

Could you tell in a few words why do you want to use Allegro 3d routines and not some real 3d API or even a full-blown engine? Is it just for fun/learning experience or something else? If it is a learning excersize then what are you trying to learn?

Too bad. I'll just say that for the most of the world (MS)Dos has been dead for over five years now and I personally see no point in developing games for it.

If you have some fancy arcade machine then it is of cource a whole different story. Unless you have some really high-end CPU in that there is little chance you can get anything to run with decend quality on it by using Allegro routines.

For a reference you could run allegro test program and do the 3d benchmark to get a rough idea how many polygons can your computer run. Then divide the number with expected framerate and number of passes (2 if you only use lightmapping).

Here are results on 4GHz P4 runing at 800x600-32bpp in windowed mode under Linux X11:

Memory profile results, using MMX:

    flat           - 192476
    gcol           - 78375
    grgb           - 79050
    atex           - 92142
    ptex           - 43882
    atex mask      - 61163
    ptex mask      - 30742
    atex lit       - 57365
    ptex lit       - 36114
    atex mask lit  - 50197
    ptex mask lit  - 31243

ptex is the number that intrest you for drawing perspective-correct textured polygons. For lightmapping you will probably need to combine it with either lit or mask, I don't really know. Perhaps even you have to write your own rasterizing functions.

Assuming 30FPS you can roughly render 1.5k polygons (triangles) per frame*. Using coloured lightmapping would leave about 500-750 plygons per frame or less**. Average very low-poly model has ~100-200 polygons, half of them visible. If you have several opponents on screen things will get even more "interesting". Now if you have a slower machine divide them by some certain number, e.g for 500MHz I would divide by something between 5-10. Now add other things that take CPU time (2d UI, sound, networking?, AI) and you get a pathetically low number

*) Actually Allegro is not really polygon-limited but pixel-limited but since I have no idea how many pixels per second can Allegro rasterize I just go the easy way and assume that games have as big polygons as allegro test program

**) Translucent stuff will eat pixels as there is no tomorrow, also I have no idea how complicated coloured lightmapping is. Most probably quite complicated.

To get better understanding of how fast Allegro 3d is I suggest porting some nehe tutorials to Allegro 3d. I did it once and it requred only minor changes if I used the allegrogl port of the tutorial. IIRC I could render quake2 grunt with about 250 polygons, no lightmapping and about 1/3 screen coverage on 640x480@8bpp on 3.3GHz P4 around 100FPS.

A real game engine, like build, quake or others.
Btw, quake 1, 2, and 3 are all opensource now but I think only the first one runs in dos.

Also, there is mesa3d, a software implementation of OpenGL that should run in Dos
http://www.mesa3d.org/
I wouldn't be surprised if you get much better speed with using mesa than using allegro 3d routines

http://www.mesa3d.org/README.DJ
Well, guess what... this is the DOS port of Mesa 6.3, for DJGPP fans
That should mean Mesa compiles with DJGPP.

I would assume it is. After all, Mesa is the same as OpenGL and you probably know AllegroGL

I couldn't get Mesa to compile with DJGPP either. Two or three tries a few months apart. Open Watcom is good as long as you don't need more than Pentium II capabilities (although the wasm assembler knows recent stuff), gcc or MSVC mop the floor with Watcom. Using Allegro would probably be slower than optimizing exactly what you need for your game, say, 20%. OTOH, I was trying some 1997 texture mapping code from Chris Heckers web page a couple years ago, it was optimized for Pentium I, it ran 40% faster than Allegro texture mapping on a real Pentium I but 20% slower on an AMD K6-2, and the allegro stuff looked better too.

That could have something to do with the 3DNow instructions.

Allegro's 3D stuff. Though, I haven't used it in a long while. Any computer worth playing games on these days will have respectable OpenGL support, and you can do so much more with OpenGL than Allegro's 3D stuff.