From: teunis <teunis@computersupportcentre.com>
  To  : GGI Developers <ggi-develop@eskimo.com>
  Date: Mon, 24 Aug 1998 09:48:01 -0700 (MST)

Re: 3D Graphics Library (libGGI3D) design ideas...

On Mon, 24 Aug 1998, MenTaLguY wrote:

> On Sun, 23 Aug 1998, teunis wrote:
> 
> > Anyways, rather than one monolithic library I'm designing a whole raft of
> > different inter-related libs...  ie (libGGI3Dmath, libGGI3Drasterization,
> > ...)   I don't know how it'll turn out but this could be fun! :)
> 
> Indeed.  Sounds like a good idea -- has some real bloat-reducing potential,
> and it forces us (you) to properly generalize the design, to boot :) 

*thanks*
Just signed up to GGI3D devel list btw....

Hmm.  I'm starting with seperating into chapters but it looks like OpenGL
isn't really organized that way....  *sigh*, well it's a place to start :)
[it's coming along nicely]

hmmm though.  libggi3d-math is going to be a pain!  (haveta lookup how to
create inverses of matrices - something I haven't done on computer in a
long time!

[clip]
> 
> > 	Also - can variables be overridden?
> 
> Mmm... I dunno.  What exactly do you mean?  private extension-specific data
> structures, or what?

*yep*.
[sigh]
I'll come up with something....

> > Hmm.  Also - is it possible to request a list of supported API's?  Or will
> > I have to design a call myself?  I don't mean this thing to -be- OpenGL or
> > I'd be fubar.  I just mean this as an easy step to building opengl drivers
> > for Mesa or 3D drivers for other toys (like Direct3D).  Any of the
> > components can be skipped and the -entire- engine will be open to
> > change...
> 
> In theory, for GGI stuff, ALL APIs should be supported, but emulated in
> software if the hardware cannot directly support the functionality exported
> by that API.  IIRC, in the LibGGI* model, no API functions/stubs/data are
> loaded into a visual until such time as you explicitly request that API to
> be used for that visual, so that's not really that bad at all. 
> 
> I think that is a better approach than simply allowing/disallowing certain
> APIs depending on HW support.  I guess if an API function makes absolutely
> no sense whatsoever for a particular visual, the ideal behavior should be
> for it to always return -ENOSYS or something like that.

Okay....
Thing is, I -dont- want to make a whole OpenGL API unless HW supports it.
Gonna design an api to detect what calls are supported then...
*hmmm*

G'day, eh? :)
	- Teunis