I wrote a ray tracer in Brainfuck
An engineer built a ray tracer in Brainfuck by developing a multi-stage compiler that translates C code through an intermediate DSL into 23MB of Brainfuck.
read it It offers a fascinating, hands-on look at implementing fixed-point math, memory layout, and compiler tooling targeting an esoteric language.
summary
The author set out to write a ray tracer in Brainfuck, using an LLM to convert a C implementation into SSA form and a custom compiler to transpile it via a DSL into 23MB of Brainfuck code. To handle the math without floating-point support, they implemented signed Q16.16 fixed-point arithmetic, custom long-division, and iterative square roots. While rendering a full image would take months without optimization, the project demonstrates creative problem-solving in low-level code generation and memory management.
key points
- Signed Q16.16 fixed-point arithmetic was implemented to handle decimal numbers and large scales within a tape-based byte architecture.
- The toolchain pipeline required converting C code to SSA form, mapping it to a custom DSL with over twenty operations, and emitting Brainfuck.
- Advanced mathematical primitives like division and square roots were written from scratch using manual long-division algorithms adapted for tape cells.
who should read it
Systems programmers and compiler engineers interested in esoteric languages and low-level code generation.
discussion warm
consensus
Commenters note that calling this written in Brainfuck is a misnomer since it relies on a multi-stage C-to-DSL-to-Brainfuck compiler pipeline rather than hand-writing.
pushback
Some critics point out that algorithmic Brainfuck generation creates massive code duplication and overhead from constantly moving and copying tape values.
brainfuck is unpleasant to write directly - e.g. the language doesn't have variables, so you need to manually do the bookkeeping of which memory offset is storing what 'variable'. & if you need to refactor your program slightly, in a way that changes the memory layout, maybe you need to manually rework the absolute & relative offsets. So I can appreciate why the author didn't roll up their sleeves to directly write BF - that's neither a productive nor interesting exercise.
Interesting to see how the author decomposed the problem:
- C raytracer …
It outlines the precise file transformation pipeline from the initial C source down to the 23MB Brainfuck output.
Generated by an LLM from the article and thread. Check the sources before relying on it.