@Toni: Perhaps for a simple sprite-frame without having to add bitplane dma? (i.e. width 320 _plus_ some pixels, but only as sprites please)?
@TheDarkCoder: I'd have to look, but I think the trick was to calculate all blitter values normally, then subtract 1 from blitsize height just before drawing. This trick requires that all lines are drawn downward (or all upward), ie. swap endpoints to make sign of dy the same for all.
Quote:
Originally Posted by TheDarkCoder
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?  |