From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 11:08:58 -0700 (MST)

Re: LibGGI3D RFC

On Wed, 19 Aug 1998, Rodolphe Ortalo wrote:

> [I don't quote anything from former posts, because I guess
>  everyone read them, and they are long...]
> 
> Well, first, let's say I'm glad of the way this RFC was written and
> commented. I'm also glad that Jon did this first try... (In other words,
> thanks for the work ;-)
> 
> 
> I tend to agree with the overall design of Jon. And I also tend to
> agree with the comments Scott McNab made.
> 
> To summurize my views (with Jon's proposal as the basis):
>  - I don't really feel the need for having a notion of camera in
> libggi3d. I would be happy with simple 2D parameters in libggi3d
> (in fact, projected 2D parms, plus 1/Z, U,V, etc...)

I can't think of a reason unless libGGI3D does clipping (which is a good
idea).  In that case, full camera info -should- be present - or at least
available to the renderers.
	(a 'renderer' extension to libGGI3D?  or KGI/...?)

>  - I think that Z-buffer wouldn't be so annoying to manage.
> Jon does not seem to have the same view, so, could you point the things
> that worry you on this point Jon ?

A Z-buffer requires X,Y,Z present...
(hmm - yer comment above about U,V,...  hmmmm.  I've got code that has up 
to 27 discrete coordinates... just a simple gouraud-shaded
multitexture+transform renderer...)

>  - I also think alpha management could be very useful and not so
> difficult... (Same comment as previous point.)

it's part of that shading_data...

Now thinking about it:
	Coordinate clipping requires info about -all- present coordinates.
		(X,Y,Z[,W][,U,V[,U2,V2..]][colour])
	mayhaps we need to think about this further?  (don't know)

>  - I want clipping in libggi3d also.

See above...  and this requires also the camera info (view frustrum,etc)
to be available....

>  - I am not yet completly clear of how you want to manage textures ?
> What about texture cache management also ? You associate that to
> a particular shader, that's the idea ? BTW, I tend to like that idea
> of registering & using shaders like you proposed.

extension to libGGI:
	video cache management
handles allocation of videobuffers for functions requiring such (BITBLT in
libGGI, libGGI2D, texturemapping in libGGI3D, fonts, additional screen
targets for displays that support such, ...)

perhaps
int register_buffertype(struct buffertype { int visible, char *name; } )
<handle> request_videobuffer(int width,int height,int bpp,int buffer,
			     int buffer_type);
	[it makes sense in case hw needs this on specific boundaries]

either that or:
<handle> request_videobuffer(size_t size, int blocktype,
			     void *additional_data);


I'm not sure from here.

G'day, eh? :)
	- Teunis