Previously, we've used Wasmtime as the primary WebAssembly runtime. This time around, I believe that we should initially use WAVM. My main reason for saying this is because exploring alternative runtimes is valuable in of itself, and WAVM has several benefits over Wasmtime:
better performance: uses LLVM instead of Cranelift, also can do CPU-arch-specific optimizations like Gentoo
more conformant to the standardized C API
written in C/C++: more hackable by Mondradiko developers as opposed to Rust-based Wasmtime and Wasmer, can be built in-tree
native CMake build support: no more hacky vcpkg portfiles that download and configure binaries, we can write a portfile to actually build it as needed, and if we do so, we could push to the upstream vcpkg repo
The first step we can take with Wasm scripting is to create a singleton instance of a WebAssembly module loaded from disk, then call an update(dt) (takes an f32, returns nothing) function exported from it once a frame. Then, debug draw commands can be provided to the script to draw basic colored lines, using a very similar approach to drawTriangle() from Canary or the prototype engine's UI system.
To organize this, a new header/source file pair can be created:
include/scripting/debug_script.h
src/scripting/debug_script.c
Because debug draw is the only access the script has at the moment, the env parameter of Wasm functions can be set to the debug draw list itself. See world.c for an example of how this is wired up. cli/main.c can then create an instance of debug_script and update it every frame just like how it updates world.c.
Previously, we've used Wasmtime as the primary WebAssembly runtime. This time around, I believe that we should initially use WAVM. My main reason for saying this is because exploring alternative runtimes is valuable in of itself, and WAVM has several benefits over Wasmtime:
vcpkgportfiles that download and configure binaries, we can write a portfile to actually build it as needed, and if we do so, we could push to the upstreamvcpkgrepoThe first step we can take with Wasm scripting is to create a singleton instance of a WebAssembly module loaded from disk, then call an
update(dt)(takes anf32, returns nothing) function exported from it once a frame. Then, debug draw commands can be provided to the script to draw basic colored lines, using a very similar approach todrawTriangle()from Canary or the prototype engine's UI system.To organize this, a new header/source file pair can be created:
include/scripting/debug_script.hsrc/scripting/debug_script.cBecause debug draw is the only access the script has at the moment, the
envparameter of Wasm functions can be set to the debug draw list itself. Seeworld.cfor an example of how this is wired up.cli/main.ccan then create an instance ofdebug_scriptand update it every frame just like how it updatesworld.c.