Halflife: [GoldSrc] Higher framerates slows down trigger_camera rotation

Created on 18 Jun 2020 · 9Comments · Source: ValveSoftware/halflife

Setting in-game FPS more than 99 FPS slows down rotation movement. Because camera's rotation depends on framerate.

This can be easily fixed by changing this line:

https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/dlls/triggers.cpp#L2369

pev->avelocity.y = dy * 40 * gpGlobals->frametime * 3;

Fix proposed

Source

BlackShadow

👍2

All 9 comments

hey, but this fixes the fps depency? if you play with low fps it moves more fast than it should be?

rtxa on 3 Jul 2020

hey, but this fixes the fps depency? if you play with low fps it moves more fast than it should be?

Yes it rotates in same speed without relying on FPS.

BlackShadow on 4 Jul 2020

👀2 👍1

Damn, now i know why i kept losing on my 15 yo HP recipebook

PRinceBhai on 4 Jul 2020

hey, but this fixes the fps depency? if you play with low fps it moves more fast than it should be?

Yes it rotates in same speed without relying on FPS.

well.. First, It's not a matter of yes or no if the question is posed in this manner. It would be improper to use existing code implementation as criteria or basis to how it 'should' or 'shouldn't' be @rtxa. Having said that, @BlackShadow , your proposed change clearly doesn't remove reliance on FPS; it may have the opposite desired effect with low fps - as it would 'speed up trigger_camera rotation'.

And of course, it's just arbitrary constant factor being proposed here. if framerate was 10 times higher, would we get this issue writeup again that purposes * 3 be changed to * 30?

EDIT: I typo'd trigger_camera

brcaswell on 9 Jul 2020

hey, but this fixes the fps depency? if you play with low fps it moves more fast than it should be?

Yes it rotates in same speed without relying on FPS.

well.. First, It's not a matter of yes or no if the question is posed in this manner. It would be improper to use existing code implementation as criteria or basis to how it 'should' or 'shouldn't' be @rtxa. Having said that, @BlackShadow , your proposed change clearly doesn't remove reliance on FPS; it may have the opposite desired effect with low fps - as it would 'speed up trigger_rotation'.

And of course, it's just arbitrary constant factor being proposed here. if framerate was 10 times higher, would we get this issue writeup again that purposes * 3 be changed to * 30?

Changing this to 30 frame per second is way too fast for trigger_camera. My fix is tested and working fine.

BlackShadow on 10 Jul 2020

😕1

haha.. did you really just respond with "It works on my machine" -_("/)_ /- ?

look, you observed an issue which may merit work (a change), and I would prefer these comments be about that issue - not your proposed changes. (they detract from the grooming effort on the issue)

We need a better algorithm that mitigates FPS differences here.

Having said that, your purposed changes have issues and they should be dismissed as a consideration:

Firstly, they don't address the issue you've observed, and
they have an impact that you aren't really all that considerate to, of, and\or on.

Lets set aside the issue with low framework being impacted by this change for a moment.

You observed,

Setting in-game FPS more than 99 FPS slows down rotation movement.

But your purposed change doesn't address that observation (the underline issue, behavior). It will continue to be slowed down, based on higher framerate compared to lower framerate.

So, the merit of your purposed change is actually to 'fix' the perceived slowness; or how it seems to 'you'; Which, of course, is quite a subjective notion and criteria. Since you have not actually provide much details (a scenario, your framerate, nor how fast you think it ought to be), both the issue your addressing with this 'fix' (which, again, isn't the observed behavior) and the perceived correct speed are just arbitrary at the moment.

Now, putting aside both the subjectivity and impact considerations of this proposed change (which, again, doesn't address the observed behavior issue), I actually raised a scenario that is in regards to making arbitrary code changes to address user perception issues. That is, setting it to more than 999 FPS slows it down even more, so the perceived slowness would be greater and observable (again), right?

aide from all that, a minor code review related issue with your proposed change - you should modify the existing multiplier const and not add a new factor (i.e. in pev->avelocity.y = dy * 40 * gpGlobals->frametime; the * 40 * 3 would be * 120). I'm sure the compiler would optimize this (depends on compiler and flagging perhaps); it isn't as much as a matter of performance as much as it is on code quality and with consideration to collaborative coding practices. To that point, I would actually prefer the 40 or 120 const value here be declared as a field somewhere and referenced in this scope.

brcaswell on 10 Jul 2020

I don't know what you really smoked before commenting on here. Setting it on 40 * 3 tells trigger_camera rotate 3 frame per second no matter what FPS is. It's not something "it worked on my machine" Camera speed is same on every FPS.

Here's your thing on 240FPS-in game.

It jitters with lots of motion sickness.

https://streamable.com/c3elnz

Here's my fix with 240FPS-in game.

It represents actual trigger_camera with 30-60fps

https://streamable.com/n9h30k

BlackShadow on 11 Jul 2020

You should use a fix like the one i proposed for the NPC turning rate issue to remove dependency on framerate. This isn't a fix.