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:
Things I’ve tried without luck:
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.
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.
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 lag.zip (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:
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.
