ml
1be0bebda2
build / build (push) Successful in 1m43s
Replaces the single shared, side-by-side swapchain (game + menu content packed into one image, needing viewport/scissor juggling to keep the menu's own glClear from bleeding into the game's region) with two fully independent XrSwapchainState instances, each sized to exactly its own content and acquired/released on its own within the same xrBeginFrame/xrEndFrame pair - an ordinary multi-layer OpenXR setup. The shared-swapchain design was originally adopted to work around what looked like a Horizon OS compositor limitation with independent swapchains, but that was diagnosed before the real root cause of the "menu shows the game's content" bug was found (gl4es's fpe.c unconditionally substituting its own shader onto the menu's draw call - see README's Debugging notes). Since the actual fix routes the menu's blit through a real, non-gl4es glBlitFramebuffer() call - orthogonal to how many swapchains exist - splitting back onto two swapchains works fine and removes the GL_SCISSOR_TEST workaround and sub-rectangle offset math entirely. Confirmed on-device: both quads render correctly, hit-testing and 90 FPS unaffected. Also adds a visible cursor to the menu quad itself: xr_input.c now tracks whichever hand's aim ray hits the menu each frame and forwards it to a new MenuOverlay.nativeUpdateCursor(), which draws a small dot at that position (composited through the same Bitmap the menu's own content already goes through) - previously there was no visual feedback at all showing where you were pointing before pulling the trigger.