From: David Waite <mass@ufl.edu>
  To  : ggi-develop@eskimo.com
  Date: Sat, 5 Jun 1999 14:54:21 -0400

Re: Riva TNT: Accellerated Mesa drivers !!!

----- Original Message -----
From: Andreas Beck <becka@rz.uni-duesseldorf.de>


> > The real difference with hardware GL would be speed, of course, but
> > it was hard to see.  I couldn't get anything to run double-buffered,
> > because glutCreateWindow() would terminate the program if
> > glutInitDisplayMode() had been called with the GLUT_DOUBLE parameter.
> > This included many of the mesa demos. :\
>
What resolution were you in? I have heard reports that this version of the
driver does not work properly in modes other than 15/16 bit (even if you
have a TNT, blah). Also,  if you are in a resolution too high for your
britches (800x600 for Riva 128, 1280x1024 I think for the TNT are the
maxes), you won't have enough memory for the card to make both a Z-Buffer
and another copy of the window.

> Without hardware specifically designed for it (don't know, if the TNT is,
> though), this can't be done without much overhead.

TNT is DEFINATELY designed for doublebuffering. 3D accells would be near
useless without it.

> Doublebuffering means that you have two versions of the displayed image
> and switch between them. Doing so on a fullscreen display is simple. You
> just change the start address of the vidmem. In a window, this would mean,
> that you'd have to copy the entire surroundings of the window before
> flipping.
>
> The hardware support I'm talking about is either:
> - treating the window as a big sprite. You can then change the base
address
> of the sprite memory or write one image into regular vidmem and turn
on/off
> such a sprite to see the second page which comes from sprite memory.
> - having special bits in the framebuffer that do HW-frameflipping on a
> per-pixel basis. It's like having a "setup-bitplane" that tells how data
> for a specific reagion is to be fetched from vidmem. AFAIK that's what
> allows SGI to have truecolor and palettized displays at the same time.
>
> CU, ANdy
>
> --
> = Andreas Beck                    |  Email :
<andreas.beck@ggi-project.org> =
>