i fuckin love software rendering. the act of creating a fully realized 3D scene entirely in your own program, without the aid of OpenGL or DirectX or any GPU whatsoever. something about that is so charming to me. it leads to so many interesting technical design decisions and shortcuts taken to get it to run fast (if that is the goal).
i've been on this kick bigtime since like 2022, when BRender got open sourced. i basically taught myself C programming by digging through the source code of BRender and trying to get it to build again. a totally fruitless effort of course, i was too inexperienced to get anything done, but it led to everything i've learned and am doing now, so i'm happy with it.
for some reason it just has such a special Look to it... i'm already a big fan of crunchy pixelated 3D graphics, so getting into the weeds about how it actually works was natural for me.
if you've gotten to this point in the post and aren't exactly clear on what software rendering is, i've come up with a loose definition:
software rendering: the act of creating 2D or 3D graphics entirely in the main body of a program, on the CPU, without the aid of any external hardware acceleration (like a GPU).
it's a bit of a loose definition, as i said, because there are actually some software renderers i've found that manually do all the rendering, but use something like OpenMP to parallelize the work, which could be considered hardware acceleration. the usage of SIMD Instructions is also common in software rendering in some situations.
my favorite examples of software rendered games are the original releases of Quake, DOOM and Duke Nukem 3D. all these games had highly optimized software rendering pipelines for their respective hardware targets (usually a mid to high range MS-DOS computer with an 80386 processor or better). DOOM and Duke Nukem 3D are especially interesting because over the decades, they've come to be known as "2.5D" games, as if their fully interactive environments are somehow missing half a dimension.
i mean, i understand why they've gotten that name. while the games do have a proper three dimensional Z-axis, the construction of the levels in those games is very... two dimensional in nature, usually being done on a flat grid drawing shapes that define "sectors" with a floor and ceiling automatically added. i just don't exactly agree with the assertion that it means they're somehow less than fully 3D. if you want a first person game that is genuinely missing a dimension, try Wolfenstein 3D from 1992. that game genuinely does not have any knowledge of how things move on a Z-axis, despite being played from a first person perspective. every single item, enemy and player in that game is placed by an X/Y coordinate on a two dimensional grid. it's a fascinating time capsule of game development at that point in time, trying to force a 3D game into hardware that was simply not powerful enough to support it (in this case, the 80286 CPU).
as of yesterday, i've added yet another 90s software renderer to my library of repaired/modernized projects on my github page. Plush3D! by Justin Frankel, originally made between 1996 and 2000 for Nullsoft, Inc. for those at home, that's three so far that i've done heavy modernization work to. here are the obligatory links: