Defold 1.3.4 has been released

Defold 1.3.4

Engine

FIX: (#6643) Reduce Lua bytecode size

Details

For builds using LuaJIT the resource archive contains both 32- and 64-bit versions of the bytecode for all Lua files. The difference between the 32- and 64-bit bytecode is usually not that big which means that there is a lot of duplicated bytecode. To improve on this the build tools now generate a diff/delta between the two and instead apply this delta to generate the 32-bit bytecode if needed. With the improvement in place the size of the bytecode can be reduced by between 30% to 90%. Finally, if bundling for only a single architecture the delta will be ignored and only the bytecode for the appropriate architecture will be included in the bundle.

Fixes https://github.com/defold/defold/issues/6193
Fixes https://github.com/defold/defold/issues/6643


FIX: (#6642) Only copy Android native libs for the bundled architectures

Details

The Android bundler always copies native libraries from dependencies for all supported architectures (32 and 64b bit) even if the bundle is created for a single architecture. To reduce the size of the generated APK the Android bundler will now only copy library files for the architecture(s) for which the bundle is created.


FIX: (#6647) Speed up Lua script file processing

Details

This fix will speed up the processing time of Lua files significantly. The primary improvement is achieved by changing the way Lua comments are removed from the source code and by caching results between build steps.


FIX: (#6549) Early out of render script if window is minimized

Details

The frustum calculation in the default render script does not take into account situations when the window width or height is 0. This can for instance happen on the frame when the window is minimized on Windows. In such situations the frustum calculation resulted in an invalid frustum and the subsequent draw command generated a Lua error. The default render script will now detect this and early-out of the update() function.


FIX: (#6563) Improved progress bar when streaming the wasm file on engine startup

Details

This improves the accuracy of the HTML5 progress bar when streaming the .wasm file on engine startup (using the Wasm Streaming option in game.project).


FIX: (#6629) Crash when processing invalid render entries

Details

The frustum culling task modified the behavior of the render entries list.
We need to keep that array compact, and in this case the dmRender::RenderListSubmit()-logic was a bit flawed.


FIX: (#6602) Issue 6602: Fix for looping out of bounds when generating render batches

Details

Fixes a crash when generating render batches.


Editor

FIX: (#6401) [DEFEDIT-6401] Faster resource-sync after external changes

Details

User-facing changes

  • Reloading large collections or game objects that have been modified externally is now a lot faster.
  • The editor will now skip reloading externally touched files if they already match the in-memory state.

Technical changes

  • Added metrics for time spent in project loading, resource-sync, and graph transactions during development. To enable, add the metrics profile to the Leiningen command line, or start java with -Ddefold.metrics=true when running the editor.
  • Optimized graph traversal when applying overrides.
  • We now calculate the hash of externally touched files and compare them to our in-memory state to check if they have meaningful changes. If they do not, we skip reload and keep the existing nodes in the graph.
  • The g/override function now takes a :traverse-fn instead of a :traverse? predicate in the opts map. You can create a traverse-fn from a traverse? predicate using (g/make-override-traverse-fn traverse?). Like before, the traverse? function takes a Basis and an Arc, and is expected to return true if the Arc should be followed.
  • Added g/node-instance-of-any? for when you want to efficiently determine if the type of a Node adheres to any of several node types.
  • We now use Arcs and pair in some hot-spots where we used to use multi-element Clojure vectors.

FIX: (#6558) Don’t scroll to selection unless it changed

Details

We scroll on every selection sync. This was initially implemented to scroll to item in the outline when selection in the scene is changed. Current behavior has a downside: when a property of a selected item is changed, it forces the scroll to happen, which is very annoying. This changeset skips tree view scrolling if the selection didn’t change.


24 Likes

There isn’t a 1.3.4 stable release - I presume it’ll be the same sha as Release 1.3.4 · defold/defold · GitHub ?

Huh, that is odd. I think I’ve seen that happen before. I’ve unchecked the Pre-release checkbox on GitHub.

1 Like

Seems, the new profiler very resource-intensive on Windows PC. Not sure why but build with enabled profiler runs also Windows Defender and both they got about 60-70% of CPU. Vs 8% with disabled profiler by appmanifest.
Also the profiler blinks:

Before create an issue report i want to explore is it only mine issue, or it affects other Win PC.

Defold channel editor-alpha
Defold editor sha c0ed825
Defold engine sha 80b1b73
Defold version 1.3.4
GPU NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2
GPU Driver 4.6.0 NVIDIA 472.39
Java version 11.0.15+10-LTS
OS arch amd64
OS name Windows 10
OS version 10.0
4 Likes

For me the blinking happens too. I will check out performance later on

1 Like

I’m not sure if this is a general problem on Windows or not. We haven’t seen this in our own tests as far as I know. @JCash any idea?

For me 1.3.4 not worked in windows :frowning:

1 Like

It seems like some kind of Windows defender or Windows firewall affects that.
Could you please take a look if some other process takes a lot of CPU at the same time, if so could you try to add your project folder and Defold itself into a whitelist ?

3 Likes

Two of my team have the same issue. How can we disable the web profiler?

Generate App Manifest here Defold App Manifest generator with disabled profiler and add it to the project settings in native extension section

1 Like

Set buffer to 64 in project and get the following
ERROR:GAMESYS: A sound could not be played since the sound buffer is full (32).

Any crash related to the new profiler? I’ve just moved over to 1.3.4 and I’m getting random crashes on iOS (latest version).
They happened while I was recording gameplay videos via quicktime but never had those before and nothing changed in my code. I’m at a point where I’m simply balancing game settings.
Will need to check the full logs tomorrow and also test without recording.

Yes. There is a fix in the 1.3.5 beta.

2 Likes

Could you please try the latest beta and let us know if it works or not?

https://d.defold.com/beta/

1 Like

It is still the same.

INFO:DLIB: Log server started on port 55799
INFO:ENGINE: Target listening with name: DESKTOP-H503RHD - fe81::3929:231b:a3ac:c738 - Windows
INFO:ENGINE: Engine service started on port 55800
INFO:GRAPHICS: Initialised graphics device 'opengl'
INFO:ENGINE: Defold Engine 1.3.5 (1bbbf68)
INFO:DLIB: MAWE: Create global Remotery instance!
INFO:DLIB: Initialized Remotery (ws://127.0.0.1:17815/rmt)

And then the window freezes (not responding)? Do you get any kind of connection request that you need to approve?

And then the window freezes (not responding)?

Yes, It is.

Do you get any kind of connection request that you need to approve?

Yes, it was once from windows firewall as usual after update or first run.

1 Like

Ok. Others are no longer having the window freeze issue. Strange. Could you please try this build and see if you still get a freeze or not:

I didn’t understand which build. 1.3.5 (1bbbf68)?
Not freezing do you mean It should run build?

I shared a build with a potential fix for the “Window not responding” issue here:

http://d.defold.com/archive/dev/4fedc6c9b60a833f89734a9ef28d430357c08a01/dev/editor2/Defold-x86_64-win32.zip

Yes.

By the way, let’s continue the discussion on GitHub to collect all info in one place. Please let me know the result by posting in the GH issue!

3 Likes