mirror of
https://github.com/tangerineturtle1/NX2navi.git
synced 2026-11-15 19:19:58 -04:00
4cbdecb64b
Above 60 fps players fell off moving platforms. The physics system takes its solver step count for a frame as trunc(frames per update * 4 + 0.001): 4 at 60 fps and 8 at 30, the rates the game ships with, but 3 from 61 to 80 fps, 2 to 120, 1 to 240 (144 solver steps a second at 144 fps against 240 at 60), and 0 in a frame shorter than a quarter of a 60 Hz frame. The solver skips its whole solve and sub-integration loop at 0, so such a frame resolves no contact or friction and moves no rigid body. At a 240 fps limit, which "unlimited" paces at too, that was the frame after every late one: the pacer keeps its phase, so the next display interval is shorter than the period. The new patch set osolver rounds the count up, ceil(frames per update * 4 - 0.25): 4 and 8 as before, never fewer steps a second than at 60 fps, at least 1. physics_steps = 0 gives the game's own count. The step itself was the mean of the last five display intervals and changed with every frame: intervals of 5 and 30 ms in turn gave steps of 15 and 20 ms in turn, and one 60 ms frame at 200 fps took the step from 5 to 16 ms for five frames. The game never saw a changing step on the console. The step is now the mean of the last 12 intervals without the longest and the shortest, is the pacer's period when within 3% of it (at a 60 fps limit exactly one frame, every frame), and repays the time the game was not given at up to a tenth of the step, so game time still follows the clock. It is at least 1/480 s. step_steady = 0 gives the mean of five again. With trace = perf the fps lines show the shortest and longest step and the time owed. tests/frame_step_check.py drives frame_rate.c with made-up display times and the rest of the runtime stubbed. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>