If I recall, bresenham's line routine is really very easy. There are also bresenhams routines which are very similar, for drawing circles and ovals.
I might be remembering wrong, but basically I think you figure out the difference between the start and end X coords, call that XDiff, then figure out the difference between the start and and Y coords, call that YDiff.
Then, for as long as those numbers are divisible by two without it becoming a decimal, you divide both by two to make them as small as possible.
Then you just do a simple loop where you count from 0 to the bigger of the two differences, adding the smaller difference to the counter each time. When the value is more than the the bigger difference, you `wrap it around` by subtracting the bigger difference and keeping the remainder as the next counter value.
If you plot that as you go, from 0 to the biggest difference (ie in X or in Y), you end up basically plotting one pixel for every row or column and then you jump to the next adjacent row/column when there is a wraparound of the counter.
I hope I got that right and explained it okay. It's basically to do with wrapping an integer counter around based on X2-X1 and Y2-Y1. It's all simple integer additions/subtractions, nothing else, no floating point, and for integer math it is fast. It also lets you have control over how every single pixel is drawn, individually - dotted lines, color changes, clipping, etc.
There is a more complex version that draws circles and ovals but I don't quite understand it.
Nowadays, though, there is possibly a good argument for saying that f
floating-point math is as fast as integer math. The `lockedline` routin that jb posted is a floating point algorithm and has nothing to do with bresenhams.
I might be remembering wrong, but basically I think you figure out the difference between the start and end X coords, call that XDiff, then figure out the difference between the start and and Y coords, call that YDiff.
Then, for as long as those numbers are divisible by two without it becoming a decimal, you divide both by two to make them as small as possible.
Then you just do a simple loop where you count from 0 to the bigger of the two differences, adding the smaller difference to the counter each time. When the value is more than the the bigger difference, you `wrap it around` by subtracting the bigger difference and keeping the remainder as the next counter value.
If you plot that as you go, from 0 to the biggest difference (ie in X or in Y), you end up basically plotting one pixel for every row or column and then you jump to the next adjacent row/column when there is a wraparound of the counter.
I hope I got that right and explained it okay. It's basically to do with wrapping an integer counter around based on X2-X1 and Y2-Y1. It's all simple integer additions/subtractions, nothing else, no floating point, and for integer math it is fast. It also lets you have control over how every single pixel is drawn, individually - dotted lines, color changes, clipping, etc.
There is a more complex version that draws circles and ovals but I don't quite understand it.
Nowadays, though, there is possibly a good argument for saying that f
floating-point math is as fast as integer math. The `lockedline` routin that jb posted is a floating point algorithm and has nothing to do with bresenhams.