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