Defold 1.2.141 has been released


#21

Not sure that’s very useful, considering that we need the LLVM library to link it to Defold, not the final .js or .wasm binary which is useful if you want to use fmod from JS


#22

@dapetcu21 I created a PR for the fmod extension that should solve the issue: https://github.com/dapetcu21/defold-fmod/pull/6

@dmitriy you could try changing to this branch to verify it works for you as well (replace dependency in game.project with this URL): https://github.com/andsveking/defold-fmod/archive/hotfix-wasm.zip


#23

Update: For iOS and HTML5, you can use the common platform name (the second part of the tuple), in this case “web” and “ios” to store the library. For HTML5 it works because it’s the same intermediary format output by emscripten. For iOS it works if the library is in fact a fat library (i.e. it contains both armv7 and arm64 versions)

This is in fact how @sven solved the issue in his PR to the FMOD repo.


#24

Thanks! I merged it and made a new release:


#25

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?

#26

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.


#27

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


#28

@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


#29

I’m using nginx.


#30

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.


#31

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?


#32

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


#33

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


#34

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:

Added issue DEF-3604.


#35

pprint issue tracked as DEF-3607.


#36

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


#37

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

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