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 calls implemented:
simple answer: about 1/4 to 1/2 of them.

as for functionality implemented by the rasterizer:
* most stuff related to glBegin/glEnd;
* things like glTexImage2D, glTexParameter, ...
* various misc things, like glClear, glClearColor, glDepthRange, ...
* matrix operations (glPushMatrix, glPopMatrix, ...)
* ...

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:void BGBRASW_DrawSpanFlatBasic( bgbrasw_pixel *span, int npix, bgbrasw_pixel clr){ bgbrasw_pixel *ct, *cte; ct=span; cte=span+npix; while((ct+16)<=cte) { *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; } if((ct+8)<=cte) { *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; } if((ct+4)<=cte) { *ct++=clr; *ct++=clr; *ct++=clr; *ct++=clr; } while(ct>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; } if((ct+4)<=cte) { clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; clr=(crag&0xFF00FF00)|((crrb>>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; } while(ct>8)&0x00FF00FF); crag+=cragv; crrb+=crrbv; *ct++=clr; }}...void BGBRASW_DrawSpanTextureInterpTestBlend( BGBRASW_TestBlendData *testData, bgbrasw_pixel *span, bgbrasw_zbuf *spanz, int npix, bgbrasw_pixel *tex, int txs, int tys, int st0s, int st0t, int st1s, int st1t, bgbrasw_pixel clr0, bgbrasw_pixel clr1, bgbrasw_zbuf z0, bgbrasw_zbuf z1){ BGBRASW_TestBlendFunc_ft testBlend; bgbrasw_pixel *ct, *cte; bgbrasw_zbuf *ctz, *ctze; u32 tz, tzv, tz2; int ts, tt, tsv, ttv, tx, ty; int cr, crv, crt; int cg, cgv, cgt; int cb, cbv, cbt; int ca, cav, cat; int clr, clrt; if(npix<=0)return; if((clr0==clr1) && (clr0==0xFFFFFFFF)) { BGBRASW_DrawSpanTextureBasicTestBlend( testData, span, spanz, npix, tex, txs, tys, st0s, st0t, st1s, st1t, z0, z1); return; } cr=BGBRASW_PIXEL_R(clr0)<<8; cg=BGBRASW_PIXEL_G(clr0)<<8; cb=BGBRASW_PIXEL_B(clr0)<<8; ca=BGBRASW_PIXEL_A(clr0)<<8; crv=((int)(BGBRASW_PIXEL_R(clr1)-BGBRASW_PIXEL_R(clr0))<<8)/npix; cgv=((int)(BGBRASW_PIXEL_G(clr1)-BGBRASW_PIXEL_G(clr0))<<8)/npix; cbv=((int)(BGBRASW_PIXEL_B(clr1)-BGBRASW_PIXEL_B(clr0))<<8)/npix; cav=((int)(BGBRASW_PIXEL_A(clr1)-BGBRASW_PIXEL_A(clr0))<<8)/npix; tz=z0; tzv=((s32)(z1-z0))/npix; tzv&=BGBRASW_MASK_DEPTH; ts=st0s; tt=st0t; tsv=(st1s-st0s)/npix; ttv=(st1t-st0t)/npix; testBlend=testData->testAndBlend; ct=span; cte=span+npix; ctz=spanz; ctze=spanz+npix; while(ct>8)&(txs-1); ty=((tt+128)>>8)&(tys-1); clrt=tex[ty*txs+tx]; crt=(BGBRASW_PIXEL_R(clrt)*cr); cgt=(BGBRASW_PIXEL_G(clrt)*cg); cbt=(BGBRASW_PIXEL_B(clrt)*cb); cat=(BGBRASW_PIXEL_A(clrt)*ca); clr=BGBRASW_MAKEPIXEL(crt>>16, cgt>>16, cbt>>16, cat>>16); testBlend(testData, &clr, &tz2, ct, ctz); ct++; ctz++; cr+=crv; cg+=cgv; cb+=cbv; ca+=cav; ts+=tsv; tt+=ttv; tz+=tzv; }}...
with functions which in turn use these for drawing triangles, ... (damn near everything is decomposed into triangles).

these functions are basically given raw pointers to the appropriate locations in the respective framebuffers.

the basic strategy for drawing each triangle is to sort the vertex from lowest to highest Y coordinate, then walk from one end of the triangle to the other, drawing each span.

* so: Y0=lowest, Y1=middle, Y2=highest
* calculate stepping vectors for left/right sides (Y0 to Y1)
* walk from Y0 to Y1, drawing each span.
* recalculate vectors for Y1 to Y2
* walk from Y1 to Y2, drawing spans.

dunno if there is a better way.


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...

...