Defold 1.9.2 has been released

Defold 1.9.2

Summary

  • NEW: (#9218) Migrate dynamic GUI textures to use resource system
  • NEW: (#9236) Added function collectionproxy.set_collection() to replace collections for excluded collection proxies (Live Update functionality)
  • NEW: (#9244) Updated LuaJIT
  • NEW: (#9249) Add graphics module
  • NEW: (#9200) Make ‘image’ module excludable.
  • NEW: (#9205) Make ‘rig’ and ‘model’ modules excludable via appmanifest.
  • NEW: (#9185) Refactor shader pipeline to use SPIR-v as base
  • NEW: (#9256) The ability to launch up to four instances from the Editor on Build.
  • FIX: (#9262) Don’t attempt to preload deprecated tile_set field
  • FIX: (#9228) Upgrade GLFW to 3.4 for Win32 platforms
  • FIX: (#9224) Fix the issue where fonts with different characters generate the same glyph bank
  • FIX: (#9207) Recreate material when material resource is hot-reloaded
  • FIX: (#9216) Trigger window resize flow on GLFW3 when the window content scale changes
  • FIX: (#9223) Remove timer callback if timer freed prematurely
  • FIX: (#9231) Make non-standard OpenGL functions optional on windows
  • FIX: (#9258) Fixed issue where the scene graph can’t produce valid information for excessively long values
  • FIX: (#9220) Delete render contants from CompRenderConstants
  • FIX: (#9070) Add preference to disable build-time linting
  • FIX: (#9199) Allow copying folder’s project and absolute paths
  • FIX: (#9243) Notify language servers about file changes
  • FIX: (#9264) Fix editor crash when switching to Manual Size Mode without a texture assigned
  • FIX: (#9204) Frame the camera to the very first visible object added to the scene view

Engine

NEW: (#9185) Refactor shader pipeline to use SPIR-v as base
The shader support in Defold has gotten a major update. Defold outputs engine shaders in a pipelined manner, and currently utilises two slightly different setups: the new and the legacy pipelines. The legacy pipeline produces engine shaders the same way as before:

  • Take ES2 compatible GLSL code as input
  • Transform the shader source into ES3 / OpenGL 3 variants via mostly regexp
  • Optionally take the GL3 code and cross-compile into SPIR-v for vulkan

This setup has multiple issues:

  • The engine is using ancient GLSL code. Most modern sources of information has moved on, and so we should too
  • Each uniform is packed into their own uniform buffer, which is very inefficient
  • The ES2 → ES3 transformation is very brittle due to the nature of regular expressions
  • The GLSL code is unoptimized - there are basically no available tools that operate on old GLSL code

The new pipeline uses the same tools, but in a different order:

  • Take shaders written in at least GLSL version 140 as input
  • Generate SPIR-v via glslang
  • Run optimisation pass on the SPIR-v binary
  • Generate reflection data from the optimised shader, which will now be used by the engine for all adapters
  • At this point, we can generate shaders in whatever language and version we want via spirv-cross - including GLSL for webgl 1 / ES2, HLSL, metal and whatever else we need.

The produced shaders from this new pipeline has multiple benefits:

  • Produces optimised shaders, even for old GLSL variants
  • The engine can now use constant buffers. This means that you can pack all your uniforms into a single buffer, which can be updated in one go instead of updating each uniform individually.
  • More stable transformation of shader source into the target platform
  • The engine code for the graphics adapters is more uniform than before, which helps us to write new functionality

To utilise this new setup, shaders must be written in at least version 140 (GL3/ES3+ compatible) since that is what the spirv toolchain requires. Note that it is not required to rewrite your shaders in order to get the game to still work, but in order to use the new functionality you need to convert your shaders into the newer GLSL. In the future, all builtin shaders will be upgraded into #version 140 shaders, but for now this must be done manually.

NEW: (#9218) Migrate dynamic GUI textures to use resource system
Dynamic textures (created via gui.new_texture) are now managed by the resource system. There is no change in behaviour or function signature for how dynamic textures are managed, the biggest gain of this task is to remove GUI specific code in the engine and move some parts of the GUI system closer to the regular gameobject world, code wise.

NEW: (#9236) Added function collectionproxy.set_collection() to replace collections for excluded collection proxies (Live Update functionality)
Added a new function, collectionproxy.set_collection(), which is designed to simplify the management of resources loaded using the Live Update feature.

NEW: (#9249) Add graphics module
A new graphics script module has been added that currently only has the same graphics constants that we already use in the render and resource modules. In the future, new functionality will be added to this module for things like querying GPU extensions, max texture size and so on.

NOTE :warning:
render and resource constants, such as render.STATE_DEPTH_TEST still exist which means that existing projects will not need to be ported to using graphics constants. However, the constants are deprecated and removed from the autocomplete as well as the documentation in favor of using the graphics module!

FIX: (#9262) Don’t attempt to preload deprecated tile_set field
Fixed an issue where loading a sprite resource with no texture samplers assigned incorrectly tries to load the tileset instead.

FIX: (#9228) Upgrade GLFW to 3.4 for Win32 platforms
Windows is now using GLFW version 3.4 for window management. The window will always be centered now and no flickering will occur when the window is opened.

FIX: (#9224) Fix the issue where fonts with different characters generate the same glyph bank
Fixed the issue where the character set wasn’t taken into account when deciding if a new glyph bank should be generated.

FIX: (#9207) Recreate material when material resource is hot-reloaded
Fixed an issue where hot-reloading shaders have no effect. The fix also applies to swapping out shaders in the material resource as well.

FIX: (#9216) Trigger window resize flow on GLFW3 when the window content scale changes
Moving the window between displays with different content scales will now trigger a window resize event on MacOS.

FIX: (#9223) Remove timer callback if timer freed prematurely
Fixed an issue where a timer was created with a callback and the timer was removed before it could complete. In this case, the lua reference to the timer callback was never released, causing a reference leak.

FIX: (#9258) Fixed issue where the scene graph can’t produce valid information for excessively long values
Fixed an issue where the scene graph produces invalid JSON when some of the values are longer than 128 characters.

FIX: (#9220) Delete render contants from CompRenderConstants
Fixed a memory leak in the engine that happens when setting component constants via constant buffers.

Editor

NEW: (#9256) The ability to launch up to four instances from the Editor on Build.
Now, in the Project menu, it is possible to pick how many instances the Editor should launch when building. This functionality is useful for developing a multiplayer project. The following features are supported:

  • Launch multiple instances of the engine.
  • Relaunch or hot-reload all instances simultaneously.
  • Relaunch, hot-reload, and debug each instance separately if a particular target is selected in the Project -> Target menu.
  • If more than one instance is launched, the instance index will be added to the window title.
  • The index is available at runtime using
local instance_index = sys.get_config_int("project.instance_index", 0)
  • If logs are enabled, each instance will use its own log file, instance_N_log.txt, where N is the instance index.
  • If more than one instance is launched, each instance will have its own debugger port: the default port + instance index.
  • A new menu option (and shortcut Ctrl+J or ‘Cmd+J’ on Mac) has been added to close the engine (all instances) from the editor. See the Project menu.

FIX: (#9264) Fix editor crash when switching to Manual Size Mode without a texture assigned
Fixed an editor crash resulting from invalid vertex buffers when using Manual Size Mode with zero-area geometry.

FIX: (#9204) Frame the camera to the very first visible object added to the scene view
It may be confusing when a visible object is added to an empty scene, but nothing is visible because the camera is too zoomed in. After this fix, the very first visible object added to a scene will be framed to ensure it is visible.

26 Likes

Thank you for this nice release! I like how we can remove modules from the engine and have just what we need

6 Likes

Great release :ok_hand:

https://x.com/pawel_developer/status/1825932649485254772?s=19

1 Like

i think there is a regression on hidpi. i saw some report about it in the last few days related to GLFW but i don’t know if it’s the same thing.

tested defold stable 1.9.1 vs defold stable 1.9.2
windows10, hi-dpi screen (scaling 200% == 192dpi)

it is visible for example in britzl.publicexamples\examples\simple_lights (where probably the output depends on the window size). in 1.9.1 the scene occupies the entire window. in 1.9.2 the scene is smaller, exactly the half. let me know if you need a bug in gh

edit: i guess is this display.high_dpi does nothing · Issue #9311 · defold/defold (github.com)

Max Dynamic Textures is for gui.new_texture?

Lock mouse broken in windows:(
Worked in defold 1.9.1

1 Like

I set 0 to max dynamic textures and crash engine:)

1 Like

No defold icon :defold: :cry:

2 Likes

It’s enough to open an issue on GitHub.
It’s not a beta version anymore, so these issues will not be prioritized a special way until it’s something really critical.
These issues will be reviewed and taken into account during our weekly Monday new issues review

2 Likes

Been able to launch multiple instances of the engine is what I neded to test and develop the multiplayer functinality of my game. I’ve been using an HTML5 build served on a local server along with the usual editor instance, but this should speed up testing and development. Thank you!

2 Likes

This worries me that I’m not understanding the mapping between Defold’s mechanisms for handling uniforms and OpenGL’s mechanisms. I thought constant buffers were already available with render.constant_buffer()?

1 Like

No, it’s two different concepts. I think there might be a typo in my description of the issue, it should be uniform buffers and not constant buffers. A uniform buffer is basically a container for uniform data and is a single resource like a texture or a storage buffer. With the legacy pipeline we wrapped each non-opaque uniform into their own uniform buffer; with the new pipeline you will have to manage this yourself (usually via a single uniform buffer).

1 Like

Is there an API for creating uniform buffers? I thought this was something the engine is currently lacking.

By the way, to make sure we’re on the same page with terminology, I’m referring to uniform buffer objects for fast swapping of uniform values and sharing uniforms across shader programs.

1 Like

Not currently no. It’s on my radar together with ssbo support but no eta yet.