[GoldSrc] Higher framerates slows down trigger_camera rotation

[BlackShadow]

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:

halflife/dlls/triggers.cpp

Line 2369 in c7240b9

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

to

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

[rtxa]

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

[BlackShadow]

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.

[PRinceBhai]

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

[brcaswell]

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

[BlackShadow]

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.

[brcaswell]

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.

[BlackShadow]

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

[SamVanheer]

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.

[BlackShadow]

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.

I checked again and it seems it didn't remove FPS dependency but actually fixes slow rotation in 60 to 300 FPS. Works but still not a viable fix.

[SamVanheer]

I've implemented a fix that fully decouples the camera from the framerate.

Change this:

halflife/dlls/triggers.cpp

Lines 2368 to 2369 in c7240b9

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

To this:

pev->avelocity.x = dx * 40 * 0.01;
pev->avelocity.y = dy * 40 * 0.01;

What this does is remove a duplicate application of frametime on the angular velocity.

Take a look at Quake's code for MOVETYPE_NOCLIP:
https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/sv_phys.c#L1165-L1182

Specifically, this part:

VectorMA (ent->v.angles, host_frametime, ent->v.avelocity, ent->v.angles);

The angular velocity is applied using the frametime. When trigger_camera sets the angular velocity in the original code it also applies the frametime to set the angular velocity to apply for the current frame.

The result is essentially this:

VectorMA (ent->v.angles, host_frametime * host_frametime, ent->v.avelocity, ent->v.angles);

Frametime is usually a small value like 0.01 at 30 FPS so this results in values like 0.0001. The higher the framerate the smaller the value becomes. At really high framerates (> 200 FPS) camera rotation starts to slow down, at 500 FPS it's visibly slower and at 1000 FPS it's almost frozen.

The modified code is normalized to match frametime at 30 FPS.

This can be tested on the map c2a3e, though it's best to enter through the scripted changelevel from c2a3d.
The rotation timings match the dialogue; the camera focuses on the grunt on the right for the first back and forth, then switches to the left grunt, back to the right, and then turns back to the left when the fade to black occurs.

Also, to be clear: the solution presented in the original post does not make it framerate-independent, it just changes the results to work properly at 3 times the FPS it was originally intended for.

[SamVanheer]

Turns out it isn't necessary to calculate delta time here because the camera moves every frame anyway:

halflife/dlls/triggers.cpp

Line 2379 in c7240b9

pev->nextthink = gpGlobals->time;

This ensures the think method runs immediately, so gpGlobals->frametime is equal to the calculated delta time.

I've updated my post above to remove the unnecessary parts.