Drive the engine's mouse cursor from the VR aim ray on the game quad

The game quad's laser beam was purely visual - aiming at the game's own UI (inventory, menus, dialogs) had no way to interact with it. Add a real mouse pointer: absolute cursor position plus a single left click, mirroring a plain point-and-click mouse (no mouselook, no right-click, no drag). New xr_mouse.c/h bridges the aim-ray hit-test to the vendored engine's own public mouse API - mouse_put_xy() for position, a synthetic SDL_MOUSEBUTTONDOWN/UP (SDL_BUTTON_LEFT) via SDL_PushEvent for clicks, the same technique nativeSendPrintableChar() already uses for synthetic keyboard input. No engine patch needed. Deliberately bypasses SDLActivity.onNativeMouse()/SDL_MOUSEMOTION/SetMouseXY(), whose physical-window-size scaling is unreliable in this headless immersive build. xr_input_try_game_quad() now reports the hit u,v; a new g_game_touch_active[] tracks a held click on the game quad so it survives the ray straying onto the keyboard/menu before release, gating those overlays' claims the same way pending overlay touches already do.
2026-08-14 08:36:09 +02:00
parent 824b4a2506
commit 581af95e7b
7 changed files with 136 additions and 22 deletions
@@ -6,13 +6,18 @@
 // this frame (landing on it now, or continuing a touch/drag begun on a
 // previous frame - not merely because that overlay happens to be visible)
 // - the game quad xr_session.c submits, forwarding trigger edges to
-// whichever overlay claims the ray as synthetic touches. Since none of
-// the three targets' own feedback (the overlays' on-quad cursor, drawn by
-// their Java views; nothing at all for the game quad, which has no
-// click/touch dispatch here yet) gives any indication while the ray is
-// short of actually landing on something, every claimed target also
-// builds a thin, billboarded laser-beam quad per hand from the controller
-// to wherever the ray currently crosses that target's plane (see
+// whichever overlay claims the ray as synthetic touches. The game quad
+// itself acts as a plain desktop-style mouse pointer into the engine's
+// own UI (see xr_mouse.h) - absolute cursor position while the ray hits
+// it, plus a left click on the trigger edge; a pending click there
+// likewise keeps claiming the ray ahead of the keyboard/menu until
+// released, so the eventual mouse-up isn't lost if the ray strays. Since
+// none of the three targets' own feedback (the overlays' on-quad cursor,
+// drawn by their Java views; the engine's own mouse cursor sprite for the
+// game quad) gives any indication while the ray is short of actually
+// landing on something, every claimed target also builds a thin,
+// billboarded laser-beam quad per hand from the controller to wherever
+// the ray currently crosses that target's plane (see
 // xr_input_get_beam_layer()) - so aiming looks and behaves the same
 // whether the target is an overlay or the game quad itself.
 #ifndef QUESTSHOCK_XR_INPUT_H