Fixes for FPS display, for #117 #118
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These only happen on connection/map change or maxfps change.
There's a case with cl_async=0 and cl_maxfps=0 such that physics run thousand times a second. This breaks down movement due to possibly `cl_maxpackets', `rate', or network bandwidth. This happens anytime the client isn't hosting the game. There's the same case with cl_async=1 but it's unreachable due to `QVF_VIDEOSYNC' not getting set anywhere. Having removed the bug and dead code, we can see that the `CL_Frame()' main loop can process several cases through the same logic if it's set up right in `CL_UpdateFrameTimes()'. - Reduce branching in the main loop. - Unify some cases that depended on stubbed code elsewhere and remove the stubs. There are more stubs that may complicate code paths elsewhere in the files that had the `VID_*' stuff stubbed. - Remove the duplicate enum elements. - Add some #define constants - `cl_maxfps 120' is really 125 Hz by virtue of rounding done in `fps_to_msec'. Adjust the value. Note that on Windows, SYNC_SLEEP_60 is inaccurate, resulting in 50 Hz rather than 60. It shouldn't be too tragic. While we could use `timeBeginPeriod()', let's leave it at that.
Due to millisecond-precision timekeeping, {cl,r}_maxfps only has few
distinct actual values. Different values will round off to one of these.
I don't think it's practical to expect users to know that implicit
rounding behavior. It's also not practical to rework the timekeeping
code from the ground up.
Potentially emit the message on direct maxfps change and on startup.
v2:
- Prevent logspam on focus change.
v3:
- Prevent logspam on `developer=2'.
- Remove effectively dead debug code.
- In half-initialized state we may have "msec" equal to zero inside
`warn_on_fps_rounding()' that needs guarding against. Happens when set
during `autoexec.cfg' invocation. The same will happen when using
cl_maxfps=0 for max Hz.
Thanks to @skullernet for extensive review.
In addition, cl_maxfps=0 w/ cl_async=1 now stands for maximum allowed Hz.
Also fix bogus warning if cvar value is negative.
main_extra grows too fast, it contains previously accumulated frames as well.
… frame is scheduled. For NVIDIA#117
This is probably what most people expect from an FPS counter.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contains the following changes:
SYNC_ASYNCcasemaxfps-related patches from Q2PRO. Notably, it contains a change to inform the user when the requestedmaxfpsvalue can not be achieved exactly.All in all, these changes should address the complaints from #117.