From: u894776@bruny.cc.utas.edu.au (James McCoull)
Subject: Re: Amiga BLITTER (was Re: Atari BLITTER)
Organization: University of Tasmania, Australia.
Date: Mon, 5 Oct 1992 04:43:33 GMT

espensk@stud.cs.uit.no (Espen Skoglund) writes:

>Ummh.....I love the "possible features" James McCoull discussed in his article,
>especialy the Blitter-queue. It would be fantastic if such features were added.
>It would also be great with more than one blitter(at least two) that could work
>simultanously.   *Dreaming, dreaming*

        Hmm in the light of day - probably the most important feature is
faster support [more direct] for polygons.  I'm not sure if other people
have experience the same problem as me - but good MC68000 code on the
amiga beats the blitter for [traditional] polygon filling.  Of course
I've done some silly code which just uses the blitter to fill horizontal
lines or partitions the polygon into "rectangles" [so D=A, all sources
disabled can be used] - but this really ties up the cpu, and only brings
a speedup of a factor of around 2.  The real problem is the overhead for
drawing small polygons - hence my desire for a blitter queue [this
result comes from some *very* preliminary work I was doing with
profiling graphics routines, and blitter usage.]  Hmm has anyone patched
say KS1.3 so it records information about all the blits it performs?  I started
to once, but never finished - I'm sure the results could be a bit of an
eye opener - my guess is that the pre 3.0 gfx.library really kills a bit
of the power of the blitter [given what I have heard about Chris Green,
I'm sure the 3.0 routines are significantly better] by not handling
special cases with [fewer source] blits.

	Speaking of polygons, someone the other day was asking what
is the use of different modulos for the sources - [assuming we
are not talking about the C as reading destination source] - they are
quite handy for certain polygon drawing tricks.  Consider your average
high speed polygon routine - you have just finished your frequency analysis
and low and behold you find that the most frequent size of polygons is in
the sub 48 pixel wide ballpark.  Now your average performance freak, will
know that this is the range in which the blitter under almost any
scheme [horizontal line blits, rectangle subdivision] has no use.  Well
not quite, you can draw small trapezoids quite efficiently using two sources
one for the left edge, one for the right, and two different modulos to generate
the different step rates down the left and right edges.

Imagine you have the following image in memory [lets drop it to 4 bit words
for simplicity]

Left edge array:
	
	0000 1111 ...
	0001 1111 ...
	0011 1111 ...
	0111 1111 ...
	1111 1111 ...

Right edge array:
	... 1111 0000
	... 1111 1000
	... 1111 1100
	... 1111 1110
	... 1111 1111
	
Now each line in these edge arrays [length in words depends on the width
of the polygons are routine will handle] is repeated a fixed number of times.
[Say 256 times for a routine which might want to draw polygons up to 256
lines tall - ie we may have to repeat one edge position for every line of the
screen.]

Now we set source A to point to the correct position into the left array,
and set the A modulo according to how angled the left edge is.  Similarly
with the B source.  Now with the right logic function, and a bit of work,
it can be shown [don't ya just love math proofs] that fast small trapezoids
are possible...


Regards, James.
Newsgroups: comp.sys.amiga.advocacy