Confirmed via Gitea's own documentation (about.gitea.com's actions-cache
tutorial): Gitea Actions doesn't support the built-in hashFiles()
expression function GitHub Actions provides - it silently evaluates to
an empty string rather than erroring, so all three cache keys
(emsdk-${{hashFiles(...)}}, etc.) were actually just the constant
strings "emsdk-", "deps-wasm32-", "libwinevbs-wasm32-" on every run,
regardless of whether scripts/versions.sh or patches/ actually changed -
this is why caching "didn't work properly": correctness-wise it's worse
than no caching, since a stale cache from before a version/patch bump
would keep being reused indefinitely instead of invalidating.
Replaced with a plain sha256sum-based step that hashes the same inputs
by hand and exposes them via GITHUB_OUTPUT - no dependency on Gitea
gaining hashFiles() support, and verified locally to produce distinct,
non-empty hashes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The CI runner's base image doesn't ship cmake (build failed with
"cmake executable not found on PATH" during emcmake), and only bison
was ever explicitly installed - curl and python3 happened to work by
luck of the current runner image, not because the workflow guarantees
them. Install the full README-documented toolchain explicitly in both
the build and publish jobs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Build scripts, CMake/source patches, npm packaging, and a Gitea CI
workflow to compile the real Visual Pinball engine (SDL3 + WebGL2 +
libwinevbs for real VBScript) to WebAssembly.
The patches are validated end-to-end: the patched engine boots in a
real browser, loads a real .vpx table, compiles its real GLSL shaders,
computes environment map radiance, initializes physics, and starts the
VBScript engine, before hanging on the one deliberately-deferred piece
of work (game loop rewrite around emscripten_set_main_loop), documented
in the README's roadmap.