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.
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. Default value is 3.
- r_custompixelaspect <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)
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). Default value is 1. A "detail texture" is a shader that includes some "detail stages": if a shader has been created with one or more stages including the "detail" option, those specific stages will be ignored if the player has set r_detailTextures to 0, speeding up scene rendering a little bit (less "passages" to compute to draw the polygon surface). Those detail stages are thought for showing stuff with a smaller scale than the other stages of the texture, to do not give players a "lack of detail" sensation when looking at the surface form very near, and should follow specific rules. The variable affects only those shaders that actually have "detail stages" (it is a different thing than the "detail brush" flag that map makers can set in map editor with "make detail" command). To do a good thing, who creates a "detail texture" should check the result is acceptable with both the option on and off.
- Asinotropic filter: \r_ext_texture_filter_anisotropic <0 or 1> (default: 0), plus \r_ext_max_anisotropy <0, 2, 4, 6, 8, 16> (default: 2); these two cvars are easily controlled from the same "asinotropy" option under "graphics" menu.
- \r_texturebits <0, 12, 15, 16, 32> (default: 0): Obviously, 32 bit textures should be better than 16 bit textures: it is advisable to set this to 32 for best quality. "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.
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. It has been noticed that "r_subdivisions 0" may show ugly glitches with some curves, so "1" may be advisable instead: if there are too many vertices on a surface (>1000) it will fall back to the highest subdivision level.
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> variable 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. Decimal values (e.g. 90.5) can be used.
There is also \cg_zoomfov <number> variable, to change the FOV used while pushing the zoom button: its value is 22.5 (decimal values can be used).
Server admins can force all users to see the world (except their own weapon) like with the default FOV (and zoom 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.
"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.
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.
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:
|com_maxfps||ms per frame||real fps, assuming sufficient hardware (in brackets: fractional part, that the framerate meter always "hides" rounding down)|
|251...333||3||333 (+ 1/3)|
|143...166||6||166 (+ 2/3)|
|126...142||7||142 (+ 6/7)|
|101...111||9||111 (+ 1/9)|
|84...90||11||90 (+ 10/11)|
|77...83||12||83 (+ 1/3)|
|72...76||13||76 (+ 12/13)|
|67...71||14||71 (+ 3/7)|
|63...66||15||66 (+ 2/3)|
Simple formula to calculate the FPS (like in the counter) from a com_maxfps value:
fps = floor(1000/floor(1000/com_maxfps))
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 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.
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.
Roughly, the lower part refers to your connection (and should usually show small green lines), while the upper part refers to what you receive from the server (and should usually show small blue triangles), but it's more correct to say that the lower part is the "snapshot graph", and the upper one is the "frame graph".
In the lower graph, if you see that your ping is irregular, and often shows higher lines, consider to connect to another server or to close other bandwidth consuming applications you may have running. If you see yellow lines too often, you may wish to tweak your network settings, or to connect to another server (yellow bars indicate a snapshot suppressed to do not go over your rate value -or sv_maxrate value from the server-). 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).
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).
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.
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.
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.
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 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.
You can still distingush weapons from ammo boxes due to the fact ammo icons have got a border that recalls ammo prisms.
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.
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.
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 target" 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 you're aiming at him. Default value is 1 (enabled).
The game shows the head and the name of the last player who hit you near to the upper right corner of the screen. This info lasts some seconds. Using \cg_drawAttacker <0 or 1> variable, you can turn this feature off or on. Default value is 1 (enabled).
Low ammo warningEdit
Using \cg_drawAmmoWarning <0 or 1> variable, you can disable or enable the "low ammo warning" and "out of ammo" on-screen messages when you have few or no ammo left. Default value is 1 (enabled).
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. Some objects will not show such marks. Default value is 1.
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.
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.
"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.
"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. 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 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.
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.
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.
\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).
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.
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.
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.
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. You may even set it to 0 to do not see the message at all.
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.
"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. 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.
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. Also "GL Extensions" option (System -> Graphics menu) needs to be "on" (/r_allowExtensions 1, which is the default value), in order to use GLSL.
Currently, GLSL programs can be used in two different ways, that are two completely indepentent things (in one case, the choice of which effect to use depends from the shader/map artist, in the other case it depends from the final user -OA player-).
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 usual -ideally, more nice looking, shining or flowing-), or can be manually launched using \r_postprocess <glsl_program> variable (in "postprocessing mode", which applies the GLSL program to the whole screen instead of to a specific shader). 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 be appositely meant to be used in postprocessing mode (e.g. many GLSL programs require some texture filenames as "input variables" passed to them by the shaders that invoke them, hence cannot be used in postprocess mode).
Tip: if you set verbose console logging (/developer 1), you should be able to see which GLSL programs are being loaded. If a postprocessing program compiling fails (if invoked by a shader, this should make the "standard" version of the shader being shown instead of the GLSL one), you should see some error infos in console also without verbose logging.
Who creates a shader that contains a GLSL effect, should always take in account (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 (every single GLSL-powered shader should be tested in standard and GLSL ways: both modes have to show acceptable results: please remember that GLSL support is optional). And any GLSL program really should be tested at least with an AMD (formerly, ATI) and a NVIDIA brand graphic card (e.g. Radeon cards may require to more strictly follow formal language than GeForce cards).
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.
Round images down/upEdit
Texture creators (usually, map creators) should make textures which sizes (width and height) are power of two (examples: 128x128, 256x256, 256x1024 are ok, while 120x120 and 250x1000 not). This affects final rendering for players: when the engine finds a texture which does not follow this rule, it has to resize the image down or up, depending from the value of r_RoundImagesDown variable, losing quality in the process.
- r_RoundImagesDown <0 or 1>. Default value is 1; a vid_restart is required to make the change effective. Setting the variable to 1 means "round down", while setting it to 0 means "round up". Rounding down uses less video RAM (VRAM) and may considerably lower rendering quality; on the other hand, rounding up causes just a slight lose of quality, but consumes more VRAM, which may be a problem when playing with older hardware.
Example: given a big 1600x1600 pixels texture, rounding it down would be resizing it to 1024x1024, and rounding it up would be resizing it to 2048x2048.
Trivia: when OA3 engine will be released, it will add r_roundimagesdown 2 support, which will allow to directly use Non-Power-Of-Two Textures without having to round them up or down, hence preserving quality. That will work only with hardware supporting NPOT Textures.
- \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 leave 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.
- \r_allowextensions <0 or 1>. Default value is 1. It corresponds to the "GL Extensions" option (System -> Graphics menu). Usually it should be enabled (set to 1): the ability of setting it to 0 was designed for compatibility with very old video cards (such as Matrox G400 and S3 Savage) that didn't implement correctly some OpenGL extensions. If you wish to use GLSL effects, also this option has to be "on".
- \cg_oldrocket <0 or 1>. Default value is 1.
- \cg_truelightning <number.dec between 0 and 1>. Default value is 0.0. This controls how the Lightning gun beam is shown -following your aim (1.0), following server responses (0.0), or mid-ways between (0.9, 0.75, 0.5, etc.)- while playing without latency compensation technology.
- ↑ If you want to create detail textures, you can refer to the apposite section of Q3 Shader manual to know about detail stages rules. You can also take a look here.
- ↑ 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!
- ↑ "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.
- ↑ Yellow lines may be normal during a gunfight, if you are using an old analog modem, if then the graph returns to green after the gunfight
- ↑ Even a team-mate of yours, in case friendly fire is active.
- ↑ 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.
- ↑ 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
- ↑ If you want to try Vertex lighting while playing on your own machine, you have to disable the videflags lock before setting vertex lighting.
- ↑ Note: "edges" program adds the black outlines; irregual/rounded terrain is a feature of this specifc map.
- ↑ OpenArena is mostly OpenGL 1.1 suff, while GLSL is OpenGL 2.0 stuff (see also Wikipedia article about OpenGL). Most discrete video cards, starting from around year 2002-2003, support GLSL. However, some graphic chipsets could not support it (or have incomplete support) due to being old, "integrated" or very cheap... or due to old or buggy device drivers: if you experience problems with GLSL, be sure you are using updated video drivers. GPU Caps viewer tool may help you identifying the GLSL version supported by your card (if you are a developer: that program also contains "GLSL shader validator" feature to quickly do a first check for errors in your .glsl files).
- ↑ If the GLSL program creator does not have access to both an AMD and a NVIDIA cards, he should ask a friend with a card of the other brand, to repeat the test (but however, different generations of cards of the same brand may support different versions of the GLSL language). Also a test with GLSL-capable Intel Graphics could be useful (Intel graphics seem to be technologically behind NVIDIA and AMD). Feel free to ask in the Official OpenArena Forums.