Increasing FPS Through CVAR Tweaks

Gaming is all about removing hardware limitations and imperfections from the experience as much as possible. Nothing is worse than losing a round of TS because your FPS crapped out, or failing to return a flag because you couldn’t track the enemy with 26 FPS. This guide will show you how to squeeze more frames per second out of your existing computer, no upgrade needed!

Introduction

I will be examining how various graphical configurations affect framerate on my old computer which was purchased in November 2003. I replaced it over a year and a half ago, but I still keep it around precisely for stuff like this. Pretty much any computer built for $500-700 USD in the past 2-3 years will outperform it with ease. However, prebuilt machines from large manufacturers like Dell or HP often will have proprietary components or just plain wacky configurations which cause them to perform much poorer than their price suggests. If you’re in the old PC or lowend prebuilt boat, this guide should help you improve your gaming experience. I will provide a list of cvars which have an effect on framerate, as well as an already completed graphics config file which you can load from the console.

I may as well spoil it right now, and tell you that there is practically no difference between a high quality configuration and a quickly done low quality configuration. The only noticeable difference (and it’s significant) can be obtained by turning down/off a lot of hidden options through cvars. You can skip the whole article and go straight to the bottom if you just want the config file. The next three sections may be boring/too technical/both.

Urban Terror Graphics

Urban Terror, especially at low resolutions (1024×768 and under), is an example of a CPU bound game. That is, on your average system, in the average in game situation, the CPU will be the limiting factor in getting a higher framerate. The CPU is unable to render its portion of the work any faster, while the GPU (graphics processing unit; found on your video card) can perform all its tasks as fast as the CPU, and then some. In other words, the GPU is waiting for the CPU. This is because Urban Terror’s graphics are quite easy to render in comparison to the physics, player positions, sound, network data, etc. However, this may not always be the case. Many computers, mostly lowend prebuilts, have very weak graphics cards as they are intended for office work. Look at any big box store and you will find quad core CPUs alongside onboard graphics. What is being rendered at a particular moment is, however, the decisive element in determining what component is being “bottlenecked.” A high number of player models on screen, a wide open area on a detailed map, smoke grenades, and a large number of objects (shells, boxes, dropped guns, flags, etc.) on screen, all have a very significant impact on the graphics cards’ ability to render the scene quickly. Conversely, sitting in an enclosed area with few props and no other players on screen will result in the graphics card barely breaking a sweat, while the CPU is still working hard to calculate unseen players’ positions, crunch network data, render sound, etc.

Urban Terror has a hard cap of 125 fps, though the cap can be set lower. Your framerate will not exceed 125 fps. This is due to how the Quake III Engine’s netcode works – it is tied directly to client framerate. The goal of any player should be to get their framerate as STEADY as possible. Reaching 125 fps is all well and good, but it is detrimental to gameplay if as soon as an enemy comes on screen, the framerate plummets to 60. Although a constant framerate of 60 fps might be very playable, the DROP from 125 to 60 fps is extremely noticeable and will make it hard to play, as changes in framerate affect how smoothly the game is seen, aiming, movement (there will be a noticeable delay in input response time if you have FPS drops), and even ping. You have to therefore consider not just maximum frame rate, but minimum frame rate as well. This is what you want to bring up. The difference in an intense firefight between 20 fps and 45 fps is huge, especially if that means a drop of only 15 fps (60 capped dropping to 45) as opposed to 60 fps (uncapped, but running at 80, dropping to 20).

Benchmarks – Hardware Discussion

I will benchmark various configurations and record the results in a chart. The test system will be an Athlon XP 2500+ (Barton core) @ 1.83 ghz (stock speed), 1024 MB DDR333, and an ATI 9600XT 256MB graphics card. For a second set of benchmark runs, the FSB will be underclocked from 166 mhz to 100mhz, resulting in an effective 1.1 ghz for the CPU, and the RAM running at DDR200 rates. A 1.1 ghz Athlon XP would be roughly equivalent to a “1200+” performance rating, when considering the Barton’s 512 kb of L2 cache. A final, third run will be done at 2.2 ghz, equivalent to a 3200+ performance rating. A 3200+ Athlon XP performs on par with a 2.8 ghz Pentium 4.

Benchmarks – Methodology

I am testing 5 graphics configurations.

800×600 stock is simply the default configuration generated by Urban Terror if no configuration file is present. 800×600 is the default resolution.
1024×768 stock is the same configuration, except with the resolution bumped up to 1024×768.
800×600 low is the stock config, but with all the applicable options in the “graphics” tab under the Setup button at the main menu set to their lowest quality setting.
1024×768 high uses Nexu’s movie config file, which is tuned for optimal visual quality.
640×480 very low is a config file I made and turned every visual option to its lowest quality (best performance) setting (generally this means disabled:P). In addition, sound options were set to low quality. On a system with a dedicated sound card, sound quality level will not impact framerate. However, most people have onboard sound, which means the CPU does most of the sound processing work.

I tested each configuration using /timedemo 1 and then replaying a demo of a 6v6 match on Algiers CTF. The demo is approximately 35 minutes long. It contains many firefights, as that is the nature of Algiers, especially against a strong opponent. Smoke grenades are used for approximately one minute. Timedemo records the average framerate of a demo that is played back. Unfortunately minimum FPS is not displayed, but that doesn’t mean we can’t make educated guesses.:) I reloaded Urban Terror between each run. I also deleted all the configuration files in the q3ut4 directory, to allow Urban Terror to regenerate them each run. When a premade config was used, I named it autoexec.cfg, which forces Urban Terror to load cvars from it first, before relying on automatically generated values from q3config.cfg (which are used if a cvar is not present in the autoexec file). A clean install of XP SP3 was installed before testing began.

Benchmarks – Results

Not much difference between the 1024×768 high quality config, and 800×600 with all graphics menu options turned down. In fact it’s a difference of only 7 fps. That’s only 10% worse FPS running with high quality textures and mipmapping (mipmapping determines when a low quality distance texture is swapped for a high quality up close texture; a low quality mipmap setting swaps the textures more abruptly and at closer distances). The difference between 1024×768 stock and 800×600 stock (besides 306,432 pixels less being rendered each frame) is 0.4 fps. However, my special ultra-low quality configuration yielded an astonishing 91.6 fps. That’s almost 20 more fps than the stock configuration! This difference will be seen the most in graphically intense situations, as it is obvious from the other 4 tests that Urban Terror on an Athlon XP 2500+ and 9600XT is CPU bound most of the time. By dropping the graphics quality to extremely low levels, those situations where the graphics card is the bottleneck, become fewer and less intense. It’s better to have a CPU bound game, as in Urban Terror, the CPU’s work load is nearly constant.

The same results are present with only 1100 mhz. Although even the ultra low quality config can’t squeeze an average of 60 fps out of the system, 56.4 fps is better than the 45 fps achieved by the bottom 3 configurations (the high quality config pulling in ~10% less at 40.6 fps). 11 fps may not seem like much, but like I said at the beginning, getting those minimum FPS values up is what we’re after. Most certainly firefights where the FPS was dropping to less than 20 fps, were running at 30-40 fps with the low quality config.

Well, we almost hit 125 fps. The low quality config managed 114.6 FPS average, which means that in many situations, it was running at 125 fps. Intense scenes likely ran around 70-80 FPS. I shelved the 800×600 “low” run, as it was pointless. Instead I did a 1280×1024 run with stock settings…and got the same FPS as 1024×768 stock. That’s great news, as UrT can be run at a 19” LCD’s native resolution at the same speed as 1024×768. Of course to almost completely eliminate the GPU as a bottleneck, you still need to run at super low settings. This 3^rd run is conclusive evidence that UrT is mostly CPU bound, at least on this system. The difference between 1100 mhz and 2200 mhz is literally 100%. And when the CPU is overclocked by ~20%, the results go up around 20%.

CVAR Listening and Breakdown

I’ll list every cvar I changed for my “ultra low” config, write a brief bit of text about it, and give it a rating with regard to how important it is to gameplay (0-5). I am leaving out commands which are by default set to the lowest quality setting and can’t be changed via the menu, since it’s pretty much impossible to change them during routine tweaking. If someone asks me to, though, I’ll make a list of every graphical command that can be changed and try to explain them. I’m also leaving out cvars which are locked by the engine (such as r_vertexlighting). Let’s start with the r_ (renderer) cvars.

r_picmip
Range: 0-2
Default: 1
Recommended: 2

This IS the texture quality cvar. Higher values render blurrier textures. 0 corresponds to High in the menu, 1 to Normal, and 2 to Low. There is a “very low” (3) option in the menu, but this does not work in game, and will be set to the default of 1 if you use it.

Importance: 0 – in fact, many good players will set this to a low value because blurrier textures enhance player model visibility.

r_texturemode
Accepted values: GL_NEAREST, GL_NEAREST_MIPMAP_NEAREST, GL_LINEAR_MIPMAP_NEAREST, GL_NEAREST_MIPMAP_LINEAR, GL_LINEAR_MIPMAP_LINEAR
Default: GL_LINEAR_MIPMAP_NEAREST
Recommended: Maximum FPS, gl_nearest. Otherwise stick to default.

If you’re scratching your head over the values, you’re not alone. gl_linear_mipmap_linear is the best quality, if your video card supports trilinear filtering (it does). gl_nearest is extremely bad quality (so bad in fact the textures are always pixilated and blocky regardless of how close you are) and creates noticeable shimmering and flickering as you get closer to a texture, but I think it’s one of the biggest FPS boosters in my low quality config. gl_nearest_mipmap_nearest is slightly better looking than gl_nearest, but not enough to improve the flickering. So if you want maximum FPS, go for gl_nearest.

Importance: 4 – the low quality ones are headache inducing. I am one of those people who make their graphics ugly in order to increase visibility, but this is just too far. I would only use this if you are in dire need of more frames per second.

r_ext_max_anisotropy
Accepted values: 0-16?
Default: 2
Recommended: 0

To be honest, I’m not sure if this actually matters, as r_ext_texture_filter_anisotropic would logically need to be set to 1 for anisotropy to be active, and it’s by default 0. Most people force anisotropy on via their graphics card’s control panel anyway, if they want to use anisotropic filtering (anisotropic filtering works in conjunction with mipmapping, and causes high quality textures to be used out to an even farther distance). Regardless, there’s no point having this at 2, just in case. Anisotropic filtering is a huge performance hog, especially on low end/older graphics cards.

Importance: 0 – there’s almost no visual difference between even 16x AF and AF disabled, so why take a possible performance hit?

r_ext_multitexture
Accepted values: 0/1
Default: 1
Recommended: 0

Multitexturing makes textures look better at a performance hit for old cards, so why on earth would we leave it on?!

Importance: 0

com_blood
Accepted values: 0/1
Default: 1
Recommended: 1

Although blood can hurt your FPS, especially in a big firefight, blood trails are just too much of a tactical advantage. Well, not if you’re playing TDM. If you play mostly TS and CTF, leave blood on. Otherwise you can turn it off and you probably won’t play any worse.

Importance: 5 – for TS and CTF.
1 – for TDM and FFA

r_stencilbits
Accepted values: 0/8/16
Default: 8
Recommended: 0

This controls the hardware stencil buffer. A stencil buffer can be used to make higher quality shadows and reflections. Shadows already look terrible in Urban Terror, so obviously this doesn’t do a whole lot. Some old video cards don’t even have a stencil buffer, necessitating this be set to “0” in some cases.

Importance: 0

r_roundImagesDown
Accepted values: 0-???
Default: 1
Recommended: 2

I’m not completely sure this even does anything, but you can change the value, and the value will stick (unlike some other commands where the cvar isn’t locked, but the value you set won’t stick). I notice no visual difference between 1 and 4. May as well be safe, I guess.

Importance: 0 – I don’t believe this actually works, so play it safe and set it to 2.

r_detailtextures
Accepted values: 0/1
Default: 1
Recommended: 0

No visual quality difference, again. May as well set it to 0, just in case.

Importance: 0

r_ext_compressed_textures
Accepted values: 0/1
Default: 0
Recommended: 1

Compresses textures, which alleviates bus congestion between the motherboard and the graphics card. In reality, no card will saturate its bus, as the video card industry moved to PCI-e 16x before cards could overwhelm the AGP 8x bus. It may have other effects, though, so set it to 1. There is no visual quality loss.

Importance: 0

r_texturebits
Accepted values: 0/16/32
Default: 32
Recommended: 16

Setting this to 0 will use your desktop’s color depth setting, which is most likely at 32 bit. I believe a 24 bit desktop setting will be interpreted as a 16 bit setting, as Quake III does not support 24 bit color. Don’t leave it up to chance, though – set this to 16.

Importance: 0

r_colorbits
Accepted values: 0/16/32
Default: 32
Recommended: 16

Same as above.

r_mode
Accepted values: 3-9, -1
Default: 4
Recommended: depends

This is the resolution. 3 is 640×480, 4 is 800×600, 5 and 6 are 1024×768, and 8 is 1280×1024. There are more preset resolutions, but those are the most common. -1 allows for a custom resolution using r_customheight and r_customwidth. If you are running a CRT (tube) monitor, you can use any resolution the monitor supports. LCD monitors, however, only look best at their maximum (native) resolution. Lower resolutions on an LCD will be interpolated, and look blurry and boxy. If you are going to use an LCD at a non-native resolution, at least make sure you keep the resolution in proportion to the native resolution. For example, a 19” non-widescreen monitor has a native resolution of 1280×1024. An acceptable non-native resolution, quality-wise, might be 800×640, as both are 62.5% of the native width and height, respectively. Another solution is to use windowed mode (r_fullscreen 0), which allows lower resolutions to be run on an LCD without interpolation. The tradeoff is that the image will not will the screen, and will instead be confined to a small window. This is mostly important for those with weak graphics cards, as my tests revealed resolution has practically no effect on frame rate with the 9600XT.

Importance: 3 – A blocky, interpolated resolution can make it hard to see the action. It’s not too bad, but it’s still worse than the native resolution. If you have a CRT, it doesn’t matter at all as long as you use a 4:3 resolution (take the first number and divide it by the second; if you get 1.3333… you have a 4:3 resolution) for a standard CRT, and a 16:9 resolution for a widescreen CRT (they’re very rare). Lower resolutions on a CRT also allow for a higher refresh rate to be run, reducing eye strain.

r_displayrefresh
Accepted values: 60-85
Default: 60
Recommended: 70-75

This setting is ONLY for CRT users. Refresh rate does not apply to LCD or plasma displays. Everything that proceeds in this paragraph is irrelevant for LCD/plasma displays. The refresh rate for a CRT is how many times per second the screen is redrawn. This is independent on the framerate of the game, as the video card’s RAMDAC is designed to take any framerate and output it at the refresh rate the monitor/software is asking for. However, you can “see” more frames per second with a higher refresh rate. It’s debatable whether you can actually tell the difference between 60 hz and 75 hz (or “fps”) on a monitor, as human eyes don’t work in FPS. The goal of FPS tweaking is to make the game run smoother with regards to enemies not warping around, and having control inputs respond consistently. Anyway, the refresh rate should be around 70-75 hz, as that’s when the flicker disappears for most lighting environments and for most people. In a dark room, you can get away with a lower refresh rate and not see flicker. Most people will see very minimal flicker at 75 hz, and few people can see flicker at 85 hz looking straight on at the monitor. Your peripheral vision has a higher flicker threshold, so if you look at your monitor from the corner of your eye, it might flicker even though it doesn’t when you look straight at it. Higher refresh rates (85hz+) degrade image quality slightly, and besides, many monitors can only run fast refresh rates (75 hz+) at lower resolutions. Few monitors can do over 60 hz at their maximum resolution; that’s the difference between premium monitors like the Sony Trinitrons, and regular CRTs. Make sure the value you set here is supported by your monitor at the resolution you are using!

Importance: 0 – higher refresh rate reduces headache, but won’t really help your game play (besides making it easier to focus on the screen). But it won’t hurt your gameplay in the least. LCD users will not benefit from this setting at all.

cg_sfxMuzzleFlash
Accepted values: 1
Default: 1
Recommended: 1

This is the muzzle flash from guns. The big bright flash when you shoot. It’s really annoying, but there’s a reason many people leave it on – muzzle flashes from other players’ guns are useful. I really don’t think this has any noticeable impact on FPS since most cards handle one or two extra static lights just fine.

Importance: 4 – useful in many situations where you can’t see any enemy but you’ll see the flash of light when they shoot. It’s also very useful when shooting at people through smoke without night vision, as you can still see muzzle flashes.

cg_brassTime / cg_sfxbrasstime
Accepted values: 0-20000
Default: 5000
Recommended: 0

Time in ms for shell casing to stay on the ground. Utterly worthless for gameplay as you can’t even see them at a distance, but they’ll be rendered anyway. Not sure which cvar is active, so set ‘em both to 0.

Importance: 0 – nobody has ever made a kill based off shell casings giving away a position.

g_removeBodyTime
Accepted values: 0-???
Default: 300
Recommended: 300

Just thought I’d put this in here. This does NOTHING, as bodies stay as long as someone is dead, and disappear when they respawn. Unfortunate, as all those corpses have the same number of polygons as a living player. But they’ll be gone quickly anyway.

cg_gunsize
Accepted values: 0/1
Default: 0
Recommended: 1

Smaller gun = less polygons to render. Plus the big gun blocks a ton of screen.

Importance: 0 – in fact it should be -5, as having the big gun is a disadvantage both FPS and gameplay-wise.

cg_drawHands
Accepted values: 0/1
Default: 1
Recommended: 1, unless your FPS is really bad

This controls whether the gun is drawn or not. Obviously no gun means a lot less polygons being rendered, meaning more FPS! However, many players find it difficult to play without the gun being drawn. If you’re one of those players, there’s no point making the game less laggy if you can’t play when you’re all through!

Important: 4 – if you play better with the gun drawn, leave this at 1. Otherwise you can gain a bit of FPS by disabling it.

cg_sfxSurfaceImpacts
Accepted values: 0/1
Default: 1
Recommended: 0

Draws smoke on bullet impacts. This also controls the rendering of sparks when hitting a helmet, as well as the majority of the blood spray from a bullet impact on exposed flesh. If you rely on these effects to know when you hit someone, I recommend leaving this value at 1. If, however, you rely on another method of feedback, you should disable this cvar as it it quite a graphically-intensive process to render smoke.

Importance: 3 – but it depends if you even notice the blood spray and sparks when you hit another player.

cg_sfxParticles
Accepted values: 0/1
Default: 1
Recommended: 0

Draws sparks in addition to smoke on bullet impacts. Again, useless.

Importance: 0

cg_sfxShowDamage
Accepted values: 0/1
Default: 1
Recommended: 0

When players get shot, their skin changes to reflect the damage they received. No point loading even more textures! I personally never pay attention to the damage skins (as they’re called), as it takes too long to look at someone and decide how many times I need to shoot them. Just shoot until it’s dead.

Importance: 0

cg_visiblebleeding
Accepted values: 0/1
Default: 1
Recommended: 0

Even more useless than the above. Makes people visibly bleed when they’re shot. This has even less use than damage skins, if possible. This does not affect blood trails. Blood is one of the biggest hits to FPS, and it’s even worse in a big firefight.

Importance: 0

s_loadas8bit
Accepted values: 0/1
Default: 0
Recommended: 1

If you have onboard sound, 8 bit sound files can give a bit of FPS boost as the CPU has an easier time rendering lower bitrate files. It might sound noticeably worse, but sound in UrT isn’t very good to begin with.

Importance: 2 – only applies with onboard sound, and even then some might rather the default 16 bit sound files.

s_khz
Accepted values: 11/22
Default: 22
Recommended: 11

Lower quality sound as less of the spectrum is processed. Again, only applies for onboard sound, as a sound card is more than capable of running with all of Urban Terror’s sound quality options maxed.

Importance: 2

Finally:
If you change a /r_ setting and it says the setting will not be applied until you restart, do /vid_restart. You can enter a bunch of commands and then do one vid_restart to save time.
If you change a /s_ setting and it says the same thing, do /snd_restart.
It is, however, much easier to edit your configuration file directly. Go to your Urban Terror directory. Go to q3ut4 folder. Copy and paste “q3config.” Rename it to autoexec (autoexec.cfg if extensions are visible). Open it with Wordpad and search for the variables you want to edit. Save when you’re done. Next time you load Urban Terror, the settings will automatically be applied!

Conclusion

Another long article! I hope this will help you tweak your Urban Terror for maximum efficiency. UrT scales extremely well with CPU speed according to my results. I expect if I could overclock further, I’d see even better performance. Unfortunately Athlon XPs don’t overclock very well; once you have to start adding vCORE, they’re running out of steam, and I had to increase core voltage by 0.1 volts. And I don’t really have a good way to cool the CPU either, though I accidentally did all the stock and underclocked runs with the fan unplugged, and never had stability issues. Anyway, it becomes less and less of an issue as Urban Terror becomes older and older. Systems that can run the game smoothly with maximum detail can be had for less than $700 USD. I don’t want to offer upgrade advice, as this article is already way too long, but you can find out which part is slowing your frame rates down with a simple test. Record a demo on a decently crowded server (12-18 people). Run it with /timedemo 1. On the first run set your graphics to low quality settings (low resolution, low detail, etc.). On the second run, set everything as high as you can. If the frame rate does not drop much on the second run, your CPU is the bottleneck. But as I demonstrated in this guy, you can gain as much as 25 FPS over a “low quality” configuration by going beyond the graphics menu.

Here is the completed configuration file.

http://www.getlegitanddip.com/dailynade/lowgfx.cfg

Instructions are inside; open with Notepad or a similar text editor.

Here is a graphics card hierarchy which shows which cards are roughly equal in performance to each other:

http://www.tomshardware.com/reviews/best-graphics-card,2362-6.html

Newer isn’t always faster. The 9600XT is near the bottom middle, though it IS 6 years old!

Related posts:

1. A Comprehensive HUD Tweaking Guide The heads up display (HUD) encompasses all the elements you see clustered around your screen: the minimap, chat, the crosshair, and even the gun. All these elements can be controlled through the console (default key: ~ ), using what are known as “cvars,” or console variables. Let's see how you can get the most out of your hud!...
2. Urban Terror Aim Settings Basics This is a long awaited post. There are a few variables that you can use to improve your mouse precision besides sensitivity. These variables can really help, in conjuntion with a good mouse to improve your aim skills. Today we are going to take a look just at the basics, since the topic is really [...]...
3. Solve Urban Terror Graphic Problems with Affinity PreviousN writes: …about a year and a half ago I built what I thought would be a rockin’ computer. I was an early adopter of the AMD Phenom 9500 (I didn’t know about the memory hole prior to purchasing- OUCH!), a Geforce 8800gs (which overclocks like crazy), 4GB of RAM, and some speedy disk [...]...