Game + Physics time steps BETA testing

Announcements
#21

We use 10 Hz. But i think it is ok to fix it on 60Hz, and it can be resampled down by project individually.

3 Likes
#22

Could fixed_update() help fix the examples above? In my project, visuals, including camera movement, lagging one frame behind is one of the recurring Defold issues I havenā€™t been able to solve in a good way.

2 Likes
#23

Thanks!
I guess having it slower than the physics is easier. E.g. if the fixed frequency is a 60Hz, youā€™d call your server sync every 6th frame.

@totebo
Weā€™ll most likely add another life cycle function for the post update. Iā€™m hoping next version (after this one)

4 Likes
#24

No, it couldnā€™t. We have the same problem. I would love to have the late_update(self, dt) function in scripts or an option to subscribe for the late_update message (for example, i.e. any option is OK).
Also, Iā€™ve found that native extensions can subscribe on the pre-render callback and it can be used for late update logic (but, unfortunately, messages from that logic will be dispatched next frame). Because, broadly speaking, the purpose of the late update is to prepare your scene for rendering, i.e. move/rotate the camera or other objects that rely on the transformation of dynamic bodies. Iā€™ll post the results of my experiments then.

Sounds great!!

4 Likes
#25

This is really exciting. It will make a huge difference to my workflow.

1 Like
#26

Iā€™m of the same opinion.

I saw that some developers use fixed update for animations. However, animating something in the fixed update can produce visual jittering imho and should be used with caution.

I stumbled upon recommendations to use fixed update only for updating physics. For networking, they say that itā€™s better to implement your own fixed-step function for better control, i.e. as @Sippul did.

If you are asking that to consider whether to introduce a new function to scripts or implement that via messages (for example, to send physics_update message from a collision object to a script) then we love to have any of those options. Personally, we will use it only for physics now and will test it on Puffy Cat - the game requires the fixed step for physics to not to fall through platforms.

2 Likes
#27

I believe a fixed update amount would help with timing on a rhythm game Iā€™ve been toying with. This would allow for time aligning much easier.

1 Like
#28

Not sure if this is the right thread @Mathias_Westerdahl, but Iā€™m experimenting with the fixed_update in our current project (using the Defold version v1.3.1).

When using fixed_update to add force, the game object seems to stutter while moving. While moving it to a regular update instead, it moves smoothly.

Ex:

go.property("turn_amount", 30)

local left_turn = nil
local right_turn = nil

function init(self)
  left_turn = vmath.vector3(self.turn_amount, 0, 0)
  right_turn = vmath.vector3(-self.turn_amount, 0, 0)
end

function fixed_update(self, dt)
  local turn = vmath.lerp(delta, left_turn, right_turn)["x"] -- no linear lerp function i defold except in vmath
  local turn_quaternion = vmath.quat_axis_angle(vmath.vector3(0, 0, 1), turn * dt) -- set the turn quaternion based on the turn value
  local rot = go.get(".", "rotation") * turn_quaternion -- multiply with the current rotation
  go.set_rotation(rot)

  local forward_speed = 1
  local distance = forward_speed * dt
  local direction = vmath.rotate(rot, vmath.vector3(0, 1, 0)) * distance -- get a direction vector

  pos = go.get(".", "position")
  pos = pos + direction -- add this to the current position

  msg.post(".", "apply_force", {force = direction * 100, position = pos})
end
1 Like
#29

Please assemble a small repro project that we can test!

#30

Sure think, coming up :slight_smile:

2 Likes
#31

Okay @Mathias_Westerdahl, manage to sort of put a bare case together. Striped our current project down as much as I could (a car game), but still some prototype code in there (and removed steering for easier testing).

But if you start the game, touch anywhere on the screen, the player will start moving forward with a (sometimes) stuttering movement. Seems to be performance related. Happens maybe half of the time on my machine (Surface Pro 8) and every maybe 4s on my mobile (Samsung Note 9, both HTML5 and Android build).

If you change fixed_update in touch_controller.script to update it should look better, but not perfect either. So is probably related to my code. I need to run some profiling on it and get back.

1 Like
#32

I looked into your project and I see that you use collection proxies as ā€œscreensā€. In my opinion, the issue is the same as described there - Defold 1.3.1 BETA - #51 by aglitchman

3 Likes
#33

Seems to be the problem yes (Iā€™m using the monarch plugin that uses proxies to handle scene transitions). When running the game directly to the in game scene, it works fine.

2 Likes
#34

So, Iā€™ve implemented the temporary solution. Iā€™ve found that native extensions can subscribe on the pre-render callback, and Iā€™ve used that for the late update logic. The only downside is that the callback isnā€™t called if the application is iconified.

How to use:

  1. Add Scene3D as a dependency: https://github.com/indiesoftby/defold-scene3d/archive/refs/heads/main.zip.
  2. Call scene3d.prerender_register/scene3d.prerender_unregister to subscribe (unsubscribe) for that pre-render event:
-- This update will happen after game objects have been moved by the physics engine
-- Messages from that code are dispatched next frame!
local function late_update(self)
    -- Get position/rotation, update position/rotation, etc.
end

function init(self)
    local priority = 1 -- It's an optional parameter. All pre-render callbacks are sorted by priority (ascending: 1, 2, 10, 50, and so on.) and called one by one.
    self.prerender_id = scene3d.prerender_register(late_update, priority)
end

function final(self)
    if self.prerender_id then
        scene3d.prerender_unregister(self.prerender_id)
    end
end
6 Likes