On May 1, Keith Packard wrote: > \| > A > |\ > | \ > | \ > | \ > +----+-----+ > | \ | > ====B======C===D==== > | \ | > | \ | > | \| > | E > | |\ > ====F==========G=H== > | | \ > +----------+ \ > > I'm open to suggestion, but all I can think of this evening is to "snap" > the intermediate coordinates to the 16.16 grid. That seems to rather > constrain the implementation, depending on which coordinates get snapped. > > If we do need to do this, then I suggest snapping the coordinates as they > intersect the bounding area of the pixel -- snap C and E, not A and > H.
This is what had been thinking to do originally. Do you see any problem with this approach? I've already got some pretty simple calculations worked out for the seven cases determined by whether C intersects the left, top, or right and whether E intersects the left, bottom, or right side. Thanks for the nickle code. It's already helping me verify these calculations. Here's a crazy idea: A couple nights ago I had just started coming up with something like what you were doing with the triangle larger than the pixel. My thought was that that approach could be interesting if computation could be shared for determining the areas of a whole row of pixels at once, (note that the subterm area(EHG) above is the coverage of the pixel to the right). So, for Y-major slopes, maybe one could do Y-major bresenham step for each row, then determine the area of one large triangle spanning several pixels in the same row. The trick would then be to carefully divide the area correctly among all covered pixels. Otherwise, it seems I have to do a bresenham step to start a row followed by zero or more clips to determine the line-pixel intersections for each adjacent pixel in the row. -Carl -- Carl Worth USC Information Sciences Institute [EMAIL PROTECTED] 3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725 _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
