# Game + Physics time steps BETA testing **URL:** \ **Category:** Announcements\ **Created:** [March 14, 2022, 9:29am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539 "2022-03-14T09:29:24Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 14, 2022, 9:29am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/1 "2022-03-14T09:29:25Z")
On the dev branch (the alpha version of the editor), we now have support for fixed time steps for the physics, and also variable framerate for the game loop. Our goal was to solve the framerate issues our users have experienced on machines with displays that runs faster than 60Hz. We’d like for you to test these settings to make sure that they work as intended for your use cases. These are the relevant settings: - `physics.update_frequency` - `display.update_frequency` (integer) - `display.swap_interval` - ~~`display.vsync`~~ (DEPRECATED) - Use the [sys.set\_update\_frequency(hz)](https://defold.com/ref/stable/sys/?q=set_update_frequency#sys.set_update_frequency:frequency) to control the “display.update\_frequency” at runtime. Here’s the alpha build: > **[Release v1.3.1 - alpha · defold/defold](https://github.com/defold/defold/releases/tag/1.3.1-alpha)** > > Defold version 1.3.1 channel=alpha sha1=f3e760de84133e467775cf7ae2a04c8c96b4965b date='2022-04-04 13:16:08' ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 14, 2022, 10:34am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/2 "2022-03-14T10:34:32Z")
---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 17, 2022, 3:33pm UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/3 "2022-03-17T15:33:59Z")
We haven’t heard feedback regarding this, so we’re not sure if all is working as expected, or if there are any issues. Note that these features will land in the Beta on monday. ---
**Author:** ![aglitchman](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/aglitchman/32/19432_2.png) [@aglitchman](https://forum.defold.com/u/aglitchman)\ **Post date:** [March 17, 2022, 4:19pm UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/4 "2022-03-17T16:19:02Z")
> [@Mathias\_Westerdahl](#): > > We haven’t heard feedback regarding this, so we’re not sure if all is working as expected, or if there are any issues. I will test it after DefoldCon, so expect my feedback soon! 😀 ---
**Author:** ![dapetcu21](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/dapetcu21/32/25120_2.png) [@dapetcu21](https://forum.defold.com/u/dapetcu21)\ **Post date:** [March 18, 2022, 5:00am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/5 "2022-03-18T05:00:50Z")
We did some tests yesterday on a computer with two displays (both VRR with different native refresh rates). When before the game’s speed would be incorrect and would also change if the window was moved between screens, now it behaves correctly. We don’t use physics at all, so can’t say anything about that. We plan on putting a build on Steam with the new engine (currently waiting on a few other content fixes) and see if we still get reports from players. ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 18, 2022, 8:08am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/6 "2022-03-18T08:08:04Z")
That’s good news! Thanks for testing it out! ---
**Author:** ![aglitchman](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/aglitchman/32/19432_2.png) [@aglitchman](https://forum.defold.com/u/aglitchman)\ **Post date:** [March 19, 2022, 10:55pm UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/7 "2022-03-19T22:55:39Z")
> [@Mathias\_Westerdahl](#): > > we now have support for fixed time steps for the physics, and also variable framerate for the game loop. The idea of making physics time-stamp fixed is excellent! It’s substantial step forward for Defold, to be honest. It seems that the `display.update_frequency` option now works as it was intended to. I mean that, previously, its behaviour wasn’t clear. Next is `physics.update_frequency`. I prepared a small demo project to test it - [GitHub - aglitchman/defold-physics-131-test: Defold 1.3.1 ALPHA - Physics Tests · GitHub](https://github.com/aglitchman/defold-physics-131-test) In this demo balloons should stay in the middle of the screen, i.e. `balloon.script` constantly, every frame, compensates the gravity. Why do they fall if I set `physics.update_frequency` to non-zero value? ---
**Author:** ![aglitchman](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/aglitchman/32/19432_2.png) [@aglitchman](https://forum.defold.com/u/aglitchman)\ **Post date:** [March 20, 2022, 9:29am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/8 "2022-03-20T09:29:38Z")
> [@aglitchman](#): > > [GitHub - aglitchman/defold-physics-131-test: Defold 1.3.1 ALPHA - Physics Tests · GitHub](https://github.com/aglitchman/defold-physics-131-test) Plus, I’ve added two kinematic objects (a game object with a sailboat sprite 😀 ) to count the number of collision responses per frame, which equals to the amount of physics updates. Just in case. ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 20, 2022, 10:14am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/9 "2022-03-20T10:14:31Z")
Thanks for the repro case! In short, the fixed fixed physics timestep needs some rework 😕 In this particular case, the initial game loop dt is large enough to make the physics tick several frames, which makes the objects accumulate velocities due to gravity (Using update\_frequency = 60). Similarly, it works the other way, if we set the frequency to 30, we’ll accumulate forces that are larger than the applied gravity, and the objects will go upwards. Ofc, we need to come up with a solution to this, and I think we need something like the [FIxedUpdate() in Unity](https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html). I’ve started looking into this now… ---
**Author:** ![aglitchman](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/aglitchman/32/19432_2.png) [@aglitchman](https://forum.defold.com/u/aglitchman)\ **Post date:** [March 20, 2022, 11:55am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/10 "2022-03-20T11:55:29Z")
> [@Mathias\_Westerdahl](#): > > Thanks for the repro case! And I added a game object (the “anchor” sprite) that falls down under the gravity to test that the speed in the end of its way is the same across all combinations of new project settings. And it’s about 250 px/sec. > [@Mathias\_Westerdahl](#): > > Ofc, we need to come up with a solution to this, and I think we need something like the [FIxedUpdate() in Unity](https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html). > > I’ve started looking into this now… And I would like to have something like [LateUpdate()](https://docs.unity3d.com/ScriptReference/MonoBehaviour.LateUpdate.html). Its necessity has been discussed a couple of times ([#1](https://forum.defold.com/t/getting-an-up-to-date-camera-transform/65068), [#2](https://forum.defold.com/t/dealing-with-the-one-frame-lag-when-visualising-dynamic-bodies/64957) etc). The docs describe its purpose right: > For example a follow camera should always be implemented in LateUpdate because it tracks objects that might have moved inside Update. So, in Scene3D, we have to use [@totebo hack](https://forum.defold.com/t/delay-when-using-draw-line-in-update/68695/2) not to lag to dynamic bodies’ positions. ---
**Author:** ![totebo](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/totebo/32/36087_2.png) [@totebo](https://forum.defold.com/u/totebo)\ **Post date:** [March 20, 2022, 12:37pm UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/11 "2022-03-20T12:37:55Z")
> [@aglitchman](#): > > we have to use [@totebo hack](https://forum.defold.com/t/delay-when-using-draw-line-in-update/68695/2) I love that I now have a hack to my name. 😇 ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 20, 2022, 3:26pm UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/12 "2022-03-20T15:26:39Z")
I have a new [PR](https://github.com/defold/defold/pull/6482) up for review, and the CI is building my new branch [here](https://github.com/defold/defold/actions/runs/2012180975) Basically, I’ve added a new script function “fixed\_update(self, dt)” together with a slight change in config settings. I feel it’s much more robust than before. The thing that will change for users is the way they think about these things. I worry a bit about the transition for existing games though. I haven’t really discussed this with @britzl yet either, so it’s a bit experimental. ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 21, 2022, 9:44am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/13 "2022-03-21T09:44:32Z")
Question for the community: Given a fixed update script function, what are your uses cases for it? (Other than physics related updates) _We ask since we want to know as much as possible before we add a feature._ ---
**Author:** ![dapetcu21](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/dapetcu21/32/25120_2.png) [@dapetcu21](https://forum.defold.com/u/dapetcu21)\ **Post date:** [March 21, 2022, 10:05am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/14 "2022-03-21T10:05:44Z")
Well any sort of simulation, I guess. Including custom physics simulations (for example, in a platformer, for it to feel snappy you probably want to manually simulate jumps and such. Also, now that the physics engine is decoupled from the main loop, you don’t have a way to react to every physics state. For example, if you have some ray casting checks, that you might want to do each frame (for something like an enemy shooting you if you go out of cover, for example), you can’t guarantee fair gameplay across different framerates unless you have this `fixed_update()` function where you can react to every physics tick. ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 21, 2022, 10:09am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/15 "2022-03-21T10:09:15Z")
Well, the physics is the main reason for the fixed update function. The question was, _what other_ uses there are? ---
**Author:** ![sergeysinyavsky](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/sergeysinyavsky/32/20991_2.png) [@sergeysinyavsky](https://forum.defold.com/u/sergeysinyavsky)\ **Post date:** [March 21, 2022, 10:16am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/16 "2022-03-21T10:16:17Z")
I had cases when I wrote my fixed update for validation on the server. The game recorded certain events tied to the counter and then, roughly speaking, played the game on the server. ---
**Author:** ![Sippul](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/sippul/32/26976_2.png) [@Sippul](https://forum.defold.com/u/Sippul)\ **Post date:** [March 21, 2022, 10:19am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/17 "2022-03-21T10:19:35Z")
Network games need it. Since with deterministic update on client and server traffic between then can be dramatically reduced. Same for p2p games. We have our custom fixed update for this ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 21, 2022, 10:22am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/18 "2022-03-21T10:22:37Z")
Thanks! The server updates are a good use case. I wonder about the frequency you use in these cases? E.g. compared to physics updates which might use 60 or 30 Hz. ---
**Author:** ![dapetcu21](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/dapetcu21/32/25120_2.png) [@dapetcu21](https://forum.defold.com/u/dapetcu21)\ **Post date:** [March 21, 2022, 10:28am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/19 "2022-03-21T10:28:24Z")
Hmm, if you’re asking if it should be part of the physics module, I think `fixed_update` should exist even if the engine is compiled without a physics engine. Someone might want to implement their own physics and `fixed_update` is still useful in that scenario. (though concievably, one could implement the behaviour of `fixed_update()` using `update()`, it’s just more work and an extra thing to pay attention to) As for non-physics related things, you can simulate so many non-physics things: Think Factorio, for example. Each of their tiles have particular behaviours they do each tick and ideally that shouldn’t be tied to the framerate. Or events and troop movements in a military simulation, etc… Can these be done in a FPS-independent way using just `update()`? Probably yes, by implementing a similar logic as you have and calling your tick more/less times per frame depending on dt. Is it good to have a convenience function for this? Definitely and I will be switching some simulation code for our tower defence mini-game in GMAI to `fixed_update()` if it gets implemented. Getting that timing behaviour right without stutters is not an easy task and I think it’s good if you give Defold users a “known good” implementation of it. One place where `fixed_update()` is really necessary and no other alternative exists, is when wanting to sync up with the built-in physics engine. ---
**Author:** ![Mathias\_Westerdahl](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias_westerdahl/32/228_2.png) [@Mathias\_Westerdahl](https://forum.defold.com/u/Mathias_Westerdahl)\ **Post date:** [March 21, 2022, 10:31am UTC](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539/20 "2022-03-21T10:31:41Z")
Thank you for your input! We’ll go for adding a new life cycle function `fixed_update()`, and we’re currently trying it out a bit, to better understand what the migration steps will be for our users. [Next page](https://forum.defold.com/t/game-physics-time-steps-beta-testing/70539.md?page=2)