From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 17 Aug 1998 22:16:16 -0700 (PDT)

Re: 3d

On Mon, 17 Aug 1998, teunis wrote:

> On Mon, 17 Aug 1998, Marcus Sundberg wrote:
> 
> > > PS: On the DirectBuffer comments - IMHO support isn't ready for this
> > > either yet but this one -should- be done soon!
> > 
> > If you are talking about the DirectBuffer system in libggi it's ready
> > to handle any buffer you can possible imagine.
> > And requesting Z-buffers doesn't belong in the core libggi, that's
> > stuff that belong in some extension.
> 
> Ah - but it has to be -requested- from the hardware.  sometimes.  Most of
> the time you're just requesting a buffer of "x" size inside of videoram.
> Some cards might impose a restriction on where that buffer can be (ie:
> only on 8-byte boundary). Some cards may only allow certain kinds of
> buffers or have flags on buffers to provide special acceleration - say
> Z-buffer, bitmap, alpha-buffer, MPEG/YCbCr buffer, ...
> 
> Is -THAT- handled by libGGI?
> (that's the part that matters)

	AFAIK, no.  DirectBuffer is about raw access to memory, not the
structure of the memory.  DirectDepthBuffer (see my other posts in the
thread) is an example of a type of buffer which needs to be handled in a
particular way (write-through with coordinate translation).

> Sending graphics commands (ie ggiDrawPixel with Z-buffer) should be in an
> extension though - such as a Z-buffer extension of GGI2D.

	I think the extra coordinate justifies a LibGGI3D.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed