Talk:Xiaolin Wu's line algorithm
From Wikipedia, the free encyclopedia
The extension to cover nearly-vertical lines is trivial, and left as an exercise for the reader.
Doesn't get any more aloof than that, gentlemen.
Indeed it doesn't, and could frustrate someone coming to Wikipedia for algorithm help (I know I have). If they haven't studied Bresenham's algorithm the way to fix it may not be so obvious. I'll edit the article.
Contents |
[edit] This Article needs some Images.
Maybe even readers not able to use a compiler themselves may want to know what it looks like...
[edit] Typo in code?
// check that x1 < x2 if x2 < x1 swap x1, x2
Surely just swapping x1 and x2 creates a mirror-image of the line? Shouldn't y1 and y2 also be swapped?
This is what is done in Bresenham's_line_algorithm:
if x0 > x1 then swap(x0, x1) swap(y0, y1)
[edit] The nearly-horizontal case
"the nearly-horizontal case (Δx > Δy)"
makes more sense (to me) if it would read
"the nearly-horizontal case (Δx ≫ Δy)"
Am I missing something obvious here?
- Yes, the word "nearly" is a bit misleading. Δx > Δy is just the more-horizontal-than-not case, in which one can iterate over x to draw all the points. 80.137.89.203 17:07, 1 August 2006 (UTC)
[edit] Posted Pseudo-Code Works
FYI, I used the pseudo-code posted on the wiki page as the basis for my own Wu line generator in C++ combined with SDL (Simple DirectMedia Layer). It works very well, is very fast, and can be easily generalized to other octants in the plane. Thanks a ton to the original poster.
- I just implemented this in python and IMHO "ipart(x) == integer part of x" should be clarified to really mean floor(x), that is for negative numbers (like -2.5) it should still round down (to -3.0) instead of to the integer part (-2.0). Also i used "1.0-(intery-floor(intery))" to calculate the alpha (also because of negative numbers) 80.137.89.203 17:18, 1 August 2006 (UTC)
[edit] Diagonals
This algorithm doesn't antialias diagonal lines (+45°, -45°, +135°, -135°) nor lines close to these angles aren't antialiased very visibly. Maybe this should be mentioned? 82.229.207.75 09:07, 15 December 2006 (UTC)
-
It should probably be noted - it was in the paper and by any authoritative coverage of the algorithm. Horizontal, vertical, and diagonal lines are special case scenarios that simply shouldn't be handled by the Wu algorithm as it can be done much faster using special code; the pixel weightings are constant, after all. 83.84.34.115 00:07, 14 March 2007 (UTC)