Austin Shijo found his prompt in the CMake documentation: code generation, cryptographic signature utilities, “and even ray-tracers” have been written in CMake Language, “but this is not a recommended practice.” He had already written a ray tracer in C and again for the GPU, so he went one notch further down and picked Brainfuck — on the theory that the simplest language produces the simplest codebase.

The target was fixed in advance: the exact metal-scene render from Ray Tracing in One Weekend, written from first principles with no prior art consulted. That made correctness checkable pixel by pixel.

The representation came first:

  • Every double is spread across four cells as a signed Q16.16, range [-2^15, 2^15), resolution 1/2^16
  • Q8.8 was tried and rejected — the ground plane needs r=1000 to look flat, which its ±128 range cannot express
  • Temp slots and carry cells live next to each value so the tape pointer travels as little as possible

Then the missing primitives, built from eight instructions:

  • move is [->+<], copy is [->+>+<<]
  • Multiplication is repeated addition over cell pairs, products summed at result[i+j], with the low cells discarded to undo the ×2^16 embedded in both operands
  • Division is school long division — R = R*256 + next_cell, subtract repeatedly at most 255 times per cell — with the dividend pre-shifted left 16 bits because division loses precision where multiplication inflates
  • For sqrt, Heron’s method lost on division cost and a Taylor expansion died because its error was worst below ~0.305, exactly where the render lives; a long-division integer square root won
  • rand is A = (5*A + 1) % 256, guaranteed a full 256-value period, which is enough for supersampling
  • Signed comparison needed 2^7 added to the top cell, or negatives read as larger bytes

The harness is where the real engineering sits: a Python codegen with its own DSL and IR of ~31 ops between parser and emitter, code converted to SSA-like form, recursion made iterative, function-scoped Hungarian prefixes to prevent collisions, and functions emitted inline at each call site.

What it actually produced:

  • 23 MB of Brainfuck for a 0.9 MB image — “a rather poor choice for a compression technique”
  • ~100 ray calculations per minute, or one pixel per minute
  • A 400x225 image implies roughly 62.5 days, and the sphere bounces push it much further
  • 1,229 of 90,000 pixels generated when he wrote it, 10 of which differed from the C reference, mostly by a value of one

The interesting part is not the joke. Almost every difficulty in the post traces back to one early decision — Q16.16 fixed point — and the numerical-method choice was settled by plotting approximation error over the domain actually used rather than the domain that was convenient to derive.

It also shows what layering buys. None of this is readable Brainfuck: parser, DSL, codegen and emitter are separate stages, and only the last one has to think about the tape. The tape is a compilation target, and the compiler is written in Python, where the problems are ordinary ones.