Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!sun-barr!lll-winken!ubvax!ardent!peck!rap
From: rap@peck.ardent.com (Rob Peck)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Area Fills
Message-ID: <8924@ardent.UUCP>
Date: 1 Nov 89 18:31:13 GMT
References: <1989Oct27.162303.787@sjsumcs.sjsu.edu> <8888@ardent.UUCP> <1989Oct31.191532.19902@sjsumcs.sjsu.edu>
Sender: news@ardent.UUCP
Reply-To: rap@peck.ardent.com (Rob Peck)
Organization: Ardent Computer Corp., Sunnyvale, CA
Lines: 90

In article <1989Oct31.191532.19902@sjsumcs.sjsu.edu> 33014-18@sjsumcs.SJSU.EDU (Eduardo Horvath) writes:

(quoting me):

>>       If you generate multiple shapes by using several
>>       groups of commands consisting each of:
>>
>>              shape 1: One AreaMove + One or more AreaDraws
>>              shape 2: One AreaMove + One or more AreaDraws
>>              ...
>>              shape n: One AreaMove + One or more AreaDraws
>>
>>       and then finally an AreaEnd, there can be NO overlapping
>>       of polygonal shapes from the independent objects, though
>>       the individual objects themselves may employ any number
>>       of inter-object line crossings.

>Since I was trying to display a 3D object, the lines bordering the different
>polygons should be the same.  Does that mean that there's an overlap? 

Note that the term overlap also refers to edge-to-edge abutment.

>I tried this next.  What I had were faces of differing colors coming in at
>random due to depth sorting, etc.  What I ended up with was a blob *only
>rendered in one color.*  Some of the lines and surfaces around the exterior
>were also confused.  What I want to do is:
>
>       SetAPen(Color1);
>       AreaMove(Poly1); .... AreaDraw(Poly1);
>       SetAPen(Color2);
>       Area Move(Poly2); ..... AreaEnd(Poly2);
>
....
....
>I had been able to infer that this must be how the functions worked from
>the data structures involved.  But do they support more than one color per
>AreaEnd() ?
>
NO.  The AreaEnd uses whatever is the current contents of the RastPort
as its key.  It uses the foreground pen for the primary color, the
background pen as the secondary color (if there is an area pattern
and/or a line pattern present).  It uses the current color of the
area outline pen to outline the shapes.


This areafilling system was designed to be a fast 2-D system that takes
advantage of the custom hardware area fill, but also assures that layering
operations always work as expected.

Re the overhead in AreaEnd... it has to be there to make sure that
no matter whether there are obscured or unobscured layers, the drawing
still happens correctly.  The fastest speed, though, will be obtained
by drawing directly into the Screen's RastPort, with no windows
attached to the screen, minimizes consideration of layers.


One way to solve the overlap problem before rendering would be to
calculate a bounding rectangle for each shape before it was added
to a list of shapes to be rendered.  If there is no bounding rectangle
overlap with previously added shapes (all prior to generating an
AreaEnd) there'd be no blob.

Doing a shape-overlap calculation would take a lot more effort and
I would not care to try to tackle it.

There is another method that Amiga supports directly, supported by
the blitter.  There is a bit that indicates whether as a result of a blit
there were any one bits in the result.  (Check the Hardware Manual
for this), but it would entail creating two single-plane rastports,
rendering the polygon shapes one at a time into one of the planes.
Then doing a single blit operation with an AND function between the
two planes, throwing away the output (turning off the store-to-destination
bit) and only examining the flag that said whether or not there were
any one's in the result of the operation.  That'd say whether or not
there was an overlap of the new polygon with any of the existing ones.
Then, if not, do an OR operation between the two planes and store the
result in the destination plane against which a new polygon can be
compared.   AreaMove, AreaDraw and AreaEnd could be used to create
the polygons and since they'd be working with a single-plane
RastPort, and with no layers to slice and dice, they'd be pretty
fast.   You'd keep rolling this background check until the first
overlap occurred, then do issue an AreaEnd for the main drawing area
instead of adding the thing that causes the blob.   Continue until
all shapes are drawn.  BLITLAB, by Tom Rokiki (available on a FISH
disk) contains more details about blitter register operations and can
let you experiment to verify what happens in cases of overlap.

Frankly, the bounding rectangle idea is probably a lot faster.

Rob Peck