Q: Who is the user? about wasm4

[aduros]

For the common platforms I'm planning to support things like w4 bundle build/cart.wasm --windows my-game.exe even if you're not on Windows. Prebuilt runtime binaries would be shipped with wasm4 and the cartridge would be injected into them, without requiring recompilation. Exciting stuff!

As for how to best support embedded devices, not sure yet but one step at a time 😄

[aduros]

Is the goal of the project to be extendable for language creators, or to write Wasm games that run easily on any new/exotic platform?

Both! 😄

From my point of view, there are only two main platforms: the web browser (written in JS), and everywhere else (written in C). The C implementation would use something like wasm3 to run on everything from desktops to embedded devices. Would that not basically cover every platform or am I missing something?

We'll always have to maintain some platform-specific code for touching the hardware for things like sound, I/O, etc. I think the only platform agnostic part of the runtime right now is framebuffer.js, which is fairly minimal. We'll need to port that file to C at some point.

I avoided including the runtime in the cartridge wasm because:

• Smaller cartridges since they don't include any runtime.
• For embedded platforms, runtime methods implemented in native C are faster.
• Runtime methods don't need to be re-implemented in multiple client languages (AssemblyScript + C + Rust + Go + ...)

In the future if the runtime grows and maintaining JS + C versions becomes a lot of work, we could potentially move everything to C and compile that to a wasm4-runtime.wasm shared library that we load on both web and native.

What do you think?

[ttulka]

Thanks for the answer, makes a lot of sense!

So, wasm4 provides C source codes that the user can compile the platform on any machine/architecture/whatever from. Then some glue code for IO and it is ready to go.

I guess more insight will be gathered from the first implementation. I am looking forward!