Forum unknown
· SoftwareDevelopment
#POSTSCRIPT
11 messages in this 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.
Yes, I am *painfully* aware of the proceedure for filling. My point was that
the 68k can't hope to compete. By carefully choosing your colors and planes,
in a specific application, (like a game) you could restrict changes to 1 or 2
planes. It's hard to see how else the (they) could implement a fast fill in
hardware, without the complexity of another entire microprocessor. I'm very
impressed with Miner's approach! That blitter is better than the original
smalltalk bitblit. does everything and more! the original bitblit only had, I
think, 8 possible operations. (Is that right? I think so!) So, anyway, where
can I read about incremental fills?
I'm not aware of any literature on Incremental Fills.. its a phrase that sort
of 'came about' with myself and other interested people talking about the
same subject… the name sort of 'grew!' The actual technique may be called
something else totally in American literature. Look up Watkins algorithms
for hidden surface removal in a graphics textbook, like Foley/Van Dam.. or
Newmann and Sproull. It says the sort of rough idea.. but you can take it a
lot FURTHER than that! It'll take me another 2 months to finish development
on an incremental system, the main reason for the huge delay being that I've
got to finish off my current game 'StarGlider' while doing development on new
ideas… and unfortunately 'PAID WORK' takes priority over algorithm
development.
Yes, I have Newman/sproul and Foley/VanDam but didn't recall the term
incremental fill. Basically what you are doing is subtracting the new polygon
fromm the old one to define a new "delta" region. Right? If so, are you able
to define this new region as 3 vertices? Multiple polygons? What sort of
description do you end up with, generally?
Yes, I have Newman/sproul and Foley/VanDam but didn't recall the term
incremental fill. Basically what you are doing is subtracting the new polygon
fromm the old one to define a new "delta" region. Right? If so, are you able
to define this new region as 3 vertices? Multiple polygons? What sort of
description do you end up with, generally?
I'm not aware of any literature on Incremental Fills.. its a phrase that sort
of 'came about' with myself and other interested people talking about the
same subject… the name sort of 'grew!' The actual technique may be called
something else totally in American literature. Look up Watkins algorithms
for hidden surface removal in a graphics textbook, like Foley/Van Dam.. or
Newmann and Sproull. It says the sort of rough idea.. but you can take it a
lot FURTHER than that! It'll take me another 2 months to finish development
on an incremental system, the main reason for the huge delay being that I've
got to finish off my current game 'StarGlider' while doing development on new
ideas… and unfortunately 'PAID WORK' takes priority over algorithm
development.
Yes, I am *painfully* aware of the proceedure for filling. My point was that
the 68k can't hope to compete. By carefully choosing your colors and planes,
in a specific application, (like a game) you could restrict changes to 1 or 2
planes. It's hard to see how else the (they) could implement a fast fill in
hardware, without the complexity of another entire microprocessor. I'm very
impressed with Miner's approach! That blitter is better than the original
smalltalk bitblit. does everything and more! the original bitblit only had, I
think, 8 possible operations. (Is that right? I think so!) So, anyway, where
can I read about incremental fills?
Couldn't you just clear the bit-plane(s) section to draw the lines, to then
fill? (using double-buffering, of course, to avoid flicker) That would save a
blockmove. Question: How much faster can the blitter clear memory (to 0) over
the 68000?
68000 can clear a word every half a microsecond. blitter can do it at least
twice as fast, I believe. Probably more.
No, you can't just clear the bitplanes onscreen to draw a new polygon, because
you don't want to lose the existing data that was underneath your new polygon..
ie: there may have been 10 other polygons underneath, and you want them to
still be there!
68000 can clear a word every half a microsecond. blitter can do it at least
twice as fast, I believe. Probably more.
No, you can't just clear the bitplanes onscreen to draw a new polygon, because
you don't want to lose the existing data that was underneath your new polygon..
ie: there may have been 10 other polygons underneath, and you want them to
still be there!
Couldn't you just clear the bit-plane(s) section to draw the lines, to then
fill? (using double-buffering, of course, to avoid flicker) That would save a
blockmove. Question: How much faster can the blitter clear memory (to 0) over
the 68000?