player model shifted to the side when stop walking

Yamagi Burmeister

This is another incarnation of a problem that's sometimes called "zero has gravity", which is part of the bigger 125hz bug thing. It can be found an nearly all games based upon the several incarnations of the Quake engine, Quake II and it's direct descendant are affected more than Quake I and Quake III.

Quake II has a 3 dimensional coordinate system, reaching from -8192 to +8192 in each direction. I don't know why id Software chose to use negative coordinates, but from an outsiders viewpoint it wasn't a good decision. It complicates some things and makes physics behavior much more inexplicable. Additionally Quake II implements larger parts of the physics and movement calculations in floating point math, while the rest of the game is based upon integer math. There are at least two problem with using floats:

Floating point math is inaccurate, each calculation adds an error. Over time these errors accumulate more and more.
Floating point math is slow. The original Quake II code (I don't know if Daiktana did this, too) limited the floating point precision to 24 bit, causing much higher inaccuracies than with the x87 default precision of 80 bits.

In practice these inaccuracies aren't a big problem because the whole math is independent for each frame and some inaccuracies cancel themself out. Much more impact have the inaccuracies introduced by float -> int conversions. When a floating point number like 42.23 is converted into an integer, the decimal places are removed. The number becomes 42.

An example: The user moves, it's final x coordinate determined by the movement code is 23.56. When this final coordinate is transferred into the client die decimal places are lost, becoming just 23. The user just moved 0.56 units nearer to zero, from his viewpoint to the left. This can be seen at base1.bsp in Quake II. The starting point is right from zero, each movement puts the player somewhat to the left. Just going forward and backward will let you drift in that direction. The other side of the map, the big corridor connecting the start, the end and the outdoor area is at the left of zero. Each movement will drift the player to right.

(EDIT: Left and right seen from the player looking from the start to the exit, e.g. the landing pod is in the players back)

It's the same with jumps: Start coordinate 23 and target coordinate 15.42, after conversion just 15. The player jumps 0.42 units too far. On the other side from coordinate 23 to 42.81, after conversion just 42. The player jumps 0.81 too short.

Another big source for inaccuracies is Quake IIs rather "squishy" internal timing. A millisecond seen by the client may be in fact 0.9 milliseconds or 1.1 milliseconds. Quake II is synchronous, each render frame is a physics frame. Since the render framerate is not constant, the physics framerate isn't either. But movement predictions depend on the internal timing and the physics framerate. The more frames are rendered, the the higher the error. In Quake II with more than 90 FPS things start get fishy, over 120 FPS movement is more or less broken. This can be exploited for trickjumps, speedruns and the like.

2016-08-14T19:50:42+00:00

Comments (9)

Американский Шпион reporter
- edited description
- 2015-01-23T22:22:08+00:00
Frank Sapone
Need a video, I don't understand.
- 2016-07-31T06:23:32+00:00
Американский Шпион reporter
- attached drag.dem
- 2016-07-31T18:57:08+00:00
Американский Шпион reporter
Notice that I pressed only forward and backward buttons
- 2016-07-31T18:57:49+00:00
Yamagi Burmeister
This is another incarnation of a problem that's sometimes called "zero has gravity", which is part of the bigger 125hz bug thing. It can be found an nearly all games based upon the several incarnations of the Quake engine, Quake II and it's direct descendant are affected more than Quake I and Quake III.

Quake II has a 3 dimensional coordinate system, reaching from -8192 to +8192 in each direction. I don't know why id Software chose to use negative coordinates, but from an outsiders viewpoint it wasn't a good decision. It complicates some things and makes physics behavior much more inexplicable. Additionally Quake II implements larger parts of the physics and movement calculations in floating point math, while the rest of the game is based upon integer math. There are at least two problem with using floats:
- Floating point math is inaccurate, each calculation adds an error. Over time these errors accumulate more and more.
- Floating point math is slow. The original Quake II code (I don't know if Daiktana did this, too) limited the floating point precision to 24 bit, causing much higher inaccuracies than with the x87 default precision of 80 bits.
In practice these inaccuracies aren't a big problem because the whole math is independent for each frame and some inaccuracies cancel themself out. Much more impact have the inaccuracies introduced by float -> int conversions. When a floating point number like 42.23 is converted into an integer, the decimal places are removed. The number becomes 42.

An example: The user moves, it's final x coordinate determined by the movement code is 23.56. When this final coordinate is transferred into the client die decimal places are lost, becoming just 23. The user just moved 0.56 units nearer to zero, from his viewpoint to the left. This can be seen at base1.bsp in Quake II. The starting point is right from zero, each movement puts the player somewhat to the left. Just going forward and backward will let you drift in that direction. The other side of the map, the big corridor connecting the start, the end and the outdoor area is at the left of zero. Each movement will drift the player to right.

(EDIT: Left and right seen from the player looking from the start to the exit, e.g. the landing pod is in the players back)

It's the same with jumps: Start coordinate 23 and target coordinate 15.42, after conversion just 15. The player jumps 0.42 units too far. On the other side from coordinate 23 to 42.81, after conversion just 42. The player jumps 0.81 too short.

Another big source for inaccuracies is Quake IIs rather "squishy" internal timing. A millisecond seen by the client may be in fact 0.9 milliseconds or 1.1 milliseconds. Quake II is synchronous, each render frame is a physics frame. Since the render framerate is not constant, the physics framerate isn't either. But movement predictions depend on the internal timing and the physics framerate. The more frames are rendered, the the higher the error. In Quake II with more than 90 FPS things start get fishy, over 120 FPS movement is more or less broken. This can be exploited for trickjumps, speedruns and the like.
- 2016-08-14T19:50:42+00:00
Frank Sapone
I thought asynch rendering was supposed to combat this problem by separating the rendering frame and input/network frames. Or am I mistaken on something here?
- 2016-08-14T19:58:02+00:00
Yamagi Burmeister
Yes, async rendering combats the problem that movement and physics are depended on the frameware. But it doesn't help against the general inaccuracy.
- 2016-08-15T11:45:23+00:00
Frank Sapone
But, basically, it's probably safe to say this is a bug that will never be fixed in DK because the game is so fundamentally broken and relies on broken behaviour to even work in the first place.
- 2016-08-15T16:25:57+00:00
Frank Sapone
- changed status to wontfix
As Yamagi stated, this would be a huge undertaking. Likely breaking many things very subtly in the process.
- 2016-09-18T18:39:18+00:00
Log in to comment