WebAssembly is a portable execution format that has drawn a lot of interest due to its ability to execute applications in the browser at near-native speed. By its nature, WebAssembly has some special properties and limitations. However, by combining it with other technologies, completely new possibilities arise, especially related to gaming in the browser.
This article describes the concepts, possibilities, and limitations of running WebAssembly on Firefox.
The sandbox
WebAssembly has a strict security policy. A program or functional unit in WebAssembly is called a module. Each module instance runs its own isolated memory space. Therefore, one module cannot access another module's virtual address space, even if they are loaded on the same web page. By design, WebAssembly also considers memory safety and control-flow integrity, which enables an (almost-) deterministic execution.
Web APIs
Access to many kinds of input and output devices is granted via JavaScript Web APIs. In the future, access to Web APIs will be available without the detour over to JavaScript, according to this proposal. C++ programmers can find information about accessing the Web APIs on Emscripten.org. Rust programmers can use the wasm-bindgen library that is documented on rustwasm.github.io.
File input/output
Because WebAssembly is executed in a sandboxed environment, it cannot access the host's filesystem when it is executed in a browser. However, Emscripten offers a solution in the form of a virtual filesystem.
Emscripten makes it possible to preload files to the memory filesystem at compile time. Those files can then be read from within the WebAssembly application, just as you would on an ordinary filesystem. This tutorial offers more information.
Persistent data
If you need to store persistent data on the client-side, it must be done over a JavaScript Web API. Refer to Mozilla Developer Network's documentation on browser storage limits and eviction criteria for more detailed information about the different approaches.
Memory management
WebAssembly modules operate on linear memory as a stack machine. This means that concepts like heap memory allocations are not available. However, if you are using new in C++ or Box::new in Rust, you would expect it to result in a heap memory allocation. The way heap memory allocation requests are translated into WebAssembly relies heavily upon the toolchain. You can find a detailed analysis of how different toolchains deal with heap memory allocations in Frank Rehberger's post about WebAssembly and dynamic memory.
Games!
In combination with WebGL, WebAssembly enables native gaming in the browser due to its high execution speed. The big proprietary game engines Unity and Unreal Engine 4 show what is possible with WebGL. There are also open source game engines that use WebAssembly and the WebGL interface. Here are some examples:
- Since November 2011, the id Tech 4 engine (better known as the Doom 3 engine) is available under the GPL license on GitHub. There is also a WebAssembly port of Doom 3.
- The Urho3D engine provides some impressive examples that can run in the browser.
- If you like retro games, try this Game Boy emulator.
- The Godot engine is also capable of producing WebAssembly. I couldn't find a demo, but the Godot editor has been ported to WebAssembly.
More about WebAssembly
WebAssembly is a promising technology that I believe we will see more frequently in the future. In addition to executing in the browser, WebAssembly can also be used as a portable execution format. The Wasmer container host enables you to execute WebAssembly code on various platforms.
If you want more demos, examples, and tutorials, take a look at this extensive collection of WebAssembly topics. Not exclusive to WebAssembly but still worth a look are Mozilla's collection of games and demos.
Comments are closed.