Talk:Xiaolin Wu's line algorithm: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎REXX comment: new section)
Line 56: Line 56:
The new REXX entry currently says "Apparently, there may be an error in the definition of the algorithm (which only manifests itself with negative numbers): use of the IPART function should probably be FLOOR"
The new REXX entry currently says "Apparently, there may be an error in the definition of the algorithm (which only manifests itself with negative numbers): use of the IPART function should probably be FLOOR"


But, in the sort of context where this line algorithm would be useful that I have seen, screen coordinates are always have been positive numbers, so in practice this kind of ambiguity should not matter. --[[User:Rdm|Rdm]] 15:52, 4 June 2012 (UTC)
But, in the sort of context where this line algorithm would be useful that I have seen, screen coordinates are always have been non-negative integers, so in practice this kind of ambiguity should not matter. --[[User:Rdm|Rdm]] 15:52, 4 June 2012 (UTC)

Revision as of 15:52, 4 June 2012

Any guy can give me Xiaolin Wu's line algorithms code in C#. Than you.

Bug in the C code?

<lang c> } else {

   if ( y2 < y1 ) {
     swap_(x1, x2);
     swap_(y1, y2);
   }
   double gradient = dx / dy;
   double yend = round_(y1);
   double xend = x1 + gradient*(yend - y1);
   double ygap = rfpart_(y1 + 0.5);
   int ypxl1 = yend;
   int xpxl1 = ipart_(xend);
   plot_(xpxl1, ypxl1, rfpart_(xend)*ygap);
   plot_(xpxl1, ypxl1+1, fpart_(xend)*ygap);
   double interx = xend + gradient;

   yend = round_(y2);
   xend = x2 + gradient*(yend - y2);
   ygap = fpart_(y2+0.5);
   int ypxl2 = yend;
   int xpxl2 = ipart_(xend);
   plot_(xpxl2, ypxl2, rfpart_(xend) * ygap);
   plot_(xpxl2, ypxl2 + 1, fpart_(xend) * ygap);

   int y;
   for(y=ypxl1+1; y <= (ypxl2-1); y++) {
     plot_(ipart_(interx), y, rfpart_(interx));
     plot_(ipart_(interx) + 1, y, fpart_(interx));
     interx += gradient;
   }
 }

} </lang>

The start and end pixels here in the else where fabs(dx) <= fabs(dy), should have a secondary plot point +1 in the x-direction, not y-direction. It's correct for the main loop and the first if, but not the two end points, for any drawn line with a slope greater or equal to 1.

So where it says: <lang c>

   plot_(xpxl2, ypxl2, rfpart_(xend) * ygap);
   plot_(xpxl2, ypxl2 + 1, fpart_(xend) * ygap);

</lang> it should say: <lang c>

   plot_(xpxl2, ypxl2, rfpart_(xend) * ygap);
   plot_(xpxl2 + 1, ypxl2, fpart_(xend) * ygap);
</lang>

76.175.220.55 11:20, 3 July 2011 (UTC)

REXX comment

The new REXX entry currently says "Apparently, there may be an error in the definition of the algorithm (which only manifests itself with negative numbers): use of the IPART function should probably be FLOOR"

But, in the sort of context where this line algorithm would be useful that I have seen, screen coordinates are always have been non-negative integers, so in practice this kind of ambiguity should not matter. --Rdm 15:52, 4 June 2012 (UTC)