Defold 1.2.141 has been released

[dapetcu21]

So, regarding dynamic libraries, using dynamicLibs should allow us to link against dynamic libraries on platforms where you were compiling with -Wl,static, (namely Linux and Android, I think), right? Two questions:

1. Does this also bundle the library along with the executable or do we still have to duplicate it in res?
2. When running from the editor, if the game links against any dynamic libraries (which would exist at their proper paths if bundled), it will most likely crash if it doesn’t find them. Are there any plans to mitigate this?

[Mathias_Westerdahl]

Well, I’m afraid there are still a few things left for the actual ticket (DEF-2732) to support dynamic libraries. E.g. uploading the shared libraries to we can link against them, bundling with them in a correct fashion. Still no ETA on that.

This flag (“dynamicLibs”) was one part of it, but also needed for using the sharedlib “jnigraphics” for Android, in a native extension.

[snakky]

html5 build stopped loading after update, there’s a message in console:
wasm streaming compile failed: TypeError: Response has unsupported MIME type

[sven]

@snakky What webserver are you running from?

From the editor it should work, it has been updated to serve the wasm files with correct MIME type. However, if you are running the bundled output through your own webserver it needs to be configured.

Here is a super simple python server that will serve the wasm files with correct MIME type: https://gist.github.com/andsveking/df04bcac5f687525f7ce2389817ae595

[snakky]

I’m using nginx.

[sven]

You can configure them this way: https://stackoverflow.com/questions/16789494/extending-default-nginx-mime-types-file

It should be configured so that files ending with .wasm has MIME type application/wasm.

[dmitriy]

I updated to new defold-fmod version and project works now (thanks everyone involved). It works ok in Safari on macOS and in Edge on Windows, but in macOS Opera it runs super slow. Any thoughts why it runs so slow in Opera?

[sven]

Any thoughts why it runs so slow in Opera?

Not sure, is it the “release” version you are bundling?

[dmitriy]

Yes, “release”. Without webassembly support this example worked in Opera slightly faster then in Safari.

[sven]

Just tried the example again and it looks like logging is enabled, which would indicate it’s not a release build. Do you have your own app-manifest or similar?

Edit: I think I found it. Sadly it seems that variants does not work as expected for wasm builds, I will fix this and it should be available in next release. Until then, as a workaround, you should be able to modify the output HTML file by adding this:

engine_arguments: ["--verify-graphics-calls=false"],

to the extra_params object. More details here:

Low performance in html5 bundle (SOLVED)

Are you using a native extension? Native extensions currently always generate debug builds. Debug builds does a lot of calls to check for webgl errors and this is slow on Chrome. If this is the case you have two options: Bundle with an app.manifest file that replaces the debug version of the engine with a release version. Check here for tools to generate app.manifest files: Stripping appmanifest maker Edit your index.html file and explicitly disable graphics call verification. Like this: v…

Added issue DEF-3604.

[inactive-vilse]

pprint issue tracked as DEF-3607.

[COCO]

The engine file of wasm is only 750kb after gzip, that’s fantastic!

[sven]

I’ve created a separate post regarding WebAssembly and using a custom HTML template:

Custom HTML templates and WebAssembly

Hi all! If you are currently using a custom HTML template for your HTML5 bundling (specified as html5.htmlfile in your game.project) you might have problems after the latest update (1.2.141). This is due to us changing the name of the engine binaries in HTML5 bundles. Previously there was only one engine JavaScript file (<project_name>.js), but after 1.2.141 there is actually two files (<project_name>_asmjs.js for AsmJS and <project_name>_wasm.js for WebAssembly). The quickest fix is to bundl…

If you are having issues with a custom template, please reply to that thread!

[britzl]

pprint issue tracked as DEF-3607

Released in 1.2.142

[britzl]

Added issue DEF-3604

Released in 1.2.142

[lazy.kokos]

Could you please clarify the “dynamicLibs” usage for iOS ? We can’t seem to get it working. Best result which we were able to achieve so far is the error message "Error in ‘thirdparty/ext.manifest’: invalid lib - ‘dynamicLibs’:‘thirdPartySDK’ "

[Oleg_The_Evangelist]

let me help @lazy.kokos to assemble the whole story here.

Here’s his question in the chat:

got the build completed successfully, when linked against static library. it’s ok on its’ own but we have another issue with static lib itself (its’ the question to library devs, not to you).
So we tried also to build with dynamic library version, which is newer and doesn’t have the issue - and in this case plist version doesn’t seem to help - we’re getting “embedded dylibs/frameworks are only supported on iOS 8.0 and later” despite the version in plist was set to 10.0

My understanding is that @lazy.kokos is trying to build an empty/dummy project with a single native extension that utilises a third party library that was built/linked for iOS 8. The issue they’re having is that they cannot make the whole project get linked for iOS 8.

So probably the question is: how can they ensure that Defold builds/links the project for iOS8 so their 3rd party library is compatible.

[Mathias_Westerdahl]

First, read this clarification
Basically, it’s currently for Android, to control the flag “-Wl,dynamic”

We currently build for min iOS version 6.0.
There currently is no way of changing that by the user.

[gerrykwok7]

Hi, @Mathias_Westerdahl
Would you please explain How to link against dynamicLib concretely?

[Mathias_Westerdahl]

We currently don’t support linking to the users’s dynamic libraries. It’s in ticket DEF-2732, which we hope to be able to start soon, in the beginning of 2019.