[FEATURE REQUEST] WebAssembly Build

[xx1182]

As the title suggest, i'll also try and then post progress:
It should be pretty easy, because GLFW just provides "context for opengl" while go-gl is the actual graphics library.

Regards.

[xx1182]

Hey, I've looked into it and there is nothing I can do, unless you throw glfw away.

Also there is gopherjs which compiles go to js, but I'm unsure it will work, since there are still c bindings.

If you got a better idea/plan feel free to suggest, and I'll look into it:

The easiest approach(I think) would be like I said, skipping glfw and writing directly in goGL. Regards nice cock

[formula1]

I'm moving forward, probably just on the easy parts

The general Plan is

• FileSystem
  • Change the filesystem to load from a zip and save as memory or localstorage
  • I'm thinking LocalStorage for things like Controller Config
• Controller
  • Controllers will be handled in the browser
    • This includes maping GamePad's to compatible Ikemen Go Controllers
  • Every Frame, Ikemen will run a "getControllerInputs" function which will provide all the controllers current Buttons
• Audio
  • Hopefully I can just use beep or another go library
  • Try to use WebAudio
• Draw
  • Whatever's closest to current (Webgl, Canvas, etc)

FileSystem and Controllers are likely the easiest but I need some help

So I'm having some issues with Go Generics FileSystem

• It seems you're using only a small subset of what os has to offer
• It's relatively easy to create bindings to native
• But I'm having issues with handling the Generics
  • Generic callbacks https://github.com/formula1/ikemen-go-js-bindings/blob/master/native/file_native.go#L35
  • The Whole Mess that is New Types https://github.com/formula1/ikemen-go-js-bindings/blob/master/go/src/file_wasm.go

This is my first time getting deep into go so any guidence would be appreciated

[xx1182]

Hi, any news on this?

[formula1]

@xx1182

I was able to get the filesystem out of the way but audio and drawing is more complicated

Now that ikemen go is using the latest beep audio should be less of an issue

• https://github.com/ikemen-engine/Ikemen-GO/pull/1949/files
• Can't compile to wasm gopxl/beep#77

I don't remember looking into controllers but I probably need someone to point me into the write direction

Here was my pull request #1639

[mathmati]

Hi all, following up on this item we got Ikemen GO running fully in the browser & there's a live demo below:

https://mathmati.github.io/fiiight/

It's the current develop engine (05b7d98) compiled with GOOS=js GOARCH=wasm, no server side, runs entirely client-side:

New js-tagged backend files alongside the SDL ones: WebGL2 renderer (ported from the GLES 3.2 backend), WebAudio sink wrapping the same final-mix interface as the SDL speaker, keyboard + Gamepad API input with save-file-compatible key names, and a canvas window whose SwapBuffers blocks on requestAnimationFrame so the loop yields every frame.
Game content ships as a single zip mounted on an in-memory Node-style fs shim (what wasm_exec.js expects), with saves persisted to localStorage.
The diff is deliberately structured for upstreaming: additive _js.go files plus five small patches to shared files (build-tag gating, a speaker factory, modifier-key constants). Full seam analysis is written up in the repo (port/SPEC.md).
Source: https://github.com/mathmati/fiiight (engine vendored; the js backend lives in engine/src/_js.go).

Known gaps: netplay (raw TCP/UDP doesn't exist in browsers - a WebRTC DataChannel transport is the plan) and module music (.xm/.mod/.it/.s3m); 3D-model shadows are disabled (WebGL2 has no geometry shaders). Background videos, streamed music and MIDI (via a bundled soundfont) all work.

If there's interest in taking this upstream I'm happy to open a PR and adapt to whatever structure you prefer.

Roster note: the bundle includes Takezo and Genpaku by @donswelt (KGenjuro) as they were fully original, hand-drawn, and their small animated intro stories helped test a few things in the port (storyboards, MIDI music, video). I've included them with a note and accreditation in the bundle manifest but please KGenjuro let me know if you're happy with them staying in, or would rather I removed them. I wanted some demo characters beyond the Kung Fu Man cast, but it's hard finding IP-safe things for a clean baseline repo, if others have open characters from original IP that could be included, let me know.

For transparency we are using Claude Code as well while working on this.

[donswelt]

Hey, Donswelt here, creator of Takezo and Genpaku. I knew it was a good idea to upload them to Github when I found those characters in an old backup of mine. I'm totally fine with them being part of this project.

[mathmati]

Thanks Don - they are nice characters and helped test out some additional features on the browser port. All seems to work fine and I have had plenty of fights using them now :)

[K4thos]

Hi, @mathmati, I went through the port, the seam document, build scripts and browser-side code. I also tested it on my laptop and in Brave on my phone, and it seems to be working just fine.

I'm personally in favor of upstreaming it, if you're also willing to help maintain the upstreamed WASM code, look into browser-specific bugs or regressions that come up after it's merged and finish the work on netplay integration (can be done post merge).

Before preparing the PR, please join our Discord so we can discuss it with the other active devs and collect any additional feedback or objections:
https://discord.gg/Qu8aPzwX7

I don't want to promise the merge on behalf of everyone before that discussion, but my general direction would be:

• Rebase the work onto the current develop branch and adapt it to the upstream layout. The engine is in the repository root, so the changes should go directly into src/, rather than bringing over the vendored engine/ structure.
• Do not include the fiiight demo content, roster, DROP-IN-PICKS.md, generated WASM/content bundles or test screenshots. For official builds and any official web showcase, we would use the existing Ikemen-GO-Screenpack, the same as for our other releases.
• Integrate Web as a target of our existing build system, ideally something like ./build/build.sh Web. A dedicated helper script underneath that is fine. The output should be a self-contained static directory that users can host themselves.
• The content packager should accept a complete game/content directory instead of assuming the fiiight content/ layout. CI can prepare an official directory from Ikemen GO plus the Screenpack, while users can point it at their own game. Worth to consult with @Jesuszilla who is maintaining the android port, maybe this content.zip functionality could be unified. Either way this is just an extra feature, the engine should use what's directly in the folders by default.
• Please avoid an unrelated global Go toolchain or dependency bump unless it's actually required by the port. You used Go 1.24, while we're still on 1.20 due to Windows 7 compatibility. A Web-specific CI job can use a separately pinned Go version, but only if it's actually needed.
• The browser runtime could be moved to build/wasm/, with generated output going to bin/Ikemen_GO-Web/.
• The Android-specific helper seam using androidInit() plus a non-Android no-op could also be renamed to something generic, such as platformInit() and platformInitSubSystems(), to provide a cleaner abstraction.

We could update our release pipeline to build an Ikemen_GO-nightly-Web.zip artifact containing the static host directory and official screenpack bundle. Users would be able to unzip it, replace or regenerate content.zip, and host it on any suitable static server. The pipeline could also deploy an official nightly showcase under ikemen-engine.github.io/play/.
The pipeline stuff is something I can handle myself after the merge. Feel free to add those changes yourself if you like, though - I'll review them.

The Claude Code note is fine, and thanks for being transparent about it. It doesn't change the normal review requirements. The important part is that the submitted code is understood, testable and maintainable by its contributors.

edit: discussion started here: https://discord.com/channels/233345562261323776/233363722934943744/1526174334627090452

[mathmati]

Hi K4thos, thank you for the positive response. I don't use Discord etc. as it all turned into a bit of a black hole of time for me. I confirm I'll help with any integration issues, and no issue re: removal of "fiiight" etc., that was just a working folder, and the main focus is helping get a browser version live for Ikemen GO.

I've addressed the points on a branch off current develop:

• Rebase onto develop / changes in src/, not a vendored engine tree: done. Rebased onto current develop; the browser backend is a set of additive *_js.go files in src/, with only small build-tag gating on the shared files. No engine/ directory.

• No fiiight demo content/roster/DROP-IN-PICKS/generated bundles/screenshots: done, none of that is on the branch. The packager pulls the official Ikemen-GO-Screenpack, same asset set as the other release targets.

• ./build/build.sh Web target with a helper script, self-contained static output - done. Web is a target in build/build.sh; the helper is build/wasm/build_web.sh; output is a self-contained static directory at bin/Ikemen_GO-
  -Web/ that can be hosted anywhere.

-Generic content packager (any game dir, not the fiiight layout): done. It takes a complete content directory (CONTENT_DIR arg/env) and defaults to the repo's own data/ external/ font/ with the Screenpack overlaid. The engine uses what's in the folders directly; the zip is just an optional packaging step. Happy to coordinate with @Jesuszilla on unifying this with the
Android content path as a follow-up, I kept it decoupled from this branch for now.

• No global Go toolchain/dependency bump; stay on 1.20 for Win7: done, go.mod stays go 1.20 with no toolchain line. The one change that was actually required: the flac decoder's helper (mewkiz/pkg) doesn't compile under GOOS=js (unix-only syscalls in its old term subpackage), and its fixed release declares go 1.23. I vendored it and mewpkg/term under third_party/ with their go directives lowered to 1.20, wired via replace. Verified it builds on both a real Go 1.20.14 toolchain and 1.24, so the desktop build path is unchanged and no Web-specific Go pin is needed. (If you'd prefer, the alternative is asking mewkiz to tag the js fix under go 1.20, which would drop third_party/ entirely, happy either way.)

-Runtime under build/wasm/, generated output under bin/Ikemen_GO-Web/ : done, exactly that layout.

-androidInit → platformInit / platformInitSubSystems: done, as its own commit; the Android init plus a default no-op counterpart now sit behind the generic seam.

Regarding release / incorporating it - happy with whatever you suggest. If people want to play with it for a while and see if anything breaks first then thats fine. Happy to jump on bugs that come up.

The full branch is here to review against develop:
develop...mathmati:upstream-wasm-port

[K4thos]

Thanks. There were no objections to upstreaming the Web port in the Discord discussion. Review and merging may take some time since we are currently preparing the 1.0 release. This will probably end up in a release after 1.0, but there is no need to wait before opening the PR.

The main issue I noticed after a quick look through the diff is the workaround under third_party/. We should not commit modified copies of dependencies directly into the repository. Ideally, the fix should be released upstream. If that is not possible, a small dedicated fork pinned in go.mod would be much cleaner (we could host it under the ikemen-engine organization). Another option might be a separate go.mod for the Web build if maintaining forks is too much hassle, though I am not sure whether that would be the best approach here.

I'm also not sure we need the smoke tests in their current form since that's something extra to maintain. Once this is upstreamed, we plan to have a working showcase built from develop and deployed to ikemen-engine.github.io/play/, which should already provide a practical end-to-end test of the Web build.

[mathmati]

Thanks, on these:

• third_party/ could be removed, it only exists because of a dependency (mewkiz/flac, via beep/v2/flac) in sound.go for FLAC decoding. I can build-tag FLAC out of the Web build, same approach the port uses to for module music currently, so the js build never pulls that dependency. go.mod then goes back to what's on develop. It means no FLAC background music in the browser version but thinks thats rare anyway & mp3 etc will all still work fine.

• smoke tests yes agree, I can take them out.

Checking these and seem ok so I'll push them to the branch.

No issue on timing - I'll get the PR up & you can decide when to do it, I'm happy to have it working and maybe I'll find a few other improvements before it gets incorporated.

[K4thos]

we're currently discussing dropping Windows 7 support and moving to Go 1.23. More and more of our dependencies are dropping support for older Go versions (for example beep author made us a favor to maintain 1.20 branch just for us), so we'd have to make this move sooner or later anyway.

We'll test whether the build works on Windows 7 with VxKex, and if it does, we’ll most likely bump the Go version.

So no need to worry about those dependencies for now - feel free to prepare the PR using Go 1.23.

[mathmati]

Thanks, good to know. The browser version should still work for Windows 7 users - looking the last supported browser was Chrome 109 & it seems to support WASM etc. Would need a test run but would hopefully mean they can still play in-browser with no install.

I think the only thing we'd gain with 1.23 is being able to add FLAC back to the browser build and as it stands it should fail gracefully (i.e. just be silent) so maybe I just leave it for now unless FLAC is more common than it seems to be.

[ValorZard]

@mathmati @K4thos hey guys!
I happen to work on the Pion project as well as being super into fighting games.
if you need any help with the WebRTC stuff just let me know.

I have a sample project you can take a look at if you need help setting up the netcode for it:
https://github.com/pion/example-webrtc-applications/tree/main/ebiten-game
it should work on both native and WASM if you need to port GGPO-go to it

[ValorZard]

Making a port of ikemen to WebAssembly/using WebRTC datachannels has actually been a big priority of mine, I’ve just never found the time.

[ValorZard]

I made an RFC on the ggpo repository page if you wanna talk more about this: ikemen-engine/ggpo#1

[mathmati]

Hi ValorZard, I have had a look through and think it could work really well. Happy to coordinate on this once the browser port is live, it would be great to have working and looks like it would slot in neatly.