asm.js support

[pezcode]

Hey,

Is compiling for asm.js supported with this particular build setup? I can compile just fine with VS2017 but I'm struggling to get it to work with CMake and the Emscripten toolchain file.

I tried different CMake generators:

• MinGW or Unix Makefiles: CMake complains about CMAKE_MAKE_PROGRAM not being set
• Ninja: Can't find X11
• NMake Makefiles: Can't find Threads library

I'm wondering if this is a problem with the libraries being used or a mistake on my end.

[JoshuaBrookover]

I don't know if GLFW works with Emscripten, that would be my main concern with trying this. If it does, you're on the right track with trying to use the Emscripten toolchain, because that should set your CMAKE_MAKE_PROGRAM. I'm not sure why it's failing you. My guess is that Unix Makefile would be the proper generator to use.

Someone else added the Emscripten build support to bgfx.cmake, and they provided build instructions in the travis file here: https://github.com/JoshuaBrookover/bgfx.cmake/blob/master/.travis.yml#L81

Seems they use emconfigure cmake . -DBGFX_BUILD_TOOLS=OFF and emmake make. If you're familiar with docker maybe you can try running all that in the same docker container they're using.

I'm happy to help further, but I have a backlog of other things I need to get to before I can try any of this myself. Best of luck.

[pezcode]

Thanks for the pointers. I made some progress off of this so that it compiles:

GLFW3 is supported by Emscripten. Instead of building/linking to it, you have to set -s USE_GLFW=3 during linking. The way I fixed this in Bigg is to check if a target called glfw already exists and only then does it include the subdirectory in deps. Then, before adding bigg, I defined my own interface target glfw in CMake like this:

add_library(glfw INTERFACE)
target_include_directories(glfw INTERFACE "${EMSCRIPTEN_ROOT_PATH}/system/include")
target_link_options(glfw INTERFACE "SHELL:-s USE_GLFW=3") # links in GLFW emscripten port

There are some changes to Bigg source code required:

• Emscripten has no glfw3native.h
• Emscripten doesn't support glfwSetCharModsCallback but that's only a warning
• The blocking while loop with glfwWindowShouldClose doesn't work in browsers. Instead you have to call emscripten_set_main_loop_arg with a callback. That callback (draw) essentially does the same as the code inside the loop previously:

	lastTime = ( float )glfwGetTime(); // lastTime is now a class attribute
#if BX_PLATFORM_EMSCRIPTEN
	// Enter Emscripten loop
	auto drawLambda = [](void* _this) { (( bigg::Application* )_this)->draw(); };
	emscripten_set_main_loop_arg(drawLambda, ( void* )this, -1, 1);
#else
	// Loop until the user closes the window
	while ( !glfwWindowShouldClose( mWindow ) )
	{
		draw();
	}
#endif // BX_PLATFORM_EMSCRIPTEN

• There were some other minor hickups with bgfx that needed changes
  • entry_asmjs.cpp was missing an #include<csdtdio>
  • glsl-optimizer defines ffs() and ffsll() which causes linker errors because they already exist in libc which Emscripten links statically (simple fix: add_compile_definitions(ffs=my_ffs ffsll=my_ffsll))

So now it compiles but nothing appears on screen. I haven't figured out how to get bgfx to initiate a context inside the canvas element. There are functions for creating contexts in Emscripten from a given canvas, but I don't know how to pass that to bgfx. This suggests it's possible, but I don't know what data it expects.

As for the bgfx tools:

Emscripten compiles shaderc etc. into .js files. You can build them or not (BGFX_BUILD_TOOLS=OFF), doesn't really matter. The problem is that the add_shader function in CMake tries to run shaderc. I have a few ideas on how to fix that, but this is a minor problem. My current workaround is to build the project natively and then just copy the shaders manually. Worth revisiting once the code works.

Not sure how soon I'll get to work on this again since I'm a little strapped for time as well, but I'll update this with any progress.

[pezcode]

A few more sidenotes for anyone else reading:

The X11 and Thread errors appear because GLFW needs them. Not compiling and linking it (as outlined above) fixes all those errors.

I ended up using Ninja because I didn't feel like putting make into PATH on Windows:

mkdir build_emscripten
cd build_emscripten
emsdk_env
set TOOLCHAIN=%EMSCRIPTEN%\cmake\Modules\Platform\Emscripten.cmake
cmake .. -G "Ninja" -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=%TOOLCHAIN%
cmake --build .

I didn't need emconfigure or emmake, I suppose the CMake toolchain is enough to set up all necessary variables.

Also, to generate .html instead of .js for the main executable:

set_target_properties(App PROPERTIES SUFFIX ".html")