Native Multiplatforming - Android + Web

[Splizard]

I've been busy over the last few weeks rearchitecting the internals of graphics.gd (Go + Godot), with the goal of bringing web support up to scratch, as well as making it easier to develop projects for Android. I'm pleased to report that this is looking to be a success!

Web

Here's the command that will launch the current graphics.gd project in your web browser:

$ GOOS=web gd run

Once the build is complete, you can then open the localhost URL printed to the console to visit the exported page.

Here's the shader sample running in the browser, showcasing simple shaders written in Go, these are compiled to WASM, which generates a .gdshader at runtime which is translated by Godot to WebGL GLSL 🤯

Click the image to see it running in your browser!

Behind the Scenes

Supporting web has actually been quite the challenge! One might think that since both Godot and GDExtension already support web exports, it would be as easy as compiling Go to WASM and calling it day. It's not that simple! GDExtension has only been designed with Emscripten's non-standard dynamic-linking in mind (Emscripten is a C/C++ to WASM compiler). This works for C++ and Rust which both support Emscripten but not for Go which has it's own builtin compiler for WASM with entirely different calling convention and Javascript runtime.

What this means in practice, is that I've had to develop an entirely new way to interface with the GDExtension API on web through Javascript. Initially as a proof-of-concept, I modified the Godot engine to export all the gdextension functions using Emscripten's binding mechanism, then partially linking to this with an entirely separate backend forgraphics.gd. The GDExtension interface is actually quite big and there was a lot of hand-crafted code here. This meant that projects often didn't work at all and would run into difficult-to-debug crashes as I had to maintain two largely separate GDExtension backends. My recent work has been to consolidate both native and web backends into a single .c file that is shared between both native builds and web builds.

This is fantastic, as now both targets are running mostly equivalent code paths, any fixes for one target, should benefit both! This also opens the door to Hot Reloading support and eventually (and easily) calling directly from Go WASM to Godot WASM without a Javascript bridge. All the samples are now running on web, including the partially completed Go port of GDQuest's third-person-controller example. Woohoo! 🎉

Android

Here's the thing, I've always had a rough time developing anything for Android, it's always a complete mess of agreeing to terms of service, downloading random SDKs, configuring everything to work... and don't get me started on Android Studio!

Probably the best experience I had was at my first Godot game jam, after I managed to install the SDK, I could just deploy any GDScript-based projects and run them on my device connected by USB, brilliant!

I wanted to capture this very experience when writing native applications for android with graphics.gd, so I am very excited to share the official process for developing an Android app with graphics.gd (Go + Godot) and Godot export templates installed:

1. Plug in your Android device via a USB cable (with developer mode on).
2. Run GOOS=android gd run.
3. The app launches on your device.

That's it... That's the entire process!

You don't have to agree to anything, you don't need Java (at all), nor do you need to hunt down the Android SDK/NDK. You'll have an entirely native Android app running on your device. 🎉

After following these steps, here's the Go shader sample running natively on my phone:

Behind the Scenes

Go already supports GOOS=android but cross-compiling with cgo can be a challenge.. Fortunately graphics.gd bundles the minimum set of headers necessary to compile for Android and uses zig to build the native library. This works on any host machine! Godot then fills in the template .apk with the Go shared library and the gd command downloads standalone Open Source builds of apksigner and adb to sign the resulting .apk and launch it on the device.

Windows/MacOS/Linux

Don't forget, just like Godot, graphics.gd already supports natively exporting to Windows/MacOS/Linux on any machine:

GOOS=macos gd build
GOOS=windows gd build
GOOS=linux gd build

This wouldn't be possible without all the amazing work by the Zig Foundation, so do go and support them!

Disclaimer

There's a lot of different system configurations out there (I only have limited access to each platform), if you don't have the same plug and play experience, please open an issue, the goal here is to build native graphical applications for any major platform on any machine at any time - with a single command!

Thanks!

I want to thank all of the users who've had the patience and care to report the issues they've encountered with graphics.gd, I know it's been a bit of a bumpy road working through this latest internal rearchitecture, special thanks to everyone who has contributed funding to the project, which now sits at a total of $284.69NZD! The website and documentation pages are now being speedily hosted on a CDN and if you haven't had a chance to check them out yet, they have been substantially improved to provide a better introductory experience to the project.

I hope the project continues to meet your needs!

@ring-c @nii236 @mdevnull @sanikoyes @skilletfun @McMelonTV @mikolbeckwith @jonatandorozco

[nii236]

Thanks for your incredible work @Splizard, and giving us gophers a fighting chance in the world of game development!

[drpnsystems]

Thanks for putting this out there it really feels like you’ve given developers everywhere a shot at keeping up in a world that moves insanely fast. Makes the community stronger and the journey a lot less frustrating.

[jugglingjsons]

Hey, quick question.
Should this still work as of today ?

I have tried examples from samples and samples-web branch but they fail for me.

go version go1.25.3 darwin/arm64

terminal from the run command:

WARNING: Project export for preset "Web" completed with warnings.
     at: _fs_changed (editor/editor_node.cpp:1280)
gd: serving wasm/js on http://localhost:8080

errors I see in web console

Godot Engine v4.6.dev.custom_build.6845cbd9c (2025-09-16 08:55:51 UTC) - https://godotengine.org index.js:452:16
OpenGL API OpenGL ES 3.0 (WebGL 2.0) - Compatibility - Using Device: Mozilla - Apple M1, or similar index.js:452:16
An AudioContext was prevented from starting automatically. It must be created or resumed after a user gesture on the page. index.js:1:204514
Build configuration: Emscripten 4.0.12, multi-threaded, no GDExtension support. index.js:452:16
panic: runtime error: invalid memory address or nil pointer dereference wasm_exec.js:22:14
[signal 0xb code=0x0 addr=0x0 pc=0x0] wasm_exec.js:22:14
<empty string> wasm_exec.js:22:14
goroutine 8 [running]: wasm_exec.js:22:14
graphics.gd/startup.init.3.func42({{}, 0x7ff800010000000e, 0x19fb5f0}, {0x1544a40, 0x0, 0x0}) wasm_exec.js:22:14
	/Users/username/go/pkg/mod/graphics.gd@v0.0.0-20250923075705-9b8b2467f208/startup/startup_js_v2.go:510 +0x1 wasm_exec.js:22:14
syscall/js.handleEvent() wasm_exec.js:22:14
	/usr/local/go/src/syscall/js/func.go:117 +0x28 wasm_exec.js:22:14
exit code: 2 wasm_exec.js:109:14

[Splizard]

It's definitely working on the latest release.

Could you update to the latest version of both graphics.gd as well as the gd command?

go install graphics.gd/cmd@release

go get graphics.gd@release

[timklge]

I recently tried to run my project and one of the graphics.gd example projects on Android, but ran into some issues.

• I already had an android SDK on my linux x64 machine; but when gd called the apksigner of that, it enters an infinite loop, allocating memory until running OOM. My SDK installation works fine with android studio.
• When I deleted my sdk in ~/Android/, gd downloaded apksigner, but not adb and the java stub file for some reason. After I downloaded adb from the url in the source code, the build ran through.
• Apparently, the adb install call expects the executable to have the same name as the containing folder, which it does not have in my case, so the install step failed. After calling adb install on the built debug apk myself, the app runs fine on my phone. Great job 👍

Maybe the CI could run an android build of one of the samples in the future so that one can be certain that issues like these are related to the local system setup?

[Splizard]

What platform are you on?

[timklge]

Linux amd64, Ubuntu 25.10

[Splizard]

Thanks for reporting your experience!

I'm not sure why it's not working with the proprietary SDK, the tooling is meant to fallback to anything that's already in your $PATH, I'm certainly open to patches to fix this but I don't plan to use the proprietary SDK.

Starting from a fairly empty Linux install, I did find a few issues, gd will now create the debug.keystore without java/keytool. I've also updated all the android tooling for linux/amd64, so that all of the tools are static musl binaries that should run on any distro. Everything appears to work, building a sample project after deleting ~/gd and ~/Android.

which it does not have in my case

Can you provide some details on how your project is structured?

[Splizard]

Both gd run and gd build should now work on Windows, Linux and Mac OS, if you don't already have Google's SDK.

[timklge]

Out of curiousity, I've implemented a super simple benchmark of 20000 godot sprites moving around on the screen; every sprite is a sprite2d node and updates its position in process. I guess this mostly just benchmarks the call overhead of the virtual methods.

out.mp4

I think the results are expected for this scenario and kind of good, as just repeatedly calling into the engine with cgo is kind of the worst case. The graphics gd web version appeared to run at 1 fps instead of the logged 10 fps - I guess godot caps the reported delta time between frames to about 0.1 seconds, so the benchmark implementation is wrong there.

Platform is amd64 linux on a Ryzen 5800X, Radeon 7900 GRE with compatibility renderer and default radeonsi driver. Browser is Firefox. C# is dotnet 10 JIT. Godot 4.5.1.

[Splizard]

Oh awesome, are you going to release a repo for this? Would be nice to include some of the other GDExtension targets too, C++, Rust, Swift, etc

[timklge]

I've pushed it to https://github.com/timklge/spritebench . For funsies, I also ran it with graphics.gd compiled with go1.26rc1, which mentions "30% reduced cgo overhead" in the release notes. It runs as fast as with go1.25 though; so I've probably made a mistake somewhere, or maybe cgo is not the bottleneck.

[Splizard]

Thanks, I'm keen to explore this, perhaps we can start a new discussion on this?

[timklge]

Sure, let's create a new thread for it. I had accidentally run the gdscript version with 10_000 sprites instead of 20_000, which flips the results between C# and gdscript. And caching the window size to avoid calling get_window().size per sprite per frame improved the graphicsgd performance to 50 % of that of gdscript, which is a great result I think.

I'll double check the implementations. But C# actually being the fastest also makes sense I think, as to my limited understanding, virtual method calling with pinvoke is very fast and no parameter marshalling is required here.

[mikolbeckwith]

Those are interesting results. It makes sense that C# is faster than gdscript but everything I've read said that gdscript engine calls were faster. Good job. I'm excited to try these tests out myself.

[timklge]

The workflow to build for web is very convenient thanks to the prebuilt export template that is automatically downloaded from your server by the gd tool, which is great. I was wondering if there is some documentation on how to build it from source?

[Splizard]

https://github.com/Splizard/godot
Then follow godot build instructions for web export templates.

[timklge]

Thanks!