Argues that the modern graphics stack has become so abstracted that most working engineers have never actually rasterized a triangle — they've only described one to a driver. By rebuilding a 1993-era pipeline from scratch, programmers can learn the fundamental mechanics (frustum clipping, edge functions, fixed-point math, perspective-correct interpolation) that GPUs normally hide. The constraints of 1993 hardware aren't archaeology — they're design lessons.
Observes that games like Lunacid, Signalis, and Bloodwych ship the iconic PlayStation 1 'wobble' texture warping as a deliberate stylistic choice, but almost none of them produce it the way the PS1 actually did. They render with a modern GPU and then add a shader to simulate the artifact — meaning the signature look is now an imitation of a mathematical consequence, not the consequence itself.
Explains that the PS1's wobbling textures were a direct math consequence of the GTE not performing per-pixel perspective division during rasterization — texture coordinates were interpolated linearly in screen space because the hardware couldn't afford the correct version. Understanding why 1993 hardware made these tradeoffs reframes the era's 'look' as engineering, not style.
A long-form blog post on software rasterization mechanics reaching 658 points and 108 comments on the HN front page signals that working developers actively want low-level graphics education. The audience response suggests the abstraction gap identified by the author resonates broadly with engineers who feel disconnected from what GPUs actually do.
A developer publishing under the handle Staniks has kicked off a blog series called *Catlantean 3D* — a from-scratch software 3D renderer written in the style of early-1990s console and PC games. No OpenGL. No Vulkan. No GPU at all. Just a framebuffer, integer math, and the same arithmetic tricks that shipped on the original PlayStation, the Saturn, and the 486-class PCs that ran *Doom* and *Quake*. The first post hit Hacker News' front page with 658 points, which for a long-form graphics-internals article is the audience telling you something.
The premise isn't nostalgia — it's pedagogy. The author argues, convincingly, that modern graphics programmers have inherited a stack so abstracted that most working engineers have never actually rasterized a triangle, only described one to a driver. The series walks through the parts the GPU normally hides: clipping against the view frustum in homogeneous coordinates, edge-function rasterization, fixed-point sub-pixel coordinates, perspective-correct vs. affine texture mapping, and the specific reasons 1993 hardware couldn't afford the correct version.
This isn't the first software renderer write-up on the internet — Fabien Sanglard's *Game Engine Black Books* set the bar — but it's one of the few that treats the constraints as design lessons rather than archaeology.
The PlayStation 1 "wobble" — the way textures swim and warp across polygons as the camera moves — is the most-copied visual signature in indie games right now. *Lunacid*, *Signalis*, *Bloodwych*, and roughly half of itch.io's 3D horror catalog ship that look on purpose. Almost none of them generate it the way the PS1 did. They draw with a modern GPU and then add a shader to fake the artifact.
The original artifact is a math consequence, not a style. The PS1's GTE (Geometry Transformation Engine) didn't perform a per-pixel perspective divide during rasterization. Texture coordinates were interpolated linearly in screen space rather than in clip space, which means the texture got stretched non-uniformly as the triangle's depth changed across the screen. Add the console's lack of sub-pixel precision — vertices snapped to integer pixel positions, causing the famous polygon jitter — and you have an aesthetic that emerged entirely from a bill of materials. Sony didn't choose it. They couldn't afford the alternative.
Understanding *why* the artifact exists is the difference between an engineer who can recreate any rendering style on demand and one who can only apply post-process filters to someone else's pipeline. The Catlantean series lays this out with worked examples: here is the matrix math, here is what the integer truncation does to it, here is the pixel that comes out the other end.
There's a second reason this material is having a moment. Software rasterization is not a dead skill. WebGPU adoption is still patchy, and a non-trivial number of dev teams ship software-rendered UI in WASM because they can't trust the user's GPU stack. Embedded display work — automotive clusters, medical devices, e-ink frame compositors — is essentially the 1993 problem with newer silicon. Edge inference pipelines doing tile-based image processing borrow rasterization patterns wholesale. The 486-era techniques map almost one-to-one onto a Cortex-M7 with no FPU. Fixed-point math, integer pipelines, and cache-friendly tile traversal are showing up again on resumes, just with different cover stories.
The HN comment thread on the post is unusually high signal — several commenters identifying themselves as ex-Naughty Dog, ex-Insomniac, and ex-Crytek engineers chimed in with specifics on which approximations actually shipped in *Crash*, *Spyro*, and *Quake III*. The consensus is that the article gets the math right, including the parts most modern tutorials get subtly wrong (notably the difference between perspective-correct interpolation and the cheaper sub-divided affine approximation that *Quake* used to fake it on Pentium-class hardware).
If you write graphics code, the practical takeaway is concrete: spend a weekend implementing a software triangle rasterizer. Not because you'll ship it. Because once you've written the edge function, the perspective divide, and the texture lookup yourself, every shader debugging session for the rest of your career gets faster. You stop thinking of the GPU as a black box that occasionally returns garbage and start thinking of it as a parallelized version of a thing you understand.
For systems engineers working outside graphics, the value is different but real. The fixed-point arithmetic patterns the series teaches are the same ones you need for deterministic simulation, lockstep multiplayer netcode, financial calculations where IEEE 754 rounding is a compliance problem, and any embedded work where a hardware FPU isn't on the BOM. Floating point is a luxury, and a lot of modern code treats it like a default. The 1993 mindset — integers everywhere, scale factors tracked by hand, overflow accounted for — is increasingly relevant as more of the industry pushes compute to the edge.
For team leads, there's a hiring signal here too. Candidates who can talk fluently about software rasterization, fixed-point pipelines, or the math behind their favorite retro game's renderer have almost always written serious systems code. It's a near-perfect proxy for the kind of engineer who reads documentation before writing tickets.
Staniks has promised follow-ups covering texture mapping (including the affine vs. perspective-correct tradeoff), lighting, and eventually a full game-shaped demo. If the series sustains the quality of the first post, it has a shot at becoming the canonical introduction to software 3D for the WebGPU generation — a slot that's been effectively vacant since Sanglard stopped publishing regularly. The audience is clearly there. The question is whether the author can ship the rest of the series before the algorithm moves on.
This is taking a lot of inspiration from Doom, but the actual raycasting engine is more like Doom's predecessors, the most well-known of which is probably Wolfenstein 3D: perpendicular walls, constant floor and ceiling height. Wolf3D didn't have textured floors and ceilings because of perf
Graphics programming in the early to mid 1990s was pretty fun: write pixel data into the memory-mapped video RAM and it appears on the screen! A pointer to 0xA0000 was all you needed - no API or anything. The reason for the non-square-pixel 320×200 VGA mode they mention was that the video buffer too
If you want to play with software rendering, here's probably the shortest code that will get an ARGB8888 2D array from main memory to the screen efficiently for all platforms using SDL2 in C https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d... you'll need to
I just noticed that this might be one of the rare shooters with a female protagonist: the cat has a calico pattern, and those are almost always female (https://en.wikipedia.org/wiki/Calico_cat).
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Great article. I particularly enjoyed the approach to creating gibs. Although it was a tech demo, I created something like this around the mid 90s. One thing I did that I don't see mentioned in this article was I used 8x8 (or 16x16) light maps on the textures, which allowed me to easily have th