Glquake & QW Guide
* Yo... I thought I'd compile this little collection of tips for the glquake users out there that want to increase the game's performance, or simply want to customise it to suit their needs. I should make it clear from the start that this is not intended to be a comprehensive tweak guide, and I certainly don't claim to know everything; instead this guide includes only the information which I feel is important or interesting, after having gone through all the tweak guides and console command lists myself. I'll also include a few obscure things that are rarely or never mentioned in glquake tweak guides, so that this information compliments that which can be found in existing guides, rather than simply attempting to reproduce said guides.

I find it quite amazing, but a large percentage of quakers don't seem to bother investigating the commands and options available to customise the game... whether it just doesn't occur to them, or they couldn't be bothered, I don't know. That then is the goal of this project - to assist these 'tweak newbies' in customising the game. Ok, to be more specific, the main motivation for doing this is that I'm sick of going through the same things repeatedly with different people, as I try to help them individually. I don't mind doing that necessarily, but its very time consuming, and I decided it was time to assemble all  the information in one place, so when people ask me questions I can simply give them this single URL, and they're set.

Despite the aforementioned admission that this is by no means intended to be an exhaustive guide, I'd be happy to hear from anyone who has either corrections or additions to suggest. If you spot anything dodgy (I'm not 100 percent sure about all of this info :) then please do contact me and I'll update the page. Likewise if you feel that something important is missing, let me know.

Contents
Basic Benchmarking
Command Line Parameters
Console Commands
Idgamma
Texture Cache Mismatch Error
Resources
Basic Benchmarking
In order for you to determine how well quake is performing, and to ascertain the extent to which certain commands increase or decrease your frame rate, you'll want to use the timedemo command. It is not the ideal tool, for example timedemo does not report the all-important minimum frame rate value, however since it reports the average frame rate for the demo you specify, its a reasonably useful tool. Keep in mind though that you want to get your average frame rate as high as possible... an average frame rate of 30 is pretty useless if you were dropping below 20 at certain points in that demo. Ideally you want a very high average frame rate (60+ FPS) in an intense demo in order to ensure that your minimum frame rate is as high as possible.

To run a timedemo, go to the console and type timedemo demoname, for example:

timedemo demo2

Demo2 however is not a very good demo to use for benchmarking, as the frame rates here are significantly higher than they would be in an intense deathmatch game. Bigass1.dem is, or at least was, a popular demo for benchmarking, you can grab that one here. The game is from sCary's POV, but it seems to be a very very old demo, so don't expect to see mad skillz on display here. :)

It is important to ensure that you disable VSYNC when running timedemos (my frame rates in-game are a lot better with vsync disabled as well). If vsync is enabled then your frame rate is limited by the monitor's refresh rate, so the timedemo command will not be able to run the demo super-fast (and you'll get dodgy results).

Command Line Parameters
There are a number of command line parameters that you may find useful, some of these are glquake specific commands, while others are general commands may help you increase performance. Note that I am only including the commands which I find useful, if you need a more complete listing please visit The Console.

In order to give glquake.exe extra parameters, you will need to do one of the following:

- manually type the commands in a dos window
- create a windows shortcut to glquake and then add the commands
- create a batch file which includes the commands

Whichever method you use, command line parameters are added in this manner:

glquake.exe -width 640 -height 480

With that aside, here are the commands:

-width
Specifies the horizontal resolution. Generally used in conjunction with -height. You may only change resolution in glquake from the command line.

Example: glquake.exe -width 640

-height
Specifies the vertical resolution. Used in conjunction with -width. This is somewhat redundant, given that you can use -width only to specify the video mode if you like. However, you might as well use this for the sake of completeness, or to use non-standard resolutions on systems that support them.

Example: glquake.exe -width 640 -height 480

-conwidth
Specifies the horizontal resolution for the console and HUD. Generally used along with -conheight. This is useful if you want to change the size of the console independently of the actual screen resolution; for example if you play quake in 1024 x 768 but find the text is too small and hard to read, you could change the console width to 640 and leave the screen resolution at 1024.

Example: glquake.exe -conwidth 640

-conheight
Specifies vertical resolution for the console and HUD. Used in conjunction with -conwidth

Example: glquake.exe -conwidth 640 -conheight 480

-bpp
Sets the pixel depth mode the video adapter should switch into, bpp = bits per pixel. Additional info from the Quake Info Pool: note setting it to 24 or 32 won't actually increase the visual quality of the game, usually just slow it down, but useful for getting certain GL cards to function with GLQuake.

Example: glquake.exe -bpp 16

-heapsize
Allows you to manually assign an arbitrary amount of RAM for glquake to use. If you're as pedantic as me you'll probably want to assign a precise amount of memory to glquake, so be aware that you need to specify the amount in kilobytes rather than megabytes, ie 16384 is 16 mb and 32768 is 32 mb, etc. There really is no need to exceed 16 meg for Q1, but most of you will do it anyway simply because you can, and I approve of that. The general rule of thumb though is that you should not exceed 2/3 of your total system ram, leave plenty for windows.

Example: glquake.exe -heapsize 32768

-particles
This is a command that I have not seen mentioned in any glquake tweak guide, which is unfortunate given how useful it is. Use this command to specify the maximum number of particles to be rendered on screen at once. By 'particles' I'm referring to stuff like rocket trails, blood, the teleport effect, etc. I highly recommend that you use -particles 0 for glquake. Despite the zero, this will not eliminate all particles, which is a good thing... I still want to see the rocket trails and other effects. What it will do is set the maximum number of particles to the lowest possible value (presumably). This won't make a difference in many cases, however in big games, when there is a lot of shit going down, glquake will reduce the amount of particles being rendered, and these big games are precisely when you need that extra performance the most. This is a significant performance boost, for example on my system, a timedemo bigass1 will be literally 10 FPS faster using -particles 0. A nice performance gain with very little real difference in visual effects.

Example: glquake -particles 0

-primarysound
Forces quake to use the primary sound buffer rather than the default secondary buffer. A more thorough explanation from The Console: Normally the game will use the secondary sound buffer because it is more compatible across more hardware. If you know that your hardware is 100% DirectX DirectSound compliant you can use this setting in order to increase the performance of the game. The primary sound buffer works fine for me, I suggest that you use -primarysound and only revert to the secondary sound buffer if you experience sound problems.

Example: glquake.exe -primarysound

-nocdaudio
Disables CD audio. The performance increase is probably negligible, but every little bit counts of course. More importantly you won't cop the infamous 'cd lag' when the tracks change. If you still want to listen to a cd occasionally, just leave the windows CD player open as you play. That option is preferable because the tracks won't change when the maps change in-game.

Example: glquake.exe -nocdaudio

-noipx
Disable support for the IPX/SPX network protocol. Supposedly disabling some of these options will increase performance by a few % so it can't hurt, especially if you need extra performance. Naturally you do not want to disable this if you play quake over an IPX-based lan.

Example: glquake -noipx

-nojoy
Disables joystick support. This may seem insignificant but it removes the need for the game to constantly watch for joystick input, so it will increase performance, if only slightly.

-zone
Allows you to assign more memory for your aliases and config files, stuff like that. Generally it is not needed but if you're experiencing crashes as a result of having large config files, you can allocate more memory for these files by using -zone 512 or -zone 1024. Probably more useful for mods like the frogbot or TF, where you're using many large additional config files.

Example: glquake -zone 1024

Console Commands
The commands that follow are your common-or-garden variety console commands, these can be typed in the console or added to any config files you like. Whilst quake will remember the settings of most commands, some will always be reset when the game is run again so its a good idea to put all important commands in autoexec.cfg in your quake/id1 directory (create that file if necessary, its just a plain text file). This has the added benefit of ensuring that those settings are used for all quake executables and game mods.

The list below is a bit of a mess, the commands are not all glquake specific, and I'll throw in some quakeworld commands as well. Personally I put all this stuff in autoexec.cfg, even though the QW commands will be ignored by glquake.exe, because its just more convenient that way.

sv_aim
default: 0.93
recommended: 1

This variable controls how lenient the game is with vertical (I believe it is vertical only) aim. With the default setting, you can shoot a little off-target but the shot may still head directly for the player you were aiming at. Essentially this was originally designed to help keyboarders out a bit, but for experienced players its very annoying, especially in multiplayer. Note that this is a quake server command, the command is not applicable in quakeworld. Use it if you run quake servers or play with bots.

m_filter
default: 0
recommended: 1

Use m_filter 1 if the mouse movement seems jerky to you. This toggle will smooth out the input but it will cause a little latency between the actual movement of the mouse and the actual response in the game. If you have a serial mouse, this command is pretty much essential. Some users find that with a USB mouse or a PS2 mouse + high sampling rate with PS2rate, they can turn the filter off without noticing the jerky movement. It seems that is fine for people with low mouse sensitivity, but personally I need to use m_filter 1 even when sampling the mouse at 100 hz, otherwise the movement is noticeably jerky.

showturtle
default: 0
recommended: 1

Novelty value only. When using showturtle 1, a turtle icon will appear in the corner of the screen if the game drops below 10 FPS. I should certainly hope that none of you are dropping below 10 these days! This is really only a legacy command in my config files from when I was playing software quake on the p120. If you see the turtle at any point, its time to change your settings, or upgrade!

show_fps
default: 0
recommended: 1

This command works with quakeworld only, which is to say qwcl.exe and glqwcl.exe, not standard quake. Displays the current frame rate in the lower right of the screen.

+speed
Same as holding down the run key. You'd think that this would be redundant given that the 'always run' option exists, however some people claim that you get slightly more acceleration off the mark if you turn 'always run' off and use +speed in your config instead. Given the number of quirks in the Q1 physics I'd not be surprised at all if this was true.

+mlook
Permanently enables mouse look. Obviously everyone should have this on. If you're still using the keyboard only... don't. The mouse is your friend. Embrace it. Accept it.

sensitivity
default: 3
recommended: err.. whatever you like, experiment

This variable controls the mouse sensitivity. The importance of this variable should be self-evident, but just in case it is not, I'll make it clear... this is a very important variable. You really need to experiment with this and find the value which is most suitable for you and your system. Actual sensitivity will vary depending on many factors, however a good rule of thumb is to ensure that you can comfortably turn 180 degrees quickly. Other than that, it really doesn't matter what you use provided you're comfortable with it.

r_dynamic
default: 1
recommended: 1

Toggles the rendering of dynamic lighting. Dynamic lighting (eg from rocket fire and explosions) is nice, however it is also one thing which significantly slows down most hardware. You will have to choose whether or not to use dynamic lighting based on your preferences and your hardware. If you have powerful hardware, you can get away with leaving it on, but if you don't have a beastly PC, chances are you'll need to disable this using r_dynamic 0 or the game will be very slow when there is a lot of action. It can be a tough call though; apart from being attractive, dynamic lighting can also be important in games - you might want to light up a dark area with weapons fire so you can see better, for example... also the glow around player using the quad/pent will be missing when you turn dynamic light off, leaving the sound cue only as a warning.

I generally leave dynamic light on, but occasionally I turn it off during big games in order to get a bit more performance. Note that if you turn dynamic light off in the middle of a game, chances are that you will see some weird visual effects because all the dynamic light being displayed at the instant you turned it off will be permanently visible, so it is better to turn if off in between level changes, or reconnect to the server. Also note that dynamic light will be automatically disabled if you use gl_flashblend 1.

gl_flashblend
default: 1
recommended: 0

By default glquake will draw a ball of light around all dynamic light sources, including weapons fire, rather than using the proper lighting method. Note that dynamic light is disabled when you use flashblend 1 and this ball/glow effect replaces the dynamic light. This method is significantly faster but it looks pretty crap in my opinion... gl_flashblend 0 will use the proper lighting model, just like in software quake. The one nice thing about using gl_flashblend 1 is that it creates the coloured glow around the quad and pent powerups.

There is a good reason for flashblend 1 being the default though - dynamic light is a real performance killer, especially on lower end hardware like the voodoo1 (which was the only decent 3d card around when glquake was released). Thus unless you have a high end machine, you may find that the game slows down too much when you have flasblend set to 0 and dynamic light on. If this is the case, you might want to try using the default 1 (some people probably prefer this method anyway). If you really want that extra speed, I'd say you would be better off using r_dynamic 0 and gl_flashblend 0 so that you get the speed boost without the absurd light ball. As with most of these commands though, you should experiment and find the best settings to suit your hardware and preferences.

gl_polyblend
default: 1
recommended: 1

Toggles the use of palette shifting. This variable controls whether or not your view will be tinted another colour when you are underwater, taking damage, or when you have powerups etc. Some players like to disable this using gl_polyblend 0 so that they can see better, but be aware that it'll be harder to tell when you're being hit, because your screen will not turn red. I prefer to leave it on the default 1.

gl_subdivide_size
default: 128
recommended: 1024

The value used to divide the sky into individual brushes. Glquake handles the sky very poorly, it basically has to chop the sky brushes up into smaller pieces. Lower values used here will mean the sky is chopped into more pieces, which may look better but it will also run slower, because the game is rendering more polygons. I recommend using a very high number like 1024. This looks like shit, but I figure the glquake sky looks like shit anyway so I might as well get the best performance rather than looks, in this case. This 'chop' variable will also affect animated teleport textures, and possibly liquids.

gl_playermip
default: 0
recommended: 2

This controls the level of detail of player skins (deathmatch opponents only, this does not affect monster skins in single player). The default 0 is the most detailed, the other valid values are 1, 2, and 3 which are progressively less detailed and distinctly blurry. 2 is a good setting for cards with limited texture memory (like the voodoo1) or in large games where there are many player skins present. Personally I use 2 for two reasons... it is slightly faster than 0 (about 5 fps in some timedemos) and also for some reason the player models stand out more when using 2. I think its because the player models are blurry with this setting, whereas the game textures are sharp, and that contrast allows me to see my opponents better. Note that if you change this variable it will not take effect until either you reload a map or the player changes his colours (in glquake), although in glqwcl you may type 'skins' in the console and the changes will take effect.

gl_ztrick
default: 1
recommended: 1

From the glqwcl readme: Glquake uses a buffering method that avoids clearing the Z buffer, but some hardware platforms don't like it. If the status bar and console are flashing every other frame, clear this variable. The default setting of 1 is the fastest, and thus you should leave this alone unless you are experiencing the aforementioned flashing effect. If so, use 0.

gl_keeptjunctions
default: 0
recommended: 1

From the glqwcl readme: If you clear this, glqwcl will remove colinear vertexes when it reloads the level. This can give a few percent speedup, but it can leave a couple stray blinking pixels on the screen. Take it from me, using the default setting of 0 will leave a couple of stray blinking pixels on screen. These pixels are very distracting and make the world appear a lot less solid... you'll often see them along the seams of certain brushes. For this reason, it is recommended that you always use gl_keeptjunctions 1 unless you're desperate for extra performance.

scr_conspeed
default: 300
recommended: 1000 or higher

The speed at which the console lowers itself. The default 300 seems dreadfully slow and I certainly don't want to wait for the console to drop so I can type commands, so I set it to 1000. You might want to go even higher in order to force the console to appear instantaneously.

pushlatency
default: -999
recommended: -999

Controls the amount of client-side movement prediction. The default in newer versions of quakeworld is -999 and I recommend all users leave this variable as-is, because -999 will give instant response to movement controls, regardless of what ping you have. In earlier versions of the quakeworld client, using too high a value for pushlatency was problematic because you'd get some prediction errors, however now that the client is much more robust, you will only experience prediction errors if you have extreme lag and/or packet loss, so it is safe to use a high value.

rate
default: 2500
recommended: dependant upon connection

The rate at which the server sends you information. Aside from pushlatency, this is the most important quakeworld client command. The default value of 2500 is for 28.8k modems and is therefore far too low for anyone with a superior connection. The general rule of thumb for rate is this: go as high as you can go until you experience uremoves or extra packet loss, then bring it back down a bit. You should be able to get away with 3200 and higher on a 33.6k connection, use your common sense to find a suitable rate for your connection.

Your frame rate is directly tied to the rate at which you receive packets from the server, which is why you want to go as high as possible. At rate 2500 you'll be getting about 30-32 fps max, which is less than ideal, if only because certain jumps and rocket jumps will be impossible with this frame rate. 3200 will give you about 40 fps max. The higher your rate, the higher your maximum frame rate will be and the smoother the game will feel.

noaim
default: 0
recommended: 1

This variable controls client-side auto-aiming in quakeworld. Similar to the sv_aim command listed above, however this variable can be adjusted by clients independent of the server. The default noaim 0 is equivalent to sv_aim 0.93, in other words it is bloody annoying, so proper players should all use noaim 1 to turn off auto-aim.

noskins
default: 0
recommended: 2

This determines whether or not player skins are downloaded and displayed in quakeworld. The default 0 will download all new skins where possible, and display skins in game. Noskins 1 will disable skins completely, no custom skins will be downloaded or displayed. Noskins 2 will display player skins (if you have the image files) but it will not download new skins, so you won't be waiting to connect to a server while you download skins.

Idgamma
Using idgamma to create a modified palette is pretty much essential in my opinion. This is totally unrelated to performance, but given that you can make glquake look twice as good as it does by default, its certainly worth a mention here.

Glquake looks like shit. I know a few of you may argue here, but really, lets face it - it looks terrible, especially on nvidia cards. Its not too bad on a 3dfx board... the colours are washed out though. On a TNT2 its disgraceful; way too dark and murky. Idgamma allows you to modify the quake palette to suit your own tastes and hardware setup, with surprising results. Most people initially get idgamma so that they can adjust the quake gamma (as we know the in-game gamma command is broken in glquake). However, as far as I'm concerned this is a secondary benefit, I've never had a problem with gamma myself - gamma 1 is fine by me. The main reason I use an idgamma created palette is because I can modify it so that the image displayed features brighter, more vivid colours, and is somehow much clearer and sharper than with the default palette - not at all murky as it was originally. If you're still unconvinced, here's two comparison screenshots... a before and after type deal.

No doubt you'll agree that the second image is much nicer. Those images are not edited by the way, they are raw .tga screen dumps converted to .jpg with acdsee, no post-processing.

You can download idgamma here, and play around with it to find the settings you prefer. I recommend the following settings, these work great for me and for the vast majority of people:

Intensity 2
Gamma 1
Saturation Level 1
Fullbright Intensity 1.5


Alternatively, you can simply download this pak2.pak file and place it in your id1 directory (rename it to pak3.pak or whatever if you already have a pak2.pak, just make sure you keep them sequential). This pak file contains a palette file created with the above parameters. All you have to do to test it out is delete all instances of 15to8.pal (these files reside in your glquake directories, for example quake\id1\glquake, quake\qw\glquake, etc). It is important to remember that any time you modify the palette you must delete that 15to8.pal file and allow glquake to re-create it based on the settings contained in the new palette file. Don't worry though, you won't hurt quake, and if at any time you want to revert to the default quake palette, you only need to move or rename the pak2.pak file (and delete the 15to8.pal files).

Texture Cache Mismatch Error
Glquake doesn't re-load all level textures when a map loads, it re-uses any textures that it thinks are already in the texture cache. This is all fine and dandy in theory, but in practice not every texture has a unique name - often people give textures the same name as an existing texture, and that's where we start to have problems.

One of two things can happen when glquake tries to re-use different textures with identical names. If the texture size is identical, then glquake will simply display the wrong texture in one of the levels... it may be unsightly but its a minor problem. The major problem, the dreaded texture cache mismatch error, is where you have two different textures with identical names, but different dimensions. If you load these two clashing levels in the same session, glquake will crash. One of the classic examples is dm4 and dakyne... if you load levels with these two clashing textures in the one glquake session, the game will crash. The order you load the maps in is irrelevant.

Unfortunately, there is no easy solution. Or rather, there is a simple solution which is impossible to implement since QW 2.3 introduced the sv_mapcheck variable. All you have to do is open up the .bsp files in a program like adquedit and rename one of the offending textures... problem solved. Unfortunately changing the bsp file in this way will cause it to fail the CRC check if you're playing on servers with sv_mapcheck 1, so you'll get kicked from the server for having modified files. Of course, you can still use this fix if you only play on normal quake servers, or if you play on servers that turn map checking off. Unfortunately most servers do have map checking on, if only because it is the default.

A less palatable but nonetheless viable option is to simply avoid loading levels with clashing texture names. A couple of common ones are dm4 + dakyne, or efdm7 + ultrav... if you remove one of the offending levels, you'll never encounter the problem. If you are a server admin you can remove one of the levels from the rotation, or if you're playing lan/bots, simply don't load one of the levels. As an average user playing online though, there is unfortunately nothing (that I know of) that can prevent you from copping this error. If you're playing on a server which has a dud combination of maps, the only thing you can do to prevent crashing is to quit the glquakeworld client and reconnect to the server before the problem map loads. If possible, ask your server admins to remove one of the problem maps.

Resources
http://www.quakeworld.net/ - go here to download glquake and quakeworld
http://rockape.qgl.org/glquake.zip - glquake.exe 0.98 beta (adjustable FOV)
http://www.d128.com/idgamma/ - Idgamma homepage
http://www.inside3d.com/qip/ - console & bug information
http://www.planetquake.com/console/ - comprehensive list of console commands and variables
http://www.voodooextreme.com/3Fingers/stuff/quake.htm - 3 Fingers' ultimate glquake tweak guide
http://www.nvidia.com/ - grab the detonator reference drivers for nvidia cards here
http://www.3dfx.com/ - the place to get reference drivers for 3dfx boards
http://www.reactorcritical.com/ - go here for the latest leaked beta drivers for your card
http://www.tweak3d.net/ - look for tweak guides for your 3d card
http://www.students.tut.fi/~zibbo/other/ps2rate/ps2rate.zip - ps2rate
ftp://ftp.cdrom.com/pub/idgames2/utils/graphics_edit/resource_browsers/adquedit_v13.zip - adquedit
http://www.planetquake.com/frib/misc/Bigass1.zip - bigass1 demo for benchmarking