4 Commits

Include renames

Author	SHA1	Message	Date
valknarandClaude Sonnet 5	b8bf9f1510	Fix back buffer not resizing on fullscreen toggle ... Window::OnResized() (called for every SDL window-resize event, including entering/leaving browser fullscreen) updated the window's own tracked pixel size but never propagated it to the window's back buffer render target, whose stale size kept driving glViewport() - so toggling fullscreen resized the canvas but rendering stayed pinned to the old, smaller viewport. Mirrors the resize handling the BGFX backend already does explicitly elsewhere in RenderDevice.cpp. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 18:03:08 +02:00
valknarandClaude Sonnet 5	7c63f01527	Fix GL viewport sizing and ship a real playable default table ... The OpenGL back-buffer render target was created with the window's logical/CSS size instead of its device-pixel size, so on any browser tab with devicePixelRatio != 1 the GL viewport only covered a fraction of the canvas's actual backing buffer (rendering anchored bottom-left, matching GL's viewport origin) - confirmed against a live repro and fixed to match the convention already used by the BGFX backend elsewhere in the same file. Also swap the bundled default table from test000-default-table.vpx (upstream's rendering/component regression-test fixture, which has no gameplay script) to exampleTable.vpx - a genuine playable demo table with working flippers, slingshots, bumpers, targets and a plunger - confirmed keyboard input and audio now work end-to-end through it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-22 17:56:51 +02:00
valknar	a5e5b6f34a	Phase A/B: fix the game loop and trim the asset payload ... 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.	2026-08-22 16:06:17 +02:00
valknar	0a63835689	Scaffold vpinball-wasm: Emscripten port of Visual Pinball ... 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.	2026-08-22 14:30:14 +02:00