Repository navigation
fix(fp): a hit-stop never ends before its second frame (low fps caps) - #122
Merged
Merged
Conversation
Review of hit feel at the browser's 20-25 fps cap: the stop's clock is real time charged per rendered frame, and the frame a blow lands on charges the whole frame's span — so at 40-50 ms frames the short stops (a bite's 0.04 s, a weak animal hit's 0.03 s, at 25 fps even the weakest punch's 0.045 s) were spent before one frozen frame was drawn, and the stop vanished. Now a stop never ends before its second tick: one frame's overdraft holds it open, so every stop spans the frame it lands on plus one full frozen one. At 60 fps nothing changes (three 16 ms ticks already span two frames); at 20-25 fps every stop reads. Shake and kick decay were already frame-rate independent (exponential and linear in dt, clamped to MAX_FRAME_DELTA); the shake's 9 Hz/15.6 Hz wobble aliases past Nyquist at 20 fps, which reads as harsher jitter, not a lost effect — noted, not changed. fp_hitfeel's _real helper now ticks per frame, as production does, and a new _check_low_fps pins the floor at 20 fps and the unchanged few-frames read at 60 fps. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Automated reviewNo new findings on the 4 changed files (gdlint, complexity, TODO policy, dead code). Run |
fp_animal_hits drives the stop clock with one coarse tick(1.0) after a blow; the two-frame floor held that stop open and the scale never came back. A single frame longer than STOP_MAX has already displayed the frozen world for longer than any stop asks (a real hitch does the same), so it ends the stop on its own. The floor still covers the case it was for: frame-sized ticks at a 20-25 fps cap. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
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.
What
Round-4 impact item 7 — the hit-feel review at the 20-25 fps browser cap, and the one fix it found: short hit-stops vanished at coarse frame times. No flag (a feel fix, no gameplay change); everything else in the hit-feel path already holds up at coarse dt.
The review
MAX_FRAME_DELTA(0.1 s)The fix
A stop never ends before its second
tick(): one frame's overdraft (1e-4s) holds it open until then. Every stop now spans the frame it lands on plus one full frozen frame at any frame rate. At 60 fps behavior is unchanged — three 16 ms ticks already span two frames, and the stop durations are untouched.Tests
_check_low_fps: at 50 ms frames a 0.04 s stop still holds after the landing frame and ends a frame later; at 60 fps the same stop still reads as a few frames._real()now ticks in frame-sized steps, as production does (a single coarse call previously let one "frame" charge a whole second).Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>