From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 17:24:21 -0700 (PDT)

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, teunis wrote:

> On Wed, 19 Aug 1998, James A Simmons wrote:
> 
> > > * int DrawTriangle (float x1, y1, x2, y2, x3, y3; shader_index shader; void
> > > *shader_data) is the core drawing function.
> > 
> > Should go into the kgi drivers accel.
> 
> Correct - but we need more thought 'cause all 3D cards I know of can do a
> -lot- [and tend to require Z coords etc.. as well].  The S3 ViRGE is no
> exception here...
> 
> Incidentally, how do you pickup the size of a "void* shader_data" for
> transfer into kernelspace?  AFAIK size was needed....

	Each shader_data struct type for the KGI driver in question will
be defined in a header file that both the KGI driver and the LibGGI diaply
target for that driver will #include.  Then you just do a sizeof().  Note
that this KGI driver shader_data struct may not be the same as the
LibGGI3D shader_data struct.

> > > * int DrawTriangleSet(triangle_set *triset; shader_index shader; void
> > > *shader_data) draws set of triangles, which can be used to draw polyhedra
> > > for hardware like infinite planes.  If future hardware can draw surfaces
> > > directly, triangle-based surface patches can be used with this function as
> > > well. 
> > 
> > Should kgi drivers support triangle sets? IMHO no.
> 
> IMHO yes.  Faster transfer from userspace->kernelspace and besides, the
> code needed is -really- small.  (worst case around maybe 4K IIRC but I
> could be wrong here - it's been a while since I last built a decomposer)

	Good point.  If KGI ever gets a general-purpose command-batching
system, this could be part of it. 

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed