If the lines are correct, you should be able to run "linetest": http://www.xfree86.org/~mvojkovi/linetest.c without artifacts. The zero-width lines are the hardware ones. Mark. On Sun, 23 Nov 2003, Thomas Winischhofer wrote: > FYI: Klaus Peichl just confirmed that the e1 value was wrongly > calculated, and that replacing > > e1 = major; > > by > e1 = minor; > > fixes the bug. Fix committed to CVS. > > > Thomas > > Kevin Brosius wrote: > > Klaus Peichl wrote: > > > >> > >>Thomas Winischhofer wrote: > >> > >> > >>>Apparently, after looking into the 3.3.6 code, the first generations of > >>>S3 do support Bresenham lines after all. > >>> > >>>What I see from comparing the code is that the 3.3.6 version does a lot > >>>of stuff to reduce the error term to 12 bit which is the hardware's > >>>maximum. > >>> > >>>The 4.x code, although demanding a 12bit Bresenham error term from XAA, > >>>simply adds the given minor and error term and writes the result to the > >>>hardware register, without checking it for overflows. I don't know what > >>>values this function is given, but in case the values are somewhat big, > >>>this may result in a completely wrong error term. The result may very > >>>well look like what the original poster saw, namely lines with a wrong > >>>slope. > >>> > >>>Furthermore, I think the way the error term, e1 and e2 values are > >>>calculated differ: > >>> > >>>3.3: > >>> > >>>(deltas: adx = x2 - x1; ady = y2 - y1) > >>> > >>>if (adx > ady) { > >>> axis = X_AXIS; <-- x is major axis; adx=major > ady=minor > >>> e1 = ady << 1; > >>> e2 = e1 - (adx << 1); > >>> e = e1 - adx; > >>>} else { > >>> axis = Y_AXIS; <-- y is major axis; adx=minor < ady=major > >>> e1 = adx << 1; > >>> e2 = e1 - (ady << 1); > >>> e = e1 - ady; > >>> ... > >>>} > >>> > >>>Simply put, if I understood that right, this does > >>> > >>> e1 = minor; > >>> e2 = minor - major; > >>> > >>>4.x: > >>> > >>>Here it looks like this: > >>> > >>> e1 = major; > >>> e2 = minor - major; > >>> > >>>Would be interesting to know what impact this difference has. If > >>>anybody's interested, I could compile the driver with that change and > >>>send out the binary. > >> > >>That would be great! > >>Will the binary be a replacement for /usr/bin/X11/XFree86 > >>or will I have to change something else to test it? > >> > > > > > > The default XFree86 binary is a module loader, using drivers in > > /usr/X11R6/lib/modules/drivers/ by default. Thomas would likely provide > > you a s3.o module you could swap with your existing driver. > > > > > -- > Thomas Winischhofer > Vienna/Austria > thomas AT winischhofer DOT net http://www.winischhofer.net/ > twini AT xfree86 DOT org > > _______________________________________________ > XFree86 mailing list > XFree86@xxxxxxxxxxx > http://XFree86.Org/mailman/listinfo/xfree86 > _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
