Defold 1.4.1 BETA

Release notes
#1

Defold 1.4.1

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.

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

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

Summary

  • NEW: (#7139) Use standard gamepad mapping for unknown gamepads in HTML5
  • NEW: (#248) Automatically create Android R.java files for all Gradle dependencies
  • NEW: (#7124) resource.set_texture improvements
  • NEW: (#7154) Create texture resource in runtime
  • NEW: (#7179) Added configfile extension functionality to dmSDK
  • NEW: (#7158) DEFEDIT-7152 Added preference to disable loading of external changes on app focus
  • FIX: (#7133) Remove old rig.max_instance_count counter.
  • FIX: (#7143) Add serialization nested depth limit to the debugger
  • FIX: (#7155) Added opt-in for Lua bytecode deltas
  • FIX: (#7171) Fix crash when max sound instances is 0

Engine

NEW: (#7139) Use standard gamepad mapping for unknown gamepads in HTML5
This change adds support for a standard gamepad mapping in html5 builds. The standard gamepad is defined in the default.gamepads (in builtins) with device name “Standard Gamepad”. This mapping will be used for any gamepad that is identified as a standard gamepad in the Gamepad API.

The standard gamepad mapping is defined as 16 button gamepad with 2 analog sticks with a button layout very similar to a PlayStation or Xbox controller (see the W3C definition and button layout for more information).

NEW: (#248) Automatically create Android R.java files for all Gradle dependencies
This change automatically adds each resolved Android Gradle dependency containing resources as an extra package when linking resources using aapt2. This reduces or completely removes the need to specify aaptExtraPackages in ext.manifest.

NEW: (#7124) resource.set_texture improvements
Added new functionality to the resource.set_texture function - you can now update a specific region of the texture as well as update only a specific mipmap with new data. This is done by setting the new “table” argument values:

local header = {
	width = ...,
	height = ...,
	type = ...,
	format = ...,
	x = number, -- New field
	y = number, -- New field
	mipmap = number, -- New field
}

NEW: (#7154) Create texture resource in runtime
Added a function to create texture resources dynamically in runtime. Use the new function resource.create_texture(path, args) to create a texture, and then go.set to assign it to components or resource properties like any other resource.

NEW: (#7179) Added configfile extension functionality to dmSDK
We’ve added new extension macro DM_DECLARE_CONFIGFILE_EXTENSION in dmsdk/dlib/configfile.h.
The extension allows extension developers to provide custom properties, or override existin ones.

In order to fully utilize this mechanic, we’ve created the sys.get_config_string(), sys.get_config_int() and sys.get_config_number() functions. The old sys.get_config()is now deprecated, in favor of sys.get_config_string().

FIX: (#7133) Remove old rig.max_instance_count counter.
Remove old deprecated max counter rig.max_instance_count which was the reason of minimum 128 max_count for model component.

FIX: (#7143) Add serialization nested depth limit to the debugger
Lua debugger table serialization now has a nesting limit of 100 depth levels. Deeper tables will not be serialized and instead will be shown as e.g. ...0x0119a21230. This also prevents stack overflow exceptions on breakpoints if very deeply nested structures (without circular references) are used.

FIX: (#7155) Added opt-in for Lua bytecode deltas
Moved Lua bytecode delta generation behind a bob flag (--use-lua-bytecode-delta). The default behavior is now to bundle with full 64 and 32 bit bytecode for multi-architecture builds (primarily on Android). Just like before when bundling for a single architecture only bytecode for that architecture will be included.

FIX: (#7171) Fix crash when max sound instances is 0
Fixed a crash when max sound instances is 0 in game.project

Editor

NEW: (#7158) DEFEDIT-7152 Added preference to disable loading of external changes on app focus

  • Added checkbox Load External Changes on App Focus to the General Preferences page. When disabled, the editor won’t scan for external changes when it receives focus. A new menu entry Load External Changes will appear in the File menu so users can trigger the process manually.
  • Moved Code Editor Font setting from the General Preferences page to the Code Preferences page.
13 Likes
#2
#3

Curious to see if this help switch gamepads work for me!

Edit: Sadly it does not…

2022-11-28 22_19_05-Gamepad Tester 1.0
2022-11-28 22_19_05-Gamepad Tester 1.01484×501 48.4 KB

https://gamepad-tester.com/ does work with it though so I know it can work.

2022-11-28 22_19_56-Gamepad Tester - Check Controllers and Joysticks Online
2022-11-28 22_19_56-Gamepad Tester - Check Controllers and Joysticks Online1061×335 30.6 KB

Edit 2: Actually I think the problem is the gamepad tester example project is outdated, it needs to be updated to work with the builtin gamepads list and not the one in the project.

When I swap those out it no longer says none detected and some but not all buttons are detected, but that may be mapping issue I will try more.

2022-11-28 22_26_53-Gamepad Tester 1.0
2022-11-28 22_26_53-Gamepad Tester 1.0924×419 7.86 KB

#4

Correct. As mentioned above: “The standard gamepad is defined in the default.gamepads (in builtins) with device name “Standard Gamepad”. This mapping will be used for any gamepad that is identified as a standard gamepad in the Gamepad API.”

So in order to make use of the standard gamepad mapping you need to have a mapping for “Web” with name “Standard Gamepad”, like in builtins/default.gamepads.

Which buttons didn’t work? I tested with several different gamepads (Xbox, PS4, Stadia etc) with a layout similar to the W3C definition of a standard gamepad and they all worked:

image
image1052×744 80 KB

#5

Is there a newer controller tester sample project you can share?

#6

Which project was that?

#7
#8

This is interesting. So is this meaning that you can load am image directly from the image path and push it as a sprite texture straight off? And what args are going to be available? And how is path exactly used?

#9

No, the path is not a file path on disc, it’s a resource name.
It’s what the resource will be known as.
It must not exist before (I’m not sure if it will throw an error).
It must also end with .texturec

The documentation unfortunately misses to make it any clearer.

#10

The new dynamic texture features seem pretty cool and useful, I am giving them a try now. :partying_face:

I’m curious how these decisions get made though. These features are cool and open up new possibilities, but they are fairly esoteric—the vast majority of projects won’t use them. They were added to the core engine, not as an extension, and from the commit log it seems they involved a fair amount of new code. Compare this to, say, a function to toggle fullscreen on desktop, which almost every desktop project needs, and which, from my understanding would hardly need new code, only a lua binding to call a GLFW function or two that’s already there.

Was this feature requested by a large sponsor or something? From what I’ve seen, the usual arguments against adding new features are: a) Not enough people have asked for it, and b) The engine’s core philosophy is to remain lightweight and the feature is not necessary for everyone.

6 Likes
#11

Yes, it was requested by a sponsor.

This is absolutely true and it drives our decision making at all times! When it comes to the ability to manipulate existing textures and create new atlases (will be included in 1.4.2) it is something that has been requested many many times over the years. Examples:

The feature also goes hand in hand with other work such as the ability to trim transparent pixels and loading packed textures from for instance Texture Packer or using our own tools. We’re also working on multi paged atlases which is tangentially related to this work. Finally we also have multi texture atlases which is going to be helped by the work we’ve done now.

7 Likes
#12

Just like with other built in code, it might eventually happen that we’ll move it into an extension.

Creating a new extension api for this could have been done from the start, but it was a border case I’d say. I still think more people will use these things than has actually voted for the issue.

1 Like
#13

Yes it could be moved into an extension, but I think there’s several benefits to having low level functionality closer to the core than as an extension.

We are introducing new use cases in the engine that we haven’t really had before, i.e creating resources in runtime. These functions interact tightly with the resource system and collection/gameobject code for managing the created resources which means we would need to add a bunch of new APIs to the dmsdk to interact with these systems. This in turn requires us to commit to those apis a lot more in order to avoid breaking changes, as well as having unit tests running on every commit.

It’s our philosophy to have as much as possible as extensions where it makes sense, and of course we can always make this change later. But for now I don’t see any benefits of doing that at this stage of development since we will invest more in runtime resource management (creating buffers in runtime for example, which is highly requested afaik). And as Mathias points out, I think this will be useful for a lot more people than you’d think :slight_smile:

4 Likes
#14

Hi @jhonny.goransson, I understand @ross.grams post slightly differently. He doesn’t call for the new dynamic texture features to be moved into an extension. He wonders why other features, that are probably useful for more people and would require less code, are not part of the core. Like fullscreen toggle for desktop development. I agree with him, this is a rather vital feature. Personally, I would love to see RenderCam being part of the core, too, if that were at all possible.

5 Likes
#15

Yeah true, I think I answered something else or just justified our decision to not have it as an extension maybe :thinking: But in any case regarding the fullscreen feature specifically, it’s unfortunately a bit more work than exposing glfw functions - the (heavily modified) version we are using doesn’t support toggling video mode without deleting the GL context it seems, so we’d have to do something similar to what defos does. Which of course is doable, but we don’t know exactly how right now and probably don’t have time to solve it right now I’m afraid… But I agree, it’s something we should have.

3 Likes
#16

Hmm, so what does DefOS do?

Actually there’s quite a bit more code than you’d think. Here’s the PR for mouse lock which we added recently (a little over 300 lines of code in total):

2 Likes
#17

It would be nice to have this function in the engine, but there is a huge difference between these two things:
For now you can make your game full screen just by installing an extension.
But you can’t manipulate resources in runtime even if you really need it.

6 Likes
#18

Thank you three devs very much for the explanation concerning the fullscreen toggle feature.

2 Likes
#19

Answering this myself:

It does not call a function in glfw, instead it calls native functions per platform.

#20

Thanks, this answers 80% of my question right here. :laughing:

Sorry, I wasn’t really trying to get into the weeds comparing these specific features, I more meant: Given that there are 1000 open issues, what made you decide to dedicate a week/fortnight/however-long of your very limited time to this specific issue, above the 999 others? Especially considering that it appears to fall in the same categories as things you have refused to work on in the past.

But again, if it was requested by a sponsor, then that pretty much answers the question. :+1:

I have only one response: :scream: :scream: :scream: :sob: :sob:
:stuck_out_tongue:.

On the topic of Defold’s desktop support, well :sweat_smile:…I’ve been complaining about that for around 5 years and it has only improved by a few tiny steps (some only prompted by mobile development needs). Defold is mobile and web focused and that’s that.