Defold 1.3.1 has been released

[Mathias_Westerdahl]

Release notes

Improved timestep support

The biggest change this release is the improved support for the different timesteps between the game update loop and the physics update loop.

The goal is to have the game using vsync, and use the delta time between the display refreshes as the dt for the game loop.
This will fix the issues we’ve seen with game running on displays with variable frame rates (or rates > 60hz).

The display.update_frequency (default is 0) variable has changed somewhat, and is only limiting the frame rate if it’s lower than the current refresh rate of the display.
E.g. it can be useful to limit the frequency to something low (like 30) to simulate the behavior of for instance a KaiOS device.

The fixed physics update is off by default, in order to stay compatible with the old behavior.

(More on the settings at the end of this post)

We’ve added a fixed_update(self, dt) life cycle function to the game object scripts.
When using fixed timesteps for the physics, this is where you’ll want to add the forces to your game objects, in order to keep in sync with the physics updates.

After the requests and comments from the community, we’re confident that the new implementation is a good way forward.
However, due to the nature of the implementation, it wasn’t possible to keep it 100% backwards compatible.
We hope that the community can help test their project with this release, and find and report any changes in behavior, so that we may discuss a way forward.

Frustum culling

We’ve added support for frustum culling. In this initial version of the feature, it’s only used for sprites.
Expected benefits are reduced vertex buffer sizes (saving GPU bandwidth), and reduced number of draw calls (depending on projects).

Frustum culling is enabled by default in the default.render_script. If you have a custom render script, you need to create a frustum matrix, and pass it into your render.draw() calls.

Floating point render targets

We’ve added support for floating point render targets on the devices that support them.
The following constants are set if supported on the device and are otherwise nil if not supported:

* render.FORMAT_RGB16F
* render.FORMAT_RGB32F
* render.FORMAT_RGBA16F
* render.FORMAT_RGBA32F
* render.FORMAT_R16F
* render.FORMAT_RG16F
* render.FORMAT_R32F
* render.FORMAT_RG32F

Engine

• Issue-6319 - Added: Added support for creating floating point render targets
• Issue-6456 - Added: Added frustum culling to default render script
• Issue-6460 - Added: Added support for specifying fixed physics time steps
• Issue-6336 - Fixed: Ignore focus lost/gain events for detection if app is in background (Android)
• Issue-6431 - Fixed: Add all android:configChanges with requered API less or equal than 16
• Issue-6437 - Fixed: Make sure particle fx duration doesn’t go below 0
• Issue-6440 - Fixed: Reset key state when canvas focus is lost (HTML5)
• Issue-6445 - Fixed: Add frustum culling support (currently sprites only)
• Issue-6447 - Fixed: Correctly scale convex collision shapes in nested factory created game objects
• Issue-6452 - Fixed: Improved error handling when using multiple tilemap collision objects in a single game object
• Issue-6453 - Fixed: NE: Added dmGraphics api for querying the supported extensions
• Issue-6458 - Fixed: Do not create animations for box nodes with one frame flipbook animations during gui scene creation
• Issue-6461 - Fixed: Label alpha not always working properly in html5
• Issue-6464 - Fixed: Game loop now uses display.update_frequency to use variable/fixed frame rate
• Issue-6467 - Fixed: Changed default value for wasm streaming
• Issue-6470 - Fixed: Editor plugin restart message
• Issue-6472 - Fixed: Bob doesn’t unpack plugin shared libraries unless they’ve changed
• Issue-6473 - Fixed: Improved GUI property API reference
• Issue-6474 - Fixed: Speed up building of script files
• Issue-6476 - Fixed: Improved Bob exception reports (“resource cannot be null”)
• Issue-6478 - Fixed: Editor: Added support for setting constant arrays
• Issue-6481 - Fixed: Added support for component timestep

Settings related to time steps

These are the relevant settings:

• engine.fixed_update_frequency

  • an integer setting in Hz
  • Default is 60
  • 0 means it’s disabled
  • We recommend e.g. 30 or 60 Hz
  • Corresponds to the script life cycle function fixed_update(self, dt)

• physics.use_fixed_timestep

  • boolean
  • 0 (false) is default
  • 0 means variable frame rate (default)
  • We recommend using 1 for new projects

• display.update_frequency (integer)

  • an integer setting in Hz
  • 0 means variable frame rate (default)
  • > 0 means fixed frame rate. Capped at runtime towards the actual frame rate. I.e. you cannot update the game loop twice in an engine frame.
  • Fixed time steps may be used to simulate slower devices, or throttle the performance at runtime. E.g. set to 30 to simulate the frame rate of KaiOS.

• display.swap_interval

  • An integer setting that sets the OpenGL swap interval
  • (doesn’t work with Vulkan)
  • 0 disables vsync
  • Default is 1

• display.vsync (DEPRECATED)

  • boolean
  • If set to false, forces a display.swap_interval = 0

• Use the sys.set_update_frequency(hz) to control the “display.update_frequency” at runtime.

[wkqco33]

Thanks! You know what your team makes my dream!!

[WhiteBoxDev]

This release has lots of great new features. Thank you!

[AGulev]

Thank you @britzl for this blog post with more info about the release: https://defold.com/2022/04/05/Defold-1-3-1

[piXelicidio]

Haven’t used Defold since about 2 years, logged in just to celebrate the improvement/fixes for Sync/framerate dependency issues…

[SkaterDad]

Is there any plausible reason that this release would break rendercam in subtle ways?

rendercam.screen_to_world_2d seems to be returning incorrect values for the first 0.5 seconds of the game loading. This is happening while debugging, but also with a Windows release build.

That function relies on some projection matrices, which are calculated during the render script’s update. Since this release involved some update frequency changes, maybe this was an unintended side effect? I’ve tried setting the display.update_frequency to both 0 and 60. Same issue.

Project worked well on 1.3.0. Unfortunately the archive link on Defold Downloads is giving me a 404.

[Mathias_Westerdahl]

I don’t think so, no.
Remember that the downloads are served at github:

Releases · defold/defold

[SkaterDad]

Thanks for pointing me to Github, I had forgotten. Perhaps the website could be updated to say that as well?

I’ve just downloaded 1.3.0 and the game works as intended again. Rendercam is providing the correct values right at the main collection’s init().

I then deleted the Win32 cache and build folder, and tried 1.3.1 again. The problem is still there.

I will try to make a minimal repro tonight after work.

[SkaterDad]

Here is the minimal reproduction I promised. Started with my game and aggressively removed nearly everything.

There’s a screenshots folder showing the results I get on the 2 engine versions, and a few comments in the main.script.

Hope this helps isolate what is happening!
camera_issue.zip (97.0 KB)

[britzl]

It seems like there’s an issue with the timer. I’m not getting the correct delay.

	local t = socket.gettime()
	timer.delay(0.2, false, function()
		print(socket.gettime() - t)
	end)

This prints 0.00020813941955566. With a delay of 0.5 I get an actual delay of 0.2. We’re looking into it!

[Pkeod]

@Mathias_Westerdahl

We’ve added a fixed_update(self, dt) life cycle function to the game object scripts.
When using fixed timesteps for the physics, this is where you’ll want to add the forces to your game objects, in order to keep in sync with the physics updates.

Could you offer guidance on how kinematic walker could adapt to this change?

Improve example player move so when pressing against walls the camera doesn't shake

astrochili/defold-kinematic-walker/blob/master/walker/walker.script

You may need a newer GPU on Windows to actually observe the issues. I tested with a 3080 Ti on Windows 11 though someone on Linux reported this issue as well. On older macOS version and hardware it looks fine but it may simply because of differences in speed / whatever weird thing vsync has with newer GPUs that’s interacting with physics update (this seems to still be an issue, I still have to tell people to force enable vsync to have our games run reliably on newer GPUs).

I’m not sure how to make it work right so it’s smooth and reliable. Does the script just need to have the physics checks untangled and moved to fixed_update, or is something else going on?