From: MenTaLguY <mentalg@geocities.com>
  To  : GGI Developers <ggi-develop@eskimo.com>
  Date: Mon, 24 Aug 1998 10:25:42 -0500 (EST)

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

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

> Anyways a question:
> 	Can GGI targets call back to calls they overrid?
> 	(this would be handy as sometimes this could be needed)

Sure.  However, in that case it is your responsibility to save the old
function pointers to call back to.

> 	Also - can variables be overridden?

Mmm... I dunno.  What exactly do you mean?  private extension-specific data
structures, or what?

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

-=MenTaLguY=-