From: Rodolphe Ortalo <ortalo@laas.fr>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 21:24:51 +0200

Re: LibGGI3D RFC

> On Wed, 19 Aug 1998, Jon M. Taylor wrote:
>> hmm...  Okay - makes sense.
>> That means doing a
>> vis=ggiOpen("display-texture", [view options]);
>> vis=ggiOpen("display-Zbuffer", ...);
>> vis=ggiOpen("display-wbuffer", ...);
>>
>> Yes?
>	Yeah.  They you'd maybe use something like LIBGGI[3D?]_DISPLAY =
>cache:[texture,zbuffer,...].  I dunno LibGGI *that* well yet.
>
>> Though there should be some kind of internal mechanism for handling
>> display memory!  (so it doesn't get all fragmented and can be used
>> effectively!)
>
>	I guess the buffer system doesn't *have* to be in a target.  AAIK
>is isn't(?) in LibGGI2D.

Well, it seems to me that I'm starting to understand the way you want
to go... However, there may be some problems in doing so... (Even though
libggi should provide a convenient framework.)


The extension mechanism of libggi provides a mean to add _new_ functions
to the GGI API, available for a given ggi_visual_t.
This means that you can add a function ggi3dDrawTriangle(x,y,z) easily
(NB: The x,y,z parms are here just because I _need_ parms for the following,
I don't mind if this is realistic.)
This is the purpose of extension libraries.

A display target allows you to _specialize_ the functions (ie: to adapt
them to a specific environment). E.g. you can provide a
ggi3dDrawTriangleDamnFastOn16Bpp(x,y,z) function in a display-damnfast-16bpp
display target. And the user will not call it directly, it will simply
use the normal ggi3dDrawTriangle(x,y,z).
This is the purpose of display target and dynamic loading of specialized
lib. (As you guessed, the "stub" lib is the generic lib that gets loaded
anyway if there is nothing specialized for the running environment.)


However, with respect the zbuffer issues, textures, etc. on libggi3d it
seems to me you are doing the two things at once...
Okay, drawing with textures enabled is only a particular way of shading.
But it also implies a different number of parms for the function that
draws triangles...
So, I don't think you can simply provide ggi3dDrawTexturedTriangle(x,y,z,u,v)
through a display target, you also need the extension lib (because of the
u,v parms...)

You can turn around this (e.g. for texture management) using some
kind of "drawing context", with a function like ggi3dSetShaded(the_shader).

But, can this prevent you from having a ggi3dDrawTexturedTriangle function
which arguments are different from the normal ggi3dDrawTriangle ?

If not (and I suspect not, or I would not argue) then you have another
function added to libggi3d that you did not want...


So, I don't know exactly the API you want to use, but it seems to me that:
 - zbuffer management can be turned on/off rather easily, and that conventional
functions like ggi3dDrawTriangle can have a zbuffer and non-zbuffer
implementation, hence I thought that feature would be easily integrated
in libggi3d (through the use of a specialized display target);
 - while texture management, on the contrary, seems to require a different
function (with different arguments from the normal one), hence I thought it
would be better in another extension lib (libggi3dtextured).

Hence my remark that zbuffer handling wouldn't be so costly in comparison
to texture management... (I admit I did not consider both simultaneously.)


Where am I wrong on what I say ? (if you understood anything at all ;-)


Rodolphe