Phase A (the hard blocker): the engine now plays a real table live in
the browser via a real per-frame game loop, not just a static render.
Two real, previously-unknown upstream bugs found and fixed along the way:
- RenderDevice::WaitForVSync() unconditionally spawned a real std::thread
every frame, even on __STANDALONE__ builds - a hard crash under
Emscripten's single-threaded runtime (0003).
- The desktop game loop is a blocking native while loop with manual
uSleep throttling, incompatible with a single-threaded WASM main
thread. Adds Player::EmscriptenStepFrame() (one frame, no internal
loop) driven by emscripten_set_main_loop, plus new JS-callable
lifecycle entry points (vpinball_wasm_start/stop/dispose in the new
src/core/EmscriptenBridge.cpp) that bypass the desktop main()/WinMain()
chain entirely, since that chain assumes the process runs exactly one
table to completion then exits (0004).
Verified end-to-end in Chrome: real .vpx load, real shader compilation,
real physics/script engine init, a real running frame loop (observed
advancing), and a clean stop() -> ~Player() teardown mid-session with
no crash or hang.
Phase B: trims the preloaded asset payload from ~51MB to ~11MB by
excluding editor-only bundled example tables and a Monaco code editor
never used by the player runtime, and adds real link-time optimization
(-O2 --closure 1) and --use-preload-cache for repeat visits.
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.
valknar