Emscripten Support

Hi,

I’ve made a port of the Urho3D engine to Emscripten. The github repo is at github.com/badpixels/Urho3D/tree/1.32-emscripten

It’s based on the 1.32 tag. Many of the changes came from the Atomic Runtime repo. (Thank you Atomic dev(s)). Most of the samples work at some level but there are a few unsolved problems:

  • no sound
  • terrain doesn’t render
  • mouse locking fails
  • no networking. As far as I know, javascript only supports http and websockets and I don’t think kNet will work over websockets. (I could be wrong)
  • Angelscript fails. I think it has something to do with generic calling conventions but not sure.
  • anything else I haven’t tried.

The built samples can be viewed at di01.wwweb3d.net/urho/

I’ve put this up in this state as I don’t have much more time to spend on it in the near term and I thought others might be interested in helping. I would have created a pull request but I don’t know if it’s in a acceptable state of functionality yet and I would need some help rebasing it to HEAD and getting it to work with the new build system.

Most of the changes to the engine source are quite simple and are separated by #if defined(EMSCRIPTEN) directives. I had to move the files Controls.cpp and Controls.h from the Source/Engine/Network directory to Source/Engine/Input but this move doesn’t seem to affect any of the rest of Urho so I assume it’s an acceptable change.

If this is acceptable for a pull request, let me know here and I’ll create one.

Enjoy :slight_smile:

Welcome to our forum.

Great work! I happen to monitor your work at your fork a few hours earlier. I have been thinking of creating the Urho3D emscripten port too and stumbled upon your fork.

Extremely good work! AngelScript failing is exactly because of missing generic calling convention bindings, and that won’t be necessary for the PR to be accepted. We can mark the emscripten support as experimental and keep improving it as time goes on.

Nice work badpixels !

Just to note: badpixels is a regular on the irc for a long time, always helpful.

I seemed to be able to rebase to master without much trouble, however I didn’t build samples yet. Looking forward to building this myself !

I think the code should rebase quite easily, but the problem I had when I tried it was it would try to use the gnu compiler to build a native executable and would not use emcc (the emscripten compiler frontend). I poked around a while in the various cmake files but did not find a reason why. It does have the file Source/CMake/Toolchains/emscripten.toolchain.cmake which should tell it which compiler to use but that info apparently didn’t make it into the various Makefiles.

I haven’t tried building this on windows at all.

I can reproduce your success in my 64-bit Linux host system. There are still quite a number of compiler warnings from the Urho3D library side though which I think need to be cleaned.

Last night I have tested the water also on the Travis-CI to see whether their servers are capable of automate CI building with Emscripten compiler toolchain. The Linux OS environment using OLD Ubuntu LTS 12.04 is not able to build the tools, not surprisingly. The Mac OS X environment using Xcode 6.1 and OSX 10.10, however, shows some promising result. It appears to me that the emsdk when runs on Mac OS X host would actually just download the pre-built binaries for all the tools, so the whole update/install/activate things lasted just about a minute. I reckon it is fast enough to perform all these three steps at the start of each CI build. Earlier I thought we need to “install” the toolchain in one of our Github repo first, just like how we do it for android-ndk toolchain. Anyway, I am very confident that if we want to support Emscripten port officially then we have no problem in setting up the CI build for it. We could even upload the build artifacts (the html + data files) to our Github pages.

@weitjong:
I guess you’re focusing on getting linux build going first, but just fyi there is an issue with building via cmake (Windows 7): pastebin.com/jLYNDJ9U

I saw a similar error when I updated emscripten to master, however I could avoid it with mingw makefiles. I double checked and the error isn’t in master for Unix Makefiles or Mingw Makefiles.

Which generator did you choose when generating the project using cmake-gui? I have added cmake_emscripten.bat yesterday to specifically instructs CMake to choose “MinGW Makefiles” generator. But you are correct to say that at the moment I mainly tested my changes on main workstation running on Linux. You are all welcome to test the branch on other host systems and contribute to make the change. I think we should get there faster if all work together.

I am getting a build error:

/usr/include/stdc-predef.h:59:1: error: one or more PCH files were found, but they were invalid
 #endif
 ^
/usr/include/stdc-predef.h:59:1: error: use -Winvalid-pch for more information
/usr/include/stdc-predef.h:59:1: fatal error: AssimpPCH.h: No such file or directory
compilation terminated.

This is the normal build cmake_generic on linux with gcc.

I also noticed that the emscripten build doesn’t respect the folder specified in the build. It always targets the root folder.

[quote=“friesencr”]I am getting a build error:

/usr/include/stdc-predef.h:59:1: error: one or more PCH files were found, but they were invalid
 #endif
 ^
/usr/include/stdc-predef.h:59:1: error: use -Winvalid-pch for more information
/usr/include/stdc-predef.h:59:1: fatal error: AssimpPCH.h: No such file or directory
compilation terminated.

This is the normal build cmake_generic on linux with gcc.[/quote]
I think you should recreate your build tree from scratch. The Assimp library (only used by AssetImporter tool) should not be added as a CMake target in the first place. If you have pulled the latest code in the branch, our CMake common module should have prevented the tool targets from being added into the build tree, regardless of whether the URHO3D_TOOLS build option is set or not as this option should be ignored for Emscripten.

Not sure what do you mean by that. I am now very accustomed to the rake tasks. I just do: “rake cmake emscripten URHO3D_SAMPLES=1 && rake make emscripten”. The build tree is generated in the “…/emscripten-Build” relative to my Urho3D project root path, which is as expected.

I should be been clearer. This is on master. I needed to build the packaging tool so i could bundle the Data/CoreData pak files with the emscripten stuff. I reset/deleted everything and am still getting the same error.

Question about license.

I originally intended to add Emscripten license text in our existing License.txt. However, I did not check that in in the end because I realize that so far we only add licenses from third party libraries that we use when building Urho3D and we do not include any licenses from the compiler toolchains (which arguably are downloaded and installed by users into their host system instead of provided by Urho3D). Let us know if you think differently.

I am sorry that I cannot reproduce it. I just nuke my native build tree and rake cmake and rake make it successfully. All tools and samples are rebuilt OK. Before you wonder, no, there is no difference in using rake tasks or normal cmake_generic.sh build script to configure/generate the build tree.

I pulled down a fresh copy and the build works. There must be a hidden file or something I missed.

I also had to move my ~/.emscripten_cache/ports-builds/sdl2/include/sdl2 folder to get the compile to work. Package managers seem to prefer the SDL2 folder. I would bet things like the steam runtime would look there too. It might not be a bad move to use the <SDL/SDL2> path to make it easier to dropin different sdls. Hopefully we can use vanilla sdl someday.

The error is when loading the emscripten toolchain file on both Unix Makefiles and Mingw Makefiles generators (that particular error was with Mingw Makefile). Without the toolchain, cmake will configure and generate normally (although without the correct toolchain of course). The error also occurs with the cmake_emscripten.bat

I’ll look further into it and let you know if I come to any solution.

I believe weitjong has set it up for Urho to build it’s own SDL : github.com/urho3d/Urho3D/blob/e … ts.txt#L54

Also supported by the latest commit where -s USE_SDL=2 was removed. I’m not entirely sure this will prevent emscripten from including some version of SDL however.

Yeah was kind of used to doing things the old way. I am getting it slower than my ego would like.

The executable type in the toolchain ‘js’ isn’t being respected:

/home/chris/emscripten/emscripten/master/em++    -Wno-invalid-offsetof -ffast-math -m32 -Wno-warn-absolute-paths -Wno-unknown-warning-option -O3 -DNDEBUG    CMakeFiles/38_SceneAndUILoad.dir/SceneAndUILoad.cpp.o  -o ../../../bin/38_SceneAndUILoad -rdynamic ../../../lib/libUrho3D.a -lGL 

when running make against the samples the output doesn’t have an extension.

renaming the output to 01_HelloWorld.bc and using emcc:
emcc bin/01_HelloWorld.bc -o 01_HelloWorld.html --preload-file Data.pak --preload-file CoreData.pak -s ALLOW_MEMORY_GROWTH=1

this seems to work.

I get a runtime error in the browser:
Assertion failed: you need to wait for the runtime to be ready (e.g. wait for main() to be called)

The error is when loading the emscripten toolchain file on both Unix Makefiles and Mingw Makefiles generators (that particular error was with Mingw Makefile). Without the toolchain, cmake will configure and generate normally (although without the correct toolchain of course). The error also occurs with the cmake_emscripten.bat

I’ll look further into it and let you know if I come to any solution.

I believe weitjong has set it up for Urho to build it’s own SDL : github.com/urho3d/Urho3D/blob/e … ts.txt#L54

Also supported by the latest commit where -s USE_SDL=2 was removed. I’m not entirely sure this will prevent emscripten from including some version of SDL however.[/quote]
I have to temporarily remove that Emscripten-specific compiler flag first in order to enable the em++ to precompile the header. With the "-s USE_SDL=2’ some how it does not work. I have added in the code a comment that this is still in my todo list. From what I have read in my own research, I agree with you that this flag should be set to inform Emscripten to use SDL2.

I am aware of that. I only said the branch is ready for “early” testing. I did not say the work has completed. :slight_smile:

if you run emcc with -v you can see it adds a hidden path ~/.ecmascripten_cache/port-builds or something like that too the compile. emcc is a rather intrusive animal it seems.

another suggestion is that the build is using -O3 which might not work and might make debugging harder. using -O2 or lower while we test would be good.

EDIT: the reason i was confused is because the docs say to go look in the bin folder for html files.