See also: Tweak

There are many video options you can customize to adapt to your system performances and to your personal flavour. They can affect 3D world rendering or your HUD (head-up-display).
Many of them are in these menus:

• Setup --> System --> Graphics
• Setup --> System --> Display
• Setup --> Game options

And some may be available only via command console. You can restart video system using \vid_restart command (but many options do not need to do this to have effect).

Writing a variable name without setting its value will return the present value, and often also its "default" value. Warning: you should check default values after starting a match... if you check them from main menu, before entering a match, previous value stored in your config file may be erroneusly indicated as "default" one.

For some infos about compatibility with some GPUs, you may take a look to the VidCompat page. For some "developer" tricks to keep graphic compatibility with specifc (mostly, very old) hardware, you may take a look to VidWorkarounds page.

ResolutionEdit

Go to "Graphics" options menu and first select your monitor aspect ratio (4:3 is classic, but nowadays many monitors are "wide", 16:9 or 16:10), then your resolution and then click "accept" to submit changes (if you exit with "escape" key, there will be no change). Higher resolution gives better image quality, but this has a big impact on performances. Do some attempts to find the best resolution according to your monitor size and your system's "power". For example, you could enable \cg_drawfps 1 then begin from 640x480 or from 800x600 and then increment resolution, checking your frames-per-second at each try (remember that fps change from various factors, like how many players are there and what are you watching, for example, if you watch the ground directly under your feet you will have higher fps). Notice that at higher resolutions, text in command console will appear smaller.

You can set your resolution by commands, this will give you more possibilities :

• r_mode <-1, 0, 1, 2, 3, 4, etc...> : resolution of the screen : -1=custom (see r_custom*) ; 0=340x280 ; 1=420x340 ; 2=530x420 ; 3=640x480 ; 4=800x600 ; 5=1024x768 ; etc... type \modelist to see the remaining codes.
• r_customaspect <0 or 1> : enables custom aspect of the screen, with r_mode -1
• r_customheight : custom screen height pixels with r_mode -1 (useful for widescreens)
• r_customwidth : custom screen width pixels with r_mode -1 (useful for widescreens)

View sizeEdit

Usually, the game world takes all your screen, with the HUD drawn in front of it. However, it is possible to draw the 3d world in a smaller "window"; this would allow to write part of HUD infos (most notably, health/armor values and chat messsages) outside that part of the screen, in front of a plain grey background, if you like it. It may also allow your system to gain some more frames-per-second (but also may not!).

This is controlled by /cg_viewsize <number>. 30 is the lowest value allowed, and 100 is the maximum value allowed. Default value is 100.

Alternatively, you can also change "view size" 10 by 10, making it smaller with the /sizedown command (enter the command again to make it even smaller), and then expand it again with the /sizeup command. "Sizedown" is binded by default to "-" and "_" keys, and "siezeup" to "+" and "=" keys, but, depending from your keyboard layout, you may have to press other keys (like "'" and "ì" on an Italian keyboard -such keys are usually near to the "backspace" key-), instead.

Texture quality and detailEdit

Changing texture detail can heavily affect framerate and overall video quality. You can change "texture detail" from "graphics" menu, selecting from 4 different levels. Highest quality level is associated with \r_picmip 0, lowest detail level is associated with \r_picmip 3 (higher r_picmip value means lower quality). It needs \vid_restart to be effective and default value is 1 (if you have a good machine, it is advisable to set it to 0). You can use console to set even lower texture quality levels, specifying higher values for r_picmip, even 8 or 16: this increases framerate more (making very "plain" textures); but, when you set a value higher than "3", it tends to automatically return to "3"; this is due a videoflags lock (value 2), which is included with the default videoflags value, 7 (7=4+2+1). This because with high r_picmip values the game isn't nice-looking and because using flat textures on walls may give an unfair advantage in finding other players. Unless the server administrator disables that videoflags lock, users r_picmip will continue to automatically return to 3, if they set it higher.

Other settings related to texture quality:

• \r_detailTextures <0 or 1> (it should be set to 1 for best quality).
• Asinotropic filter: \r_ext_texture_filter_anisotropic <0 or 1>, plus \r_ext_max_anisotropy <0, 2, 4, 6, 8, 16> (these two cvars are easily controlled from the same "asinotropy" option under "graphics" menu).
• \r_texturebits <0, 12, 15, 16, 32>: Obviously, 32 bit textures should be better than 16 bit textures. "Texture quality" option is available in "graphics" menu: "default" corresponds to 0. Important: with OpenArena 0.8.8 executables, you have to force texture quality to 32 bit, or you will not be able to use Bloom graphic effect.
• "Texture filter" can be set to "bilinear" or "trilinear" from "graphics" menu.
• \r_simpleMipmaps <0, 1>: If 0, it performs a linear resampling filter on lower resolution mips, reducing shimmer. Increases loading time. Defaults to 1 (fastest).
• Typing \r_ext and pressing TAB key you can find some other texture-related CVARs.

Hint: if you have old hardware and experience dramatic framerate reduction in some maps, when looking in particular zones, try to lower the texture detail (higher \r_picmip value) and/or set r_texturebits to 16 (about r_texturebits 16: check the results with framerate meter enabled: modern graphic cards may be no more optimized for 16 bit graphics, and thus in some cases it may happen to do not notice any improvement in speed, while certainly losing graphic quality). If you don't experience performance problems, set texture detail to the maximum (\r_picmip 0) and 32 bit textures (\r_texturebits 32): the game will look much better.

Geometric detailEdit

You can change "geometric detail" from "graphics" menu, and set it to "low", "medium" or "high". You will see quality difference on some curves and in some polygonal models. Choose "high" for quality, "low" for rendering speed. It affects r_subdivisions and r_lodbias variables.

/r_subdivisions <number> variable: it affects curves (that will be shown more or less smooth). "High" is 4 (the default), "medium" is 12 and "low" is 20. A vid_restart if required after changing the value in console. It is possible to set a quality higher than "high" by setting r_subdivisions to 0 or 1, however remember your custom value will be overwritten when you will make some other change in the "graphics" menu.
Videoflags locks, if engaged (by default), prevent users from using r_subdivisions values higher than 20.

/r_lodbias <number> variable: if affects some items quality. Higher number means lower quality. "High" geometric detail sets this variable to 0 (its default), "medium" and "low" set it to 1. Vid_restart is not required after changing it from the console. It affects some of the weapons in your hand (e.g. your shotgun will be shown using less polygons if you set it to 1 or 2), and the distance at which some objects (e.g. the "bubbles" around health bonuses) switch from being drawn using their high-polygons models to their low-polygons models. Setting it to 2 or higher would cause your weapon to look bad and some items shown in low quality mode even if you are next to them... on the other side, setting it to a negative value (e.g. /r_lodbias -1) would make objects as the "bubbles" being rendered using their full quality models at long distances where they would usually switch to the low quality model. Your custom value will be overwritten to 0 or to 1 when you will make some other change in the "graphics" menu.

Field of viewEdit

You can use \cg_fov <number> command to change your view angle. So you can have a larger lateral view and find your enemies more easily. However it also makes enemies smaller and your aim precision and reaction time might be slightly worse if this value is increased. Theoretically a large value is best in open environments and a low value best in corridors. To get a precise and fast aim you should find a value you like and stick with it. Notice that, as you increment this value, world will seem distorted, distances will seem bigger and your movement will seem faster. Default value is 90, and 120 could be a nice compromise.
Server admins can force all users to see the world (except their own weapon) like with the default FOV by setting dmflags to 16.
There is also a videoflags lock that controls it; it's 1 (and the default videoflags value is 7, that means that 4+2+1 options are enabled: max FOV lock is enabled by default): it limits users cg_fov (and cg_zoomfov, too) to a maximum of 140. If you set a field of view higher than 140 (e.g. 150), only your weapon will be drawn according to it, but all the rest will be drawn as 140. If the server admin turns off that videoflags lock, you can actually use FOVs higher than 140 (up to 160, which is the original FOV limit), but probably it is not a good idea anyway.

cg_fov 90 (default)

cg_fov 120

cg_fov 170 with videoflags 7: world is drawn as with cg_fov 140 (notice the distortion), while weapon is drawn as with cg_fov 170 (even more distorted). World distortion would have been much more if videoflags was not active (in that case, the actual world drawing would have been like cg_fov 160).

Add a photo to this galleryAdd a photo to this gallery

Weapon barEdit

"Weapon bar" is the series of icons that shows your available weapons (your weapon inventory). Usually it is visible only when you are switching weapons; OpenArena can always draw it, if you enable "always show weapons" in "game options" menu (or enable it with \cg_alwaysweaponbar). Notice that if this option in enabled, you will not see names of items you pickup during game (as far at OpenArena 0.8.5 it is so). Default value is 0.

There are various styles for the weapon bar. You can use cg_weaponbarstyle <number> command to change style. Some are on the lower edge of the screen, others on the left edge. Some simply show weapon icons, other also a bar to show ammo for each weapon, other the accurate ammo number for each weapon. Default value is 0.

"Always show weapons" and "weapon bar style" options were not available in the original Quake III Arena, thus they will not work while playing with old mods (there are however a few mods, like OSP, that implemented their ownadvanced weapon bar features).

Force player modelEdit

This allows to save system resources if your machine isn't too powerful, and to prevent your enemies from partially "hide" from your view using, for example, a dark model on a space map (where the background colour is dark). You can enable "force player model" option from "game options" menu or using \cg_forcemodel 1: this way, during non-team-based gametypes, you will see all the player models look like yours. During team-based gametypes, instead, all players will look like the Sarge character: this can be useful since some models have small areas that change colour according to team (red or blue) -making difficult to tell apart your friends and your enemies-, while with Sarge the team colours are evident. Dafault value is 0.

FramerateEdit

You can use \cg_drawfps <0 or 1> to display in the upper right corner how many frames per second (fps) your computer processes. You may check this when you are changing graphic options, trying to balance your graphic quality over speed. Default value is 0.

You can also use \com_maxfps <number> to change the maximum number of fps allowed. Default value is 85 and 0 means "no limit" (but it is not recommended!). You should set it to a framerate your machine can manage constantly. As later shown, more com_maxfps values can result in the same effective frames-per-second.

Tech note: the game engine has an internal clock which runs at a frequency of 1 kHz -or put differently at 1000 fps- so each of the game clocks ticks has a duration of 1 millisecond (ms) exactly. The game engine can process a frame every clock tick (1000 fps) if processing a frame never takes longer than 1 ms, every second clock tick (500 fps) if processing a frame never takes longer than 2 ms, every third clock tick (333 fps) if processing a frame never takes longer than 3 ms, etc. By setting com_maxfps to a given frame rate you specify once in how many clock ticks the game engine should process a frame and more importantly how much time your computer has at maximum to process a frame. If you set com_maxfps to round(1000 / 1) = 1000 your computer has 1 ms to process a frame every clock tick, if you set it to round(1000 / 2) = 500 it has 2 ms to process a frame every second clock tick, if you set it to round(1000 / 3) = 333 it has 3 ms to process a frame every third clock tick, etc.

Commonly used values for com_maxfps include 43, 76, 125 and even 333 because these represent sweet spots where the in-game physics (in case of "frame rate dependent physics" servers -read game physics page for more info: if the server uses "fixed" or "accurate" physics, instead, the game physics should be fair for all players intependently from their single com_maxfps values chosen, if their hardware can manage them-) are most advantageous to the player: the player can make higher jumps and consequentially can develop higher speed more quickly by strafing. Note: this is true while playing with the standard 800 gravity.^[1]
In any case, it's important to pick a frame rate your computer (the bottleneck being your graphics card) can process constantly, because if processing a frame takes longer than the maximum time for a given frame rate, the game engine will drop the next frame. Unstable framerate makes the game less responsive and could even mean a packet with player information will not be sent to the server now and then. This also means setting com_maxfps to 0 for anything other than a performance test is a bad idea. Talking about performance tests, you may be interested into using OpenArena as a benchmark tool: in this case, take a look to Timedemo.

If you are using a laptop running on battery, and you want to maximize your battery duration, you could set a lower frame rate limit (maybe with a bit lower video resolution and quality settings, too) to prevent your PC from using 100% CPU (with Microsoft Windows, use your task manager to check the CPU load; with Linux, you can use "top" Linux console command) -Note: this CPU load saving would probably be really effective only if you have /com_busywait set to 0 (the default), anyway you can try with both 0 and 1 values. A value of 1 should not allow great CPU load saving, but may keep framerate even more constant, still talking about the case where your machine can provide the required com_maxfps framerate.-. You may also want to do this just to keep some CPU power available for other processes (e.g. if you are running an OA dedicated server and an OA client on the same machine).

Com_maxfps is related with cl_maxpackets: for info about cl_maxpackets, please read Tweak#Tweaking online gaming parameters.
Note: with the default sv_fps value (20) on the server, clients with com_maxfps higher than 500 may experience "connection interrupted" messages while their framerate goes very high: it looks like the problem can be avoived client-side by setting com_maxfps to 500 or lower, or server-side by using an higer sv_fps value, e.g. 30 or 40.

For info about framerate-dependent, fixed and accurate physics, please read Game physics.

Com_maxfps ranges and actual frameratesEdit

You may notice that your actual framerate may be a little higher than your com_maxfps value. Typical case: your com_maxfps value is 85 and your framerate meter displays 90. This is due to how the engine works: while controlling the desired amount of fps, you are indirectly controlling the time to render a frame... what is important is how many milliseconds the engine has got to render a frame, and those milliseconds are discrete values; effective fps resulting, instead, can have fractional parts, and the meter "floors" them (always rounds them down). This means that there are com_maxfps values "ranges" that have absolutely the same effect. E.g. all com_maxfps values between 84 and 90 cause a frame every 11 ms, and thus all of them cause an effective framerate of 90+10/11 (or 90,90909090, if you prefer), that the meter rounds down to 90, altough being effectively closer to 91. If you set com_maxfps to 91, instead, it produces 100 effective fps, because it enters the range from 91 to 100 (10 msec per frame).
A table to sum up:

Simple formula to calculate the FPS (like in the counter) from a com_maxfps value:
fps = floor(1000/floor(1000/com_maxfps))

Com_busywaitEdit

ioquake3 changed the way the engine waits for the time to render the next frame, once you already hit the desired com_maxfps value. /com_busywait <0 or 1> allows you to select if you want to use the new behaviour -a select() system call- (by setting it to 0) or the original behaviour from Q3A -a busy wait loop- (by setting it to 1). Default value is 0.

Com_busywait 0 should be more CPU efficient in this case (reducing power consumption and CPU heat), but in some systems the old behaviour may be better (mostly due to a more stable framerate).

To look at what com_busywait 0 does: if you open your OS task manager while playing the game, checking the CPU usage graph, and set a low com_maxfps value (e.g. 25), you should notice a change in CPU usage when enabling or disabling com_busywait. You probably will see your CPU usage going down while having com_busywait set to 0, and staying up with it set to 1. After the test, set com_maxfps back to your desired framerate.

Another thing to notice is that com_busywait 0 may cause the framerate being a little more unstable (i.e. no constant 125fps, rather toggle between 124-126fps), and this may affect game physics a little (you may try to set it to 1 if you have problems performing certain jumps, especially with framerate-dependent physics, although you have a right com_maxpfs value).

In other words:
Com_busywait switches between two waiting methods: with it set to 1, a busy waiting loop (which should burn 100% CPU^[2] just for waiting, but will hit the exact right time for the next frame) or, with it set to 0, a select() call with a timeout (which might be just a little unprecise, but does not burn CPU cycles while waiting).
If your CPU is too slow to reach your com_maxFPS setting then there's no time left until is has to run the next frame and it'll be at 100% utilization anyways, so there are no possible savings from using select().
The granularity of the select() timeout can be too low on some systems, which causes the framerate to have more jitter, since waiting intervals become too long.

Trivia: as you can guess after reading this, in the original Quake 3 game, setting a low com_maxfps value did not really save a lot of CPU load, unlike what is possible with ioquake3/OpenArena.

LagometerEdit

The "lagometer" is a small window in the lower right corner of your screen that graphically shows your ping (the ping is the time your packets (data) need to reach the server and come back: lower it is, better it is) as a graph, with some seconds of "history". You can enable it with \cg_lagometer 1 (and disable with 0). Default value is 1. It is not shown when playing locally.
If you see that your ping is irregular, and from green goes yellow (with higher lines), consider to connect to another server or to close other bandwidth consuming applications you may have running. Red lines in the lagometer indicate "packet loss" (data that is lost and did not reach its destination): if you have many of them, change server or try to set \cl_packetdup 1 (to send each packet two times); if you don't have them, you can try to set \cl_packetdup 0 for best performances (default value is 1). You can read your current ping as a number when showing the score table (usually holding TAB key).

SpeedEdit

You can use \cg_drawspeed 1 to show your current horizontal speed in the upper right corner. Default value is 0.

The original Q3A did not have it, hence some of its mods may have similar commands for that (like Alternate Fire, where you can use \cg_speedometer 1), while others may not include speed meter at all.

Show or hide 2D (HUD)Edit

You can use \cg_draw2d 0 to hide your HUD. You will no more see your statistics: you may want use this when you want to capture screenshots. Default value is 1 (show).

ThirdpersonEdit

You can use \cg_thirdperson <0 or 1> to switch from first-person to third-person view. This game is designed to play in firstperson, and enabling thirdperson is not so comfortable since you cannot see your crosshair (this may be "wanted" by design since Q3A, since the game is meant to be a first person shooter, and maybe playing in third-person may seem like cheating, giving more lateral view: not having the crosshair may be an easy way to discourage the use of third-person). Some mods, like Bid For Power, may be designed to work with thirdperson view. Default value is 0.

Additional cvar \cg_thirdPersonAngle <number> (default: 0) allows to place the "camera" not exactly behind you, but laterally or even frontally (e.g. with it set to 90, the "camera" will see you from your left side). Cvar \cg_thirdPersonRange <number> (default: 40), instead, allows to place the "camera" closer or farther from your character. Please notice that cg_thirdPersonAngle and cg_thirdPersonRange are cheat protected: you cannot change them from their default values, unless the server started the map in "development" (cheat-enabled) mode, with \devmap <mapname> command; anyway, it is possible to change them during playback of demos, making them useful when trying to capture a suggestive screenshot or to export to a video.

When thirdperson is enabled, if you set com_cameramode 1 (default value is 0), your player model, weapon and shadow will not be shown.

BrightnessEdit

You can change "brightness" ("gamma") from "display" menu. This will make game brighter or darker. You can control it also from console using \r_gamma <number>, where number is a value like 1.213450, for example. Default value is 1.

Other related cvars:

• \r_ignorehwgamma <0 or 1> (default = 0; requires \vid_restart)
• \r_mapoverbrightbits <number> (default = 2; requires \vid_restart)
• \r_overbrightbits <number> (default = 1; requires \vid_restart)
• \r_intensity <number> (default = 1; requires \vid_restart)

Brightness-related known problems:

• FAQ#The game crashed, and it left my screen too bright! - Windows desktop can be restored to normal brightness by using a small tool.
• FAQ#Brightness controls do not work in windowed mode - If you switch from fullscreen to windowed mode, brightness controls stop working, while continues to work in fullscreen mode; you can launch the game directly in windowed mode.

Screen sizeEdit

If you are experiencing a low frame rate, you could also reduce "screen size" from "display" menu. This will draw the 3D game stuff inside a sort of window. 2D HUD will not be affected. You can change it from console using \cg_viewsize <number> (default value is 100). \sizedown and \sizeup commands are/can be binded to specific keys.

FullscreenEdit

If you want to switch from "full screen" mode to "windowed" mode, you can use "Fullscreen" option from "display" menu. You can also use \r_fullscreen <0 or 1> to do this.

Simple itemsEdit

"Simple items" option in "game options" menu replaces 3D models for powerups (weapons, ammo boxes, etc.) around the arena with simple 2D icons. This should save system resources. You can also use \cg_simpleItems <0 or 1> to control this option. Default value is 0.

Draw team overlayEdit

"Draw team overlay" option in "game options" menu allows you to view your team-mates health, armor, current weapon and (if supported by the map) current location, during team play modes (like TDM and CTF). You can also control this function with \cg_drawTeamoverlay <number>. 0=off, 1=upper right corner, 2=lower right corner, 3=lower left corner. Default value is 0.

Draw friendEdit

If enabled, \cg_drawfriend <0 or 1>, during team modes shows a well-visible symbol above the head of your team-mates, to help you tell apart your allies from your enemies. Default value is 1 (enabled). The option is available from "game options" menu.

Draw rewardsEdit

If \cg_drawRewards <0 or 1> is enabled, when a player earns a "Medal", its symbol appears over his head for a while. If you are that player, you will see the icon on the screen and you will hear the announcer saying it. Default value is 1.

The symbol of the medal over the head of the player will hide the "draw friend" symbol (the one that helps you to identify your team-mates during team-based games) for a while, and for this reason you may want to set cg_drawrewards to 0. In this case, the medal will not be shown over the head of the player, and if you are that player, you will not see the icon on the screen, but you will still hear the announcer. The medals earned at the end of a single player deathmatch will be shown as usual.

Identify targetEdit

This option, available from "game options" menu or with \cg_drawcrosshairnames <0 or 1> variable, shows the name of the player you are aiming at, after a while. Default value is 1.

Marks on wallsEdit

This option, available from "game options" menu or with \cg_marks <0 or 1> variable, shows damaged surfaces on walls hit by shots. Marks will disappear after some time. Default value is 1.

Ejecting brassEdit

This option, available from "game options" menu or with \cg_brasstime <number> variable, controls how long you will see the cartridge cases ejected by some weapons, before they disappear. From the menu, you can disable (the variable is set to 0) or enable them (the variable is set to 2500, the default value); however, you can specify other values using the console.

Projectile trailEdit

Rockets and grenades leave a smoke trail behind them. It is possible to disable it: this could give some more fps and a bit of better visibility, while maybe making a little more difficult to guess the trajectory of such projectiles and thus where the player that fired them was a while ago.
This is controlled by \cg_noprojectiletrail <0 or 1>. 0 (default) shows the smoke and 1 hides it.

FlaresEdit

"Flares" option is available in "Graphics" menu or using \r_flares <0 or 1> command. This will add glow to light sources and "lens flare" effects. Flares are nice at view, but may distract you from playing. You may want to disable this option. Default value is 0. If you type \r_lensreflection and hit TAB key you see there are some other variables to fine-tune this function.

r_flares 0

r_flares 1

Both "r_flares" and "r_bloom" are enabled here

Add a photo to this galleryAdd a photo to this gallery

BloomEdit

"Bloom" option is available in "Graphics" menu or using \r_bloom <0 or 1> command. This will add "glowing" effects to some light sources (less than "flares" option) and to some objects (like ammo boxes and yellow armour). Disable if you are trying to get higher FPS rate (bloom has got a noticeable impact on performance!), enable if you like this effect. Default value is 0.
If you type \r_bloom and press TAB key, you will see there are some other variables to fine-tune this function (note: while r_bloom does not need /vid_restart to be enabled or disabled, some of the additional variables may need it instead; changing too much some of those values may go over allowed range and disable bloom, in that case, you can restore the default value for that variable and then enable bloom again).

Starting with OA 0.8.8 an alternate bloom algorithm, known as "cascaded bloom", is available (opposed to the "classic bloom").

Very important: with OpenArena 0.8.8 executables, bloom works only if you first set texture quality to 32 bits^[3]. You can set "Texture quality: 32 bit", in Setup --> System --> Graphics menu, or type /r_texturebits 32 in console (see also Texture quality and detail section). If you use the console, you have to first type /r_texturebits 32, then load another map (or use /vid_restart) to make that change effective, and then set /r_bloom 1; if you use the menu, you can set bloom and 32 bit texture quality at the same time. If r_texturebits is not set to 32, r_bloom will automatically be reverted to 0 and the effect disabled. R_texturebits default value is "0" ("default" on the GUI), and that does NOT allow to use bloom: you have to manually force 32 bit textures (even if your operating system is set to 32 bit color depth) and enable bloom again. If r_bloom remains to 1, you're okay.</small>

Note: in general, Bloom has got a noticeable impact on performance. But in particular, enabling both bloom and greyscale features brings a drastic framerate drop, due to internal color conversions required between the two: it is advisable to do not enable both bloom and greyscale at the same time (you may still want to do it, if you have good hardware).

Cascaded bloomEdit

"Cascaded bloom", also known as cascaded blur or bloom cascade, is a new bloom version, introduced with OpenArena 0.8.8 executables. Cascaded blur (created by Tcpp) is a blur algorithm intended to provide a more "natural" and smoother effect than standard bloom, and uses much less CPU power than OpenArena classic bloom (altough bloom impact on framerate is still remarkable).

It is enabled by setting /r_bloom_cascade to 1 (and r_bloom has to be set to 1, too; please remember than in OA 0.8.8 r_texturebits must be set to 32, otherwise r_bloom will be automatically reverted to 0). In OpenArena 0.8.8, r_bloom_cascade is set to 0 by default; this may change in future versions (for the moment it is not enabled by default due to an "excessive aura" problem that may be very (or very few) visible depending from the advanced settings values in use, and depending from map in use -problem quite visible in slimefac map-).

If you type /r_bloom TAB or /r_bloom_cascade TAB in console, you can see that it has got some additional advanced settings, other than those of the "classic" bloom.

CrosshairEdit

You can change your crosshair look from "game options" menu. Options there allow you to select its shape and its color (controlling three slide bars for the three color components -red, green and blue-). The "Crosshair shows health" option (enabled by default) makes the crosshair change color when your health goes down: it is initially white, then becomes yellow and then red when you are low in health; please notice that this also means that the crossahair color you manually select is only used if you turn off "crosshair shows health" feature.

Using the console, /cg_drawcrosshair <0-9> selects crosshair shape: default value is 4, and value 0 shows no crosshair. Typing /cg_crosshair TAB you can see the other variables that control crosshair aspect, like cg_CrosshairHealth.

WeaponEdit

You can use \cg_drawGun <number> to select where your weapon will be shown in your view. 0 = weapon not shown; 1 = right; 2 = left; 3 = center. Default value is 1. Before OpenArena 0.8.5, only 0 and 1 values were allowed.

TimerEdit

\cg_drawTimer <0 or 1> allows to hide or show a timer that indicates the time elapsed since the beginning of the match. Default value is 0.

You may use it as an aid for the tactic known as "control" (mastering an arena by learning its items spawn times and using them in your favor).

ShadowsEdit

The \cg_shadows <0 - 3> variable determines how the shadows of the characters are drawn. The standard shadow is a sort of disc under the character, but the engine is capable to draw more complex shadows (known as "detailed shadows", "stencil shadows" or "volumetric shadows": they reproduce the 3D model and are projected to the opposite side from the light source), although with some glitches (sometimes you can see such shadows go through the walls). In OpenArena 0.8.5, the detailed shadows have been disabled almost completely, and they are available in Single Player Deathmatch (g_gametype 2) mode only. Moreover, detailed shadows are not shown under character models that contain more than a certain number of polygons.

• cg_shadows 0 - No shadows under yourself, under the other players and the powerups.
• cg_shadows 1 - Simple semi-transparent "disc" shadow under yourself and under the other players; no shadow under powerups. It is the default value.
• cg_shadows 2 - Semi-transparent grey detailed shadow under the other players and under the powerups (items and weapons); no shadow under yourself, unless you enable cg_thirdperson. It needs r_stencilbits <> 0 (usually set to 8 -default-, 24 or 32). Disabled in OpenArena 0.8.5, except when playing in Single Player Deathmatch mode.
• cg_shadows 3 - Non-transparent uniform black detailed shadow under yourself and under the other players; no shadow under powerups. Disabled in OpenArena 0.8.5, except when playing in Single Player Deathmatch mode.

Stereoscopic viewEdit

See also: Stereo Rendering on ioquake3 wiki site.

ioquake3 engine includes stereoscopic view features, to have a more deep 3D experience, even if only for the sake to try it. You need special glasses to see such images in the right way. There is support for "anaglyph rendering" (with cheap different colors lens glasses) and "OpenGL stereo rendering" (with more expensive shutter glasses).

Anaglyph stereoscopy is enabled changing the value of \r_anaglyphMode variable. There are different values depending from the colors of your glasses. You don't need \vid_restart to change this.

• 0 = disabled (default)
• 1 = red-cyan
• 2 = red-blue
• 3 = red-green
• 4 = cyan-red
• 5 = blue-red
• 6 = green-red

Note: these codes are valid for official OA 0.8.8 binaries, and may change in future, as more colors will be added.^[4]

Each frame contains two sligthly different images, with altered colors, and the colored lens will prevent each eye from seeing one of the two main colors, so your brain should "see" two separated images and put them together as a single 3D image. You may try to enable also monochrome rendering with \r_greyscale 1 (default value is 0) to have not problems with items of a single color (note: greyscale slows down a lot the framerate if bloom effect is enabled: you may want do disable bloom).

Unfortunately, at the moment (OA 0.8.8) there are two known bugs with anaglyph stereoscopic view: the little one is that a few indicators (speed, framerate) in the upper right corner are messed up, and the big one is that the crosshair is not shown.

OpenGL stereo rendering, instead, needs shutter glasses, and works only on hardware that supports quad buffers. Each eye will get only half of the frames (each half with a slightly different image), and your brain should put them together in a 3D image. This mode is enabled with \r_stereoEnabled 1 (default value is 0 and requires \vid_restart to be effective). It is not confirmed whether this method actually works flawlessly with OA or not.

You can tune the stereo rendering using \r_zProj (default value is 64) (you can find here a good explanation of how the "projection plane" works in stereoscopy) and \r_stereoSeparation (default value is 64) variables. It is advisable to read the more extendend help in the ioquake3 wiki for how to use them.

Using 3D glasses for long times may be tiring for your eyes.

GreyscaleEdit

The variable \r_greyscale <0 or 1> allows to view the game in greyscale. Even too much "old style", it is almost useless (and may slow down frames-per-second a lot if Bloom effect is enabled, too: it is advisable to disable Bloom when using greyscale), but it can help when anaglyph stereoscopic view is enabled. It then needs \vid_restart. Default value is 0. If used, having also cg_drawfriend enabled is advisable, too.

Frag message sizeEdit

Each time you score a frag, a message appears on the screen, mentioning the name of who you just killed. The variable \cg_fragmsgsize <number.dec> allows to customize the size of such message. Default value is 1.0. You can make it bigger using an higher value (e.g. 1.3), or smaller using a lower value (e.g. 0.7): you may want to have it smaller, if you feel it too much distracting from the game.

Draw World and ClearEdit

The variable \r_drawworld <0 or 1> (set to 1 by default) determines if the arena itself will be shown or not. Obviousy, it should be set to 1: if you disable it, you will not see the anything but objects like bonuses and characters: no floor, no columns, no ceiling. Disabling it may be useful if you want to take a screenshot of a specific item with a single color background (that will be easy to remove using an image editor program).

To get the single color background, and to avoid strange artefacts (caused by the missing refresh of the "hidden" world), proably you will need to set also \r_clear 1 (its default value is 0) before taking the screenshot.

To take the screenshot, use /screenshot (for TGA format) o /screenshotjpeg (for JPG format) command. It is advisable to bind the command to a specific key, for example \bind F10 screenshotjpeg: this way, you will capture a screenshot when you will press the F10 key.

LightingEdit

"Lightmap" is the standard setting for game lighting; it allows some important effects such as advanced shaders and dynamic lights (e.g. seeing floor/walls enlighted from a firing weapon may help you recognizing the incoming danger). "Vertex", instead, is an alternate lighting method, a lower quality setting designed to have Quake 3 Arena run on 1999 low-end hardware; arenas lighting looks more "flat" (maybe someone considers this a way to better spot players that hide in dark places and so it may be considered a sort of cheating), it does not allow dynamic lights, and some shaders do not work correctly (e.g. you may see a plain grey surface instead of an "animated" surface). Especially on old hardware, vertex lighting can give you more frames-per-second than lightmap mode, but it's not advisable to use it. Set \r_vertexlight <0 or 1> to 0 (the default) to use "Lightmap" (normal quality); set it to 1 to use "Vertex" (low quality) instead. A vid_restart is required to make the change effective.
Please notice that some maps may be designed in a way that may not allow at all to play them in vertex mode, but require lightmap mode in order to be played (they are rare, anyway two examples are islanddm and islandctf).

Important: starting with OpenArena 0.8.5, Vertex lighting is generally no more activable, unless a specific lock is disabled: a videoflags (set by the server your client is connected to) prevents players from enabling vertex ligthing. If videoflags 4 is enabled (default videflags value is 7, that is 4+2+1, that means "vertex lock" is enabled), clients playing on that server will have their r_vertextlight variable automatically reset to 0.^[5] If clients set /cg_autovertex 1 (its default value is 0), they will automatically have r_vertexlight enabled again each time they will connect to a server that has the related videoflags lock disabled. The videoflags lock did not exist in Q3; when using old mods, players are allowed to use vertex lighting anyway.

Note: "Vertex lighting" (r_vertextlight) is not the same "vertex" option that enables GLSL effects (r_ext_vertex_shader), it's a different thing.

GLSL effectsEdit

OpenGL Shading Language (in short, GLslang or GLSL; -see Wikipedia article-) is an high level shading language. It allows to use your graphic card features to achieve particular graphic effects, without consuming main CPU power. GLSL support has been introduced in OpenArena (by Hitchhiker) with 0.8.8 binaries, and it is expected to be quite used in the future "OA3" reboot. A graphic card capable of Pixel Shader 2.0 features is required to use GLSL.

The variable \r_ext_vertex_shader <0 or 1> allows to disable or enable GLSL features. In OA 0.8.8 binaries, default value is 0 (disabled) -this may be changed in future versions-. With it disabled, the game should keep its classic looking even when more GLSL programs will be created. A /vid_restart is required after the change. "GL Extensions" option (System -> Graphics menu) needs to be "on" (/r_allowExtensions 1, which is the default value), in order to use GLSL.

A GLSL program can be used in a shader (e.g. associated to a texture in a map or in a model, that will look differently than normal -ideally, more nice looking, shining or similar-), or can be manually launched using \r_postprocess <glsl_program> variable (in "postprocessing mode"). Example: if you set \r_postprocess edges, the "edges" GLSL program will be loaded, and you will see black edges around objects, in a way that may loosely resemble some toon-shading techniques (see Cel-shaded animation on Wikipedia). A vid_restart is required after changing r_postprocess value (and its default value is "none"). Some GLSL programs may only be used in shaders, while others may only be used with r_postprocess. Tip: if you set verbose console logging (/developer 1), you should be able to see which GLSL programs are being loaded.

Who creates a shader that contains a GLSL effect, should always create (and test!) the standard shader version, too, considering players who have r_ext_vertex_shader 0 or whose graphic cards do not support pixel shader 2.0. And any GLSL program should be tested at least with an AMD (formerly, ATI) and a Nvidia brand graphic card.

Trivia: OpenArena is mostly OpenGL (Wikipedia) 1.1 suff. GLSL is OpenGL 2.0 stuff.

Blood and gibsEdit

Due to its "shooter" nature, the game features violence, with gore and flying pieces of meat. Some variables allow to control the violence shown.

• \com_blood <0 or 1>. Default value is 1. This variable can be used both server-side and client-side. It should be noticed that, server side, it does enable or disable the "gibbing" feature (when you cause enough damage to a corpse, or kill someone by havily hitting him while he has got low heath, the body does explode: this is known as "gibbing" someone. Note: "gibs" word can also be used to indicate few meat parts that may occasionally come out while someone is being shot, especially in Q3A.).
  • Set to 1 on the server and to 1 on the client: game acts as usual, showing usual blood when hitting someone. Corpses can be "gibbed" as usual.
  • Set to 1 on the server and to 0 on the client: that specific player sees no blood when hitting someone. Corpses can be technically "gibbed", but he does not see gibs: "gibbed" corpses immediately disappear, instead of leaving blood and pieces of meat.
  • Set to 0 on the server and to 1 on the client: players see some blood when hitting someone, but corpses cannot be "gibbed": no matter how hard you hit them, they will be there until they will disappear (this means players may see corpses "suspended" in the "outer space" below the map for some time, if someone falls down from a "space-themed" arena).
  • Set to 0 in the server and to 0 on the client: corpses cannot be "gibbed" at all, and that specific player would also not see blood when hitting someone.

It is important to know that enabling or disabling gibbing (com_blood on the server) affects the Kamikaze item. Normally, if the player holding the Kamikaze is killed, the explosion is automatically triggered after three seconds, but "gibbing" the corpse prevents the explosion from happening. If corpses cannot be gibbed, the explosion cannot be aborted.

• \cg_gibs <0 or 1>. Default value is 1. If set to 0, you will se less gibs than usual, when someone will be "gibbed".

• \cg_leiSuperGoreyAwesome <0 or 1>. Default value is 0. If enabled, it should make more blood and gibs being shown than usual. This was not part of Q3A.

OtherEdit

• \cg_leiEnhancement 1 enables some new graphic effects, like some particle effects and a nice rocket explosion. Default value is 0.
• \cg_oldrail <0 or 1>. With 1, external "spiral" trace is omitted from railgun beam. Default value is 0. The spiral is nice at look, but you may want to remove it, if you find it a distraction. The railgun trace colors are controlled from "player settings" menu.
• \cg_oldplasma <0 or 1>. With 0, plasma balls left additional particle effects behind them (nice at view, but nothing impressive and they could distract from gameplay). Default value is 1. At the time of this writing, with OA 0.8.8, if you have cg_leiEnhancement 1, then cg_oldplasma value is ignored, and you see as with cg_oldplasma 1.
• \cg_oldrocket <0 or 1>. Default value is 1.
• \cg_truelightning <number>.

NotesEdit

1. ↑ Different physics behaviors at different framerates are caused by the rounding that occurs while processing players' coordinates (that, except the case of "accurate" physics, are sent over the network as integer numbers); gravity may look like a constant here, but take in account that in some cases it may differ. Most maps use 800 gravity (and most framerate-dependent servers probably use g_gravitymodifer 1), and with that, the rounding makes players jump a little higher when at 125 fps than at 90 fps. But if the gravity is different than 800, 125 fps may not give you rounding advantage anymore! At gravity 600, you will jump a bit higher at 90 fps than at 125!
2. ↑ "100% CPU" is just an approximate value: there are many things that may affect actual CPU usage, e.g. number of "cores" in your processor, graphics card bottleneck, etc. Thus, instead of 100%, you may see your CPU usage at 80%, 50% or else.
3. ↑ In 0.8.8 binaries, bloom is disabled if texture quality is set to 0 (default) or 16 (16 bits). It works if you set r_texturebits 32 (32 bits) only. 32 bits textures will be used then for sure, so the engine is sure it will not encounter the "16 bit textures bloom bug" that affected 0.8.5 executables (that was a mysteryous semi-transparent "square" in the lower left corner of the screen).
   The error message you read in 0.8.8 console output is misleading:
   WARNING: 'R_InitBloomTextures' no support for 32-bit textures, effect disabled
   It refers to an engine component (that requires 32 bit) that tries to call another engine component (that is not set to 32 bits instead), or something similar, and thus it shuts down.
4. ↑ According to updated ioquake3 readme file, the new codes are:
   • 0 = disabled (default)
   • 1 = red-cyan
   • 2 = red-blue
   • 3 = red-green
   • 4 = green-magenta
   • 5 = cyan-red
   • 6 = blue-red
   • 7 = green-red
   • 8 = magenta-green
   Test binaries of OA may already use such new codes.
5. ↑ If you want to try Vertex lighting while playing on your own machine, you have to disable the videflags lock before setting vertex lighting.
6. ↑ Note: "edges" program adds the black outlines; irregual/rounded terrain is a feature of this specifc map.

See alsoEdit

• Command console
• Manual/Console Commands
• FAQ#The game isn't as pretty as the screenshots :(
• Tweak
• VidCompat - Infos about compatibilty with some GPUs
• VidWorkarounds - "Developer" tricks to keep compatibility with specific graphic cards.