Pages: [1]
  Print  
Author Topic: Why pmove_fixed is flawed ?  (Read 19563 times)
GrosBedo
Member


Cakes 20
Posts: 710


« on: June 20, 2010, 01:47:45 PM »

Hello there,

I would really like to setup fps independant physics on some servers, but the pmove_float var can't simulate 125 FPS physics currently (and changing gravity isn't effective as it has to be done at each map restart / map change), so Im falling back to the old pmove_fixed.

I have heard that it is fundamentally flawed, but why ? How exactly it is flawed ?
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #1 on: June 21, 2010, 12:40:34 PM »

It is me that has used the word "fundamentally flawed". It might have been an over statement but it does have some nasty bugs.

First it drops sound events if the physical framerate is below the pmove framerate. If the physical framerate is 62 and the game emulates 125 frames per second around half of all sound events will be lost (not sound effects, only events). This can properly be fixed by someone giving the necessary time.

More annoying is that running at a framerate different from the emulated framerate can cause some shutter. It is not a problem if running on the same framerate as the server emulates. It is not really noticeable if the reason for running a lower framerate due to your hardware because the hardware generates enough problems already. It is likely caused by rounding a different number of times in every frame. I believe this problem is near impossible to solve and the reason I use the word "fundamentally".
Logged

There are nothing offending in my posts.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #2 on: June 21, 2010, 03:38:25 PM »

Thank you very much for your reply Cheesy

I've got 2 more questions :

1. Where exactly does reside/how behave the rounding error ? What parameters can affect it : sv_fps, connection parameters client-side ?

The reason why I ask that is that the engine was found to have an unstable behaviour with some sv_fps values leading to a snaps packets drop (which are necessary for a stable physics calculation I guess).

More infos : http://forums.urbanterror.info/topic/19188-wierd-behavior-of-the-engine-snapss-perhaps-important/

2. How pmove_float address those issues and why can't it simulate 125 Hz framerate ?
Logged
Falkland
Member


Cakes 6
Posts: 590


« Reply #3 on: June 22, 2010, 09:27:40 AM »

1. Where exactly does reside/how behave the rounding error ? What parameters can affect it : sv_fps, connection parameters client-side ?

The reason why I ask that is that the engine was found to have an unstable behaviour with some sv_fps values leading to a snaps packets drop (which are necessary for a stable physics calculation I guess).

More infos : http://forums.urbanterror.info/topic/19188-wierd-behavior-of-the-engine-snapss-perhaps-important/


I've read this UrT forum post sometimes ago and I should have reported here in the forum ( about some magic values that don't take to snaps loss ) : in particular I've tested on a Q3 CPMA local server in duel against a bot ( rat.75 ) : what I've noticed is that the game is much more consistent while sv_fps has a magic value ( 25 or 125 ). Lucky shots had a notable decrease and I had to be much more accurate to hit enemy ; both the server and my client showed a little bit lower CPU use .

I've also proposed to eliminate snaps client cvar by the engine and to permit clients to automatically tune themselves to server's sv_fps ( like in CPMA ) so to eliminate the possibility to client voluntary cause artificial lags/connection errors "on request" - with a bind - when it is needed.

Anyway rounding errors could be the cause also of other kind of hit and pickup issue eg this

This issue happened few times for me and conducting me to wrongly affirm that a direct RL hit can take more than 100hp of damage. But anyway I wasn't able to serially reproduce it .

In particular this happened some times ago while I was playing against Kakashi , before he joined beta,Squad ( maybe he could remember or not :/  ) :
Quote from: Falkland
[..] And [..] another action happened in an OA071 duel in which I've fragged my opponent with a single rocket in aggressor map while he was jumping over the YA near the teleport to RG and after he had picked up the MH. (We both had quite the same ping )

My point is that rounding errors ( which regard other part of the engine and the VM ) can cause different kind of issue which could depend on the rounded mode performed by the specific machine , by the specific OS or C-lib installed , by the specific compiler conformance to a particular C standard ( in particular I've read they've dropped MSVC support to compile UrT engine and they only use mingw+gcc at the moment : http://www.www0.org/w/Optimized_executable%3b_builds_of_ioq3_engine_for_urt ), by the network connection conditions ...

This topic is started to currently be discussed also on ioquake3 mailing lists.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #4 on: June 22, 2010, 11:04:10 AM »

1. Where exactly does reside/how behave the rounding error ? What parameters can affect it : sv_fps, connection parameters client-side ?

The reason why I ask that is that the engine was found to have an unstable behaviour with some sv_fps values leading to a snaps packets drop (which are necessary for a stable physics calculation I guess).

More infos : http://forums.urbanterror.info/topic/19188-wierd-behavior-of-the-engine-snapss-perhaps-important/


I've read this UrT forum post sometimes ago and I should have reported here in the forum ( about some magic values that don't take to snaps loss ) : in particular I've tested on a Q3 CPMA local server in duel against a bot ( rat.75 ) : what I've noticed is that the game is much more consistent while sv_fps has a magic value ( 25 or 125 ). Lucky shots had a notable decrease and I had to be much more accurate to hit enemy ; both the server and my client showed a little bit lower CPU use .

That's why it's already in use in OA-CL 2010 official servers Wink

Thank you very much for your details, this enlighten me quite a lot, confirming me that the game calculation are more stable, but I didn't anticipated that it would reduce lucky shots and require players to have a more precise aim ! This explains some feedbacks we had from some players.

I've also proposed to eliminate snaps client cvar by the engine and to permit clients to automatically tune themselves to server's sv_fps ( like in CPMA ) so to eliminate the possibility to client voluntary cause artificial lags/connection errors "on request" - with a bind - when it is needed.

I fully agree. Would avoid a possible cheat and profit to inexperienced players since they wouldn't have to set manually their snaps for each server.

Another good thing would be to set sv_fps as a public, server var by default so people can know what snaps to set to (currently you have to ask the server admin, or the server admin can set it with sets sv_fps 25 as a workaround to make it public).

My point is that rounding errors ( which regard other part of the engine and the VM ) can cause different kind of issue which could depend on the rounded mode performed by the specific machine , by the specific OS or C-lib installed , by the specific compiler conformance to a particular C standard ( in particular I've read they've dropped MSVC support to compile UrT engine and they only use mingw+gcc at the moment : http://www.www0.org/w/Optimized_executable%3b_builds_of_ioq3_engine_for_urt ), by the network connection conditions ...


That's what I hope for about pmove_fixed. I guess we'll just have to test it and see if that just works XD

This topic is started to currently be discussed also on ioquake3 mailing lists.

Very interesting, have you got a link ?
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #5 on: June 22, 2010, 12:04:16 PM »

pmove_fixed physics is highly depended on g_gravity. On a low gravity map with g_gravity around 760 you can jump higher with a framerate of 91 than 125 because at that gravity the rounding error goes the other way.

Quote
2. How pmove_float address those issues and why can't it simulate 125 Hz framerate ?
There are no longer any rounding and therefore no rounding errors. You can lower gravity as suggested. During test I did not notice that g_Gravity is reset on every map change. I might add a g_gravity_modifier for that.

Some might notice that vertical speed is also higher on 125 fps but I believe that is only affected indirectly because you can gain more speed with more airtime. Normally vertical acceleration will even itself out because unlike gravity it is not constant.

It should be noted that pmove_float is not without downsides either because it makes the snaps harder to compress and therefor uses more bandwidth.

When I first read Falklands links about sv_fps I did try it and did notice the effect. Unfortunately there are few variables that can be increased without some sacrifice. The extrapolation code used by the original game was not well suited for larger values (there was a tolerance of 1 missing packet). The delag code by Neil “haste” Toronto (has been integrated in baseoa since 0.7.6) makes it possible to loose more packets by letting the server do the extrapolation with a larger dataset.
 
The net variables are even worse these days mostly because of the annoying wireless networks that are spreading more and more (I still prefer cable myself). Some high speed wireless algorithms might join packets in batches to increase throughput at the expense of latency. That problem did not exist in the old days back then larger throughput meant smaller queues and therefor less latency. And I do not put much faith in Quality of Service rules to make up for it in the near future. 
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4384


WWW
« Reply #6 on: June 22, 2010, 02:46:22 PM »

During test I did not notice that g_Gravity is reset on every map change.
I was testing some map rotation configurations, and I wanted to automatically change speed and gravity between the rounds. I had to do various tries before finding a way to have it working.

Using for example
Code:
set d2 "g_speed 280; g_gravity 600; map am_galmevish; set nextmap vstr d3"
does not work (speed is really 280, but gravity is set back to 800)
Code:
set d2 "map_restart; set nextmap vstr d3; g_speed 280; g_gravity 600"
does not work (speed is really 280, but gravity is set back to 800)
Code:
set d2 "map am_galmevish; set nextmap vstr d3; g_speed 280; g_gravity 600"
works (speed is really 280 and gravity is really 600).
So, to be able to set the gravity, we have to use two workarounds at the same time: put g_gravity after "map" command, and always use "map" also when you usually could use "map_restart"...

Some fix could be nice! ^_^
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
RMF
Member


Cakes 12
Posts: 694



« Reply #7 on: June 23, 2010, 12:11:24 AM »

oh well why fix it if it works with in a little bit different order (which I always just used anyway)
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4384


WWW
« Reply #8 on: June 23, 2010, 02:11:30 AM »

oh well why fix it if it works with in a little bit different order (which I always just used anyway)
Because with "map_restart" it does not work at all...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #9 on: June 25, 2010, 04:38:20 AM »

During test I did not notice that g_Gravity is reset on every map change.
I was testing some map rotation configurations, and I wanted to automatically change speed and gravity between the rounds. I had to do various tries before finding a way to have it working.

That's normal, default gravity setting is contained in maps directly, so when you load a map, it will load that settings (and some others), so to change the gravity you have to set it after the map loading.

The problem is not in map rotations, there is indeed a way to work it out (even it's not optimized -> you have to add a set gravity at each map rotation), but the problem resides when you do map / map_restart : when restarting matchs, we noticed that the gravity was reset to map's default value.

pmove_fixed physics is highly depended on g_gravity. On a low gravity map with g_gravity around 760 you can jump higher with a framerate of 91 than 125 because at that gravity the rounding error goes the other way.

What do you talk about when you say that "with g_gravity around 760 you can jump higher with a framerate of 91 than 125", did you mean the serverside fps physics emulation (with pmove_fixed 1 and pmove_msec 11) or the client com_maxfps ? Because I thought that this var enforced the physics on all clients to be the same, indepently of the clients' fps !

Quote
2. How pmove_float address those issues and why can't it simulate 125 Hz framerate ?
There are no longer any rounding and therefore no rounding errors. You can lower gravity as suggested. During test I did not notice that g_Gravity is reset on every map change. I might add a g_gravity_modifier for that.

That would do the trick indeed, but some maps have a higher gravity, some others lower, so how can the modifier be constant enough to consistently reproduce the 125Hz framerate physics ?

Some might notice that vertical speed is also higher on 125 fps but I believe that is only affected indirectly because you can gain more speed with more airtime. Normally vertical acceleration will even itself out because unlike gravity it is not constant.

Indeed, I can assure that there is no boost in any speed, the only thing that change is the jump height. So with more airtime you can indeed gain more speed, but it depends on the map : on aggressor for example, having 333 FPS will do the inverse since the map is made of small corridor, longer jumps do not serve you much and actually do the inverse (you loose speed because you don't touch ground at the right time and can't do a turn).

It should be noted that pmove_float is not without downsides either because it makes the snaps harder to compress and therefor uses more bandwidth.

Very interesting. Can you give an estimation about how much more bandwidth is required ?

When I first read Falklands links about sv_fps I did try it and did notice the effect. Unfortunately there are few variables that can be increased without some sacrifice. The extrapolation code used by the original game was not well suited for larger values (there was a tolerance of 1 missing packet). The delag code by Neil “haste” Toronto (has been integrated in baseoa since 0.7.6) makes it possible to loose more packets by letting the server do the extrapolation with a larger dataset.

In the end, do you think that increasing sv_fps to 25 is a valuable change, worth the network load increase ?

From what I know, most competition oriented servers like RN, ROFL or super are based on 40 sv_fps because it was believed to enhance the network stability a lot for players who would set snaps 40. In the light of those articles, by setting sv_fps 25 would benefit a much more stable connection while decreasing the network load for those servers.
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #10 on: June 25, 2010, 09:52:58 AM »


pmove_fixed physics is highly depended on g_gravity. On a low gravity map with g_gravity around 760 you can jump higher with a framerate of 91 than 125 because at that gravity the rounding error goes the other way.

What do you talk about when you say that "with g_gravity around 760 you can jump higher with a framerate of 91 than 125", did you mean the serverside fps physics emulation (with pmove_fixed 1 and pmove_msec 11) or the client com_maxfps ? Because I thought that this var enforced the physics on all clients to be the same, indepently of the clients' fps !

Quote
2. How pmove_float address those issues and why can't it simulate 125 Hz framerate ?
There are no longer any rounding and therefore no rounding errors. You can lower gravity as suggested. During test I did not notice that g_Gravity is reset on every map change. I might add a g_gravity_modifier for that.

That would do the trick indeed, but some maps have a higher gravity, some others lower, so how can the modifier be constant enough to consistently reproduce the 125Hz framerate physics ?

It should be noted that pmove_float is not without downsides either because it makes the snaps harder to compress and therefor uses more bandwidth.

Very interesting. Can you give an estimation about how much more bandwidth is required ?

When I first read Falklands links about sv_fps I did try it and did notice the effect. Unfortunately there are few variables that can be increased without some sacrifice. The extrapolation code used by the original game was not well suited for larger values (there was a tolerance of 1 missing packet). The delag code by Neil “haste” Toronto (has been integrated in baseoa since 0.7.6) makes it possible to loose more packets by letting the server do the extrapolation with a larger dataset.

In the end, do you think that increasing sv_fps to 25 is a valuable change, worth the network load increase ?

From what I know, most competition oriented servers like RN, ROFL or super are based on 40 sv_fps because it was believed to enhance the network stability a lot for players who would set snaps 40. In the light of those articles, by setting sv_fps 25 would benefit a much more stable connection while decreasing the network load for those servers.
1. Emulated 91 Hz with pmove_fixed+pmove_msec 11 or com_maxfps 85 with no pmove at all.

2. No, but at other gravities players that used to play with com_maxfps 85 might complain that they could no longer jump as high as before because. It would always emulate the best fps available.

3. pmove_float will use up to 32 times as much bandwidth in the extreme case. Or make absolutely no difference in other cases. I read somewhere that it usually requires around 2k bit/s in the average case but I did not have the data used for that calculation.

4. There can also be some benefits in having numbers that are related like 40=20*2=4*10 while 25 might be bad because: 25 != 2*12. In some cases the client will automatically (and silently) adjust some parameters if they are not related but I do not remember if snaps is one of them.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4384


WWW
« Reply #11 on: June 25, 2010, 10:18:32 AM »

iD Software (and derived) engines & games' powerful console commands are both a great thing and a trouble... :-)
"Having too many options is like having none...." ^_^

Anyway, Sago, do you think it is possible to do something for the next release, to have the ability to have something like
set d2 "map_restart; set nextmap vstr d3; g_speed 280; g_gravity 600"
work, as
set d2 "map am_galmevish; set nextmap vstr d3; g_speed 280; g_gravity 600"
does?

Now I understand why g_gravity has to be placed after "map" command (because gravity is set within the map itself), but why doing it with "map_restart" does not work?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #12 on: June 26, 2010, 04:20:16 AM »

If I'm not wrong, map_restart has a countdown. It executes the following commands meanwhile and only then it changes map.

ROFL has default snap values (20), I didn't play with it because I was fearing they could harm people with average connections, and because snaps is not set automatically by the client.
Logged

Todo: Walk the cat.
Gig
In the year 3000
***

Cakes 45
Posts: 4384


WWW
« Reply #13 on: June 26, 2010, 05:47:49 AM »

If I'm not wrong, map_restart has a countdown. It executes the following commands meanwhile and only then it changes map.

ROFL has default snap values (20), I didn't play with it because I was fearing they could harm people with average connections, and because snaps is not set automatically by the client.

So I should insert a "wait" command to execute it about 5-6 seconds later? But since, "wait" command pause is counted "frames"... I suppose this pause varies very much depending of the client. Using it server-side, what will do? Depending from sv_fps? If sv_fps is 20, a "wait" of 100 will be 5 seconds?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #14 on: June 26, 2010, 07:25:48 AM »

Rather, don't use map_restart, and use map instead Smiley

Personally I have no use of map_restart when writing a map rotation, though the problem mentionned by GrosBedo (no more custom gravity when map_restart is called from within a vote) still holds. It is indeed a problem. As Sago suggested, a g_gravity_delta which would affect g_gravity but would remain would solve it ?

If pmove_float (to have a consistent playing experience) and that gravity modifier (to suit to map jumping requirements) sound like a definitive solution, I'd say we should go for it, at least it could be tested. Actually I only modify gravity on the few maps which need it (ps37ctf), rather than on every map.
Logged

Todo: Walk the cat.
Falkland
Member


Cakes 6
Posts: 590


« Reply #15 on: June 26, 2010, 10:38:05 AM »

Very interesting, have you got a link ?

I've lost the main link ( maybe not on ioquake3 ML ) in which someone has pointed that with ioquake3 some kind of walljump are possible in baseq3 while they are not with q3 1.32b ... anyway the behaviuor ( about snaps magic value ) is reported on the ioquake3 BUGLIST . No any response yet.

- http://bugzilla.icculus.org/show_bug.cgi?id=4351
- http://bugzilla.icculus.org/show_bug.cgi?id=4345

About the rounding errors in general there was someone pointing the attention over an old ( SGI Graphics ) rounding/approximation function and asking about the possible implications : http://lists.ioquake.org/pipermail/ioquake3-ioquake.org/2010-May/004168.html

[...]
The net variables are even worse these days mostly because of the annoying wireless networks that are spreading more and more (I still prefer cable myself). Some high speed wireless algorithms might join packets in batches to increase throughput at the expense of latency. That problem did not exist in the old days back then larger throughput meant smaller queues and therefor less latency. And I do not put much faith in Quality of Service rules to make up for it in the near future.

There is actually the Datagram Congestion Control Protocol (DCCP) , an experimental protocols that could bring some benefits to online gaming ... but as now it's only an interesting reading since it's a real revolution and its implementation is only available on linux kernel :
- http://www.ietf.org/rfc/rfc4340.txt
- http://www.ietf.org/rfc/rfc4342.txt

Another interesting protocol is UDT ( UDP-based Data Transfer ) which is actually implemented in userspace and it performes better on high or very high load.

Anyway both protocol "resides" in the experimental territory and they still are unproposable projects.

4. There can also be some benefits in having numbers that are related like 40=20*2=4*10 while 25 might be bad because: 25 != 2*12. In some cases the client will automatically (and silently) adjust some parameters if they are not related but I do not remember if snaps is one of them.

I've seen only 2 checks about snaps in the server code :
1. when client snaps is higher than 30 , the value is automatically set to 30
2. when client snaps is a negative value , the value is set automatically to 1 !!! ( Huh )

In practice snaps value can be changed by user and in game to a whatever value between 1 and 30. Maybe it's changed back to an acceptable/default value after map change but I am not sure about it.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #16 on: July 01, 2010, 04:58:49 PM »

I've seen only 2 checks about snaps in the server code :
1. when client snaps is higher than 30 , the value is automatically set to 30
2. when client snaps is a negative value , the value is set automatically to 1 !!! ( Huh )

In practice snaps value can be changed by user and in game to a whatever value between 1 and 30. Maybe it's changed back to an acceptable/default value after map change but I am not sure about it.

Are you sure of this information ? Can you post the code snippet ? Because if that's true, it would mean that most servers and client configurations are badly wrong !

Quote from: Cacatoes
As Sago suggested, a g_gravity_delta which would affect g_gravity but would remain would solve it ?

I don't think this is a solution since the gravity is not homogenous amongst maps, particularly the space ones where gravity is generally lower. A gravity delta modifier would solve the problem for most maps, those maps with normal gravity, but not for the ones with a different gravity, so I don't think this would be a good solution.

@Sago : isn't it possible to make a new var like pmove_float_msec that would behave like pmove_msec for pmove_fixed, to configure how pmove_float behave ?

Another thing : I've heard that on 0.8.5 the client's settings should correct themselves on each map load, and so the client should receive the server's pmove_* cvars on each warmup/change, so this would mean that pmove_fixed should be much more stable and not editable clientside. Is it true ?
Logged
Falkland
Member


Cakes 6
Posts: 590


« Reply #17 on: July 01, 2010, 07:04:34 PM »

I've seen only 2 checks about snaps in the server code :
1. when client snaps is higher than 30 , the value is automatically set to 30
2. when client snaps is a negative value , the value is set automatically to 1 !!! ( Huh )

In practice snaps value can be changed by user and in game to a whatever value between 1 and 30. Maybe it's changed back to an acceptable/default value after map change but I am not sure about it.

Are you sure of this information ? Can you post the code snippet ? Because if that's true, it would mean that most servers and client configurations are badly wrong !

I was only partially wrong because if snaps is higher than sv_fps , it's set to sv_fps ( 30 is the max allowed value for cl_timenudge indeed ) but yes , as now snaps can be variable between 1 and sv_fps in game .

Code:

// snaps command
val = Info_ValueForKey (cl->userinfo, "snaps");
if (strlen(val)) {
i = atoi(val);
if ( i < 1 ) {
i = 1;
} else if ( i > sv_fps->integer ) {
i = sv_fps->integer;
}


I've proposed at least a patch to set snaps equal to sv_fps also when clients try to use a lower value  ( http://rainbow.furver.se/index.php?name=Forums&file=viewtopic&t=1445#8548 )

Code:
--- code/server/sv_client.c 2009-01-18 18:42:24.000000000 +0100
+++ code/server/sv_client.c 2009-02-02 00:59:04.000000000 +0100
@@ -1378,8 +1378,8 @@
        val = Info_ValueForKey (cl->userinfo, "snaps");
        if (strlen(val)) {
                i = atoi(val);
-               if ( i < 1 ) {
-                       i = 1;
+               if ( i < sv_fps->integer) {
+                       i = sv_fps->integer;
                } else if ( i > sv_fps->integer ) {
                        i = sv_fps->integer;
                }
« Last Edit: July 01, 2010, 07:20:54 PM by Falkland » Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #18 on: July 23, 2010, 12:07:40 PM »

pmove_fixed physics is highly depended on g_gravity. On a low gravity map with g_gravity around 760 you can jump higher with a framerate of 91 than 125 because at that gravity the rounding error goes the other way.

I now understand, I have re-read the original papers about the calculation of those rounding errors that produce the FPS-dependant physics behaviour :

http://web.archive.org/web/20071029155302/http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html
http://web.archive.org/web/20080514005858/http://www.quake3world.com/ubb/Archives/Archive-000001/HTML/20000822-3-015173.html

If gravity gets changed, the rounding error calculation gets changed too, so with the same FPS but different gravities, you will get different behaviours (with 800 gravity and 125 FPS, positive error = you gain jumping height ; with 760 and 125 FPS you get negative error = you loose jumping height).
« Last Edit: July 23, 2010, 12:29:07 PM by GrosBedo » Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #19 on: July 25, 2010, 04:52:45 PM »

Interesting post about pmove_fixed and b_fixedphysics in another game :

http://bani.anime.net/banimod/forums/viewtopic.php?t=4096

Quote from: Rain
Since Quake 3, the function that's responsible for game physics (amongst other things) is named Pmove(). Normally, this function is run once every client frame, and this is where framerate-dependant physics (most notably jump heights) come from. pmove_fixed is an attempt to level the playing field by running this function at a fixed rate (every pmove_msec milliseconds.) The default pmove_msec of 8 is equivalent to normal physics at 1000 / 8 = 125 frames/second.

pmove_fixed can be set on either the client or the server--the client will default to the value on the server (and, on non-etpro servers, it'll be reset to the server's value quite frequently due to some silliness in the code.) pmove_msec can only be set on the server side.

b_fixedphysics (which you didn't specifically ask about, but is worth mentioning) is a server-side setting with similar goals to pmove_fixed. b_fixedphysics 1 avoids rounding the velocity at all (removing the framerate-dependent behavior in movement); however, it offers b_fixedphysicsfps to adjust the jump velocity to emulate the old framerate-dependent behavior. This is the best of both worlds�no movement speed problems (as several people observed at 333fps) nor any of the problems that pmove_fixed brings with it (some parts of the game behave poorly at high fps, most notably mounted MG42 and mortar aiming), but the same jump heights trickjumpers would kill us for taking away. Silly b_fixedphysics 2 is a cross between normal behavior and fixed behavior, which effectively just caps the maximum framerate-dependent behavior to 166fps.

b_optimizedprediction is a client-side setting that (theoretically) has no effect other than increasing performance. Basically, etmain (and RTCW, and Q3) will re-do all the physics computations for up to the previous 64 frames in order to figure out where you should be for the current one. b_optimizedprediction will store the result of the previous computations and reuse them (if the results look acceptable based on the latest data the client has from the server) instead of doing all the math again. This provides a rather dramatic performance boost, especially if you have a high ping.

Another one about pmove_accurate :
http://clanarena.org/arena/forum/posts/id_10/title_-connect-q3eu-com/

Quote
cg_pmove_fixed (default = 1)
   Previously, every player was forced to accept the server's pmove_fixed setting.
   Now a player may set cg_pmove_fixed to "0" to override that. Note that to use pmove_fixed it still must be
   enabled on the server.
   0 - disable pmove_fixed
   1 - enable pmove_fixed ( id default )
   2 - enable pmove_accurate

   pmove_accurate :
   This is an alternative to pmove_fixed. pmove_fixed has issues - namely occasional frames going by without a
   player state change (which can make the game stutter a bit), and some slight (very slight) aiming issues.
   pmove_accurate addresses framerate-dependent behavior by eliminating rounding error rather than forcing
   all movement into frames of constant duration - which does not create the same problems as pmove_fixed does.
   It also takes a little less processing time to advance a player than pmove_fixed does, both on the client
   and on the server.
   cg_pmove_fixed feels almost exactly like pmove_fixed 1, pmove_msec 8. You should probably only disable it
   if you have serious incoming bandwidth issues (cg_pmove_accurate takes up to about 50 bytes/sec of bandwidth),
   or if the very slight difference between it and pmove_fixed (or normal, framerate-dependent movement) bothers you.
Logged
Falkland
Member


Cakes 6
Posts: 590


« Reply #20 on: July 25, 2010, 05:12:28 PM »

[...]
Another one about pmove_accurate :
http://clanarena.org/arena/forum/posts/id_10/title_-connect-q3eu-com/

Quote
cg_pmove_fixed (default = 1)
   Previously, every player was forced to accept the server's pmove_fixed setting.
   Now a player may set cg_pmove_fixed to "0" to override that. Note that to use pmove_fixed it still must be
   enabled on the server.
   0 - disable pmove_fixed
   1 - enable pmove_fixed ( id default )
   2 - enable pmove_accurate

   pmove_accurate :
   This is an alternative to pmove_fixed.
   [...]

cg_pmove_fixed is disabled in ioquake3 and anyway pmove_accurate is available only in xbattle mod. But its description makes me thinking it has the same behaviour than OA pmove_float ( pmove_float doesn't deal with anything that "floats" : float suffix is referring to the use of floating point precision for calculation instead of integer that IS the cause of physics rounding errors).
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #21 on: July 28, 2010, 07:06:21 PM »

Exactly, that was the point. But they succeeded in simulating the 125 FPS gravity. And it seems that the one implemented for ET Pro is the most advanced one since it's configurable.

So there's hope.
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #22 on: July 29, 2010, 08:11:36 AM »

There is a g_gravityModifier in a recent OAX-commit. But getting the right value might require some time.
Logged

There are nothing offending in my posts.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #23 on: July 29, 2010, 07:57:37 PM »

There is a g_gravityModifier in a recent OAX-commit. But getting the right value might require some time.

Good news Cheesy
Logged
Pages: [1]
  Print  
 
Jump to: