This kind of misses the point of the beauty where in his original algorithm worked perfectly with pure integer math and only needing addition/subtraction/comparison.
The only routines using floats are for bezier curves, right? I think the author actually tried to show the universality of the principles, and routines are seemingly similar enough to back this premise up. It will be of course possible to avoid floats in them, which may or may not simplify the routines, but I guess such changes can destroy the inherent similarity and the author was not brave to try that out. (Multiplications are more common but the same argument applies.)
Does this make the novelty of "real Bresenham's algorithm" a historical curiosity? Now that all we care about is cache misses (hyperbole), how much do we care much about a division per row of pixels?
More to the point: if you're doing anything but pure rasterising, something that requires anything more than a hash table lookup per cell, is it worth "doing it right"?
Bresenham's algorithm is very useful when building software that uses stepper motors to follow a particular path (e.g. robotics, plotters, 3d printers, CNC machine). It's especially nice if you're trying to use a wimpy CPU like an Arduino.
Note that this (and not raster display) was actually the problem Bresenham was describing in the 1965 paper.
Amusingly, the stock firmware for the Makeblock XY Plotter kit did not use Bresenham's algorithm-- and has horrible artifacts due to crazy rounding errors. Reimplementing Bresenham on a plotter does feel a bit like a trip to the past.
Bresenham's algorithm as originally designed lends itself well to implementation in hardware, where you don't want a more complex implementation than necessary, so I'd say it still matters…if GPUs bother to implement GL_LINES in hardware anymore.
(I don't know if GPUs bother with it any longer. The OpenGL spec allows but does not mandate a Bresenham-based implementation, so tessellating into triangles is theoretically an option if they can make the diamond exit rule work. Games rarely use lines, but it wouldn't surprise me if they keep the hardware around for CAD software or whatever.)
Nvidia's Quadro GPU offerings still have 'proper' GL_LINES hardware support for CAD. I'm not sure if they still use Bresenham under the skin though. But most of the consumer GPU offerings just resort to tessellation into triangles AFAIK.
Though they remain in Vulkan as an optional feature, supported by all the desktop GPUs - so they're aren't going away anytime soon.
Of course, how much of that is driver fakery and how much is actual hardware support can be debated, but there's surely some hardware support, otherwise it wouldn't be exposed in Vulkan which is supposed to be a thin layer.
are you sure they are actually supported in modern GPUs . if you enable the core profile instead of the compatibility profile you get no thick lines. Whether those thick lines are gpu lines or software lines I don't know but usually when things are pulled out of GL it's becasue the are not actually supported in the hardware.
Another property is that because it holds an integer numerator & denominator, there's no round-off errors in drawing the line. Now, we'll have to get some pretty high pixel counts for that to matter, but it's another interesting property vs accumulating a fixed or floating point calculated slope.
> how much do we care much about a division per row of pixels?
EDIT: I just realised I'm not actually answering your pixels question, but a more generalised question of "when would we want to use this integer arithmetic method instead of floating point multiplication and division?"
As much as the rounding error of repeated addition matters - especially with cumulative addition. The comment by white-flame only regards this from the point of view of pixels, but there are many other applications where Bresenham's algorithm is the best solution. As described on Roman Black's website from 2001:
> Bresenham's Algorithm is a system where 2 imperfect periods can be alternated to produce an average that matches any "perfect" period.
I probably don't have to convince you that this can still be a serious issue in embedded systems. The most obvious use-case would be long-running code where cumulative errors add up. A famous example of this going horribly wrong is the Patriot Missile disaster:
> It turns out that the cause was an inaccurate calculation of the time since boot due to computer arithmetic errors. Specifically, the time in tenths of second as measured by the system's internal clock was multiplied by 1/10 to produce the time in seconds. This calculation was performed using a 24 bit fixed point register. In particular, the value 1/10, which has a non-terminating binary expansion, was chopped at 24 bits after the radix point. The small chopping error, when multiplied by the large number giving the time in tenths of a second, led to a significant error. Indeed, the Patriot battery had been up around 100 hours, and an easy calculation shows that the resulting time error due to the magnified chopping error was about 0.34 seconds.
Bresenham's Algorithm avoids this rounding error altogether (but it only works as long as you have a fixed numerator/denominator ratio - or if you really push it one denominator and a set of numerators).
EDIT2: Also, this does not just apply to repeat addition: calculating xp/k from scratch whenever x changes doesn't always work either. You can still get significan rounding errors if the intermediate calculation of xp is such a large number that it barely fits in a floating point.
> calculating x * p/k from scratch whenever x changes doesn't always work either. You can still get significan rounding errors if the intermediate calculation of x * p is such a large number that it barely fits in a floating point.
Too late to edit that accidental markdown, so replying to myself
