CompuServe Messages

#POSTSCRIPT

#: 4868 S9/SoftwareDevelopmentForum unknown
    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.