Defold 1.3.1 BETA

Release notes
#1

Defold 1.3.1 BETA

The latest beta is now released, and we invite those interested in beta testing the new features in the editor and engine to join now.
The beta period will be 2 weeks and the next planned stable release is two weeks from now.

We hope this new workflow will highlight any issues earlier, and also get valuable feedback from our users. And please comment if you come up with ideas on improving on this new workflow.

Please report any engine issues in this thread or in issues using Help → Report Issue

Thx for helping out!

Disclaimer

This is a BETA release, and it might have issues that could potentially be disruptive for you and your teams workflow. Use with caution. Use of source control for your projects is strongly recommended.

Access to the beta

Download the editor or bob.jar from Releases · defold/defold · GitHub

Set your build server to https://build-stage.defold.com

Release notes

Improved timestep support :warning:

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.

:warning: 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 beta, 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).

EDIT 2022-03-23: 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.

23 Likes
#2
#3

An amazing set of updates :clap:

Just curious, why is 1 the suggested value if 0 is the default?

3 Likes
#4

Backwards compatibility.
Currently, the games use their “update()” function to add forces to their physics objects.
When using fixed updates for physics, you need to move such code to the “fixed_update()” function.

3 Likes
#5

I can not download the beta editor:

https://d.defold.com/archive/editor-alpha/487296f0e70e8f3c09d7f3e79673926bc8ee18ae/editor-alpha/editor2/Defold-x86_64-win32.zip

image
image1291Ă—304 33 KB

#6

Download it from Github:

2 Likes
#7

I did a quick test (opened the project and made a screenshot of profiler in two places on the map (middle of the map in top row and far right in bottom row) in Witchcrafter, where several sprites of different atlases are + GUI is not drawn, I have a custom render script + no changes were made to project when switching editors) with 1.2.192 alpha, 1.3.0 alpha and 1.3.1 beta:

Screenshot 2022-03-22 160337
Screenshot 2022-03-22 1603373051Ă—1166 1.01 MB

Could you please judge the results?

2 Likes
#8

Well, you didn’t seem to have much performance issues to begin with? The Engine.Simtaking ~ 2-3ms is virtually nothing.
Sure there are a few draw calls, but not that many to be honest.

Let me ask you this, are you experiencing any performance issues?

2 Likes
#9

I’m glad with current performance, I rather do not experience stuttering or lower fps at all, maybe sometimes testing on mobile. The fps sometimes drop when I trigger too much particles and there is already a lot of sprites in the screen (I also have still a design mistake, where particles remain enabled not in visible area e.g. fire is burning on other part of map and I try to do mayhem in the other :grin:)

Since I couldn’t figure out proper Culling myself I started to design smaller maps and add loading screens between - I want to get rid of them and make bigger, open maps, so one part of this is to still load chunks of map asynchronously, but with possibly no stuttering while loading neighbouring chunk, other is to cull anything not visible.

3 Likes
#10

I have several prototypes whose collision shapes consist of a multitude of convex polygons. In addition, they are nested multiple times. Scaling did not work well in version 1.3.0 even though Allow Dynamic Transforms is turned on in the project settings. In the 1.3.1 beta, however, everything is perfect. Thanks! :+1:

3 Likes
#11

Just to make sure: Did you apply changes in your custom render_script for culling?

1 Like
#12

No - I did not change anything, even though I was pretty sure there must be something more to do :smiley: I’m looking for the information on what should be changed

3 Likes
#13

Compare with the default.render_script.
I’ve updated the release notes with the relevant info.

5 Likes
#14

There are also changes in the default AndroidManifest.xml file. I would recommend to apply the same changes in custom manifest devs use on their projects.

4 Likes
#15

I try frustum culling, but it doesn’t happen what I would expect.
All I do is set up frustum based on:

local frustum = vmath.matrix4_frustum(100, render.get_window_width() - 100, 100, render.get_window_height() - 100, -1, 1)

Then this:

render.draw(self.tile_pred, { frustum = frustum })

So based on that, I would expect the sprites to render in an area smaller than the screen. But in the same way, they are rendered in full screen. Am I missing something or misinterpreting it?

#16

Here’s en example of what I used in my tests:


        local view = vmath.matrix4_look_at(eye, eye+vmath.vector3(0,0,-1), vmath.vector3(0,1,0))
        local margin = 100
        local proj = vmath.matrix4_orthographic(margin, margin + render.get_width()-2*margin, margin, margin + render.get_height() - 2 * margin, -1, 1)
        frustum = proj * view
2 Likes
#17

Now we’re talking! :smiley: 1.3.0 beta with passed frustum:

[UPDATED picture:]

Screenshot 2022-03-23 121745
Screenshot 2022-03-23 1217451917Ă—1984 838 KB

Now the atlases could be optimized and I could have a huge map, with just a few draw calls and really decreased buffer!

6 Likes
#18

Thanks Mathias! It works with vmath.matrix4_ortoghraphic (weird because I thought I should use vmath.matrix_frustum), but still not as I would expect.

I created a test project that includes 9 sprites as shown below. There is also a white frame showing the current position / size of the frustum. I start to reduce the size of the frustum dynamically. Sprites at the edge of the screen as the size of the frustum decreases disappear sooner than they should and then reappear later when they are outside the frustum boundary. Because of these, I would think culling isn’t perfect yet, but it could also be that I’m making a mistake.

FrustumCullingTest.zip (544.2 KB)

image
image502Ă—532 3.77 KB

#19

I don’t understand, did you swap the version numbers?
I’d expect the lower vertex buffer size to be in the 1.3.1 beta?

1 Like
#20

Yes, good catch, there is a mistake on the bottom picture (I will correct it) :smiley: the bottom picture is the same version - 1.3.1 beta! Comparing to my previous posts, results are way better!