Hi all this is my first post in this board
!
I resurrect this old thread. First to say that, according to my tests (which may be not as extensive as those made by Toni) also BLTALWM is unused in line mode. (In contrast to what C= HRM says).
Thanks Toni for discovering BLTDPT is used just for first pixel, I now use this feature in my line routine.
I have also tried to replicate Photon technique to avoid "filling problem", but it didn't work. It seems to me that the blit height in line mode is a pixel counter, not a line counter, so subtracting 1 avoids the last pixel to be drawn. This is ok for lines with slope >= 1 (because there is one pixel per line) but not for the others:
a line finishing like
..............**
.................***
in one-dot mode becomes
..................*
.....................*
so the last pixel would not be drawn in any case (because of one-dot mode). This is not good because next line will start exactly there, so we end up with 2 pixels in the row.
I guess there is somethnig else I don't understand.
Photon, could you enlight me, please?
Quote:
Originally Posted by Photon
This is most interesting, because you normally want 1 pixel of the line to be omitted if you want to fill the poly afterwards... Otherwise you get double pixels plotted at the corner points of the poly, resulting in the infamous horizontal lines emanating from the corners when it's filled.
I did it by subtracting 1 from the blit height in the linedraw routine just before drawing, Slayer did it by XOR'ing an extra pixel so it goes away, but could this mean that by pointing BLTDPT to a trash area, the pixel goes there and the rest of the line goes to BLTCPT and is correct for filling?
If it's true, then a bunch of cycles would be saved in the linedraw routine
1) one register saved and one sub.w (up to 12 cycles on A500)
2) one longword or word write to memory for the BLTDPT. UNLESS BLTDPT is increased after the blit to point to just beyond the last pixel. (up to 12 cycles more)
|