A couple of weeks ago I started a new project just for fun : A 'pure' software 3D renderer. Projection, clipping, BSP, LOD, Catmull-Rom splines and dynamic geometry all done just using wireframe and solid filled polygons.

I wanted to face the challenges of early nineties 3D where it's basically just you and and a lot of code and math.

I'm using C++ and OpenGL. GL just renders 2D triangles in a solid colour and I'm not using depth buffering. It's all just BSP sorting so it looks the right kind of early nineties glitchy that I'm going for.

Interested in what you guys have to say.

I'm thinking about creating some kind of Missile Command game with this.

https://www.youtube.com/watch?v=oBthZHSV2f8

Calling this ‘pure software 3D’ feels not right IMO. Maybe ‘Software T&L’ would be a better description.

When first GPUs came up, many games kept transformation, projection and back to front sorting on CPU side and did not use HW Z Buffer. I remember MDK as an example.
Early GPUs had no HW support for transformation and projection anyways. They only did triangle rasterization with texturing. APIs like DX or OpenGL so did the other things on CPU as well. IIRC, GeForce3 was first that moved this to GPU.

‘Software Rendering’ usually means triangle rasterization with subpixel accuracy and perspective correct texturing at first. (I'd expect this form reading the topic title.)
At least it did. With Dreams or UE5 we may give the term a new meaning of rendering using GPU compute, but not (only) GPU rasterization anymore.

Interesting and fair points. I did put ‘pure’ within quotation marks because of that. I just used 2D lines and triangles as a basis, and worked from there.

Quick and dirty integration test with my 2D game project. The 3D really should be used for the computer screens you can interact with in the 2D game for some interesting reversal of affairs …