Hello...

[Sorry for the length of this email....]

The ability to run Quake 2 using hardware rendering may be of interest to
some.  I know that I found it all together cool.  The following is how I
accomplished this using the Linux/i386 Quake 2 binaries and libraries.
There are a number of warts to be dealt with and a certain amount of
hackery needed:


Pre-Setup:

The following generally assumes that you have a working Linux/i386 Quake 2
installation already running on your NetBSD/i386 system.  If you do not
have this, then the following will likely not do you much good.


Hardware:

I have component built a 450MHZ AMD K6-2 based system which includes a
Asus AGP-V3800 video card.  This is a Nvidia Riva TNT2 based card.  There
are a number of makes of such cards.  Mine is an Asus mainly because that
was what was in stock.  The following pretty much assumes that you would
be using the same sort of hardware, or at least, the same X and glx
drivers.


Getting Source:

The following will need to be acquired:

1) The source from Nvidia which contains patches to XFree86, Mesa and
their glx server driver.  This can be acquired at from:

ftp://ftp1.detonator.nvidia.com/pub/drivers/english/riva-tnt-tnt2-vanta/linux
ftp://ftp2.detonator.nvidia.com/pub/drivers/english/riva-tnt-tnt2-vanta/linux

Make sure that you acquire at least the Mesa-3.0 patch, the XFree86 patch,
and the riva_glx server module.  Also, you will want to acquire one of the
two precompiled Linux libraries/etc, either the libc5 or the glib version.

For the sake of discussion, lets assume that all of this was put in:

	/usr/xsrc/unsupported_src


2) A new X server will have to be built using the patch above.  Make sure
that the latest NetBSD sup of the xsrc is available on your system.

3) Mesa is a must.  The simplest thing to do here is to use the NetBSD
package system.  Make sure that access to /usr/pkgsrc is available.


Building a new X tree:

1) Assuming that the latest xsrc tree is in its traditional spot of
/usr/xsrc apply the patch from the Nvidia site.  It should apply without
incident.

2) Rebuild, or build, and install the X tree.

3) Bring up the X server.  The Nvidia driver is in the SVGA server.  There
should be mention of TNT2 support and the like when the X server starts.


Building Mesa:

1) It is a good idea to get Mesa working first with software rendering.
Assuming that the package system is available.  cd
/usr/pkgsrc/graphics/Mesa and do a 'make install' as root.

2) I do not believe that the demo are Mesa built.  So 'cd
/usr/pkgsrc/graphics/Mesa/work/Mesa-3.0/work' and type make.

Wart 1: I think that the Makefile for the demos is not quite right.  One
might have to add references to -lX11, -lXext, etc...  to get the demos to
build.

3) Try the demos.  In particular, the 'trispd' binary will attempt to
benchmark the GL rendering system being used.  Don't expect just too much,
as things are still using the software rendering system at this point.


Building the Nvidia glx source:

1) The Nvidia glx source wants Mesa 3.0 available.  Assuming that the
down load from Nvidia is in /usr/xsrc/unofficial_src, put a un-archived copy
of Mesa there.  You can use the one from the distfiles in the NetBSD
package source.

2a) Apply the NetBSD patches from /usr/pkgsrc/graphics/Mesa to this Mesa
tree.  These should apply without trouble.

2b) Apply the Nvidia Mesa patche to this Mesa tree.  The Nvidia patches
will complain a little, but it appears to only be related to comments at
the top of source files.

Wart 2: The Nvidia server driver will want to use the i386 assembly
routines from Mesa.  However, we don't build those.  Indeed, it appears
that they have never been ported to NetBSD at all.  The solution is
simple, however, add a "#define FREEBSD" to the file:

	/usr/xsrc/unofficial_src/Mesa-3.0/src/asm_386.S

3) Unpack the Nvidia glx server module.  Edit the Config file that comes
with it and point the XSERVTOP and MESATOP to the proper locations.  Build
the glx module and libGL libraries.  You won't actually be building the
Mesa source directly, but the Nvidia glx module will be using parts of it
when it builds.

Wart 3: Things should build without any great problems, except for
warning.  However, when it comes times to link the glx.so module together,
there will be complaints about 'RSS ... relocation'.  The resulting shared
object will not actually work.  All is not lost, however, go ahead and
install the built glx module and libGL.so libraries.  Then 'cd
/usr/xsrc/unofficial_src/glx-0.99/servGL' and relink the glx.so module
with the following:

ld -o glx.so~ -Bshareable -R/usr/X11R6/lib asm_386.o serverglx/?*.o mesaglx/?*.o hwglx/libHwGlx.a -L/usr/X11R6/lib -lGL

The link should go ahead without complaint.  Copy the resulting shared
object to /usr/X11R6/lib/modules as glx.so.

4a) Edit your XF86Config file and add the loading of the glx module to the
proper section.  When the X server is restarted, it should indicate that
the GLX module has been loaded.  Make sure that you capture the output
of execution in a file, for if it fails you will likely be left with an
unusable display.

.
.

        GLX extension module for XFree86 3.3.3.1 -- Mesa version 3.0
                GLX package version 0.9, GLX protocol version 1.2.
(**) module glx.so successfully loaded from /usr/X11R6/lib/modules
.
.
.

4b) According to the info from Nvidia, the glx module is only optimized
for 15 and 16 bit color depth.  Make sure that all testing and running
occures at one of those two color depths.


Test with the native Mesa demos:

1) cd /usr/X11R6/lib.  Remove or rename the shared library
libMesaGL.so.3.0 and make it a symbolic link to libGL.so.1.0.  Do a
'ldconfig'.

2) cd /usr/pkgsrc/graphics/Mesa/work/Mesa-3.0/demos and run 'trispd'
again.  Things should be much faster.  NOTE - not all of the demos will
work.  The Nvidia glx module does not appear to support some of the glx
extensions.


Making Quake 2 work:

1) Lets assume that you have put a working Quake 2 Linux/i386 installation
in /usr/local/games/lib/quake2.

2) Remove or rename the existing 3Dfx "GL" libraries.  Copy in the
precompiled Linux/i386 libGL.so module from the Nvidia site.

3) cd /usr/local/games/lib/quake2/baseq2 and edit the config.cfg file.
Remove *any* references to "set _windowed_mouse ..." from this file.  It
appears that if you change GL video modes while using the windowed mouse,
the X server or Quake gets a little confused.  Always remember to turn off
the windowing mouse before fiddling with the GL video modes.

4) Try to start the game with the command:

./quake2 +set vid_ref glx +set gl_driver `pwd`/libGL.so


Wart 4: If you are lucky, it will start right up and you will be able to
select the video resolution of your choice.  However, if it complains
about a unreferenced symbol "__register_frame_info", then you will have to
resort to some binary file editing.

Read in the Linux libGL.so shared library into your favorite binary file
editor.  I use Emacs for this.  Search through the file for the string:

__register_frame_info\0

and change the first part of the symbol to:

__getpid\0


Do this also for __unregister_frame_info.  Be very careful not be add or
subtract bytes from the file.

Try to start Quake 2 again.  If you are lucky and didn't break the
library, then the game should start.  I don't know what
register_frame_info is for, and I could not find it in any Mesa or glx
source.  I may have had to do this because I am running an older set of
Linux libc5 libraries.  In any case, not calling these functions appears
to be non-fatal.



Enjoy the hardware rendering in Quake 2.  It may be a subjective matter,
but the game seemed mostly reasonable even at 1280x1024 resolution,
although it did slow down at that resolution when 3 or more bad guys were
around.  A resolution of 800x600 seemed reasonable in any case.  Also...
the amount of data going over the X pipeline is huge when using this
particular glx architecture.  As the resolution grows you might notice
that the mouse becomes sluggish.  The Nvidia FAQ talks some on this
matter.

In theory, the Quake 3 test should work also [I think that this was
already mentioned on the LISTs], but I have not personally been able to
try it yet.




Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org
[finger brad@anduin.eldar.org for PGP public key]