Software OpenGL Rasterizer + Quake 2

basically, lacking much better to do recently, I wrote a basic software rasterizer and put an OpenGL front-end on it, then proceeded to make Quake 2 work on it:

yes, kind of sucks, but there are some limits as to what is likely doable on the CPU.also, it is plain C and single threaded scalar code (no SSE).a rasterizer using multiple threads and/or SSE could potentially do a little more, but I don't know, and don't expect there to really be much practical use for something like this, so alas.

writing something like this though does make one a little more aware what things are involved trying to get from geometry to the final output.

otherwise, may need to try to find something more relevant to do...

ADD:as-is, it basically mimics an "OpenGL Miniport" DLL, which means it exports the usual GL 1.1 calls, along with some WGL calls, and some wrapped GDI calls.

this is loaded up by Quake2, which then goes and uses "GetProcAddress" a bunch of times to fetch the various function pointers.

it has to export pretty much all of the 1.1 calls, though a lot of them are basically no-op stubs (would normally set an error status, currently rigged up to intentionally crash so the debugger can catch it...).

as for functionality not implemented:* texture-coordinate generation stuff;* display lists, selection buffers, accumulation buffer, ...* pretty much everything else where I was like "what is this and what would it be used for?"* currently doesn't do DrawArrays or DrawElements, but this may change.** would basically be needed for Quake3 to work IIRC.** partial provisions have been made, but logic isn't written yet.internally, it implements the actual drawing to the screen via CreateDIBSection and BitBlt and similar.

then it has a few buffers, for example, a color-buffer, implemented as an array of 32-bit pixel colors (in 0xAARRGGBB order, AKA, BGRA), as well as a Depth+Stencil buffer in Depth24_Stencil8 format (I was originally going to use Depth16 and no stencil, but then I realized that space for a stencil buffer could be provided "almost for free").

at its core, its main operation is "drawing spans", which look something like:

the actual process rendering goes something like:* build up arrays of vertices via the glBegin/glEnd/glVertex interface;* if needed, decompose into triangles (pretty much everything other than GL_TRIANGLES is decomposed);** ok, GL_QUADS is also semi-primitive, but in the rasterizer each quad is treated as a triangle pair.* feed vertex data through a combined Projection*ModelView matrix;* subdivide triangles, such that each triangle has a limited screen-area;** needed or else textures warp all over the place (crazy bad texture deformation);** each triangle, if sufficiently large, is split into 4 sub-triangles, which may happen recursively;*** Zelda Triforce logo configuration.** quads are also divided into 4 pieces.* divide all vertex XYZ coordinates by W;* clip all the triangles/quads/... to fit on screen;* convert this into the form used by the rasterizer:** fixed point XY values with separate Z.** set magic numbers to indicate which drawing logic will be used.*** flat color? texture? needs fancy blending or tests? ...* hand them off to backend.

backend:* walks lists of triangles/quads, passing each to the appropriate rasterizer function.** quads basically just invoke the triangle-drawer twice, first for vertices 0/1/2, then for 0/2/3.* there are different triangle-draw functions for different types of triangles (flat, textured, interpolated color, ...)** in turn, function-pointers are often used to select the appropriate span-drawing functions.* the handling of blending/tests/... is basically done by assembling the blend-and-test logic out of function pointers.** different functions for the different collections of tests to be performed;** functions to select each individual operator for a given test*** GL_LESS vs GL_GEQUAL, GL_SRC_COLOR vs GL_DST_ALPHA, ...*** don't want to use switches, as these are *very slow* if done per-pixel.**** wanted to avoid the thing going at glacial speeds at least...

I played quake II a hell of a lot back in the day (and a bit recently) and that's pretty much bang on, I wouldn't be able to tell it apart if I didn't know. In fact I got so lost in the memories of playing those levels that near the end of the video I forgot it wasn't just a recording of the game. Quake II had it's own software rendering mode I remember using before I had a card, I remember it was real blocky, I would imagine carmack wrote the interface for that to match the opengl signatures, might be interesting to compare how that did the rendering.

yeah. there were a few bugs visible in the video that I have since fixed, as well as fiddling with it trying to get things to be a little faster.

unlike the Quake2 software renderer, this rasterizer currently works in 32-bit colors. I had considered 8, 12, or 16-bit colors, but had decided against this at the time (color fidelity would be lower, but they could give more opportunity for use of lookup tables).

unlike with hardware accelerated OpenGL, it basically does pretty much everything with nearest filtering. the software rasterizer here can support bilinear filtering, but it is somewhat more expensive.

as-is, it doesn't use any SSE or ASM, though these could potentially be helpful.