HTML5 platform support

[caspark]

Do you have any interest in supporting FMOD's HTML5 platform in this crate?

Doing so is tricky due to the ABI incompatibility between Emscripten and the wasm32-unknown-unknown target that much of the Rust community is targeting, but it's possible to make it work by proxying through JS: basically each fmod-oxide function would use wasm-bindgen to define some extern JS functions, which in turn call into a separate FMOD's WASM instance. The error handling is a pain but it does work (demo at bottom here).

So, theoretically:

• I think it would be possible to provide approximately the same API this crate does today, and just "magically" have it work on the web.
• The big exception is the initial initialization: it requires loading the FMOD JS script and calling window.FMODModule(myEmptyFmodObject), which then gives you a callback to "mount" files for loading banks and a second callback when FMOD is done loading - and only then can you create systems.
  • There are some other much smaller API differences too (for example you can't set a custom logging callback) but those could be handled via cfg attrs as needed.

Obviously it would be a significant amount of work to mirror all the APIs too.

[melody-rs]

This is absolutely something I want to support- I had other issues to fix first before I wanted to get around to it.
I was thinking of testing if the wasm32-unknown-emscripten target would work out of the box and supporting that
If that didn't work, I was then going to use the recently stabilized naked function feature + some inline assembly to call the FMOD functions with the right ABI (I have no idea if this is feasible)
Maybe it's possible to hook into bindgen and generate all the JS glue code like you demonstrated?

The main thing I'm concerned about is that the HTML5 FMOD API is designed to be used from JavaScript- so I have no idea how things like pointers or C String handling would work. Do correct me if I'm wrong though!

As for initial initialization, maybe it's possible to tackle this the same way other crates handle dynamic loading? That'd be something like:

let library = FMODLibrary::new();
library.mount(|| { /* code here */);
library.on_finish(|system_builder| { /* do fmod things here */ });

The callback for FMOD loading sounds like it could be turned into a future?

[melody-rs]

Reading through your blog a bit, the going for JS glue sounds.. way more complicated and simple than I expected. I had no idea they were doing pointers in such a scuffed way, but this looks so close to the C API it'd probably be possible to generate bindings
bindgen doesn't support generating glue code, so we can't use bindgen. However we can use the same approach I did for code coverage and use the clang crate to parse headers and make our own bindings, glue code included

[melody-rs]

I wonder if this is relevant? https://doc.rust-lang.org/stable/unstable-book/compiler-flags/wasm-c-abi.html

[caspark]

I think that flag is for previewing the changes related to https://blog.rust-lang.org/2025/04/04/c-abi-changes-for-wasm32-unknown-unknown/ (it's referenced in https://github.com/rust-diplomat/diplomat/blob/main/docs/wasm_abi_quirks.md , which is linked from that blog post).

I suppose it is theoretically it is probably possible to write a shim that adapts from the Emscripten ABI to "Rust's" (well, it's actually not really "Rust's", it turns out) ABI, so that you can call any Emscripten-C-compiled function from some wasm32-unknown-unknown-targeting Rust code. That's too much of a (tempting but definitely unwise!) diversion for me though :)

I'm extracting my demo's JS glue code into a standalone thing right now.

[melody-rs]

That's too much of a (tempting but definitely unwise!) diversion for me though :)

That's ok. I'm down to go on a sidequest right now :3
Atm I'm trying to see if building using wasm32-unknown-emscripten works at all, and then going from there

[melody-rs]

[caspark]

But does it work? I would have expected you'd have to do something like what https://www.fmod.com/docs/2.02/api/platforms-html5.html#build-your-own-asmjs-or-wasm-files-from-the-bitcode-bc-files sketches out.

Anyway, I've pushed up a demo of my JS shim: https://github.com/caspark/fmod-web-test/ . It is not suitable for use as-is at all because I boxed everything and did not particularly worry about sticking to the shape of the FMOD API (it's extracted from my game, so obviously I can make some assumptions). Might be useful to someone if they stumble on it if your approach doesn't work out, though.

[melody-rs]

But does it work? I would have expected you'd have to do something like what https://www.fmod.com/docs/2.02/api/platforms-html5.html#build-your-own-asmjs-or-wasm-files-from-the-bitcode-bc-files sketches out.

No idea yet, I've been fixing up the build script to allow for cross compilation

[melody-rs]

[melody-rs]

One kinda annoying problem that I don't know how to work around is that FMOD requires EMCC_CFLAGS to contain -s EXPORTED_RUNTIME_METHODS=ccall,cwrap,setValue,getValue.
Setting it in .cargo/config.toml works, but not setting it in the build script

[melody-rs]

wasm-bindgen doesn't seem to work...

Possibly related?

[caspark]

(I have not looked at your changes in master properly, however:)

rustwasm/team#291 (comment) (example 5 in linked repo) suggests that it might actually be possible to do C interop with just regular bindgen plus -Zwasm-c-abi=spec these days, so might be less impossible than I thought? However the big difference in our case is we don't have fmod's source so have to deal with whatever Emscripten outputs.

rustwasm/wasm-bindgen#1202 (comment) has some discussion regarding a nicer way of doing the initial emscripten wasm load, though it doesn't cover setting up the prerun hook that fmod expects.

[melody-rs]

rustwasm/team#291 (comment) (example 5 in linked repo) suggests that it might actually be possible to do C interop with just regular bindgen plus -Zwasm-c-abi=spec these days, so might be less impossible than I thought? However the big difference in our case is we don't have fmod's source so have to deal with whatever Emscripten outputs.

Yep, that's what I'm working with at the moment!

rustwasm/wasm-bindgen#1202 (comment) has some discussion regarding a nicer way of doing the initial emscripten wasm load, though it doesn't cover setting up the prerun hook that fmod expects.

Maybe? I've got an idea that might solve the prerun hook and the wasm-bindgen issue

It turns out, you can compile a wasm32-unknown-unknown build without linking FMOD just fine:

And it even works with wasm-bindgen:

Apparently it's possible to instantiate a webbassembly module, and then import said module's exports into another webassembly module

Need to test this, but it might be possible to compile a rust project without linking FMOD, and at runtime, instantiate FMOD separately and import it when instantiating the rust module

[melody-rs]

It kinda works

Emscripten makes this more complicated than it should be unfortunately, and I had to edit wasm-bindgen's glue code to get to this point

I suspect this has something to do with emscripten wrapping C functions. There's unwrapped versions but I can't figure out how to get a hold of them