Add a player_controls config group that maps game actions to controller
inputs, and a Controller Options menu tab to rebind them in-headset.
- 45 actions: movement, click/double-click, jump, fire, and the engine's own
keyboard hotkeys (posture, save/load, weapon/MFD select, etc.), sent to the
engine as synthetic key events. Cheat and dead hotkeys are not exposed.
- Press-to-capture rebinding with per-input exclusivity, Reset to Defaults
(built-in defaults, then questshock.config.default.json), and new defaults:
left stick moves/strafes, right stick turns.
- Controller profiles for Touch, Vive and generic OpenXR
(res/controller_profiles/), matched to the active interaction profile at
runtime, with a fatal dialog if a profile's bindings are rejected at
startup.
- The menu's thumbstick locomotion is disabled while the Controller Options
tab is open or a capture is active. A scrollable list with a tap-to-jump
scroll bar handles the long action list.
- Opening the menu pauses a running game and resumes it on close.
- Reset Position now keeps the player's facing instead of turning the screen
to the current gaze.
- Play the intro video in the game's language (engine patch 23), falling back
to English.
- Watchdog and shared-key handling for stuck movement keys, plus key-edge
logging.
- Left thumbstick snap-turns, right thumbstick smooth-moves, letting the
player line themselves up with the fixed game quad ("virtual screen")
without needing physical room-scale space to do it in. Implemented via
a second OpenXR reference space (a "play space") derived from the real
LOCAL space by the inverse of the player's transform, so every existing
quad/hit-testing/rendering call site just needed g_local_space swapped
for it - no manual coordinate-transform math required elsewhere
- Generalized the ray/quad hit-testing in xr_input.c to a proper
oriented-plane intersection (needed once quads can rotate); verified it
degenerates to the old axis-aligned formula when unrotated, so the
keyboard and non-recentered menu are unaffected
- The menu launcher now re-centers in front of the player, correctly
oriented to face them, each time it's freshly reopened
- "Reset Position" (Main Menu tab) recenters using the player's current
real head pose - not a plain reset-to-origin, which only undid
thumbstick movement and ignored physical drift since the session
started. The same recenter runs once automatically at startup too, as a
fallback for when there's no complete saved position to use instead
- Position/orientation persists in questshock.config.json's new
player_position group (independent of savegames), including new
numeric-value support in the config file's hand-rolled JSON parser
(previously string-enums only)
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.
Aiming looked and behaved differently depending on whether the
keyboard/menu was open: xr_input_try_overlay() claimed a hand's ray for
its overlay whenever the overlay was merely visible, regardless of
whether the ray was actually pointed at it - so with the keyboard open,
aiming at the main game screen still showed a beam terminating at the
keyboard's fixed depth, while closing the keyboard swapped in the old
flat cross-shaped reticle at whatever the ray was really pointing at.
Only claim an overlay when the ray is actually relevant this frame - a
real hit, or a touch/drag begun on a previous frame still pending
release - so a visible-but-unaimed-at overlay now falls through to the
next-priority target. Give the game quad its own hit-test
(xr_input_try_game_quad()) and the same billboarded laser-beam
treatment as the overlays instead of the old flat reticle, so aiming
looks and behaves identically everywhere - overlay open or not. The
old reticle GL program/shaders are now fully dead and removed. No
click/touch dispatch is added to the game quad itself; that's future
work.
The flat cross-shaped reticle used while aiming at the game quad is
drawn directly into the game quad's own texture, so it only ever made
sense there - while the menu launcher or keyboard was open, there was
no visual feedback at all until the ray was precisely on target,
making both panels hard to aim at.
Add a second, thin XrCompositionLayerQuad per hand: a billboarded
"laser beam" ribbon from the controller to wherever that hand's ray
currently crosses the plane of whichever overlay (keyboard, then menu)
claims it that frame, oriented via a view-space head pose so it reads
as a line from the viewer's eye regardless of angle, colored per hand
(cyan left, amber right) and clamped to 2m so grazing angles don't
produce an absurdly long beam. Built from data xr_input.c's existing
per-hand hit-testing already computes; the game-quad reticle itself is
untouched.
Expand the on-screen keyboard to a full US layout (letters, digits,
punctuation, Shift layer, Tab, arrows, F1-F12, one-shot Ctrl/Alt
modifiers), make it a persistent, movable, closeable panel via a
title-bar drag handle, and lower its opacity.
Previously the keyboard was just a second panel swapped into the same
quad as the menu launcher, which made the launcher translucent too and
made the keyboard and menu mutually exclusive. Extract the shared
swapchain/JNI/touch-dispatch plumbing into two generic, reusable
modules - xr_swapchain.c (swapchain + per-image FBO setup) and
xr_overlay.c (an off-screen Android View rendered into its own OpenXR
quad, hit-tested via a laser pointer) - and make the menu launcher and
keyboard two independent XrOverlay instances instead of one. The
controller's menu button now only opens/closes the launcher; the
launcher's "Keyboard" button only opens the keyboard - so the keyboard
can stay up while picking something from the menu, and only the
keyboard's own Close button hides it.
xr_menu.c/.h are gone, fully absorbed into xr_overlay.c. On the Java
side, OverlayPanel.java carries the shared off-screen-render/touch/
cursor plumbing that MenuOverlay and the new KeyboardOverlay both
subclass.
- xr_input.c/h: an OpenXR action set (aim pose, trigger/select click, a
menu-toggle button) plus ray/quad hit-testing, and a visible
laser-pointer line drawn from the controller toward the hit point.
- xr_menu.c/h + MenuOverlay.java: a second composition-layer quad,
toggled by a controller button, showing an off-screen, never-attached
Android View tree (one "Keyboard" button so far) driven by synthetic
touch events computed from the laser ray's hit UV.
- Migrate gl4es from a prebuilt binary baked into the Docker build-image
to a vendored source snapshot (android/gl4es-src/) compiled from
source at APK build time via CMake add_subdirectory(), patched through
a new android/gl4es-patches/ (mirrors the existing engine-patches/
pattern). This was needed to track down and fix a bug hit while
building the menu: gl4es's fixed-pipeline emulation (fpe.c) was
unconditionally substituting its own shader onto the menu's draw call
(fpe_ReleventState() always sets alphafunc to a nonzero sentinel, so
its fpe_IsEmpty() check could never see the state as empty), making
the menu quad show the game's own rendering instead of its own
content. Fixed by routing the menu's blit through a real
glBlitFramebuffer() call instead of a shader-based draw, which gl4es's
fpe.c has nothing to intercept - documented in README.md's new
"Debugging notes" section.
- Renumber android/engine-patches/ to close the gap left by removing an
unrelated diagnostic-only patch, and strip investigation-journal
comments and dead diagnostic code (temporary tracing, env-var probes)
left over from finding the bug above.
- Restructure README.md into numbered sections, document every
engine/gl4es patch, add Android Studio dev/testing-cycle instructions,
and generalize Quest-specific wording to any OpenXR headset. Update
NOTICE.txt to match (gl4es is now vendored/patched source, not a
prebuilt binary; add the OpenXR-SDK loader).
ml