Demoscene

The French literary group Oulipo believed that imposing arbitrary constraints on writing could force you into discoveries you'd never make otherwise. Georges Perec wrote a 300-page novel without the letter 'e'. The demoscene — a global subculture of programmers who compete to produce audiovisual art in impossibly small executables — is the Oulipo of computing. And the things they've discovered about rendering, compression, and the nature of code have rippled outward into mainstream graphics for decades.

The Culture

Demosceners gather at parties and competitions to make "demos" — small programs that generate impressive visuals and music in real time. Size categories range from 64K (barely enough for a modern JPEG) down to 256 bytes. Shadertoy, the web platform for GPU shader programming, was founded by demosceners, and the culture permeates the site: a Shadertoy shader is essentially a 4K intro with a browser as its runtime.¹

What makes the demoscene different from competitive programming or code golf is the emphasis on aesthetics. The constraint isn't just "make it small" — it's "make it small and beautiful." A 256-byte demo that renders ugly geometry technically succeeds at size optimisation but fails as a demo. The best work achieves genuine visual artistry within its constraints, and the tension between the two goals is where the interesting techniques live.

The Postcard Path Tracer

Andrew Kensler's postcard-sized path tracer is a masterpiece of constrained programming: 2,037 bytes of C++ that renders a photorealistic image of the word "PIXAR" in a room with soft shadows, colour bleeding, and glossy reflections.² Fabien Sanglard's reverse-engineering reveals the layers of cleverness packed into each byte.

The scene is defined entirely through signed distance functions — no vertices, no meshes. The letters are encoded as 15 line segments stored in a character string, where each character's ASCII value encodes a coordinate. Two half-circles for the P and R are special-cased with hard-coded positions. The room is carved from solid space using CSG: two inverted boxes for the upper and lower rooms, plus a modular box operation for the ceiling planks. Everything above y=19.9 is light.

The renderer is a legitimate path tracer: cosine-weighted hemisphere sampling for diffuse bounces, direct light evaluation with shadow rays, specular reflection on the letter surfaces. Tone mapping uses Reinhard's method in a form so compact it looks like an arithmetic accident: color = color * (1/samples) + 14/241; vec o = color + 1; color = color / o * 255.

The character string encoding is the trick that makes it all fit. Each pair of characters encodes x,y coordinates for a line segment endpoint, with 79 subtracted from the ASCII value and the result scaled by 0.5. It's not a general-purpose compression scheme — it's a one-off hack perfectly shaped to this specific data. That's the demoscene aesthetic: solutions that are brilliant but unrepeatable.

Donut on Silicon

Andy Sloane's donut.c started as an obfuscated C program that renders a spinning ASCII-art torus. Over the years he pushed it through increasingly radical reimplementations: optimised C, bitwise-only operations, and finally actual silicon — a Tiny Tapeout 8 ASIC that ray-marches a donut in real time with no memory buffer, racing the VGA beam at 48MHz on ~7,000 logic gates.³

The key insight is that a torus SDF can be evaluated using only CORDIC — a technique that computes lengths and rotations through iterated shift-and-add operations. No multiplications, no trig, no square roots. And the same CORDIC passes that compute the distance also rotate a lighting vector as a side effect, giving surface normals for free.

With only 2 bits per RGB channel on the output, Sloane used ordered dithering with temporal alternation to simulate greater colour depth. The approximate multiplier for ray stepping uses leading-bit detection instead of real multiplication. The rotation of the torus uses the Minsky circle algorithm (HAKMEM 149), which maintains sin/cos pairs through iterated shift-and-add without magnitude drift — as long as you have enough precision bits.

The result looks polygonal because Sloane could only fit 3 CORDIC iterations in one clock cycle. Bruno Levy noticed this on Twitter: restrict the iterations and you get faceted geometry. An accident born from timing constraints on a 130nm process that produces an aesthetic nobody planned for.

Fluid Dynamics in a Kilobyte

Eben Packwood's JS1K entry implements the lattice Boltzmann method for computational fluid dynamics — a full 2D flow simulation in under 1,024 bytes of JavaScript.⁴ The lattice Boltzmann method simulates fluids by tracking particle distribution functions on a grid, with streaming and collision steps at each tick. It's a real simulation technique used in serious research — the kind of thing that normally requires thousands of lines of code.

Packwood's account of getting there is one of the best postmortems of constrained programming ever written. Every trick counts: flattening 2D arrays into 1D (saving the inner loop and initialisation), eliminating all return statements by writing to global state, eliminating all var declarations by putting everything in global scope, storing direction velocities in a flat array instead of nested arrays (saving brackets and commas), computing distribution weights inline with a ternary instead of storing them.

The colour discovery is perfect demoscene: green waves on a black background looked best, but setting the canvas background to black cost 26 bytes. The solution was to swap which channel varied — set alpha to constant 255 and vary the green channel proportionally to fluid speed, so zero-speed nodes are RGB(0,0,0,255) = black and high-speed nodes are RGB(0,255,0,255) = green. Same visual result, zero extra bytes.

Packwood quotes the Oulipo explicitly: "Imposing an arbitrary constraint upon yourself can force you to focus more clearly on what you are doing, and can lead to brilliant insights you might never have realized otherwise."⁴

"Dust": 439 Characters

XorDev's "Dust" shader generates an infinite, mathematically defined space station with volumetric shadows in 439 characters of GLSL.⁵ Through collaborative optimisation on Twitter, it was whittled to 411. The whole thing is a single expression — a distance function composed with domain repetition (mod operations that tile the space infinitely), evaluated through ray marching, with lighting from the march steps themselves.

This is the extreme end: a shader so small you can tweet it, that generates a 3D environment with depth, shadows, and spatial coherence. There's no scene graph, no asset pipeline, no texture fetch. The space station exists as a mathematical truth, discovered rather than designed.

Generative Art and the Flow Field Tradition

The demoscene's aesthetic sensibility — that algorithms can be art, that constraints produce beauty — has a direct descendant in generative art. Tyler Hobbs's Fidenza, one of the most celebrated works of algorithmic art, is built on a flow field: a vector field that determines the direction of curves at every point in space. The curves follow the field without colliding, producing organic, non-overlapping paths. Thick, curved rectangles replace thin lines. Collision detection ensures spacing. Probabilistic colour palettes assign hues with hand-tuned distributions.⁶

What makes Fidenza interesting from a demoscene perspective isn't just the visual result — it's the algorithm's versatility. By varying turbulence (from none to extreme), scale (micro-uniform to jumbo XL), stroke style (solid, outlined, soft shapes drawn from thousands of parallel lines), and collision strictness, the same core algorithm produces outputs that look like entirely different artists made them. Hobbs prepared 14 colour palettes, seven scale modes, and several drawing styles, and the combinatorial space produces continuously surprising results. This is the demoscene insight scaled up: the constraint isn't byte count but algorithmic economy. One algorithm, many outputs, each one a discovery.

Flow fields themselves trace back through computational art history — they're Perlin noise's aesthetic cousin, appearing in wind visualisations, plotter drawings, and generative typography. But Hobbs's contribution was making the collision detection and shape-filling robust enough to produce gallery-quality composition from pure code. The fact that Fidenza was released on Art Blocks — where each purchase generates a unique output from the algorithm in real time — means the constraint is also temporal: the algorithm must be good enough that any random seed produces something worth owning.

The PostScript Divergence

Jasper St. Pierre's essay on why 2D vector graphics are harder than 3D traces an unexpected history that illuminates what the demoscene was rebelling against.⁷ PostScript, the imaging model that became PDF, SVG, HTML Canvas, and virtually all 2D graphics APIs, was designed for printers in the 1980s. It uses Bezier curves — implicit curves specified as mathematical functions. The Apple LaserWriter had a CPU twice as powerful as the Macintosh controlling it, just to rasterise these curves. When Microsoft created GDI for Windows, they modelled it on PostScript. When the W3C created SVG, both competing proposals (Adobe's PGML and Microsoft's VML) were both PostScript derivatives. The entire 2D graphics stack is printer technology.

3D went the opposite way. Triangles won because they were easy to model, easy to rasterise, and amenable to hardware acceleration. The GPU was built to process triangles fast. Curves were tried (NVIDIA's NV1 had limited curve support) and abandoned. So the demoscene, which grew up on hardware designed for triangles, had to rediscover implicit surfaces — signed distance functions, ray marching, boolean composition — because they couldn't afford the triangle budgets that mainstream games used. The techniques that seemed like clever hacks in 4K intros turned out to be the future: UE5's Lumen, MediaMolecule's Dreams, and the neural radiance field revolution all use implicit representations that the demoscene community had been exploring for decades.

What Constraints Teach

The demoscene matters beyond its subculture because constraints force discovery. When you can't afford a triangle rasteriser, you invent ray marching with SDFs. When you can't afford floating-point multiplication, you discover CORDIC. When you can't afford 26 bytes for a background colour, you discover that swapping your alpha and colour channels gives the same result for free.

Real-time ray tracing on consumer hardware was dismissed as impossible for decades. Demosceners were doing it on Commodore 64s.¹ The techniques they developed — ray marching, SDF composition, procedural generation — eventually made their way into production engines like Unreal Engine 5, whose Lumen system traces rays against signed distance fields rather than triangles.

The deeper lesson is about the relationship between constraint and creativity. Unconstrained code tends toward the generic — one more layer of abstraction, one more configuration option. Constrained code has to find the essential structure of the problem, because there's no room for anything else. The rendering equation was published in 1986. The demoscene has been finding new ways to approximate it in absurdly little code ever since.