game: Changing fixed physics added velocity to emulate framerate-dependent behavior

[ryzyk-krzysiek]

The idea behind it:

Framerate-dependent physics come from rounding velocity because of pm->ps->gravity * pml.frametime.
Gravity is 800 so at certain frametimes if the decimal places will be less than 0.5 the rounding will always be up.

For example at 125fps frametime = 0.008, 0.008 * 800 = 6.4
1st frame: 270 - 6.4 = 263.6 = 264 (rounding)
2nd frame: 264 - 6.4 = 257,6 = 258 (rounding)
3rd frame: 258 - 6.4 = 251,6 = 252 (rounding)
...

Some explanations of physics here too: https://www.youtube.com/watch?v=P13KmJBNn1c

The solution:

Check when the rounding up would happen and add the rounded up value, but scaled so clients various FPS is taken into account since it will be done on every frame.

I tested it against ETPro b_fixedPhysics, pmove_fixed and Legacy pmove_fixed and everything behaves the same as here(jump height, min height of box is 64u):

ETPRO and Legacy com_maxfps 125

fixedfps 30 - 64u
fixedfps 33 - none
fixedfps 40 - none
fixedfps 60 - none
fixedfps 71 - 64u
fixedfps 100 - none
fixedfps 120 - 66u
fixedfps 125 - 66u
fixedfps 200 - none
fixedfps 250 - 66u
fixedfps 333 - 72u

ETPRO and Legacy com_maxfps 200

fixedfps 30 - 64u
fixedfps 33 - none
fixedfps 40 - none
fixedfps 60 - none
fixedfps 71 - 64u
fixedfps 100 - none
fixedfps 120 - 66u
fixedfps 125 - 66u
fixedfps 200 - none
fixedfps 250 - 66u
fixedfps 333 - 72u

Map used for testing, big thanks to Aciz for making it!
pmove_debug.zip

refs #1379

[rmarquis]

@isRyven Could you do a quick review? You might be the most qualified here.
@ryzyk-krzysiek Many thanks!

[isRyven]

From brief review: is it correct that it only should "adjust" the z axis velocity? For a proper emulation wouldn't you need to correct all 3 axis (after all vector snapping affects the whole vector - meaning that rounding will happen for all 3 axis)?

[ryzyk-krzysiek]

I don't think it's the case.

I based it on etpro forums where they always state they adjust jump velocity / jump height no mention of other velocities. For example http://bani.anime.net/banimod/forums/viewtopic.php?t=4113

Another thing is just rounding is not enough for velocity to be framerate-dependent.

etlegacy/src/game/bg_slidemove.c

Line 75 in 4cff173

endVelocity[2] -= pm->ps->gravity * pml.frametime;

Because of fixed gravity and frametime and the fact that the velocity is rounded so it's always integer here it makes it so that at certain frametimes it will always get rounded up, because there is no variability. This part of code is only for z axis.

I haven't really checked out how other velocities work but the only place I can find without much checking is this

etlegacy/src/game/bg_pmove.c

Line 555 in 00b35a7

accelspeed = accel * pml.frametime * wishspeed;

wishspeed is I believe the player mouse movement, can't remember right now for sure, which is not a constant so the speed you add or subtract is not the same speed always like in the case of z axis.

I might check it later today and if not tomorrow, but I don't think it's is needed based on reasoning above (but it's not like I know everything so yea :d) and the fact that from not only my own test jump speeds are pmove_fixed like or b_fixedphysics like.

[Aciz]

Ryven has a good point. Velocity snapping affects all vectors, but this patch only touches Z vector. Even though it felt as it should for me when I was testing, some additional testing with X/Y vector speed should be done too.

[isRyven]

Yeah, basically the question would be, shouldn't x and y velocity now be frame dependent, and for instance on 333fps you should get bigger speed boost? Obviously this wouldn't match the original 333fps behavior, but still.

[Aciz]

Quick test: this patch allows for 3ups faster wallstrafing than should be possible. You should be able to only achieve 442ups while wallrunning, but this patch allows for ~445ups

Legacy with g_fixedphysicsfps 125
https://streamable.com/jq2aqr

ETJump with pmove_fixed 1
https://streamable.com/v6nw26

Adding result to all vectors with g_fixedphysicsfps 125 actually allows for even higher speed, around 449ups.

Edit: ETPro is consistent with ETJump here, also allows only 442ups.

[isRyven]

Yeah and i guess the effect is more visible with 333fps, i can get much more speed even by just strafing around on flat surface.
Btw @Aciz if you want to test the patch on etjump (as legacy seems utterly bad for this), you can get one from here https://github.com/isRyven/etjump/tree/ryzyk-fixed-physics (don't forget to disable pmove_fixed if you are using g_fixedphysics)

[ryzyk-krzysiek]

I get your points, but at the same time I don't see any difference in actual gameplay even when the numbers are different at least as of now.

The jump height looks fine with this and yet if you look at the z velocity it's different from pmove_fixed a bit anyway in simple jump up. If you compare the z velocity provided by Kimi from ETPro it's even worse. 1st frame on ETPro velocity is 271, when on pmove_fixed and this patch it's 264. Both solutions seem to work.

https://docs.google.com/spreadsheets/d/1UTf9bSpHZpS17_A-Ubgq-n7Wx2ImniZp7-rHa_kmxTw/edit?usp=sharing

There is no point adding that result to other velocities, they don't depend on gravity afaik, they are calculated differently.

I could try to figure out other velocities and adjust them too, but when looking at numbers even this solution is not exact pmove_fixed and for sure not ETPro b_fixedPhysics, so the chances I would get "correct" numbers for others are slim I think. As far as I can tell though, it works anyway.

[isRyven]

Yeah to be clear i have no issues with heights, it works quite good, i just had a concern about acceleration and friction which would remain without any special handling (unlike as it was before, and is in other mods). In essence even if there are differences with pmove they indeed are in some sort of tolerable range (especially taking into account the default 333fps range lock), actually perhaps we don't see big xy velocity boost because patch don't snap vectors anymore, and more accurate data is sent, also while jumping gammas i noticed it's actually much harded to jump with patch than with pmove, but difference ain't that big, not sure what to make out of it. I don't know if @Aciz performed any more extensive tests already, i'd leave the last word to him.

[ryzyk-krzysiek]

I did some additional testing mainly some longer jumps and I agree it is not perfect (when you look at the other velocities), but I believe it's good enough. I'm not the best strafejumper so it might not be the greatest comparison.

I tried simple jumps on adlernest from axis spawn and according to my tests this solution is closer to pmove_fixed 1 pmove_msec 8 than b_fixedphysics from ETPro.

https://streamable.com/e52g1j etpro b_fixedphysics 1 b_fixedphysicsfps 125
https://streamable.com/84rk8z etpro pmove_fixed 1 pmove_msec 8
https://streamable.com/598ihh legacy g_fixedphysics 1 g_fixedphysicsfps 125
https://streamable.com/ylc77w legacy pmove_fixed 1 pmove_msec 8

So the question is I think how close you want to get to pmove_fixed. Is being closer to it than b_fixedphysics from ETPro good enough? Which I believe is the case from above example.

I don't think it's something that would replace pmove_fixed from ETJump, but for gameplay that legacy mod targerts it's fine, where also the default value for g_fixedphysicsfps is 125 (others work too, at least when it comes jump height, but other velocities are ok too I believe).

[ryzyk-krzysiek]

More comparisons to etpro, there is almost no difference between b_fixedphysicsfps 125 and b_fixedphysicsfps 333, g_fixedphysicsfps 333 is pretty close to pmove_msec 3.

https://streamable.com/1v890q etjump pmove_fixed 1 pmove_msec 8
https://streamable.com/1476sj etpro b_fixedphysics 1 b_fixedphysicsfps 125 NOFATIGUE
https://streamable.com/45alj9 etpro pmove_fixed 1 pmove_msec 3
https://streamable.com/3zctz6 etpro b_fixedphysics 1 b_fixedphysicsfps 333
https://streamable.com/kcdhlz legacy g_fixedphysics 1 g_gixedphysicsfps 333