[quake2] help running quake2

Nelson Marques nmarques at netvisao.pt
Wed Oct 13 19:26:05 EDT 2004


should be baseq2 and not base2.

Rename it, and it should be able to load the library correctly.

nmarques

arny at taiga.com wrote:

>Hello,
>
>  
>
>>I complied from the latest CVS and copied base2 to the
>>releasei386 directory... What is my next step?
>>
>>Ron_W
>>
>>
>>CD Audio Initialized
>>------- Loading gamei386.so -------
>>********************
>>ERROR: failed to load game DLL
>>********************
>>Xlib:  extension "XFree86-DGA" missing on display
>>":0.0".
>>Failed to detect XF86DGA Mouse
>>    
>>
>
>DGA is some graphics extension, probably needed to support the
>hardware rendering (i.e. your video card does the shading of
>3d objects automatically without requiring effort from your
>PC's processor).
>
>You have 2 options, either get hardware rendering working or
>tell quake2 to use a software rendering driver such as software
>X windows, or software svgalib.
>
>Firstly, do everything as the root user.
>
>For software rendering to work, you must make sure quake2 was
>compiled with BUILD_QMAX=NO in the Makefile, otherwise it may
>just crash with a floating point or memory or segmentation fault.
>
>To use svgalib you first need
>to make sure svgalib is configured to use your video card (assuming
>svgalib is installed on your system).  Quit out of X windows and
>try running /usr/lib/svgalib/vgatest as root (use 'locate vgatest'
>or 'find / -name vgatest -print' to find vgatest if its not in
>/usr/lib/svgalib).  Once svgalib is working you need to edit the
>quake2 Makefile to make sure it has BUILD_SVGA=YES in it, do a
>'make clean' and then a 'make' to recompile if it hasnt (and then
>copy the new binaries accross as described in the readme).
>
>To use software X windows you simply need to start quake2 in X windows
>with '+set vid_ref softx' as command line options.
>
>Getting hardware rendering working may be more tricky.  I've got a
>voodoo 4 3dfx card and it took me ages to get it working purely
>because of the lack of instructions and difficulty in finding important
>files.  I can only assume a lot of linux gamers have hardware rendering
>working purely because it was set up right for their particular video
>card in their initial linux distribution.  I'll attach the notes that I
>made when I got hardware rendering working to the end of this email.
>
>Erm, my own notes seem to tell me that DGA isn't generally needed for
>hardware rendering, however I think all of what I've said is still
>valid.  The basic old software X windows quake2 driver probably wont
>need DGA, and obviously the svgalib driver definately wont (doesnt need
>x windows at all).  All you probably need to know is its some kinda
>graphics extension needed for some fancy modern applications (I've a
>feeling my TV card software needs it to allow the PCI card to access
>the memory on my graphics card _directly_, for example).
>
>The only problem in not getting hardware rendering working is that
>probably most the developers working on this quake2 project mainly
>test out quake2 using hardware rendering, so if they accidentally
>break the software rendering drivers, it may not get noticed for a
>while.  Having said that I tested the latest release candidate a
>couple of weeks ago and everything worked fine (bar the mouse which
>is a problem they're working on, and the sound which I think was just
>my crappy on board sound hardware).
>
>If you can't get hardware rendering working for quake 2, take a step
>backwards are try to get it working for the simplest game that user
>hardware rendering you can find, such as tuxkart maybe.
>
>Sorry its so complicated.  I'm not a gamer, or anyone thats particularly
>interested in graphics, I'm just trying to support this project as its
>admirable ID software made quake2 source available for linux and I think
>its an important part of linux / open source advocacy to be able to get
>a decent showcase game working.
>
>Good luck,
>
>Robin
>
>	------------------------------------------
>
>Heres what I found trying to get hardware rendering working on a
>3dfx voodoo 3 3000 card on slackware 8.1 using Linux 2.4.18.  I
>don't really know much about any of this stuff so don't take my
>word as gospel.
>
>Firstly I configured and compiled a kernel with everything that I
>might need, i.e. agpart and anything that mentions 3dfx.
>
>Then its a case of getting the following working:
>
>
>openGL	- graphics lib api invented by SGI, see www.opengl.org if you
>	  wish to read about it.
>
>mesa	- implementation of openGL, incorporated into xfree86, i.e.
>	  if you have a recent version of xfree86, you should
>	  already have this (I think), see www.mesa3d.org
>
>GLX	- glue between openGL and lower level stuff, probably part of
>	  xfree86 (like mesa), needs the line:      Load       "glx"
>	  in XF86Config.
>
>DRI	- hardwarey thing, as above incorporated into xfree86, needs
>	  the line:     Load        "dri"
>	  in XF86Config.  See http://dri.sourceforge.net/
>	  Note /usr/X11R6/lib/modules/dri/README.tdfx reckons you need
>          glide for 3dfx cards to work.
>
>glide	- f' knows what this does, its code orignally by the defunct
>          company 3dfx, but you cant seem to get it from anywhere except
>          linux distributions themselves, you just get directed to a hell
>          of a lot of broken links.  fortunately its available in extras
>	  or contrib of slackware 8.1, which is what I'm using.
>
>sidenote: an alternative to some of the stuff above (DRI at least) is
>http://utah-glx.sourceforge.net/   I haven't tried using it though.
>
>Finally keep the resolution of the X server down below 1280x1024, make
>sure its using 16 bit colour (not 8 or 24) and run everything as root.
>glxinfo will give you information, as will /var/log/XFree86.0.log,
>glxgears is a simple demo that should run at about 400 fps if hardware
>acceleration is working.
>
>	-----------------------------------------------------
>
>Extra stuff:
>
>GLUT	- I think its some library that provides a front end to openGL,
>	  available in some 'mesa demos' package or read about it at
>	  www.opengl.org  Not all apps need glut though.
>	  Seems to be two versions, some old glut thing opengl.org has
>	  a link to, and a glut in the mesademos package, although you
>	  need the configure and stuff in mesa to be able to compile it,
>	  both mesa and mesademos seem to be at
>          http://prdownloads.sourceforge.net/mesa3d/
>	  In addition there is also freeglut which is supposed to be 100%
>	  compatible and I think compiles easy, but the libraries are the
>	  wrong name, e.g. libfreeglut* Vs libglut* etc.
>	  The mesademos version is the one I had luck with.
>
><tiocsti> arny, might wanna note in glx that its only part of xfree86 if you
>+use 4.x, there is a 3rd party glx you can use with 3.x
><tiocsti> same with dri i believe
>
>
>DGA	- probably nothing to do with rendering, and flight gear seems to
>	  work fine with it disabled, but if you ever find something that
>	  needs it you should be able to enable it by commenting out:
>	        Option    "omit xfree86-dga"
>	  in XF86Config.  Note that the dga(1) test program just seemed to
>	  lock things up with a black screen (control alt backspace worked
>	  only if it was the first thing I pressed) however applications
>	  such as xawtv seemed to be able to use it fine, although mplayer
>	  had bugs with it (not to mention wrong colours).
>
>
>
>  
>




More information about the quake2 mailing list