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 the author is discussing including shadow and texture LUTs can also be done on GPUs by passing the tables in to shaders as constant read-only storage buffers; that is not 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.

This should really be titled "I love pixelated textures".

> "3D cards smoothed textures with bilinear filtering"

You can just not do that.

Ah the software rendering era. Where I gained 10fps by adding a sound card.

Everyone is already pointing out this isn't quite software rendering but rather the rendering technique which used to be the only option. I'll add that even without a GPU, CPUs will have integrated graphics. There are CPUs that don't have this but in those cases you need a GPU. The point is that modern systems no longer use CPU to output to the screen, either there is an integrated GPU or a GPU card on the system. So in a way the term "software rendering" is only applicable to special cases of embedded systems that actually use CPUs for graphics.

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.

There's Quake-SRP (the Slop Rust Port), code here: https://github.com/terrapapagalli1516/quake-srp

Playable in the browser (shareware version): https://quake-srp.pages.dev/

It's a faithful port of Quake's original software renderer. Everything happens on the CPU, which made it easier to match the original exactly. In theory the same could be done on a GPU, but I think it would be harder and messier.

The trade-off with software renderer is that it's more code. With GLQuake much of the actual rendering work is handed off to OpenGL itself, i.e. the driver and the GPU. In the software renderer, the engine does all of that in its own code.

That screenshot is 800x600 - he probably wouldn't love software rendering at 320x240 which is what we actually had to run to get decent fps back in the day (late 90s). That was the the other big unlock of 3dfx voodoo, it could do 640x480 at 30 fps.

You know what I found this past year was that I could NOT find any way, to turn off anti-aliasing, for text inside a webview. I made a whole entire custom terminal app just for myself in Rust, Tauri, xterm.js and spent a ton of time trying to un-blur the text but failed. I redid the entire thing (well, Codex/Claude mostly) using a rust graphics library (egui) and now the text is finally sharp! and its fast. I am growing more and more anti webview with these AI coding tools.. they can almost one-shot convert a slow webview app into something that uses 1/10th the ram and 10x as fast. The text looks soooo much better, all fonts look better. In xterm.js, text looks super fat all the time (to me).

Michael Abrash's Graphics Programming Black Book is still one of my all time favourite. What they did back then was almost black magic. I learned a good part of maths, cs and physics trying to mod id1 with this book during my teenaghood.

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?

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.

I recently got to try out Quake 2 on 9front, a Plan 9 fork, which ran surprisingly fast on my very, very modest Thinkpad T410i with a 2.4 GHz dual core i3 at 1440x900. Plan 9 has no GPU support so all rendering is software. Even had a little lan party with other devs. I really enjoyed the software rendering, it bought back early memories of playing Q2 before we bought our Voodoo2. I even used my ploopy trackball to play. Fun times.

Presently, Plan 9 in general lacks 3D graphics but has an in-kernel 2D rendering engine referred to as devdraw. Quake 2 software rendering is done in-engine by rendering full frames to a bitmap displayed by devdraw. A fun experiment was to rcpu into my industrial DIN rail PC, a 1.2 GHz 4 core Atom, from the Thinkpad and play Quake 2. When I run Quake 2, it runs on the CPU server but graphics are sent to my laptop. However, since Q2 is rendered in-engine on the remote iPC, full frames are copied over gigE to my laptop. Q2 full screen was stuttering badly but at about 1/4 screen size it was surprisingly playable.

An other example is a port of cave story done by a 9dront dev where he integrated devdraw so the game renders by loading its assets into devdraw and issuing rendering commands. It is likely the first Plan 9 native game. It plays perfectly over an rcpu session at full screen as the rendering is done by the client side devdraw.

Another 9front dev is doing a lot of graphics work and implemented affine warping in devdraw which is useful for rapidly transforming bitmaps, e.g. scaling the output of the gameboy emulator and Doom. He and others are interested in implementing a concurrent 3D rendering software devdraw engine as we have many-core machines now. When GPU's first hit the streets, we were on single core machines. SMP machines were not affordable by mere mortals when the 3Dfx Voodoo hit the market. So the idea is, why struggle with the gargantuan task of implementing a "modern" GPU stack when you have all these CPU cores now? Why not take a step back, think about what we have learned, and extract all the performance we can from modern many-core CPUs with all sorts of vector extensions. In a Plan 9 context, you could run the game on a many core machine to handle game logic and play remotely with a bigger many-core spraying pixels at a display. Distributed gaming. Might even be able to do multiplayer with a single engine instance with multiple rendering clients attached. Fun system to play with.

Shameless plug of my upcoming game [1] which uses software rendering. Also did a Show HN and write-up [2] last year for a previous game [3] using the same engine.

[1] https://store.steampowered.com/app/5277420/Omega_Transmissio... [2] https://news.ycombinator.com/item?id=45270981 [3] https://totenarctanz.itch.io/a-scavenging-trip

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.

I know this is not entirely what this article is about, but I love software rendering for desktop apps. It seems to me that the performance impact with proper paint invalidation is negligible, but doesn't suffer from the same driver issues as hardware accelerated rendering seems to have. Bonus that it doesnt use any GPU resources in the age of AI

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

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

Is software rendering the reason that people can run doom on everything?

Is this why Doom is so portable?

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

I love Software Rendering too! I'd add Unreal Tournament to the list of "Games worth trying", though not sure what the multiplayer scene is like nowadays.

Love seeing Blood mentioned, sometimes I feel like I'm the only one who played it

Did you use any coding app to support you building the app? In that case, witch one is the one you choose and why. Thank you.

I am still a big fan of CPU render for VFX (not games). It is stable, capable of very large scenes. GPU is fast but you will never render something really big. And CPU look is much much better.

It should be pretty obvious that you don't need a Core 2 Duo to run Quake, which worked fine on a Pentium and some of the faster 486s.

Unreal Tournament also had a software renderer IIRC, with an interesting dithering effect.

Anyone wants to tell him about CRT's?

Now that will truly blow his mind, at least on this setup and older games.

Its so interesting to me that back then we would have died for the graphics we have today, and now this retro look is being appreciated. I mean, it definitely has an aesthetic but its generally unappealing. I guess nothing is immune to nostalgia and pining for being at the age when we had less responsibilities and life seemed easier.

Because the pipelines lacked fast, dedicated linear algebra engines, you saw a lot of clever hacks to get around having to do full linear algebra as well.

The original Marathon allowed you to look up and down, but it wasn't actually tilting the camera frame; it was applying a distortion on the field of view and then basically vertical scrolling the render target. Essentially, you can think of it like you were playing the game in vertical phone mode all the time but you were looking at the middle third of that possible output domain, and looking up and down pretty much just scrolled what you were looking at and applied a trapezoid transform.

This is why you couldn't look straight up or straight down, the trapezoid transform would become painfully obvious quickly and the actual algorithm did not really tilt your field of view.

But it was good enough that they could slap it on the box as a novel feature for Wolfenstein style first person shooters.

"I prefer the hum of tube amps, they sound so much warmer"

(And I actually do like their sound, but I wouldn't want to be stuck with only tubes)

I remember when I finally saw my favourite 3D games (Quake 2 and Pod) on a Voodoo2 and I immediately bristled: I hated the blurry way the textures looked with bilinear filtering, and was iffy on their love of yellow lighting.

I've softened on the issue of non-white lights, but I 100% am still full of nostalgia about unflitered low-res textures.

UE5's nanite uses software rendering, but it doesn't look pixelated, does not need a high end computer, and does not require DOS.

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.