rusty-wacc-viewer
godot-wasm-engine
| rusty-wacc-viewer | godot-wasm-engine | |
|---|---|---|
| 1 | 1 | |
| - | - | |
| - | - | |
| - | - | |
| - | - | |
| - | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rusty-wacc-viewer
-
Why WebAssembly is innovative even outside the browser
While a "host" application (for the WASM runtime used) is required to enable access to graphical output (or user input) it doesn't have to be a browser.
At the (almost) most basic level a chunk of memory can be used as a framebuffer--the host application would read the pixel data which the WASM bytecode wrote and then write it to the host display via OS-level routines.
There are some plans/experiments at making a framebuffer "device" available as part of WASI.
I've written a couple of graphical WASM host applications that aren't browsers (and which don't use memory for pixel data transfer just integer values returned from a function):
The "WebAssembly Calling Card (WACC) Viewer" is implemented via the Godot game engine and an addon that integrates the Wasmtime WASM runtime with the engine: https://wacc.rancidbacon.com
(Also implemented a WACC Viewer in Rust: https://gitlab.com/RancidBacon/rusty-wacc-viewer)
WACC specifies how to transform three integer values (returned from a function in a WASM module) into a coloured triangle in order to render it on screen.
Another "host application" I implemented was a libretro compatible plugin that loads a WASM module and then feeds the module with input from libretro & retrieves framebuffer pixel data (one pixel at a time :D ) via a WASM function call & writes it to the libretro framebuffer for display.
godot-wasm-engine
-
Why WebAssembly is innovative even outside the browser
For me, the most interesting potential of WASM is it provides a platform-independent sandboxed way to run untrusted code written in multiple programming languages.
This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser.
And while I'm sure there's "serious" business uses for that capability :) I'm most interested in what it enables in terms of user customisation/modding of games.
Which was my main motivation for creating a Wasmtime WASM runtime add-on for the Godot game engine: https://gitlab.com/RancidBacon/godot-wasm-engine
And also designing the "WebAssembly Calling Card" specification as a way of demonstrating how the same code could produce graphical output that is then used in 2D or 3D environments: https://wacc.rancidbacon.com
What are some alternatives?
hn-search - Hacker News Search
wasmtime - A fast and secure runtime for WebAssembly
wasmer - 🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten
cap-std - Capability-oriented version of the Rust standard library
Uno Platform - Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
Graal - GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
watt - Runtime for executing procedural macros as WebAssembly
awesome-wasm-runtimes - A list of webassemby runtimes
bsnes-plus-wasm - debug-oriented fork of bsnes, with added wasm runtime for scripting