Frequently Asked Questions
Why Your Framerate Affects Jumping
|The information that follows was posted by Coriolis in the Quake3World General Discussion forum threads Why your framerate affects jumping! and The DEFINITIVE fps physics post. The posts explain how your FPS affects the 'jump' physics of Quake3 . Note that these do not apply when you are using the new 125HZ modification released 18.09.2000 and incorporated into OSP and Q3COMP. Any 1.27g or above server that has 125 Hz enabled server side is also not subject to the FPS physics issue. By default however 1.27g is set to disable 125 Hz server side. Thankyou to Coriolis for giving us permission to include this information. =)|
| posted 04-26-2001
Warning: Long / mathematical post, with pictures.
Well, I dived into the source code to see why your frame rate would affect how high / far you can jump. I will define "wu" as quake3 world units. From the source code, I got the following constants:
Gravity = 800 wu / s2
Quake3 has to model your velocity as a piecewise linear approximation to the actual curve, due to limited knowledge. Specifically, it doesn't know if you are going to hit a wall / missile / other player, or if you are going to use air acceleration to change directions. This means it cannot precalculate your entire path and just move you along it; it has to see what direction you are currently going and move you along that direction for a single time step. The time step (in seconds) is approximately 1 / frame rate. Time step is always less than 0.066 seconds.
I also found that, if g_syncronousClients is 0, the server uses the client's frame rate to get the time step for predicting the client's movement! This is probably to ensure consistency between client and server. It is crucial for frame-rate dependent jumps to work.
Recall from physics that gravity is an acceleration. It works on your z velocity vector. Quake3 uses the average vertical velocity over a time step, accounting for the change in velocity between the start and the end of the time step due to gravity. There is no cap on vertical velocity that I could see; air is frictionless, so you have no terminal velocity.
Black = ideal trajectory
As you can see, each trajector follows the ideal curve almost
exactly. This is not quite what I expected. Then I realized that space in the quake3 world
is discrete rather than continuous, so I repeated the experiment, this time clamping to
integer values. Using the same settings, I got these results:
So, the framerate dependency comes from two factors:
There is no way around either of these factors. The only thing you can do is make the time step a constant, but that would complicate the client-side rendering.
Okay, I stop typing now.
Edit: Made the second picture actually the second picture.
[This message has been edited by Coriolis (edited 04-26-2001).]
Contact Us | SavageUK | UpsetChaps
All Rights Reserved. Copyright � 1999-2007 Aqua & Requ!em