From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Fri, 21 Aug 1998 23:43:37 +1000

Re: DirectBuffer extension requests?!(!) (was Re: LibGGI3D RFC)

Marcus writes:

>  > > First, let's define our terminology.  A DirectBuffer is a memory
>  > > buffer which is specified to be located on a particular type of
>  > > storage (video RAM right now) and/or has a hardware-specific
>  > > internal layout/structure, and/or needs specialized handling
>  > > methods.  Am I in the ballpark?
>  > 
>  > This sounds right.   (there's a really good doc on this written somewhere)
>  > 
>  > TODO:  (guessing)
>  > 	KGI memory management?
>  > 	(this should be duable userspace inside KGI target, just need to
>  > 	 keep track of what's been used where)
>  > 
>  > AFAIK the rest of directbuffer is already operational.  actually the KGI
>  > (and kgicon) driver needs a buncha work here.
>  
>  Well, if we want extension libraries to be able to add DirectBuffers
>  we need to update the targets so that they only free the buffers
>  that they have allocated - not all buffers, but this shouldn't be
>  much work.
[SNIP]...
>  This gives us two options; either we add a char dummy_pad[xxx], 
>  where xxx is some sufficiently large number, or we make it a
>  union of pointers. What do you think? Andrew?

Perhaps extension libraries should just define their own DirectBuffers,
and then override the ggiDBGetNumBuffers and ggiDBGetBuffer functions to
wiggle them in front of the normal DirectBuffers.  I don't know.  

I think putting libggi3d buffers (ETC) into the main libggi header file
(ggi.h) would be a bad idea (management-wise), probably best if libggi3d
only buffers (e.g. z-buffer) belong in libggi3d headers, & libggi2d only
buffers (e.g. stencil buffer) belong in libggi2d headers, etc...

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/