The 500-Line Renderer Worth Writing Yourself

An eleven-year-old graphics course just hit the Hacker News front page again, and the top comment complained it's "old as dirt." Both things can be true: tinyrenderer is old, and it keeps resurfacing because almost nothing else fills its niche. Dmitry Sokolov, a lecturer at Université de Lorraine, first published the course in 2015; the GitHub repo has since collected nearly 24k stars. In late 2025 he rewrote the whole thing from scratch — new site, new code, new lesson structure — and that second edition is what's making the rounds now.

The premise hasn't changed: you build a software renderer in roughly 500 lines of plain C++. No OpenGL, no Vulkan, no windowing library, no math library. You get one class that reads and writes TGA images and sets individual pixels. Everything else — line drawing, triangle filling, the z-buffer, the camera, texture mapping, shaders — you write yourself. Sokolov estimates 10 to 20 hours of programming, and his stated goal is blunt: he's not teaching you to write GPU applications, he's teaching you how GPU APIs work by making you build a simplified clone of one.

Why the constraint is the whole product

There's no shortage of graphics tutorials. LearnOpenGL is excellent, vulkan-tutorial is thorough, and every engine ships walkthroughs. But they all teach you to drive a pipeline someone else built. You learn which calls to make and in what order, and when something renders black, you're debugging an opaque state machine. Tinyrenderer inverts that: after you've written a z-buffer by hand, depth fighting stops being a mystery flag you toggle and becomes an arithmetic problem you can reason about. After you've implemented perspective-correct interpolation yourself, you know exactly why affine texture mapping warps — the PlayStation 1 wobble stops being trivia and becomes a bug you've personally written and fixed.

The second edition sharpened this. Where the 2015 course leaned on old-school scanline rasterization, the rewrite presents both approaches and pushes the modern one: compute a triangle's bounding box, then test every pixel inside it with barycentric coordinates. Sokolov even sprinkles in an OpenMP #pragma omp parallel for to parallelize the pixel loop. That's not a performance flex — it's the pedagogical payload. The bounding-box test looks wasteful to a sequential programmer and obvious to a GPU, because it's embarrassingly parallel and branch-light. Working through it, you internalize why hardware rasterizers are shaped the way they are, which is precisely the mental model that API tutorials can't give you.

This puts tinyrenderer in the same genre as nand2tetris and Crafting Interpreters: courses whose deliverable isn't the artifact but the demystification. Sokolov clearly knows it — the repo's README says the code itself "is of little interest," and he maintains sibling projects (tinyraytracer, tinycompiler) built on the same bet.

Software rasterization is not retro trivia

It would be easy to file this under nostalgic computing, and that would be wrong. The most advanced rendering system shipping in games today — Unreal Engine 5's Nanite — rasterizes its micro-polygons in a software rasterizer running in compute shaders, because hardware rasterizers are inefficient for pixel-sized triangles. Occlusion culling systems rasterize depth buffers on the CPU. Mesa's llvmpipe and lavapipe render OpenGL and Vulkan on CPUs in every headless CI pipeline that tests graphics code without a GPU; Chrome falls back to Google's SwiftShader for the same reason. The algorithms in tinyrenderer's 500 lines are the working core of all of these. If your career touches rendering, "I have written a rasterizer" is closer to a load-bearing skill than a party trick.

And one HN commenter made a point worth amplifying: they ported the course to Rust, kept extending it, and found that a single-threaded CPU renderer on a modern machine is fast enough for an interactive 3D game. The gap between "toy" and "usable" is smaller than the GPU-industrial complex would have you believe — for tools, editors, plotters, and embedded targets, a software rasterizer you fully understand can be a legitimate engineering choice.

Where it stops short

Be honest about what you're getting. The recurring criticism — raised again in this week's thread — is that tinyrenderer, like most of the genre, hand-waves triangle clipping. Real renderers must handle geometry that crosses the near plane; it's fiddly, it breaks naive implementations, and skipping it is the difference between rendering a model centered in view and rendering a scene you can walk through. Gabriel Gambetta's Computer Graphics from Scratch — the closest competing text, and Gambetta himself showed up in the thread to say so — covers Sutherland–Hodgman clipping properly, and the two resources pair well.

Also missing, by design: a real-time loop, input, windowing, and any performance discipline beyond that OpenMP pragma. Output is a TGA file. If your goal is shipping a renderer rather than understanding one, this course is your first two weeks, not your roadmap.

The verdict

Tinyrenderer keeps returning to the front page because it occupies a spot the ecosystem still hasn't filled: the shortest honest path from "I call graphics APIs" to "I know what they do." The 2025 rewrite made a good course better by aligning its core algorithm with how GPUs actually think.

It's also more valuable in 2026, not less. An LLM will happily emit a working rasterizer on request — which means the code was never the scarce asset. The scarce asset is the engineer who can look at a broken render, a z-fighting artifact, or a Nanite profile and reason from first principles. You don't get that by reading generated code; you get it from the 10 to 20 hours of writing your own bugs. Block out a weekend, take the TGA class, and don't peek at the reference code until your triangles are on screen.