https://github.com/leops/fabric
An experiment on extending the Source engine with a WebAssembly runtime
https://github.com/leops/fabric
source-engine wasm
Last synced: 11 months ago
JSON representation
An experiment on extending the Source engine with a WebAssembly runtime
- Host: GitHub
- URL: https://github.com/leops/fabric
- Owner: leops
- Created: 2020-11-15T20:52:51.000Z (over 5 years ago)
- Default Branch: main
- Last Pushed: 2022-12-16T18:17:20.000Z (about 3 years ago)
- Last Synced: 2025-02-13T08:50:09.859Z (about 1 year ago)
- Topics: source-engine, wasm
- Language: Rust
- Homepage:
- Size: 28.3 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
Fabric
===============
An experiment on extending the Source engine with a WebAssembly runtime, see
[ChaosInitiative/Portal-2-Community-Edition#421](https://github.com/ChaosInitiative/Portal-2-Community-Edition/issues/421)
for an in depth context / explanation
# Features
For this version the Fabric runtime is compiled into a server plugin DLL loaded
by the engine. The features exposed to the WASM modules are a (very small) subset
of the APIs exposed to server plugins, namely registering event listeners and
inspecting received event objects. The aim here is not to provide a workable
environment for scripting (yet), but to showcase the feasibility of integrating
WASM code with Source with both calls from WASM to then engine and from the
engine to WASM.
# Backend
Right now this project uses Cranelift as a "production" backend for emitting machine code.
This allows a greater control over the emitted code compared to over "off-the-shelf" WASM
libraries, and in turns permits relaxing the threading constraints of the WASM environment
(specifically that all WASM code can only be called from a single thread, a constraint difficult
to enforce when integrating an existing software like Source without hurting performances).
But this also means a bunch of WASM feature are left unimplemented (for now), and debugging
the emitted code is nearly impossible.
In the near future I'll add an alternative "debugging" backend using V8. Since V8 needs
to be run from a single thread this version will certainly have an important performance
overhead, but will allow debugging the WASM code using the existing Chrome Devtools.