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

In article <1989Oct27.162303.787@sjsumcs.sjsu.edu> 33014-18@sjsumcs.SJSU.EDU (Eduardo Horvath) writes:
>
> At first I sent each poly
>to Area...() separately ( Called AreaEnd() between each 2 polys ) but that was
>too slow.  Then I only called AreaEnd() at the end of each frame, but all I
>got was a mono-chromatic blob, although the rendering speed more than doubled.
>In the last version, I separated the colors and rendered them separately, but
>the frame rate is not much better than the first method.

In my BKDC2 contest entry, I created some 3D business graphics and tried
to get the maximum drawing speed out of the filled (and outlined) 3D bars
experimenting with the AreaMove, AreaDraw and placement of the AreaEnd
function relative to the others.  I found that the best speed was obtained
using the system functions when I rendered bunches of things at a time.
The key, however, to avoiding the blob is:

	"If you generate a single shape by using one AreaMove
	 command and an indefinite number of AreaDraw commands,
	 an AreaEnd will correctly generate a filled (and outlined)
	 area.
	 
	 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.

This is a largely experimental result, however thinking back to about 1986
and a conversation I had with Dale (that never quite got into the RKM's)
the areafill functions (AreaMove, AreaDraw) do not actually draw anything,
but simply create lists of things that will be drawn when AreaEnd is called.
The system needs the one-plane-deep TmpRas area as a workspace because it
actually uses that area into which the shapes are to be rendered.  The
area is used many times, once for each bitplane of the final shape.
The shapes are created in this background drawing area and then combined
with the area patterns, and line patterns, and then the writemask of the
RastPort is examined, and the drawing mode, combining the now fully formed
shape-plane with the target plane.  I don't remember whether a new shape
plane (in the TmpRas) is formed for each bitplane, but I don't think so.

Individual shapes are calculated so that a single blit to do the hardware
area fill from left to right will work correctly --- that is, look in the
hardware manual for the hardware area fill rules... filling of areas
begins and ends when a 1-bit is encountered on a line by line basis,
fill-on, fill-off, fill-on etc.  Thus each individual shape is carefully
calculated such that a hardware fill will correctly create the shape.
AreaMove, AreaDraw, AreaEnd, as a sequence, for any single shape, or
AreaMove, AreaDraw... AreaDraw... AreaDraw, AreaEnd is also acceptable
because the software is careful to position the line crossings and the
one or two dots on a line so that filling a shape goes as expected.

However if the user overlaps ANY of the shapes, all bets are off.  It
is no longer possible to say exactly what the rules for what to fill 
at the overlap points might possibly be.  Thus a monochrome blob is
perhaps the most likely result.

Rob Peck