Fix FPS-dependent movement acceleration caused by ExtraMouseSample()#1949
Open
bjorn-martinsson wants to merge 1 commit into
Open
Fix FPS-dependent movement acceleration caused by ExtraMouseSample()#1949bjorn-martinsson wants to merge 1 commit into
bjorn-martinsson wants to merge 1 commit into
Conversation
This was referenced Jun 4, 2026
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
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.
This PR fixes the FPS-dependent movement acceleration bug described in ValveSoftware/Source-1-Games#8045.
The root cause is that
CInput::ExtraMouseSample()consumes movement key impulse state before it is processed byCInput::CreateMove(). SinceCInput::ExtraMouseSample()may run a different number of times depending on FPS, acceleration becomes both FPS-dependent and nondeterministic.This patch snapshots movement key state before
CInput::ExtraMouseSample()and restores it afterwards, preventing movement input from being consumed prematurely.In addition to fixing ordinary movement input, this also fixes the issue where tick taps (pressing and releasing a movement key within the same tick) randomly fail depending on FPS.
This is intentionally a minimal fix. A more complete solution would likely require redesigning parts of the Source 1 input system, which would be significantly more invasive and carry a greater risk of regressions.
The patch has been tested in TF2. Since the issue exists in shared Source 1 input code, it should also apply to other Source 1 games.
One consequence of this fix is that first-tick acceleration will consistently follow the original Source behavior of applying half acceleration on the first movement tick. Players who are accustomed to playing at high FPS may perceive this as a reduction in responsiveness, since the bug often caused full acceleration to be applied instead.
A second PR (#1950) builds on top of this one and changes the first-tick acceleration from half acceleration to full acceleration. The first PR can be merged independently. The follow-up PR cannot.