A dart thrown into the dark abstract landed on the algorithm that draws a straight line on a pixel grid using nothing but integer add and compare — no floats, no division, no y = mx + b. We light the pixels live, credit who actually made it, and find a deep irony waiting for I-13: a language with only floats would run the anti-float algorithm in floats. Three prongs, one dart.
Walk the major axis one pixel at a time. Carry an integer error term D. Each step, subtract 2·dy; when D would cross zero, step the minor axis too and add 2·dx back. The float line y = mx + b is never computed — the sign of an integer is the decision. Drag either endpoint, or throw a dart. live demo
This one is refreshingly uncontested. One name, one lab, one plotter. cited
No disputed authorship, no predecessor to name plainly — unusually clean provenance for a piece of code this famous. The “Bresenham” family (midpoint circle, ellipse) came later and carries his name by extension, not because he wrote all of them. What’s genuinely open: the same integer-decision idea was arrived at independently for circles and by others for anti-aliased variants (Wu), so “Bresenham” is now a technique-family label as much as one 1962 procedure. open
Here is the irony this dart exists for. Bresenham’s entire value is being integer-only — exact, fast, no rounding. But I-13’s Constant is f64 and nothing else: no integer type at all. So I-13 can run Bresenham — it needs only + − * and compare, which I-13 has — but every “integer” error term is secretly a float. The algorithm works, and in the same breath defeats its own reason to exist. Measured on the live compiler, not asserted:
For a small line every coordinate is well under 2^53, so f64 holds it exactly and I-13’s Bresenham lights the correct pixels — the demo above would render identically. The danger is invisible: cross 2^53 (a large canvas, a tiled address, an accumulated counter) and the error term stops being exact, and nothing warns you — the run just prints RUN OK.