From: MenTaLguY <mentalg@geocities.com>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 17:19:14 -0500 (EST)

RE: 3d

On Tue, 18 Aug 1998, Jon M. Taylor wrote:

> On Tue, 18 Aug 1998, MenTaLguY wrote:
> 
> > On Mon, 17 Aug 1998, Jon M. Taylor wrote:
> > 
> > > 	So, with those three basic concepts, we can cover the most
> > > hardware the best and easiest.  Like LibGGI, LibGGI3D would have the
> > > ability to load helper libraries, so the handling of the polygons that are
> > > fed to the rendering functions are turned into the form the hardware (KGI
> > > driver, etc) wants is optimizeable.
> > 
> > Is there any reason that this can't be done as a LibGGI extension library,
> > or a set of them?
> 
> 	I have to admit at this point that I am a bit unclear on the
> difference between a LibGGI-family library (like LibGGI2D or LibGWT) and a
> LibGGI extension library.  I envison LibGGI3D as being quite analogous to
> LibGGI2D.  It would be a true API, have its own extension libraries, 
> etc.

Well, basically there is no real techical difference.  LibGGI2D and LibGWT
are 'general-purpose', while many of what are considered the "extension
libraries" have API features that are mostly very specific to certain
targets/drivers.

All of these use the LibGGI extension mechanism for their own helper
libraries -- so saying "LibGGI3D would have the ability to load helper
libraries" implied that you were thinking it was necessary to write a
special new extension mechanism for LibGGI3D.  It just isn't so, and I
wanted to make sure you (or especially anyone reading your post) didn't
erroneously think it was necessary to reinvent the wheel. :)

-=MenTaLguY=-