Q:

What graphics cards will work with Tux Racer?

A:

Tux Racer should run on any graphics card which supports OpenGL. Tux Racer has currently been tested and works on:

• ATI Rage 128
• nVidia TNT, TNT2, GeForce256, GeForce2 GTS
• 3dfx Voodoo3

Some people have reported problems with 3dfx Voodoo2 cards. We are working on obtaining a Voodoo2 test system so that we can improve support for this card.

Q:

How do I display my frames per second (FPS)?

A:

Edit the options file in any text editor and find the line:

set display_fps false

Change false to true and you will have a display of your FPS in-game.

See also the FAQ, Where is the Tux Racer Options file?

Q:

Tux Racer runs slowly on my machine; how do I speed it up?

A:

Tux Racer requires a video card with hardware 3D acceleration. You must also have OpenGL drivers that use your video card's hardware acceleration. Under Linux, this can be tricky to set up. Loki Games has created some pages to help users set up OpenGL under Linux:

• Setting up and troubleshooting OpenGL on XFree86 3.3.x FAQ
• Loki's OpenGL drivers page

Under Windows, you should visit your video card vendor's web site and make sure you have the latest drivers installed. You can also use GLSetup to install the latest OpenGL drivers for your card. (See also the FAQ What graphics cards do you support?.)

If you've done all of this and would like to get as many frames per second out of Tux Racer as possible, then you need to tweak some settings in the options file. (See the FAQ, Where is the Tux Racer options file? if you can't find the options file.) The following settings have a significant impact on the rendering speed of Tux Racer:

• x_resolution, y_resolution: Try making the Tux Racer window smaller -- this will increase performance on many graphics cards.
• forward_clip_distance: This controls how much terrain will be visible. Try reducing this value to improve performance.
• course_detail_level: This controls how many triangles are used to draw the course terrain. Try reducing this value to improve performance.
• terrain_blending, perfect_terrain_blending: This controls whether the different terrain textures will be blended together. Set both of these parameters to false to improve performance.
• terrain_envmap: This controls whether the ice is rendered with an environment map (this makes the ice look shiny). Set this to false to improve performance.
• draw_particles: This controls whether snow particles will be drawn when the player turns or brakes. Set this to false to improve performance.
• draw_track_marks: This controls whether players will leave track marks in the snow. Set this to false to improve performance.

Q:

Where is the Tux Racer Options file?

A:

Under Linux, the options file can be found in the ~/.tuxracer directory. Under Windows, the options file can be found in the config subdirectory of the Tux Racer installation directory. Note that on both operating systems, you must run Tux Racer at least once before the options file is created.

Update: At least one user running Windows ME has reported that the config directory is not being created when Tux Racer is first run. If you have run Tux Racer but there is still no config directory, then try creating it manually and then run Tux Racer again. The options file should be created when Tux Racer exits.

Q:

How do I change the Tux Racer controls?

A:

You can change the key bindings by editing the Tux Racer options file. (See the FAQ Where is the Tux Racer options file?.) Edit this file with any text editor, and look for settings that contain the word "key".

You can map more than one key to each action; for example, the default keybinding for the right turn key looks like this:

set turn_right_key "l right"

which binds the L and Right Arrow keys to the right turn action. Key bindings are case-insensitive.

The following names are recognized for "special" keys: f1-f12, left, up, right, down, page_up, page_down, home, end, insert, tab, space, backspace, enter, delete, escape.

Q:

Can I map the SHIFT, CTRL, or ALT keys to an action?

A:

No. This is a limitation of the GLUT library that Tux Racer uses. We may switch to a different library in the future to eliminate this restriction.

Q:

Can I use a joystick with Tux Racer?

A:

Version 0.60 has experimental joystick support. If you are compiling Tux Racer from source then you need to have a version of the SDL library with joystick support installed. (We are using SDL version 1.1.4 for Tux Racer development.)

Tux Racer will use the first joystick on the system. (Under Linux this is /dev/js0.)

Q:

Can I remap the joystick buttons?

A:

Yes. This is done in the options file; look for options containing the word "joystick". Note that button numbering starts at 0.

Q:

Does Tux Racer work with analog joysticks?

A:

Yes, as long as it is supported by your operating system. With an analog joystick or gamepad, Tux will turn in proportion to how far you move the controller left or right.

Q:

The controls seem stuck -- Tux always turns to the right. How do I fix this?

A:

If you have a game controller connected to your computer, make sure it is properly calibrated.

If you don't have a game controller connected to your computer, make sure that your operating system doesn't think you have one connected.

Q:

Can I turn off the falling snow in the menus?

A:

Yes. The snow can be turned on and off with the Tab key.

Q:

Can I create new courses?

A:

Yes. It's actually quite easy to create new courses. All you need is a paint program (The GIMP does nicely) -- no 3D modelling required. The best way to learn is by example -- have a look in the <tuxracer-data>/courses directory.

Each course has its own directory, in which there is a course.tcl file (this is a Tcl script that loads the course). To create your own course, it's probably easiest to copy an existing course in the <tuxracer-data>/courses/contrib directory. Your course should also go in the contrib directory (that way it will be automatically added to the list of races in Practice mode).

To create your course you will need to modify the course.tcl, elev.rgb, terrain.rgb, and trees.rgb files. Here are some pointers:

• The course elevation data is specified as a heightfield using a greyscale bitmap (usually called elev.rgb). White is high, black is low.
• The terrain type is specified using another greyscale bitmap (usually called terrain.rgb). White corresponds to snow, 50% grey corresponds to rock, and black corresponds to ice. You don't have to be exact here; the closest match is used. NOTE: this bitmap must have the same dimensions as the elevation bitmap.
• Trees and other objects on the course are specified using (yet another) bitmap (usually called trees.rgb). This bitmap can have arbitrary size. Different colours correspond to different objects; we use a fixed palette to design courses.
• All bitmaps are in the SGI RGB format (which can be read and created by The GIMP), and can be compressed or uncompressed.
• Textures must have dimensions that are a power of 2.

Q:

When compiling under Linux, I get some OpenGL errors. What's going on?

A:

This could be due to several factors.

1. Make sure you're using a version of the tuxracer package > 0.60. That version had problems with some older gl.h header files; later versions implement a workaround to this problem.

2. Your OpenGL is too old. If you're using Mesa, make sure you upgrade to version 3.2 or later (version 3.3 is the most up-to-date, and seems very stable despite being a development version). Also make sure you install the libraries and header files in the locations described in the next item.

   If you get a warning about glXGetProcAddressARB being undeclared, then you need a more up-to-date version of the glx.h header file. This may indiciate that your entire OpenGL is out of date, but it's possible that all you need is a more recent version of glx.h. You can get a copy from the latest release of Mesa -- it's in the include/GL directory.

3. You have old copies of the OpenGL libraries on your system, and those are being used instead of your up-to-date copies. There is an official standard for where to put the OpenGL libraries and header files, agreed upon by all OpenGL providers for Linux (OpenGL Application Binary Interface for Linux):

   • OpenGL libraries should go in /usr/lib. This includes libGL, libGLU, and libglut.
   • OpenGL headers should go in /usr/include/GL. This includes gl.h, glu.h, glx.h, glut.h, glext.h, and possibly other files used by your OpenGL implementation.

   Tux Racer will look for OpenGL headers and libraries in those locations by default. Getting Tux Racer to compile and run with OpenGL files installed elsewhere is possible, but requires more work (you'll need to use the --with-gl* configure options).

   (Note that there is a bug in the configure script for versions <= 0.60.1 which puts -I/usr/include before the path specified with --with-gl-inc, so if you have old OpenGL headers in /usr/include/GL but wish to use other headers to compile Tux Racer, you will have to fix the configure.in script yourself or modify the Makefile manually.)

4. You have an old copy of the glext.h header file. You can get the latest version from http://oss.sgi.com/projects/ogl-sample/ABI/glext.h. It should go in /usr/include/GL.

   Note that there was a documentation bug in version 0.60 that instructed users to download glxext.h instead of glext.h. This has been corrected in version 0.60.1.

Q:

When I run Tux Racer under Linux, the program crashes when I slide over rock. Is there a fix for this?

A:

We believe that this is due to a bug in egcs-2.91.66, an "experimental" version of the gcc compiler (you can check which version you have by typing "gcc --version" at the shell prompt). There are two possible solutions:

• Upgrade gcc to version 2.95.x. (Note that the 2.96 and 2.97 releases are development versions and are not recommended.)

  OR

• Rebuild tuxracer with debugging turned on. This seems to make the problem go away.

  shell$ make distclean shell$ ./configure --enable-debug shell$ make shell$ make install

Q:

I have a 3dfx video card and am running Linux. If I compile the game with SDL, I get no hardware acceleration.

A:

According to Sam Lantinga, author of SDL:

This is caused by a conflict between the version of XVidMode that SDL is linked with and the one compiled into Glide. The latest SDL binaries (SDL 1.1.7 released today) have a hacked workaround for this problem.

Q:

When I play the game, the screen is nearly all white.

A:

This appears to be a problem with some drivers for the ATI Rage128 family of video cards. Make sure you are running the latest drivers for your card. If upgrading the drivers doesn't work or isn't possible, then you can make the game playable by disabling fog: set the disable_fog variable in the options file to true.