A love letter to software rendering, part 1
It's 1996, and I got my hands on the Quake demo. Like everyone else, the graphics blew my fucking mind.
At release, Quake only had a software renderer. So the CPU drew everything. The software rendering looked good, but Carmack's (and the often forgotten Abrash's) real technical feat was that it ran quite fast. PCs at the time only clocked at around 100 MHz.
Six months after Quake was released, GLquake was made available for free. As the name implies, it added OpenGL rendering to Quake. This was pretty much the death knell for 3d software rendering, short as its time was, making way for OpenGL, Glide, and DirectX running on discrete 3d accelerators. Quake 2 was the last Quake to ship with a software renderer. 3d accelerators could (and still can) simply draw way more things than a CPU can in the same amount of time. It doesn't hurt that using OpenGL is far, far easier than writing a software renderer.
Jumping to today: we have games that while we can't quite claim look like real life yet, can sometimes be mistaken for real life, especially in screenshots.
Skyrim
GTA V
The above games are both about a decade old, so you could say we've been in the time of pseudorealism for a while now.
At the same time, in part because of the expense of creating a realistic-looking game, there's been a resurgence of the low-poly aesthetic.
Untitled Goose Game
Donut Country
Some games go one or two steps beyond low polygon counts, and intentionally do things to degrade what is normally utterly clean and crisp hardware rendering. They often imitate the low fidelity rendering of early consoles like the Playstation and N64.
Heartworm
Bloodbourne PSX
Those consoles had all kinds of rendering pipeline failings and limitations, which contributed to a particular "look" for the platform. For an in-depth look at for example what made Playstation games look Playstation-y, check out check out this excellent article.
In any case, game creators today using Unity can just download one of several plugins to make their game look like a Playstation game, through the magic of vertex and pixel shaders.
Some (most?) of the people enjoying the aesthetic never actually owned those consoles. In spite of this, they're drawn to jank just like early 20th century people were drawn to Cubism. There's some essential quality, or lack of quality, that makes old, bad rendering attractive in a way that a realistic game cannot be.
Where it comes to Quake, as mentioned, it started with only a software renderer. Most everyone who had a graphics card later switched to GLquake when that was released. Over time, however, we began to realize that Quake simply looks better in software mode. Apart from all of the Quake -specific reasons pointed out in the article, while I wouldn't call Quake's software rendering "bad", it does have a certain comforting jank to it that gives it a Quake-y look. In 1996, the software renderer's niche was that it could draw 3d worlds in realtime on a home PC, and nothing else existed that could do that. Today, its niche is in evoking the Quake-y mood. I'm not the first person to realize this, and I've found at least one Quake fork that only exists to add more "special sauce" to the software renderer.
This is all to say that I'm in love with software renderers, and I'd like to make my own. I'm taking a lot of inspiration from places -- I particularly like Abrash's Ramblings in Realtime. Follow me on my journey of drawing pixels, making mistakes, and discovering my own brand of jank.