HTML5/web export

[nii236]

I’ve been avoiding using this library as I wait for HTML5 export support.

The readme states there there are “ideas” on how to achieve this but I can not find what these ideas are, how feasible it is, when these ideas can be tested, where they’re being discussed etc.

For now I’ve gone ahead with implementing game state in Go and will push it through to vanilla Godot via websockets, but would be keen to get an idea on the above.

[Splizard]

The idea is use a wasm build and bridge to Godot via some sort of Javascript layer. Unfortunately there aren't any official Javascript interfaces for GDextension, so this would need to be be developed.

I've been looking at https://github.com/godotjs/Javascript, which could be a path towards this, however it's not based on GDextension, so this doesn't look to be very straightforward.

The last time I investigated this, Emscripten had some limitations that meant it wasn't possible to access Javascript from a side module. Which I initially hoped could be a good was to expose the GDExtension API to the browser. Well I've just checked and it doesn't look like the issue has had any movement emscripten-core/emscripten#21491

The other option would be to try to develop the Javascript interface into Godot itself. If I had something to start from, I could probably chip away at it but I'm not familiar enough with Emscripten with C++ to set this up properly. Hence getting something merged into Godot would probably take some time.

[Splizard]

I've had another investigation on this, I've got an initial bootstrap of the GDExtension API in Javascript, I will continue on this path and see if I can make some progress here, I'm not confident that this would get merged by Godot so we will probably maintain our own web export template for graphics.gd.

[nii236]

Woah, appreciate you getting back to me on it. Keen to read more as you progress.

Anything I can do to help? I'm primarily a Go developer only.

[Splizard]

Notes

I've forked Godot with the changes needed to start exposing GDExtension via Javascript.
https://github.com/grow-graphics/godot

The web export template can be built with scons platform=web target=template_debug

When this is all ready and working, this export template will need to be hosted somewhere and periodically rebuilt so the gd command can download it as needed. In the meantime, it has to be configured in the editor export settings.

I've also pushed the graphics.gd changes in 998e42d, if you GOOS=js GOACH=wasm gd run a project, the gd command will build the export project, place it inside of graphics/.godot/public and serve it on port 8080.

The Go wasm will load before Godot and register an initialization function at window.GDExtension["res://library.gdextension"], the Godot fork will load everything under window.GDExtension when it starts up. After this point, it is much like the C version of gdextension except we call into javascript functions defined in the patched version of Godot. They are quite low level and designed to expose the low level wasm memory directly without allocations.

https://github.com/grow-graphics/godot/blob/master/platform/web/gdextension_web.cpp

This file is incomplete, the GDExtension API is so large, so it's rather grueling to go through and wrap each function, I will need to come back to this. Then there is the same thing in reverse on the graphics.gd side, I've only added a single function for now.

https://github.com/grow-graphics/gd/blob/master/startup/startup_js.go

There are some changes required to make sure graphics.gd is 32bit compatible, as the project currently relies on the internal 64bit memory representation for Godot variants. Some of the pointer types will also need to be adjusted for 32bit.

Anyhow the good news is at least there is a bit of a bootstrap here that can be iterated upon. Much of the annoying setup to get things connected and starting up together is at least in place.

[Splizard]

Might be worth trying some code gen here.

[Splizard]

ok @nii236, good news! There is some preliminary web support, you can update gd and run GOOS=js GOARCH=wasm gd run which will download the latest available export template and serve the project on http://localhost:8080. Only the debug target is supported and things are not fully functional but the Go extension will be loaded and successfully link with Godot. All the internal tests are passing.

in saying that, expect things to be broken, many of the examples do not work yet

I'm at a bit of a loss on how to debug things in the browser, for native builds, I have successfully used gdb to effectively track down issues, I'm not particularly familiar with the process for wasm. Would appreciate help with this if anybody comes across this and is more familiar with this sort of thing.

[Splizard]

@nii236 some of the examples are beginning to work, can confirm pong, dodge the creeps and the ui examples are beginning to work now. There is an issue with keyboard input not being recognized but everything renders and runs.

[timklge]

Very cool stuff! I tried to start the example from the README, but couldn't get it to run yet:

I have installed go-1.23 via package manager on my system. On startup, /usr/lib/go-1.23/lib/wasm/wasm_exec.js is not found. It appears to live in /usr/share/go-1.23/misc/wasm/wasm_exec.js, and I manually copied it to graphics/.godot/public/wasm_exec.js to proceed.

In firefox, the app shows an index out of bounds error when accessing http://localhost:8080 (according to the network log, library.wasm is there and loaded):

RuntimeError: index out of bounds
    _main http://localhost:8080/index.js:9
    callMain http://localhost:8080/index.js:9
    Engine http://localhost:8080/index.js:832
    Engine http://localhost:8080/index.js:827
    promise callback*start http://localhost:8080/index.js:795
    Engine http://localhost:8080/index.js:863
    promise callback*startGame http://localhost:8080/index.js:861
    <anonymous> http://localhost:8080/:208
    <anonymous> http://localhost:8080/:222

On chromium, it prints multiple times:

index.js:9 Uncaught TypeError: __emscripten_thread_crashed is not a function
    at __emscripten_thread_crashed (index.js:9:1017178)
    at handleMessage (index.js:9:4800)

[Splizard]

@timklge thanks for reporting your issue, I have been using Go 1.24 recently as 1.23 had some pretty serious c-shared performance regressions. It looks like there are upcoming wasm changes in this release too. Have you updated the gd command so that it ensures you using the latest web export template?

I have run into the index out of bounds issue on Firefox (which I normally use on my machine) but Google Chrome specifically seems to be working on my end.

Still having trouble with debugging emscripten though, compiling godot without optimisations + debug symbols balloons in size to like 500MB and refuses to startup in the browser entirely.

[timklge]

Thanks for the super-quick reply! I'm sorry, I did the usual error of not clearing my browser cache after updating. It now shows the "Hello world" in chromium 👍 Amazing work! I'll start tinkering with porting parts of my current desktop gdscript project over to Go using this library and hope to also target web at some point.

[nii236]

Amazing updates @Splizard! I'll give it a go

[nii236]

@Splizard is the experimental WASM export only for non macs?

➜  nxr-gd GOOS=js GOARCH=wasm gd run
go: unsupported GOOS/GOARCH pair darwin/wasm

[Splizard]

@nii236 have you also run go get graphics.gd@main ? The error you are getting indicates that the cgo package is being imported somewhere but this is not supported on wasm. gd doesn't use the cgo package when compiling to the wasm target. I can confirm that GOOS=js GOARCH=wasm gd run is working on mac for the examples repo.

[Splizard]

@jugglingjsons unfortunately there is a bit of a roadblock, whilst implementing a mainloop sort of works now, there is an issue with calling any Godot C++ virtual functions. Any time you call them, it results in table index out of bounds. A lot of server functions (RenderingServer, DisplayServer) are virtual and I'm not entirely sure yet whether this is an emscripten bug or if there are any work-arounds.

[Splizard]

Also make sure to either remove your project.godot so that gd can re-create it, or to add run/main_loop_type="GoMainLoop" to it so thatgd can control ahead of time whether the main loop is a scene tree, or implemented in Go.

[nii236]

@nii236 have you also run go get graphics.gd@main ? The error you are getting indicates that the cgo package is being imported somewhere but this is not supported on wasm. gd doesn't use the cgo package when compiling to the wasm target. I can confirm that GOOS=js GOARCH=wasm gd run is working on mac for the examples repo.

Thanks @Splizard

Indeed, the issue was me. CGO_ENABLED was enabled by default in my go environment. The following works now.

➜  pong git:(master) ✗ go env CGO_ENABLED            

1
➜  pong git:(master) ✗ CGO_ENABLED=0 GOOS=js GOARCH=wasm gd run

[Splizard]

@jugglingjsons some fixes have been made for web support, hello triangle works now, pong and dodge the creeps are both working now.