Running in a browser

Zinc
1

Sokol (Dinghy’s backend graphics API) supports running on the web, so I’m trying to figure out the path to make Dinghy work there as well.

The best way seems to be to leverage the wasm format. Dotnet’s wasm support is only emerging, but two main ways of doing it seem to be these:

If you want JS interop:

No js, “pure” wasm:

I tried the latter on a sandbox build and the build itself was successful, but when trying to run via wasmtime it failed. I’ve logged an error in the repo here:

If anyone else tries this, let me know what works/doesn’t work for you! I’m only dipping my toes into wasm so don’t even really know how to start debugging…

2

Looking now it seems like maybe the WASI-SDK project is actually deprecated and its now being rolled into dotnet 8 proper. Going to try this later:

https://www.strathweb.com/2023/09/dotnet-wasi-applications-in-net-8-0/

More on this same path

3

Logging some more notes here:

Seems like there are two paths:

  1. Running dotnet in wasm (the WASI stuff above, I think) — this compiles all of the dotnet application to wasm for running
  2. Running wasm int dotnet (likely using wasmtime-dotnet) — I haven’t gone this route yet but I’m wondering if it may be the way to go?

For 1 — I think some of the issues I’m having may be weird interop boundaries between native compiled DLLs trying to interop with a compiled C# into wasm program trying to PInvoke those libraries in a maybe non pinvoke-ready platform (wasm). No idea tbh.

For 2 — the path here seems maybe clearer. The native libraries themselves are compiled to wasm via something like emscripten, then the C# code is compiled to wasm via the WASI sdk above but the function binding happens instead through the host application loading in the “native” dlls as wasm modules and invoking them (instead of going through pinvoke code)?

4

There’s a good chance this is completely irrelevant – I know far too little about this sort of pipeline to judge – but on the off-chance that it’s helpful: here is a prototype of Raylib-cs compiled into WASM.

I thought it might be relevant because Raylib-cs consists of P/Invoke bindings for raylib, a C library, and because the repo has a good collection of bug reports (GitHub issues) and references (bottom of README.md) that might contain new intel.

1 Like
5

This is definitely helpful! The repo does look old in terms of wasm (2 years!) but there are definitely things I can I can pluck from here about what to do. The other issue is that there is a lot of movement on modern c#/wasm stuff as well so it’s hard to figure out what is supported these days vs. what isn’t vs. what is deprecated.

Regardless, it is really cool to image a wasm + wasi version of Dinghy that could work anywhere! The biggest sticker for me seems to be figuring out what to do with the native libraries and if I should be compiling them directly to wasm or if a wasm program can load/host native DLLs.