Game physics is the way in which the laws of nature are simulated in a computer game. This article focuses on the problems with simulating gravity in a way that is fair for all OpenArena players and independent of their personal hardware and game settings.
The different ways this may work are frame rate dependent, fixed frame rate and accurate physics. You can select one of them when creating a custom match (multiplayer or skirmish) from the menu, or using console commands according to the info you find in this page.
At standard 800 gravity, jump height/length with "accurate" physics is slightly shorter than with "fixed 125 Hz" physics, and longer than with "fixed 90 Hz" physics.
Note: if you are searching the variables to manually control in-game gravity, speed and knockback, see Special game options#Game physics instead. If you are searching info about "Vanilla" and "CPM" physics, see the dedicated section later in this page.
Hint: if the server is using "fixed" or "accurate" physics, each client's com_maxfps value does not influence player's jumps anymore... anyway it continues to control the number of frames-per-second rendered on their screens, and clients should continue to set it to a value their machine can handle constantly (e.g. setting it to 0 -no limit- is a bad idea).
To map creators: it is strongly advisable to test the maps you create, to be sure they are playable (e.g. all platforms are reachable) with "Accurate" physics and with "Fixed 90 Hz" and with "Fixed 125 Hz" physics.
You should make maps playable with all three these settings. Examples: jump-pads and accelerator pads pushing may require some tweak to do not send the player off-target; some obstacles should or should not be taller than "x" units; some jumps (gaps) may require to be a little shorter; etc. Also consider that "accurate physics" (used by default since OA 0.8.5) is not supported by many old mods designed for Q3A.
Frame rate dependent physics
Frame rate dependent physics is the original way of simulating gravity the OpenArena game engine inherited from its Quake III ancestor. The game server calculates a players position with the PMove() function and it transmits the resulting coordinates to the players game clients represented as integer numbers. If a player's coordinates have fractional parts ('decimals behind the dot'), the fractional parts have to be rounded to make them into integer numbers. This makes the moment at which the PMove() function does the rounding have an effect on the result of the rounding: if the rounding is done early the result is rounded down, if the rounding is done late the result is rounded up. Normally the rounding errors will cancel each other out over time because the acceleration is not constant. However there is one notable exception: Gravity. Because gravity is constant, rounding errors accumulate over time. The rounding error is related with gravity and fps: with standard 800 gravity, at 125 FPS you can jump a bit higher than at 90 FPS; with 600 gravity, instead, at 125 FPS you can jump a bit lower than at 90 FPS. As you can guess, higher jumps can be longer than lower jumps.
Because in frame rate dependent physics the PMove() function is called whenever a client renders a frame, a player can influence the effect of the rounding by tweaking his client's com_maxfps setting (reminder: its default value is 85, which results in 90 FPS).
The com_busywait variable is set to 0 by default, and this should help to save CPU load (assuming that your system can handle the desired com_maxfps framerate), but may make framerate a little more unstable; if you have problems performing some jumps, especially with framerate-dependent physics (and you have the right com_maxfps value), you may try to set com_busywait 1.
Advantages
- Provides that 'good old gravity' feeling for seasoned players.
- All old maps are playable as they were meant to (if all players can and do use com_maxfps 125. Of course, if those maps were designed with 125 FPS in mind).
- No choppy movement as long as the client can hold a steady framerate.
Drawbacks
- Players with good hardware and the correct game settings experience less gravitational pull than others, giving them an unfair advantage because they can jump higher and thereby farther.
Configuration
The server can be configured to frame rate dependent physics by setting both pmove_float and pmove_fixed to 0.
Fixed frame rate physics
Fixed frame rate physics solves the unfairness frame rate dependent physics by calling the PMove() function at the same, fixed time interval for all players, independent of their com_maxfps. This way all players get the same rounding error and thus all can jump the same height. The rounding error is related with gravity and FPS: with standard 800 gravity, at 125 FPS you can jump a bit higher than at 90 FPS; with 600 gravity, instead, at 125 FPS you can jump a bit lower than at 90 FPS.
Advantages
- Fair physics by emulating the same frame rate dependent physics for all players.
- Which frame rate dependent physics will be emulated is configurable (91 FPS physics, 125 FPS physics, etc.).
- All old maps are playable as the were meant to, providing the administrator has set the correct time interval with the pmove_msec cvar (being 8 for 125 FPS physics, and 11 for 90/91 FPS physics).
Drawbacks
- Players with bad hardware or wrong game settings don't get to hear a lot of the in-game sounds.
- The above will appear to have the dreaded choppy movement to other players and will experience frequent frame drops themselves, reducing the fun in online games drastically.
- Players standing on moving platforms may see an unpleasant "vibrating" effect; severity may vary depending from the specific platform movement, pmove_msec, and players' com_maxfps values. It's therefore advisable to set pmove_fixed 0 when loading maps with many moving platforms, even if you use "accurate" physics.
Configuration
The server can be configured to fixed frame rate physics by setting pmove_float to 0, pmove_fixed to 1 and pmove_msec to the desired time interval in milliseconds. The interval is calculated by dividing 1000 by the FPS to be emulated, or the other way around:
| pmove_msec | FPS | |
| 1 | 1000 / 1 = | 1000 |
| 2 | 1000 / 2 = | 500 |
| 3 | 1000 / 3 = | 333 |
| 4 | 1000 / 4 = | 250 |
| 5 | 1000 / 5 = | 200 |
| 6 | 1000 / 6 = | 166 |
| 7 | 1000 / 7 = | 142 |
| 8 | 1000 / 8 = | 125 |
| 9 | 1000 / 9 = | 111 |
| 10 | 1000 / 10 = | 100 |
| 11 | 1000 / 11 = | 90 |
| 12 | 1000 / 12 = | 83 |
| 13 | 1000 / 13 = | 76 |
| 14 | 1000 / 14 = | 71 |
| 15 | 1000 / 15 = | 66 |
| 16 | 1000 / 16 = | 62 |
| 17 | 1000 / 17 = | 58 |
| ... | ||
| 32 | 1000 / 32 = | 31 |
| 33 | 1000 / 33 = | 30 |
| 34 | 1000 / 34 = | 29 |
Notes:
- Pmove_msec cannot take values below 8 (125 FPS) or above 33 (30 FPS).
- FPS values in the table above are "floored" (always rounded down), to fit the way the clients' framerate meter shows FPS.
- "90 FPS" physics is also referred as "91 Hz" physics: pmove_msec 11 equals to 90.90909090... frames-per-second (what one would obtain with com_maxpfs values between 84 and 90, in case of framerate-dependent physics. Setting com_maxfps 91, instead, would not be the same thing. See also Manual/Graphic options#Com_maxfps ranges and actual framerates.).
Accurate physics
Accurate physics solves the problems with fair gravity simulation by rather than ussing an integer number representation of the players positional data, it uses floating point numbers instead. Floating point numbers can hold fractional values, making it no longer necessary to do rounding of the players coordinates. It has been introduced with OpenArena 0.8.5. At standard 800 gravity, with "accurate" physics, jumps are slightly lower/shorter than "fixed 125 Hz" physics, and higher/longer than "fixed 90 Hz" physics.
Advantages
- Fair physics.
- No negative side effects like those of fixed frame rate physics.
- No choppy movement even if the client frame rates are unstable.
Drawbacks
- Seasoned players cannot jump as high and far as they are used to without tweaks by the server administrator.
- Some jumps and tricks on old maps (e.g. designed for 125 Hz physics) become impossible without tweaks by the server administrator.
- Sending floating point numbers over the network instead of integer numbers takes more bandwidth.
Configuration
The server can be configured to accurate physics by setting pmove_float to 1. Furthermore, it's strongly advisable to also set pmove_fixed to 0, as enabling it at the same time would not affect jump height, but would still cause the drawbacks from "fixed" physics.
Note: the server administrator can influence the jump height by tweaking the g_gravity value and setting up a custom map rotation script, with the g_gravity value set after the map command (because the game engine sets g_gravity to the value specified by the map designer). See g_gravity for some infos about how to integrate this in a map rotation script. Please notice that situations that cause a map restart (e.g. voting for a "shuffle" of the teams during team-based games) and do not trigger the map rotation script (e.g. manual map changes), will cause the gravity change back to map default until the new match ends and the map rotation script continues to the next map.
Starting with OpenArena 0.8.8, a g_gravitymodifier cvar has been introduced to solve the problem of having to set g_gravity for each map anew. This variable keeps the value you set for it until you set it to a different one, it's not automatically reset. "G_gravitymodifier 1" means "no change", while 1.2 means higher gravity (e.g. 800*1.2=960) and 0.8 means lower gravity (e.g. 800*0.8=640). If you manually change g_gravity, too, g_gravitymodifier will multiply that value instead of the default map gravity.
Experimentation with the g_gravity tweak led to values between 756 and 768 as being optimal for simulating 125 fps fixed framerate physics at 800 gravity, when using accurate physics instead.
This leads to values of 756 / 800 = 0.945, 757 / 800 = 0.94625 or 768 / 800 = 0.9475 for g_gravityModifier.
Note: the result will be the one expected (playing maps designed for 125 fps physics as they were meant, but using accurate physics) only if the original map gravity was 800 (most maps), and if you only tweak g_gravity or g_gravitymodifier; well, you could change both of them, but the result would change.
Since OpenArena 0.8.5, default values of the server-side variables are:
- pmove_float 1 // This means that Accurate physics is enabled by default.
- pmove_fixed 0 // This means that Fixed frame rate physics is disabled by default.
- pmove_msec 11 // This means that, if one would enable fixed-rate physics, it would be set to 90 FPS emulation by default. Not important when fixed frame rate physics is disabled. Trivia: in Q3A 1.32, default value was 8.
Changes to their values are immediately effective.
Tip: you can pull down the console, write pmove and press the TAB key to see your current values for all three of them at once, quickly determining the game physics type you are using.
It is also possible to select the game physics from the menu, when setting up a new skirmish or multiplayer match using the GUI. The "Game server" menu allows to cycle between the following "Physics" values: Accurate, Framerate dependent, Fixed framerate 125 Hz, Fixed framerate 91 Hz. Accurate is the default option.
Notes:
- Setting physics type from the GUI affects all three variables. If you change them manually, please remember that it's advisable to set pmove_fixed 0 when using pmove_float 1, because if both settings are set to 1, pmove_fixed will not affect jump height anymore, but will still cause the bad side effects from "fixed" physics!
- "Fixed framerate 125 Hz" option sets pmove_float to 0, pmove_fixed to 1 and pmove_msec to 8 (giving 125 FPS physics) and "Fixed framerate 91 Hz" option sets pmove_msec to 11 instead (giving 90 FPS physics). The name "91 Hz" is due to a frame every 11 milliseconds causes 90+10/11 effective FPS (or 90,90909090..., if you prefer), that is much closer to 91 than to 90 (but be aware that a com_maxfps 91 value, in a framerate-dependent server, would cause 100 FPS physics instead: it would be like pmove_msec 10 in a fixed-physics server). You can read Manual/Graphic options#Framerate and Manual/Graphic options#Com_maxfps ranges and actual framerates to better understand the relationship between 90, 90+10/11 and 91, and what's the rounding behind that.
Mods
Pmove_float (accurate physics) is OpenArena specific and not supported by most old mods designed for Q3A (which would just ignore its value). Pmove_fixed (fixed framerate physics) is supported by most mods, and framerate-dependent physics is probably supported by any mod[1].
Vanilla and CPM physics
One may find references to "Vanilla" (or "VanillaOA" or "VanillaQ3", thus also "VOA" or "VQ3") physics, opposed to "CPM" (or "CPMA" or "ProMode") physics. The first consists of classic physics and control responses that you can usually find in the standard game. The second consists of modified physics and control responses, to allow even more hardcore tricks, like more mid-air control; it comes from the Challenge ProMode Arena mod for Quake 3, and some more mods, like DeFRaG, implemented similarly modified physics (even if not from the same source code). At the moment, only Vanilla physics is available without the need of using mods. Note: differences between Vanilla and CPM physics are a different thing than the various kinds of rounding-error calculations explained in this page; CPM physics is a real (and intentional) gameplay modification provided by some mods.
Notes
- ↑ Unless mod authors decided to completely disable it for some fairness reasons.
See also
- Tweak
- Tweak#Tweaking online gaming parameters - Some infos about optimal settings.
- Manual/Graphic options#Framerate - When you are a client, it is important to select a framerate that your machine can provide constantly.
- Manual/Graphic options#Com_maxfps ranges and actual framerates
- Special game options#Game physics - Infos about variables that control in-game gravity, speed and knockback.
- Servers
- Manual/Multiplayer
- Configuration examples