A.D.A. Amiga Demoscene Archive

Hi there,

I just found my old blitter line code from 1990 or so. And while trying to figure it out (again :-)) I saw
that when using the algo to draw colored polys I just draw the line into each bitplane (where the bits need to be set).
Since this includes multiple blitter starts (up to n for n planes) for one line I am wondering if there is a neat solution where you just draw one line and have the correct bits in all bitplanes set/cleared? Maybe by choosing special bit masks and dx,dy values??

BTW: what is a reasonable number of cycles for calculating the blitter values? My old algo needs about 430 cycles to compute the values for one line and write it into blitter registers.

One could theorize that with interleaved bitplanes, you could draw a "higher" line and have the bits end up in the right positions (at least when drawing to all bitplanes). I don't think that is possible, though. The counter argument goes something like this:

Say you have a line whose slope is such that it draws alternately one and two pixels at the same x position. If you make that line twice as high, it will always draw three pixels at the same x position. I don't think there is a way to make the blitter update the line irregularly, as to produce alternately two and four pixels at the same x, which is what you would want in this case.

However, all the setup code for the line can of course be shared between each bitplane. Presumably some of the blitter registers could be shared as well. My guess is that at least the control registers, first/last word masks and modulos can carry over from the first line to the subsequent ones. I haven't tried it, though.

As for the setup time, 430 cycles seems reasonable. I just counted my latest one (from Space Onion), and it uses 422 on average, if we take the worst-case time (70 cycles) for the bytes-per-row multiplication. If a power-of-two bytes-per-row value is used (so we could use a shift instruction instead), we could shave off around 50 cycles from that. That code is primarily size optimized, so it can probably be done somewhat faster than that.

Okay, so at least this is nothing trivial (and I was not too stupid to see the obvious :-)). I am still thinking of using a separate buffer for the poly and use up to three blits to put that into the target bitplane (for Glenz vectors or concave objects) or just simple draw the lines and use one blitter fill for the object. At least I now need to do something with my line drawer.

BTW.: If I have small polys and use a separate buffer is it faster to clear a complete buffer with the blitter or just to re-draw the lines in xor mode?

It depends on how small. In terms of blitter time, the break/even point would be when the polygon is 4 words wide, since that would be height * (2 plots per scanline) * (8 cycles per plot) for the redraw, or height * (4 words per scanline) * (4 cycles per word) for the clear. If it's wider, redraw, if it's narrower, clear.

As for CPU time, clearing will of course always be faster, as the redraw needs to do many more blitter register writes (and multiple blits).