Q: Who is the user?

[ttulka]

With a brief look at the source code, I see that the implementation (rendering, ...) is provided by the platform. This means, it is relatively easy to add support for a new language, but it is difficult to add a new platform (the whole runtime must be re-implemented).

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? The current implementation tends to the former.

I wonder if this was really the motivation as I would expect the opposite: Support of just a few popular languages (AS, Rust, C/C++) with ease of integration to my platform. This could be achieved by implementing the rendering in the Wasm module and provide just the update function, output bytes (the rendered scene) and user input interface. The platform would then need just to copy the bytes to whatever screen it has and call update.

What are your thoughts? :-)

[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!

[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 😄