Blitter: clean-up line drawing and fill mode idle cycles.

[ross]

I use the classic fast trick about poly rendering: I do not zero-fill the buffer but instead I do an x-or of the preceding line in a back buffer and then a blitter-fill into the front buffer.

But I've a peculiar blitter line draw routine where i don't have intersecting polylines (all is draw in different planes).

So my question.
Blitter usage/operation are fixed in line-mode and, apart the strange C and D channel behavior, require two chip-mem access (and idle cycle) to draw a pixel.
But in my case the first read access is unnecessary because I simply need to zero the destination memory word.
It's somewhat possible to disable read operation and gain a free cycle?

Another question.
I'm using the standard A->D(f) blitter area fill routine for the polys but this combo leave idle cycles (even with blitter nasty) that I prefer to avoid.
There is some non-standard channel usage that does not leave free cycles?

[I was in doubt if this is the right section (can be also a Coders.General request) but probably is more Asm/Hardware related..]

[Toni Wilen]

Originally Posted by ross

It's somewhat possible to disable read operation and gain a free cycle?

Yes but..: http://eab.abime.net/showpost.php?p=814879&postcount=7 (note that those useless line mode weird things are not emulated, need to know full blitter internals first)

Another question.
I'm using the standard A->D(f) blitter area fill routine for the polys but this combo leave idle cycles (even with blitter nasty) that I prefer to avoid.
There is some non-standard channel usage that does not leave free cycles?

It is not possible. Agnus can't do back to back same channel DMA accesses. (due to internal pipelining)

[ross]

Originally Posted by Toni Wilen

Yes but..: http://eab.abime.net/showpost.php?p=814879&postcount=7 (note that those useless line mode weird things are not emulated, need to know full blitter internals first)

wow, pure blitter weirdness!
Then I stay with my routine

It is not possible. Agnus can't do back to back same channel DMA accesses. (due to internal pipelining)

I suspected it, but I tried anyway to ask..
So now I need to write a CPU concurrent single-plane poly filler to take advantage of this free idle cycles.

Thanks Toni for your encyclopedic knowledge and availability.

[Seoman]

I use the classic fast trick about poly rendering: I do not zero-fill the buffer but instead I do an x-or of the preceding line in a back buffer and then a blitter-fill into the front buffer.

Can you explain that trick please?

[ross]

Originally Posted by Seoman

Can you explain that trick please?

Well, filling polygons on Amiga with blitter is simple. You have at disposal a special blitter line-mode that draw 1 pixel-per-line (too raw in wire-frame but perfect for successive fill). You can even fill multiple polygons using a single operation.
Normally you do double buffer for a smooth video rendering.
So the operations are:
- display preceding frame and at the same time:
1) clean the back buffer (zero-fill all or boxs used)
2) draw with the blitter a wire frame of the polygons
3) fill with the blitter in-place
- swap front and back buffer and repeat

But suppose you have very big polygons with simple shape and, even better, rendered in separated bit-planes (my situation).
The first operation can be too expensive and slow (the back buffer cleaning).
Much much better maintain a "copy" of the wire framed image and use an x-or minterm for the blitter line draw routine, so you can simply "erase" preceding line, rewriting over itself!

So the new operations are:
- display preceding frame and at the same time:
1) redraw with the blitter on the wire-buffer the preceding polygon(s)
2) draw with the blitter the new polygon(s)
3) fill with the blitter where source A is the wire-buffer and destination D is the back buffer
- swap front and back buffer and repeat.

But if you followed closely there is a problem..
Normally in a demo/intro the polygons are moving, so unless you fully fill the screen with one big blit the back buffer can contain some old "garbage" (remember there is not the initial zero-fill).
So you need to make some clever choice about the "enlarged" blitter-fill box around the wire-framed polygons that also overlap preceding back buffer filled polygons.
If the movements between one frame and the next are not excessively rapid, a over bounding box of 16 pixels may be sufficient.

I hope that what I wrote is understandable..

[Seoman]

Thank you ross, it's very clear now

[LeCaravage]

Thanks for this cool knack.
I'm not sure if I understand well. But, could it be possible the trick is more faster than erasing a backbuffer ? Even with a max size filling box ? You'll have an extra DMA channel + erasing lines + more datas to copy but still I wonder.
Please don't laugh too loud if I'm way off beam ;-)

[ross]

Originally Posted by LeCaravage

But, could it be possible the trick is more faster than erasing a backbuffer ? Even with a max size filling box ?

Unfortunately not always but only in particular conditions, which are those with which I find myself dealing (big and simple polygons, non-intersecting lines, separate planes).
If the video scene is composed of many small and far polygons with complex figures, it is certainly better to erase the back buffer.

You'll have an extra DMA channel + erasing lines + more datas to copy but still I wonder.

I don't have an extra DMA channel used. Also a standard blitter fill require A+D, the only difference is that usually A=D (you fill on-place).
Yes, i've (double) more data to blitter line-draw but sure less than a full back buffer erase! (remember.. big polygons.. so the filled parts are really many).
Different situation instead for the chip memory requirement, that is doubled .. since the two wire buffer (front and back) have the same size of the render buffer (plus data for the management of the structures, but they are not much).
From my tests speed gain is remarkable so i've used this technique.

Please don't laugh too loud if I'm way off beam ;-)

Il n'y a pas de questions stupides, il n'y a que des réponses stupides.

[TheDarkCoder]

Originally Posted by ross

So the new operations are:
- display preceding frame and at the same time:
1) redraw with the blitter on the wire-buffer the preceding polygon(s)
2) draw with the blitter the new polygon(s)
3) fill with the blitter where source A is the wire-buffer and destination D is the back buffer
- swap front and back buffer and repeat.

I am not sure to understand operation 1. To redraw with the blitter on the wire-buffer the preceding polygon(s), you redraw each line separately, or you have a bounding box for a wire-framed polygon that you xor with the previous content of the buffer?

[ross]

Originally Posted by TheDarkCoder

I am not sure to understand operation 1. To redraw with the blitter on the wire-buffer the preceding polygon(s), you redraw each line separately, or you have a bounding box for a wire-framed polygon that you xor with the previous content of the buffer?

Each line separately, the bounding box is too big..

Even so anyway i've hard times to move two big mono polys with a max extension box of 256x256 pixels in a 4-planes (and some 5-planes zones) screen. A single fill requires more than a 1/3 frame! And it is not even convenient to fill concurrently with the CPU since idle cycles are used by the video DMA..

Drop full frame rate is not an option