-
Notifications
You must be signed in to change notification settings - Fork 622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GoldSrc] Higher framerates slows down trigger_camera rotation #2924
Comments
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. |
Damn, now i know why i kept losing on my 15 yo HP recipebook |
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 EDIT: I typo'd |
Changing this to 30 frame per second is way too fast for trigger_camera. My fix is tested and working fine. |
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:
Lets set aside the issue with low framework being impacted by this change for a moment. You observed,
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 |
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. Here's my fix with 240FPS-in game. It represents actual trigger_camera with 30-60fps |
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. |
I've implemented a fix that fully decouples the camera from the framerate. Change this: Lines 2368 to 2369 in c7240b9
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 Specifically, this part: VectorMA (ent->v.angles, host_frametime, ent->v.avelocity, ent->v.angles); The angular velocity is applied using the frametime. When 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 The modified code is normalized to match frametime at 30 FPS. This can be tested on the map 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. |
Turns out it isn't necessary to calculate delta time here because the camera moves every frame anyway: Line 2379 in c7240b9
This ensures the think method runs immediately, so I've updated my post above to remove the unnecessary parts. |
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
to
The text was updated successfully, but these errors were encountered: