5 ms·

Ah, that's an interesting idea. We might say that Bresenham's Algorithm is not really about drawing lines; it's about doing a best-possible discrete approximat

Ah, that's an interesting idea. We might say that Bresenham's Algorithm is not really about drawing lines; it's about doing a best-possible discrete approximation to linear interpolation, using integer arithmetic. And since we can easily[1] change that line to any conic section we want, we should be able to use a variation on B's Alg. to do a perspective-correct interpolation, right? Sounds good to me. However, as perhaps you were, I'm too lazy[2] right now to work out the details. :-) -------- [1] For certain values of "easy". [2] Or perhaps "too busy". That sounds a bit better, doesn't it?

kazinator 11y ago
I was pulled in so many different directions, and basically stopped hacking on computer graphics. I guessed that the downfall of the approach would be the iterations spent on the same pixel value in a texture, when, so to speak, Bresenham is "going vertical": marching through Y values while treading on the same X. If X is the texture space, it's wasteful. While rasterizing, it really behooves us to just map backwards from screen pixels, get the color value and move on. On the other hand, the approach could do anti-aliasing: average those values being tread over. That is usually solved with mipmapping, though: pre-filtered textures at multiple resolutions. Again: no iterative work per display pixel.