Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!vsi1!octopus!sjsumcs!33014-18
From: 33014-18@sjsumcs.sjsu.edu (Eduardo Horvath)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Area Fills
Message-ID: <1989Oct31.191532.19902@sjsumcs.sjsu.edu>
Date: 31 Oct 89 19:15:32 GMT
References: <1989Oct27.162303.787@sjsumcs.sjsu.edu> <8888@ardent.UUCP>
Reply-To: 33014-18@sjsumcs.SJSU.EDU (Eduardo Horvath)
Organization: San Jose State University
Lines: 103

In article <8888@ardent.UUCP> rap@peck.ardent.com (Rob Peck) writes:
>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.

I started by doing this for each face, but speed for 30+ faces was abysmal.

>	 
>	 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.
>

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);
	
(This is, of course, greatly simplified to save space.)
Then when it finishes, I want the color of Poly1 to be different from the
color of Poly2.

>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)

[ details deleted ]

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() ?

>
>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

Since I was trying to display a 3D object, the lines bordering the different
plygons should be the same.  Does that mean that there's an overlap?  There 
also seems to be a great deal of overhesd in the AreaEnd() function.  There are at least two blits (excluding line draws): one to fill the area in the TmpRas
and another to copy the area onto each bitplane that is being filled.  

Is there a good way to do the sorting and fixing of the lines so that:

	1)  Lines are clipped to the window boundaries.

	2)  Lines are separated by colors so I can execute a single blit-fill
		on each bit-plane at the end of each frame.

	3)  Polygons then appear in the color that was active when they were
		"rendered", not at the end of the operation.

	4)  Polygons are rendered correctly, regardless of overlapping.

	5)  Overhead is minimized.  I would like a minimum of two frames per
		second when rendering 100+ faces.

It is becoming apparent to me that I may need to write my own graphics kernel.
What I want to do is make the best use of the functions provided in the OS.


===============================================================================
         //x                                    =	MEN AT WORK
        /// \	Try:  33014-18@sjsumcs.SJSU.EDU =
       ///   \                                  =	This space
      ///     \		Eduardo Horvath		=	    is
\\\  ///=======\ 				=	   UNDER 
 \\\///         \				=	CONSTRUCTION
  \xxx           \miga. The computer for the corruptive mind.
===============================================================================