Dealing with the one frame lag when visualising dynamic bodies

What’s the right approach to visualising dynamic bodies in Defold? In this example the rope should connect to the position of each body, but it gets offset because of the lag:

Physics (102.3 KB)

Things I’ve tried without luck:

  • Reversing the offset by using the difference in linear velocity.
  • Using a timer instead of the update loop.
  • Using get_world_position(“dynamic#collisionobject”) on the collision object instead of the game object.

I’m guessing this is related to the debug rendering (that the physics engines usually have), that we hook into.
I’m not entirely sure it’s something we can do anything about. We’ll have a look.

1 Like

It seems to me that the update() function returns a value that’s one frame late, rather than returning the actual position of the game object. Why else would the calculations run one frame late?

I don’t have a specific example on hand, but I’ve run into this in the past too. It seems like the physics world gets updated after the script update, so you have no chance to change things before rendering happens, unless possibly you use a raycast or collision message every frame.

1 Like

Exactly! I’ve modified the example from the first post to accept the delay of one frame and move everything at the same time: Physics (137.6 KB)

This solves the problem, but also leads to what the player sees not being accurate:

Ok, at first I thought you were using debug rendering for this, hence my answer.

What’s the right approach to visualising dynamic bodies in Defold?

The update order is (shortened list): …, scripts, …, physics, …, sprite, …, render

Inbetween, we flush any messages in the queues. E.g. after the physics update, we flush physics messages (collision etc), whic will ofc end up in the scripts.
We also update dirty transforms, such as gameobject transforms after a dynamic body has updated.

After all that, we render the objects with the gameobject transforms.

Constraints are a bit tricky since they belong to the “world”, and not to any object per se.
And since it’s a very recent addition, we haven’t really considered having a graphical object following it around (thery’re usually more like the invisible glue between objects).

It’s a bit of a hack, but I would try to set the position of the “stick” object inside the message handler, since that’s after the physics update (which moves the game objects).
However, that also requires that you do get a message every frame. I don’t have a good idea for that yet though.


If it possible to add post_update function for scripts, it can solve physics-render lag:

scripts (update), physics, scripts (post update), sprite, render

Other game engines have similar behaviors:

  • Unity - MonoBehavior has “LateUpdate” in
  • Phaser - Game Object has “postUpdate”
  • Game Maker - “end step” event

I have never been afraid to use a hack! Maybe with a dummy fixture which always collides with the player collision object.

Edit: I can confirm the “ray_cast_missed” method from this thread works.

Wow, this sounds like a much more clean solution to me.