OpenXR's grip +X is normal to the palm but points away from it on the left hand
and into it on the right, which is exactly what makes both grips carry the same
orientation when the hands hold a wheel symmetrically. The fingers therefore run
along -Y on both hands, and it is the geometry across the palm that mirrors.
Building the right hand's fingers on +Y instead left them pointing at the player
while the real hand faced forward.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The animated copy is registered for the vehicle's whole position array, and a
race frame has 228 primitives that bind it. Suppressing draw merging for all of
them turned the kart's display list back into hundreds of separate draw calls,
each recorded once and replayed in the mono pass and both eyes: on a Quest 3 the
app frame went from 15.7 ms to 21.7 ms with the GPU pinned at 97 %, which past
the 72 Hz deadline reads as 56 FPS against 42.
Merging is unsafe only between draws that resolved the array differently, since
the merged whole renders through the binding of the draw it folds into. So
resolve the replacement once per draw, before the merge test, and merge into a
draw that reached the same decision. Draws of an opponent sharing the asset
merge with each other again too, and with no set registered the test is exactly
what it was before the feature.
Measured at the same place on a Quest 3: 60 FPS against 42, the app frame back
to 13.9 ms, 564 draw calls a frame with 11808 primitives merged away.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Android frame-rate line already says where the wall clock went; what it
could not say is how many draw commands the recorded frame holds, which is what
the mono pass and both eye replays each pay for. An overlay that stops draws
merging shows up here long before it shows up as a frame rate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Quest offers XR_FB_hand_tracking_mesh without the app declaring hand
tracking, so a Quest 3 draws the runtime's own hand mesh rather than the
procedural gloves, and its fingers bent backwards on grip: the mesh's
joints point -Z towards the fingertip and +Y out of the back of the hand,
so flexion is negative about the joint's own X, on both hands. Fix and
test by the repository owner; OPENXR.md said the Quest always drew the
gloves, which was wrong.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
On a Quest 3 the gloves' fingers pointed up out of the fist and bent out
of the back of the hand as the grip closed: they were built along the
grip's -Z, which runs up the tube the curled fingers form towards the
thumb, and curled towards -Y, which is backwards on the right hand.
The fingers now run along Y, forwards out of the palm (+Y on the right
hand, -Y on the left, the frame being right-handed), and close towards
+X, the palm's outward normal, with the thumb on the -Z side of both
hands. A test pins the reach, the closing direction and that nothing
bends out of the back of the hand.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The panel was drawn into the eye images, so below a 1.00x OpenXR
resolution its 1440x1080 canvas was minified into a small eye region and
the text became hard to read. It is now submitted as a quad layer of its
own over the scene's projection or menu quad, which the compositor samples
directly at any render scale.
Each backend (D3D12, Windows Vulkan, Quest) makes the panel's swapchain
pair (plus two shared buffers on the Quest) the first time the panel
opens. While it is open, the frame hands Aurora one more stereo target
after the eyes, which the bridge fills with the panel texture or a
transparent image. The panel image follows the eyes' displayed/retained
pairing, so a cancelled frame never shows an unwritten panel. The quad
hangs where the pointer's hits are tested. Aurora leaves the panel out of
the eyes in layer mode, and a backend that cannot make the layer falls
back to drawing it into the eyes.
On the Quest, debug.wiicompiled.panel_layer 0 selects the old path at
run time. Measured there at a race start (render_scale 0.8), the layer
costs nothing while the panel is closed; while it is open, app GPU time is
10.5 ms against 9.7 ms drawn into the eyes, with unchanged frame rates.
The replay tests cover lazy creation, cancelled frames, closed and
unplaced panels, and render-first pacing on D3D12 and Windows Vulkan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found on a Quest 3 through Virtual Desktop (VirtualDesktopXR, Vulkan):
the race camera's view matched the scene camera exactly and the kart's
own wheel animated (228 draws a frame took the copy), but during the
race's opening pan no draw took it, the 30-frame fallback latched the VR
wheel for that vehicle, and it stayed until the scene changed.
The fallback now heals: copies keep being published, the VR wheel stands
in only while draws are not taking them, and the vehicle's own wheel
returns as soon as they are. Both switches are logged, a few per race.
With first_person_rotation "yaw_pitch" or "full" the wheel copy and the
hands' wheel geometry now ride in the view's own frame (the kart's
orientation around the seat) instead of the level seat, so the wheel no
longer tilts against the view on slopes.
Aurora logs, after about half a second, five seconds and a minute of
copies, how many draws bound a copied array (inside and outside its
window), how many matched, and the closest position matrix against the
expected one, so a mismatch says whether the array or the matrix differs.
first_person_seat = "cockpit" (the new default) places the head at the
driver's own eyes, measured once from the character's head bone while the
kart drives straight and undamaged, kept behind the steering wheel, at a
life-size scale (cockpit_units_per_meter, grown with the character's
height and the player's size). "yaw" takes the kart's driving direction
from a level seat frame that follows the simulation's position and
direction, so damage spins and tricks do not turn the seat.
first_person_seat = "custom" keeps the previous offset placement.
At the race draw boundary the vehicle's steering wheel disc (karts) or
handle part (bikes, re-seated level while the bike banks) is decoded from
its MDL0, turned on a copy, and posted to the GX thread for Aurora to
substitute into the player's own draws; the copies are dropped after the
frame's draws. The anchor carries the wheel or handlebar geometry in the
seated frame and the frame's exact scale, which reaches the policy and
aurora_set_stereo_scene_anchor_scaled. If no draw takes the copies for 30
frames the vehicle falls back to the VR wheel, and the log says so.
The wheel copy is matched against RaceCamera::GetViewMtx with no dolly
offset, since the scene camera is only set once the draws run; the log
reports its distance from the scene camera once a second.
Nothing turns the wheel yet: the angle comes from the XR side's driving
snapshot, which the next change publishes.
Guest offsets ported from heurazy's mario-kart-wii-VR-port, each
re-checked against the generated leaf getters and the decompilation.
A stereo packet can now carry an AuroraCockpit: tracked hands and, when the
vehicle's own wheel cannot be animated, a synthetic steering wheel or
handlebar, all in metres in the seated frame. Each eye draws it inside the
scene's pass just before the first virtual-screen draw, depth-tested with
the world's own depth mapping (captured from a full-view world draw), so
the kart and track occlude the hands and the 2D layer cannot hide them.
Hands use a runtime-provided hand mesh when one is supplied and a
procedural glove otherwise.
aurora_set_stereo_scene_anchor_scaled lets the sealed frame own its world
scale: each eye's head translation is rescaled from the packet's scale to
the frame's. A non-finite cockpit is dropped with one warning; the frame
still renders.
Ported from heurazy's mario-kart-wii-VR-port (GPL-3.0-or-later).
The VR first-person camera will animate the local vehicle's steering wheel
by handing Aurora a rotated copy of one of the vehicle's position arrays.
A draw picks up the copy only when it binds that exact array with the local
vehicle's position matrix (per-position ownership for indexed-matrix
draws), so opponents sharing the asset keep the original vertices. The copy
takes the same padded upload path as the original and never touches the
shared array cache.
Ported from heurazy's mario-kart-wii-VR-port (GPL-3.0-or-later).
- Introduced a new GX thread to handle the rendering pipeline, allowing the game thread to post commands without blocking.
- Added `gx_thread.h` and `gx_thread.cpp` to manage the command ring buffer and thread synchronization.
- Updated `vi.cpp` to utilize the GX thread for rendering tasks, improving frame pacing and responsiveness.
- Modified `main.cpp` to configure and start the GX thread, ensuring it integrates with the existing rendering workflow.
- Enhanced `openxr_integration.cpp` to register the GX thread with OpenXR for better performance in VR scenarios.
- Refactored `settings_overlay.cpp` to remove unnecessary waits for the frame worker, as the overlay now draws directly into the game thread's ImGui frame.
- Improved error handling and logging in the GX thread to capture exceptions during command execution.
- Created InstallReset.kt to handle the removal of game files, built games, and mod packs while preserving user data.
- Implemented unit tests for InstallReset to ensure correct functionality and file handling.
- Updated RetroRewindPackTest to include new test cases for update and deletion order.
- Enhanced Vulkan interop and OpenXR integration to support new thread scheduling hints for Android.
- Improved error handling and logging for GPU submission failures in Vulkan backend.
Brings in the keyboard/mouse rebinding overhaul (#162), the Kamek
skip-return hook fixes (#182, #218), the exit button and controller LED
fix (#221), the autohide-cursor and mute hotkey fix (#211), the Linux
--sysroot plumbing (#224) and the switch to the theofficialgman
dawn-build fork (#215).
Conflicts resolved to keep the VR integration intact:
- settings_overlay.cpp/.h: kept both new declarations. The controller
rebinding UI takes upstream's click-to-rebind widgets wholesale - our
only edit there was wrapping the combo width in Scaled(), and
upstream's bindingWidth is already font-relative, so the headset
panel still scales. Kept our DrawResolutionMenu() extraction (the VR
panel reuses it) while adopting upstream's DrawExitPrompt() and its
new DrawTopBar() prologue; kept our Diagnostics menu alongside
upstream's exit-button width math. HandleEvents merges both keyboard
paths, with the VR recenter hotkey now guarded by !g_rebind.active so
it cannot fire while a binding is being captured.
- AuroraDawnProvider.cmake: dropped our now-dead Android hash block.
Upstream restructured the pins into an if/elseif chain that already
covers android/aarch64, with the digest for the new dawn-build fork;
our leftover block was unreachable and carried the old encounter
digest.
- Version plumbing (Build-Installer.ps1, Setup.Windows Program.cs and
csproj): kept this fork's own line, which is 0.2.39 and centralised in
Launcher/Directory.Build.props, rather than regressing to upstream's
hardcoded 0.2.32.
Verified: translator 654/654; runtime ctest 14/14 including every VR
test; WiiCompiled and RetroRewind link; aurora gx_fifo_tests 262/263,
the one failure being the TevRegisterLiveness case already documented as
pre-existing on this branch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Brings in patchzyy/Wiicompiled main: os_sleep parked-thread fix (#195),
HTTPS Retro WFC payload (#198), macOS build guide (#177), and the
reverse-Z depth fix (#134).
Conflicts were in aurora-main/lib/gfx/common.cpp and lib/gx/shader.cpp,
both from #134, which lands squarely on the VR stereo replay path.
#134 makes UseReversedZ genuinely reversed: the near/far correction now
applies exactly once, inside effective_projection(), instead of being
applied there AND per-vertex in the shader (the double application had
been cancelling out, so "reversed" Z silently behaved like forward Z).
Three pieces of the VR path were built against that old behaviour and
would have broken silently, so they are adapted here:
- shader.cpp exact-screen-depth parked the virtual screen at -0.5*w
specifically so the shader's following negation would land it at
+0.5*w. With that negation gone it now writes +0.5*w directly; keeping
the minus sign would park the screen at NDC -0.5, outside the clip
volume, discarding every 2D/HUD draw.
- stereo_replay.hpp backend_ndc_depth_row re-applied the correction to
the projection it was handed. That projection is effective_projection()
output, which now already carries it, so the function is a pass-through
of the Z row and no longer depends on the reversed-Z setting; the dead
bool parameter is dropped. Re-applying it would invert the virtual
screen's depth ordering, so 2D layers meant to sit on top would lose
the depth test to the ones behind them.
- shader_info.cpp stages the host depth window for that exact-depth path.
It now uses the same reversed-Z remap as upstream's new SetViewport
code, since frag_depth is written directly and has to reproduce the
window the fixed viewport transform would have applied. Restricted
depth windows (how the game forces an element in front of everything)
are exactly the 2D draws the virtual screen carries.
The SetViewport resolution keeps upstream's remap but retains the
ordering/clamp guard our version had: for any ordered guest range the
result is identical to upstream, and it avoids handing WebGPU
minDepth > maxDepth for the swapped pair MKW is known to emit. The VR eye
replay reuses these recorded values, so the guard covers that path too.
Test updates:
- stereo_replay_test now asserts the composed Z row against the staged
projection's own Z row rather than against the helper's output, so it
actually catches a re-introduced double correction (verified: it fails
when the old negation is put back; the previous self-consistent form
passed).
- gx_fifo_test's clearDepthValue expectation followed #134's deliberate
clear_depth_value() inversion, expressed through UseReversedZ rather
than hardcoded. Upstream changed the behaviour without updating this
test, so it fails on upstream/main as-is.
Verified: aurora suite 247 passed with the same 2 failures that already
fail on the pre-merge branch (IndexedPaletteHistoryKeepsAbsoluteVertexSlots,
PacksOneUniformWhenBothHalvesNeedInitialValue - both pre-existing, unrelated
to depth); shader.cpp and common.cpp compile clean; translator suite 577
passed. Not yet validated on-device in VR.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Fix already downloaded toolchain re-use
the following mv command would move $work into $toolchain_dir if the $toolchain_dir folder already existed.
* resolve z-fighting
Brings in 25 upstream commits: Dolphin-compatible input expressions and
GCPadNew.ini import, NAND setting.txt console identity, empty-MKW-save
handling, rumble toggle, LLVM 22, and CI caching.
The only conflict was runtime/CMakeLists.txt, where both sides appended
test targets after mkw_platform_paths_tests. Both blocks are kept: the VR
first-person test alongside upstream's NAND save/settings, SC serial, and
input expression tests.
runtime_config.h and settings_overlay.cpp auto-merged; the VR settings
menu, recenter hotkey, and stereo/first-person init calls are intact
alongside upstream's InputBindings wiring.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Bluetooth Wii Remote support: the game reads a real Wii Remote through KPAD
Enable SDL3's HIDAPI Wii driver and hand a paired Wii Remote (bare or with
Nunchuk) to the game as a real Wii Remote: WPADProbe reports CORE/FREESTYLE
and KPADRead fills KPADStatus[0] from SDL every frame (buttons, accelerometer
in KPAD's g frame, Nunchuk stick and accelerometer), while the GameCube pad
view of that port reports no controller. The game's own motion code then
handles wheelies, tricks and Wii Wheel steering. Classic Controllers and
Wii U Pro Controllers keep going through the GameCube pad path with a default
button table picked by name.
SDL's Wii driver drops a remote on a failed Bluetooth read or when the
Nunchuk is plugged or unplugged and never re-adds it, so the runtime keeps
rescanning (Dolphin style) while no Wii controller is present by toggling the
driver hint off and, a few frames later, on again; a dropped remote is back
within 1-2 s. Settings live in the F10 overlay under Wii Remotes (Bluetooth)
and in Config.toml (wii_remotes, wii_continuous_scan).
* Fix Wii U Pro / Classic Controller ZL and ZR not registering
SDL's Wii driver reports ZL/ZR as the LEFT_TRIGGER/RIGHT_TRIGGER analog
axes, never as digital shoulder buttons. Binding them to
LEFT_SHOULDER/RIGHT_SHOULDER meant they never fired and also disabled
aurora's own analog-trigger fallback (a button table entry for
PAD_TRIGGER_L/R marks the trigger as "handled", even when the bound
digital button never actually presses). Leaving them unbound lets the
default axis mapping drive them like every other analog-trigger pad.
Reported by an end-to-end tester connecting a real Classic Controller to
a Wii Remote.
* Wii Remotes menu: live raw D-pad/ZL/ZR readout for Classic Controller / Wii U Pro
Diagnostic aid for a reported issue where the Classic Controller's D-pad
does not do anything in-game (no wheelies). Shows what SDL itself sees so
a driver-level problem (nothing lights up) can be told apart from a
mapping problem (it lights up but the game does not react).
* Fix Classic Controller D-pad input
* Address CodeRabbit review on PR #73
- PADRead: hide KPAD-served ports even while input is blocked so the port
error state does not flip when the overlay opens/closes.
- WPADProbe: run the Wii Remote rescan state machine before probing so a
reconnect probe before the next PADRead can see the remote.
- EnsureSensors: only cache the gamepad id once every accelerometer enabled,
so a failed activation is retried.
- ConfigureSdlHints: reset the in-flight rescan bookkeeping.
- Settings overlay: disable "Rescan now" while Wii Remotes are turned off.
* Bluetooth Wii Remote: fix wheel steering, native Classic Controller, extension hot-swap
Accelerometer
- The SDL -> KPAD conversion negated the wrong axis: SDL's z is the remote's
+Y (towards the user), so KPAD acc is (-wiiX, -wiiZ, +wiiY). Fixes mirrored
Wii Wheel steering.
- Drop reports whose accelerometer bytes arrive zeroed (+-5.12 g on every axis,
a few times a minute over Bluetooth) and repeat the last good sample; they
read as a full-lock steer plus a 9 g shake.
- One-button zero-point calibration in the overlay (remote flat, buttons up),
stored in Config.toml as wii_accel_offset_x/y/z. SDL's read of the remote's
factory calibration times out over Bluetooth and falls back to a nominal
zero point, which left a per-axis bias of up to ~0.3 g on the tested remote.
- Live accelerometer readout and an optional per-frame CSV trace
(wii_accel_trace = true) for debugging.
Classic Controller through KPAD/WPAD
- WPADProbe reports WPAD_DEV_CLASSIC; KPADRead fills ex_status.cl and
KPADGetUnifiedWpadStatus the raw WPADCLStatus (WPAD_CL_BUTTON_* bits, sticks
in the SDK's signed -512..511 range, triggers), so the game shows the Classic
layout and icons and no button mapping is involved. Ports served through KPAD
are hidden from PADRead; only the Wii U Pro Controller stays a GameCube pad.
Extension hot-swap
- SDL's Wii driver destroys the joystick on an extension change but keeps the
HID handle open, and HIDAPI never re-creates a joystick for such a device.
Patch the vendored SDL at configure time (AuroraSDL3Patches.cmake, wired into
AuroraSDL3Provider.cmake for both the downloaded tarball and a pre-provided
FETCHCONTENT_SOURCE_DIR_SDL) so the joystick is rebuilt in place with the new
extension type, without touching the Bluetooth handle.
- Keep a vanished remote's channel alive with neutral input for up to 3 s while
SDL re-creates the joystick, so the game never sees a disconnection. The
driver-hint rescan stays as a fallback for real drops, starting 3 s after
the loss, and also runs from the overlay's per-frame Draw. Log rescans.
Mappings / overlay
- Do not apply the shared positional [controller] bindings to Wii pads: that
override is what made a Classic Controller's A/B and X/Y look swapped.
- Raw D-pad fallback also for the Wii U Pro Controller; overlay readouts read
joystick buttons directly (SDL's generated HIDAPI mapping expects a hat).
- Overlay: Classic Controller readout, accelerometer readout and calibration.
- README: Bluetooth Wii Remote section and known limitations.
* Review pass on the Wii Remote input path
- EffectiveKind: stop bridging an extension swap once a different controller
has taken the port, and note that everything touching the scanner state runs
on the guest thread.
- KPADGetUnifiedWpadStatus: fill every requested entry (the SDK returns `count`
recent samples), capped at KPAD's 16 read buffers.
- IsKpadKind gets internal linkage; the calibration accessors get their
comments; clarify why Draw() also runs Poll().
* Drop the dead Classic-Controller-as-GameCube-pad matching
A Wii Remote with a Classic Controller is served through KPAD and its port is
hidden from PADRead, so the name matches that once gave it a GameCube button
table and the raw D-pad fallback could never take effect any more. Both now
match only the Wii U Pro Controller, and the default table is renamed
accordingly (g_defaultButtonsWiiUPro).
---------
Co-authored-by: LOL <andresguerra2k26@gmail.com>
Co-authored-by: Nick <89667145+Nick1232345@users.noreply.github.com>
darthcircuit