From: Christoph Egger <Christoph_Egger@t-online.de>
  To  : ggi-develop@eskimo.com
  Date: Sun, 28 Mar 1999 09:30:12 +0200 (MEST)

Re: Some more "texturetalk"

On Sun, 28 Mar 1999, Kenneth Johansson wrote:

> Brian Julin wrote:
> 
> >
> > Here's how it works.  You attach the libGGIAuxBuf extension,
> > either before (preferably) or after setting a mode on the
> > normal visual.  This gives you a new operation ggiAuxBufAlloc
> > on the visual which you can use to define an off-virtual-screen
> > buffer (Z,Sprite,Texture, what have you.)  This takes away the
> > poor practice of forcing the virtx, virty to do double duty
> > as an auxiliary buffer allocation -- so don't ask for virtual
> > screen resolution unless you really want just that.  It also
> > loads the "auxbufserver" renderer on top of the existing one
> > (or if that's not possible, the auxbufserver renderer must be
> > preloaded by a nested construct like display-tile does), or if
> > none is chosen yet, it will do so during the setmode call.
> >
> 
> Nice.
Yes, that's good. Some questions: 

1. When you allocate with ggiAuxBufAlloc memory i.e. for Z-buffer, which
   band-whidth has it? 16bit, 32bit or 64bit?

2. Could I use fixpoint-math, float-point math or both to access to it?

> 
> 
> >
> > If you have not set a mode, any call to ggiAuxBufAlloc merely
> > prepares the visual's informational structures to anticipate
> > needing these sprites.  You can then use advanced set/checkmode
> > functions provided in the extension to ask the target to allocate
> > these sprite areas when it sets the mode.  It will allocate the
> > sprites in the order they were requested, and continue after
> > failure to try to fit as many into video memory as it can.  The
> > rest are shunted to main memory buffers.  There will be functions
> > to check whether a particular buffer is in video memory or main
> > memory, or force moves to/from video memory, or to lock a buffer
> > into main/video memory so it never gets bumped out.  If the mode
> > was already set using the standard ggiSetMode function, the
> > allocation happens in realtime and you can check the results
> > of each one as you do it, but this may result in fewer buffers being
> > available since the setmode didn't know what you were going to want.
> >
> 
> May I suggest that you separate the memory management and sprite into two
> different things. Some types of data on the cards memory is not dependant on the
> mode that it is operating. So you would first make a memory manger that just
> allocate raw memory. This allocator have to be able to ask the allocated memory
> to move if it can otherwise we will have to much fragmentation.
> 
> Why do I think that this is needed. Well I have read about matrox G400 chip and
> they claim Support for unlimited number of simultaneous video windows and
> sprites. They have not yet released the chip programing information so I dont
> know how the sprites works but if they  have simply made the overlay also take a
> mask (iregular overlay windows)I guess that we now have the possibility to
> display 16 or 24 bit sprites on a 8 bit display and other cool things. This mean
> that no copy of data is necessary but we will need a overlay structure of some
> sort to controll it and that need to be in video mem to.
> 
> Then we have textures that have a multitude of different formats and also need
> to be in onboard memeory.

That's good. I think the types of data on the card memory should be
accessed by a KGIcon-driver. So it could emulate "unlimited" number of
simulaneous video windows and sprites like the Matrox G400 chip in
software, if one chipset doesn't support it.
 

Christoph Egger
E-Mail: Christoph_Egger@t-online.de