3 ms·

This one will however slowly drift away from the correct line as it accumulates the rounding error of the slope in each iteration. I am not sure what the worst

This one will however slowly drift away from the correct line as it accumulates the rounding error of the slope in each iteration. I am not sure what the worst case is and how long of a line you would have to draw to make a visible difference.

derefr 4y ago
As long as the accumulated error is deterministic (i.e. you get the same wrong output given the same line), and that error is continuous over the field of possible lines, rather than jumping around (i.e. a line that sags to the left a bit, if translated by one subpixel, will still sag to the left a bit, rather than now sagging to the right), that'd be fine for what the author is trying to do, no? The lines just need to stay stable under animation rather than doing the https://tvtropes.org/pmwiki/pmwiki.php/Main/LineBoil https://tvtropes.org/pmwiki/pmwiki.php/Main/LineBoil thing.
- danbruc 4y ago
  Well, it is deterministic and all but I like my lines to connect the points I specify and not end at nearby ones. A line from (0, 0) to (90, 70) has a slope of 7/9. If you represent that with one fractional digit as 0.8 and then on each step just add 0.8 to the y coordinate, you will end up at (90, 72). If you want to reach (900, 700) you will end up at (900, 720). Two fractional digits will get you to (900, 702), three will make you actually land on (900, 700), but not exactly but (900, 700.2). And even then some pixels might not be in the correct place. In the right circumstances this might all be fine and work well enough if you have enough precision for the fractional part, but this is no algorithm that I would recommend to anyone.
  - derefr 4y ago
    Can you avoid the error — without needing to use higher-precision math for every step — by 1. using higher-precision math only to calculate some control points along the line; and then 2. partitioning long lines into smaller overlapping lines that connect at the control points; so that you can then 3. draw those short lines with the cheap algorithm?
    - danbruc 4y ago
      You probably could, but why? The only advantage that the algorithm could maybe claim is conceptual simplicity and this will be gone the moment you start trying to control those errors.

derefr 4y ago

As long as the accumulated error is deterministic (i.e. you get the same wrong output given the same line), and that error is continuous over the field of possible lines, rather than jumping around (i.e. a line that sags to the left a bit, if translated by one subpixel, will still sag to the left a bit, rather than now sagging to the right), that'd be fine for what the author is trying to do, no? The lines just need to stay stable under animation rather than doing the https://tvtropes.org/pmwiki/pmwiki.php/Main/LineBoil https://tvtropes.org/pmwiki/pmwiki.php/Main/LineBoil thing.

danbruc 4y ago
Well, it is deterministic and all but I like my lines to connect the points I specify and not end at nearby ones. A line from (0, 0) to (90, 70) has a slope of 7/9. If you represent that with one fractional digit as 0.8 and then on each step just add 0.8 to the y coordinate, you will end up at (90, 72). If you want to reach (900, 700) you will end up at (900, 720). Two fractional digits will get you to (900, 702), three will make you actually land on (900, 700), but not exactly but (900, 700.2). And even then some pixels might not be in the correct place. In the right circumstances this might all be fine and work well enough if you have enough precision for the fractional part, but this is no algorithm that I would recommend to anyone.
- derefr 4y ago
  Can you avoid the error — without needing to use higher-precision math for every step — by 1. using higher-precision math only to calculate some control points along the line; and then 2. partitioning long lines into smaller overlapping lines that connect at the control points; so that you can then 3. draw those short lines with the cheap algorithm?
  - danbruc 4y ago
    You probably could, but why? The only advantage that the algorithm could maybe claim is conceptual simplicity and this will be gone the moment you start trying to control those errors.