Software rendering was useful for me for a long time but as a long-time gamer (from the original DOOM to Cyberpunk 2077 and beyond) I can firmly say that real-time raytraced games at 4K/60FPS with dynamic lighting, reflections, massive geometry detail, etc, all greatly enhance the experience. That said, the old DOOM aesthetic pre-Voodoo was definitely nice. The voodoo smoothing had a nice cheap feel to it, too.
Software rendering often provided better visual effects than the GPU paths could provide at the time. A general purpose CPU can technically do any effect since the software is the pixel shader.
Programmable shader pipelines weren't a thing until Geforce 3 in 2001.
I'm going to guess if you did it on the video card and simply disabled those enhancements it would be considerably more energy efficient than doing it on the CPU as well which (a) means your laptop battery lasts longer on a charge, and (b) also opens up the possibility of not needing a particularly powerful CPU in order to juice the resolution, because the video hardware is doing the work for you.
From a programming perspective I do completely get the desire to have the CPU do all the work though - if you want absolutely everything under your control it's easier, and especially if your game is single-threaded.
This isn't software rendering, it's called turning off spatial anti-aliasing. You can still do that in the modernest of modern games. Software rendering went out of the window because the CPU tends to have other things to do whilst playing the game besides only multiplying 4x4 matrices, which was shifted to the shader cores of GPUs. The look-and-feel that OP is discussing including shadow and texture LUTs can also be done on GPUs; there is nothing specific to software rendering. It bears mentioning that many modern software renderers (LLVMpipe/Lavapipe, OpenSWR, WARP) are basically full D3D/OpenGL/Vulkan devices in their own right, including shader compilers.
Also, modern spatial anti-aliasing works by multisampling within a pixel (or even neighbouring pixels) and taking the average, rather than filtering across singly-sampled pixels, which massively reduces the quality. Not to mention temporal and machine learning AA techniques including DLSS, XeSS, FSR, and all the TAA implementations in many games.
How is it not software rendering? These games shipped without hardware renderers. Yes, they also don't have AA, but how does that make it not software rendering?
One of the headline reasons OP prefers software rendering is because it's "how these games were built" so (1) we're clearly talking about DOS games and (2) turning off AA is clearly not going to help. :)
"Software rendering went out of the window because the CPU tends to have other things to do besides just multiply 4x4 matrices, which was shifted to the shader cores of GPUs."
Hardware rendering took over because generating a 3D scene is embarrassingly parallel, and the industry quickly learned that you can have thousands of reasonably simple "cores" that can divide and conquer a scene in parallel. There was a no way a general purpose CPU could keep up.
The article says that "even a 3.3GHz quad-core Xeon “isn’t quite enough to run Shadow Warrior at full 1600 by 1200”." But we are on DOS, so I guess three cores are just not doing anything there?
There is simply no way a modern CPU cannot crush much harder problems than Shadow Warrior. The throughput of multiple threads/SIMD/memory bandwidth + data-oriented design is terrifying. The TFLOPS are an order of magnitude less than a GPU, but still well behind human comprehension.
The Build engine's rendering was stunningly simple (and dare I say: elegant). You could run hundreds of instances of Shadow Warrior on a single EPYC (since they mentioned Xeon) if you rewrote it with modern mechanical sympathy in mind.
People, including many programmers, just don't grasp how much power we have under the hood nowadays...
Unreal (and Unreal Tournament), Thief, Quake II (a slight improvement over Quake), Half-Life (a great improvement over Quake), Shadow Warrior,
Any modern port of Doom supporting software rendering, Heretic, Hexen, Descent, System Shock, Homeworld.
> Ion Fury, a Build engine game from 2019, still ships with a software renderer.
Amazing game BTW, best shooter I've played in many years. I never really got into build engine games back then, so it's not just my rose-tinted glasses, that game is a masterpiece.
Ion Fury uses a modified version of eDuke32 which can do software only rendering, and quite well, but defaults to GPU acceleration because Ion Fury uses the real time lighting.
That said, the Build Engine had software voxels in 1997. Which was pretty cool.
I share the same opinion as the author. That said, it's also important to remember that the display devices of the time were different than they are now and the sharp pixelated textures we see now would look a bit different on a CRT from that period. The sharp, gritty look that he (and I) admire would have been just a little fuzzier back then.
A tiny bit fuzzier but not in a way that mattered back then. If you're running a software renderer it could well have been at 320x200 and on any monitor that comes out still looking pretty much like an LCD display, with slight blending on the edges technically but still large, large pixels not being blended. Even at 640x480 there was noticeable blockiness not being blended away. Monitors were designed to be sharper than the televisions the consoles were outputting to. Software rendering at anything high enough to be blended looking was a slideshow.
“Software rendering” usually means “doing rasterization on the CPU”, as opposed to “hardware rendering” that is done by the rasterization primitives of the GPU.
Nanite is a bit weird because it doesn't use the hardware rasterization of the GPU, but it's still doing rasterization on the GPU, so it doesn't really fit this dichotomy.
No software rendering requires DOS, you could use it with Windows back in the day (how I originally played Half Life) and engines that still support it will run on modern OSes too.
Eh, Nanite rasterisation is still happening on the GPU, it's "just" implemented in shaders rather than using the fixed-function pipeline. "Software rendering" is becoming less useful as a descriptor as graphics hardware becomes more general.
Wrote a little software rasterizer for a roguelike years back and the best part was just being able to step through the whole pipeline in a debugger. No driver weirdness, no shader compile quirks, the pixel is wrong because your math is wrong.
Software rendering was useful for me for a long time but as a long-time gamer (from the original DOOM to Cyberpunk 2077 and beyond) I can firmly say that real-time raytraced games at 4K/60FPS with dynamic lighting, reflections, massive geometry detail, etc, all greatly enhance the experience. That said, the old DOOM aesthetic pre-Voodoo was definitely nice. The voodoo smoothing had a nice cheap feel to it, too.
Software rendering often provided better visual effects than the GPU paths could provide at the time. A general purpose CPU can technically do any effect since the software is the pixel shader.
Programmable shader pipelines weren't a thing until Geforce 3 in 2001.
This should really be titled "I love pixelated textures".
> "3D cards smoothed textures with bilinear filtering"
You can just not do that.
Valve added this as an option to Half-Life in the 25th anniversary update, and I thank them for it - it looks much cooler.
I'm going to guess if you did it on the video card and simply disabled those enhancements it would be considerably more energy efficient than doing it on the CPU as well which (a) means your laptop battery lasts longer on a charge, and (b) also opens up the possibility of not needing a particularly powerful CPU in order to juice the resolution, because the video hardware is doing the work for you.
From a programming perspective I do completely get the desire to have the CPU do all the work though - if you want absolutely everything under your control it's easier, and especially if your game is single-threaded.
This isn't software rendering, it's called turning off spatial anti-aliasing. You can still do that in the modernest of modern games. Software rendering went out of the window because the CPU tends to have other things to do whilst playing the game besides only multiplying 4x4 matrices, which was shifted to the shader cores of GPUs. The look-and-feel that OP is discussing including shadow and texture LUTs can also be done on GPUs; there is nothing specific to software rendering. It bears mentioning that many modern software renderers (LLVMpipe/Lavapipe, OpenSWR, WARP) are basically full D3D/OpenGL/Vulkan devices in their own right, including shader compilers.
Also, modern spatial anti-aliasing works by multisampling within a pixel (or even neighbouring pixels) and taking the average, rather than filtering across singly-sampled pixels, which massively reduces the quality. Not to mention temporal and machine learning AA techniques including DLSS, XeSS, FSR, and all the TAA implementations in many games.
How is it not software rendering? These games shipped without hardware renderers. Yes, they also don't have AA, but how does that make it not software rendering?
The point is that the thing that OP likes has nothing to do with whether something is rendered in software or hardware.
They mean that what the OP prefers about it is not the fact that it’s done in software. “This” is “the thing the OP seems to prefer”.
One of the headline reasons OP prefers software rendering is because it's "how these games were built" so (1) we're clearly talking about DOS games and (2) turning off AA is clearly not going to help. :)
"Software rendering went out of the window because the CPU tends to have other things to do besides just multiply 4x4 matrices, which was shifted to the shader cores of GPUs."
Hardware rendering took over because generating a 3D scene is embarrassingly parallel, and the industry quickly learned that you can have thousands of reasonably simple "cores" that can divide and conquer a scene in parallel. There was a no way a general purpose CPU could keep up.
Love seeing Blood mentioned, sometimes I feel like I'm the only one who played it
Is software rendering the reason that people can run doom on everything?
Yes
The article says that "even a 3.3GHz quad-core Xeon “isn’t quite enough to run Shadow Warrior at full 1600 by 1200”." But we are on DOS, so I guess three cores are just not doing anything there?
There is simply no way a modern CPU cannot crush much harder problems than Shadow Warrior. The throughput of multiple threads/SIMD/memory bandwidth + data-oriented design is terrifying. The TFLOPS are an order of magnitude less than a GPU, but still well behind human comprehension.
The Build engine's rendering was stunningly simple (and dare I say: elegant). You could run hundreds of instances of Shadow Warrior on a single EPYC (since they mentioned Xeon) if you rewrote it with modern mechanical sympathy in mind.
People, including many programmers, just don't grasp how much power we have under the hood nowadays...
> Games worth trying
I can add more:
Unreal (and Unreal Tournament), Thief, Quake II (a slight improvement over Quake), Half-Life (a great improvement over Quake), Shadow Warrior, Any modern port of Doom supporting software rendering, Heretic, Hexen, Descent, System Shock, Homeworld.
> Quake II (a slight improvement over Quake)
That colored lighting, though.
> Ion Fury, a Build engine game from 2019, still ships with a software renderer.
Amazing game BTW, best shooter I've played in many years. I never really got into build engine games back then, so it's not just my rose-tinted glasses, that game is a masterpiece.
Ion Fury uses a modified version of eDuke32 which can do software only rendering, and quite well, but defaults to GPU acceleration because Ion Fury uses the real time lighting.
That said, the Build Engine had software voxels in 1997. Which was pretty cool.
My understanding was they removed that software renderer specifically because it didn't run well.
And for those who want more of this type of game I must absolutely recommend the game “Supplice” as well.
I share the same opinion as the author. That said, it's also important to remember that the display devices of the time were different than they are now and the sharp pixelated textures we see now would look a bit different on a CRT from that period. The sharp, gritty look that he (and I) admire would have been just a little fuzzier back then.
A tiny bit fuzzier but not in a way that mattered back then. If you're running a software renderer it could well have been at 320x200 and on any monitor that comes out still looking pretty much like an LCD display, with slight blending on the edges technically but still large, large pixels not being blended. Even at 640x480 there was noticeable blockiness not being blended away. Monitors were designed to be sharper than the televisions the consoles were outputting to. Software rendering at anything high enough to be blended looking was a slideshow.
Unless you were playing on a TV CRT, I don't think so. PC monitors of the time were pretty sharp already.
I too. So that I have written many software renderers in many years. A video with my recent project having a software renderer: https://www.youtube.com/watch?v=NepOPAPDvwA
Anyone wants to tell him about CRT's?
Now that will truly blow his mind, at least on this setup and older games.
UE5's nanite uses software rendering, but it doesn't look pixelated, does not need a high end computer, and does not require DOS.
“Software rendering” usually means “doing rasterization on the CPU”, as opposed to “hardware rendering” that is done by the rasterization primitives of the GPU.
Nanite is a bit weird because it doesn't use the hardware rasterization of the GPU, but it's still doing rasterization on the GPU, so it doesn't really fit this dichotomy.
No software rendering requires DOS, you could use it with Windows back in the day (how I originally played Half Life) and engines that still support it will run on modern OSes too.
Its probably not correct to state this. Its probably a combination of how nanite itself is doing Lob, lightning etc.
A mix of software and gpu
Eh, Nanite rasterisation is still happening on the GPU, it's "just" implemented in shaders rather than using the fixed-function pipeline. "Software rendering" is becoming less useful as a descriptor as graphics hardware becomes more general.
At this point words get blurry. Is using CUDA or a compute shader "software rendering" or not?
Wrote a little software rasterizer for a roguelike years back and the best part was just being able to step through the whole pipeline in a debugger. No driver weirdness, no shader compile quirks, the pixel is wrong because your math is wrong.