← Dev Log
BallOrcs2 min read

The crash that wasn't ours, and the window that stayed black

Three nasty bugs in one day, all invisible on our Linux test rig. On Windows the game crashed instantly at launch. Fixed that — and got a window that stayed pure black.

In plain words

Three nasty bugs in one day, all invisible on our Linux test rig. On Windows the game crashed instantly at launch. Fixed that — and got a window that stayed pure black. Fixed that — and the browser version still froze at the loading screen. The culprits: our crash-reporting helper crashing (the irony is noted), the engine asking the graphics card in a language our build couldn't translate, and the web version being built with a feature the browser loader didn't expect. All three fixes are in, verified with screenshots of the game actually running.

Under the hood

Ordered by discovery, since Linux headless hid all three:

  1. Startup access violation (Windows): isolated by building with the DSN removed — clean exit 0, so the only delta was Sentry auto-init firing crashpad. Shipped Sentry present-but-inert via sentry/options/auto_init=false; the DSN still gets injected at export, so re-enabling is a one-flag flip once the native crashpad init is fixed (tracked in the backlog). The web build has a separate hang in Sentry's module load that auto_init=false doesn't cover — same issue tracks it.
  2. Black window (Windows): Forward+ (Vulkan) failed every shader with "Shader language is not supported" — our from-source MinGW engine lacks the runtime GLSL→SPIR-V compiler. Diagnosed from the real godot.log on the target machine. Switched rendering_method to gl_compatibility: no SPIR-V needed, it's the only web renderer anyway, and it's the right base for a flat-shaded platformer on integrated/mobile GPUs. Verified on Intel Iris Xe.
  3. Web stuck at boot splash: browser console showed LinkError: mismatch in shared state of memory, declared=1, imported=0 — the GDExtension was built threaded (shared wasm memory) while the web engine template is nothreads. The build now passes threads=no for web and the manifest points at the …wasm32.nothreads.wasm binary, matching the Sentry addon's naming convention. Verified in Chrome (WebGL2 Compatibility).

Moral: "boots headless on the build machine" and "renders pixels on a player's machine" are different claims, and only one of them is marketing.

#war-story#debugging#rendering