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
Input sampled on wrong side of frame limiter #177
Comments
I believe in frame is called in main() after the com frame function so it happens after com frame takes place all together. |
Yes, it goes like thus:
And Com_Frame runs the framelimiter before thinking, which puts things in the wrong order. |
That's really no different from how quake3.exe does it though. |
That's right, vanilla quake 3 also has this problem. |
Is there any sort of fixes in cnq3 ? |
cnq3 somehow fixes mouse button inputs without fixing mouse movement or keyboard press inputs. |
Blunt test code here: youurayy@6908038 It's just Also tested at I'm gaming at 60Hz with GTX 980, and to me the improvement is incredible, there's just no way back. To me, the mouse movement now seems "glued" to the mouse, it's like a different game. I'm gaming with:
|
Alternate name for this issue: "Halving input latency after 17 years of Quake 3." |
Fixed in ead5478. Thanks. |
Test:
Expected behavior:
Gotten behavior:
The actual issue, from what I can tell, is that the framerate limiter is part of the thinking code itself, and the input is outside of that. Either IN_Frame would have to be shoved inside of Com_Frame, out of logical scope, or Com_Frame would have to be split up to different functions between framerate limiting and "thinking".
Why is this an issue? Some mods, like CPMA, forcibly limit framerate online. CPMA limits framerate to 125. This forces the total average input latency from the game to always be 12ms. On a machine with infinite processing power, with input sampled on the right side of the framerate limiter, the added input latency from 125fps should be 4ms, or half of the frame time, for continuous inputs. The difference is the 8ms added by basically delaying inputs for up to 1/125th of a second due to sampling them on the wrong side of the frame limiter. The added lag decreases as the FPS cap approaches the com_maxfps 0 framerate, but it's always there.
input -> limiter -> think -> repeat
The limiter sleeps between taking inputs and using them.
limiter -> input -> think -> repeat
The limiter correctly extends the thinking time on the end instead of the beginning.
The text was updated successfully, but these errors were encountered: