#POSTSCRIPT
11-Jan-86 03:56:19
Sb: #4856-#POSTSCRIPT
Fm: Jez San @ Argonaut S/W 72247,3661
To: TIM JENISON 71515,710
This message turned up in search, but its forum couldn’t be identified from the original transcript, so it may not be linked into its thread.
Yes, Amiga areafill is damn fast.. but its also VERY DUMB. In order for it
to work, you must have drawn LINES onto a BLANK area of memory so that it can
find out what to fill and what to not fill. Ie: I it can not do it directly
onto the screen because other data onscreen would confuse it. The overhead
in using this method is as follows :
a. Clear a chunk of memory . b. Draw the outlines of the polygon you want to
fill. c. Tell Blitter to Fill the area. d. Blockmove the area onto the screen
that you desire e. Do (d) up to 5 times.. once for each bitplane that you
want filled!
As you can see, its a very inefficient way of doing it. Although it is
almost total Blitter functions (thus very fast), its still very wasteful when
the uP could be drawing the polygon directly onto the display memory! Also,
the uP is smart enough to draw the same pixels into multiple bitplanes at the
same time; which the blitter cant do! Blitter functions work (on average) 10
to 20 times faster than the uProcessor, but the above algorithm is SO
wasteful on Blitter usage that I don't reckon its more than 3 times faster at
BEST, and at worst (5 bitplanes to fill), I reckon the uProcessor will even
beat the Blitter at its own job!
Incremental filling, on the other hand, is quite costly on uProcessor power.
It requires the calculation of Differences in the current frame over the last
frame.. but once done, there are very few pixels to update! (In a flight
simulator, for example, there is a huge coherence between frames. Ie:
Treating the screen as RAW colour, very little changes at any one time!)
Also, Incremental Fill cannot be done by Blitter, cos its TOO DUMB.