Fix pmove_fixed #70
Merged
Fix pmove_fixed #70
Conversation
This file contains hidden or 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
added 9 commits
July 30, 2025 10:50
adds access to cl_packetdelay which is normally cheat protected; useful for both testing and ping equalizing.
Add a new client `cl_maxfps` which allows specifying the maximum desired fps value; which may not be the same as the maximum allowed. `com_maxfps` is now derived from `cl_maxfps`. Current values are 250 when `pmove_fixed=1` and 125 when `pmove_fixed=0` The default value of `cl_maxfps -1` should probably be preferred because it just picks the best currently supported max. Future patches will raise this to 500 in the pmove_fixed=1 case.
- remove fudge factors for prediction being a rendered frame ahea and use the time from command frame directly. --> 0 error on prediction. - fix ancient nail bugs where they were not being correctly snapped - fix ancient nail bugs where original position was wrong for collision calcs
The introduced byteswap.h dependency isn't portable, use supported intrinsics
add upstream `pmove_float` (default on) which makes jump height no longer fps dependent. Previously this specific behavior resulted from accumulated errors on gravity truncation; resolve by not truncating gravity except for one case which otherwise results in erratic accel. Note: This doesnt fix other fps dependent accel
- not correctly executed under pmove_fixed - no reason to evaluate every _client_ frame - no reason to buffer underruns (client >1s stale has bigger problems) - merge per server frame checks
- remove client toggle (either it works for everyone or it's bugged and shouldn't be used) - remove realping, adds high per-frame overhead, not used - remove latency simulation, packetdelay exists and adds complexity to prediction cache / one less think to think about with pmove_fixed - move pmove_var fixup out of clientthink
pmove_fixed would previously incorrectly overlap and not handle certain frames due to treatment of time. Many frames being assigned the same time was resulting in inconsistent processing, caching, etc. pmove also segmented ranges awkwardly, e.g. (pmsec*n, pmsec*(n+1)], change this to [pmsec%n,pmsec*(n+1)) which brings mod range in congruence. Resolve this by making it an internal detail to pmove, allowing external code to behave independently wrt pmove_fixed being enabled.
When pmove_fixed is enable we want to generate interpolated subframes between movement frames so that we're updating the viewport at the intended rate (consider for example the case of walking in a straight line without moving mouse).
Member
|
Do we still want to wait for testing on this if a few games happen here or just merge now and move forward? |
Collaborator
Author
|
You might as well just go ahead and merge in. It's at least less broken than what is already there. In an ideal world I'd add the patches to get it to 500fps. Not sure if I have time unless games pick up again. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Raises FPS cap to 250 when active, 500 in subsequent patch extending command queue.