Stereoscopic 3D (a switch on the VR settings panel, stereo_screen; off by
default): on the giant screen, frames with a 3D camera are replayed twice
from the game's own camera, the 3D draws shifted sideways in clip space by
their depth, and each eye gets its own picture as a quad layer of its own
(the Quest's compositor shows the two as one stereo quad).
- Depth: a point is drawn stereo_far - stereo_depth * (Mario's depth / its
depth) eye distances apart. The farthest things lie 0.95 behind the
screen, the most the eyes take; with the whole scene behind a screen
4.5 m away there was hardly any depth, so Mario stands in front of it
and the foreground comes further out. "3D depth" on the panel sets
stereo_depth (1.75, 0.25 to 3).
- The HUD floats in front of the scene it covers instead of sitting on the
screen behind it; the pointer's cursor lies on what it points at (the
game reports the depth under it, port_vr_pointer_depth), and with the
HUD on menus.
- The two pictures are 0.8 of the single one's size (stereo_resolution),
shown through the layers' image rectangles: 8.6 to 9.7 ms of GPU a frame
on the headset against 10.6 to 13.2 at full size, 60 frames a second.
- PETARI_VRSHOT_MS also saves the screen's layers, which the eye images do
not contain.
The app's space is the runtime's LOCAL space moved to the head and turned
to where it faces on each session's first tracked frame, after a
recentring, and when the tracking jumps in a session's first seconds.
LOCAL alone can be stale when the game starts (2.15 m from the head on a
launch right after the headset woke up): the screen came up beside or
behind the player until they recentred.
In the diorama a comet mission's screen filter is left out: on the HUD
panel it was a black patch in the middle of the view.
On the giant screen no laser is drawn from the controller: the game's
cursor shows where it points. It stays for the VR settings panel.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A native port built on the Petari decompilation (previous commit): an
HLE platform layer (OS, DVD, GX, audio, input, NAND) under the game's
own code, an OpenXR presentation (a diorama around the player, a giant
screen, the HUD and settings as compositor layers, SpaceWarp, dynamic
resolution), Touch Plus controls, the tools that convert your own game
files (tools/cook, which also takes the few pieces of data the game's
executable holds from your sys/main.dol), and the port's changes to the
decompilation (`git diff petari-base -- decomp`). README.md explains
installing and building, docs/TECHNICAL.md how it works.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The sources of Petari (https://github.com/SMGCommunity/Petari), the
Super Mario Galaxy decompilation by the SMGCommunity, at commit
0a5c6608dc3b4c44a9aa68c2535d1793dc565f02, unchanged but for LF line
endings: LICENSE (as LICENSE-Petari.txt; CC0 1.0), include/, libs/ and
src/. Left out: the game data Petari keeps from the original
executable, the error message archive (include/Game/System/
ErrorArchive.hpp) and two tables (src/Game/System/GalaxyID.bcsv and
StoryEvent.bcsv); GalaxyQuest's converter takes them from the player's
own disc. The port's changes follow in the next commit, so
`git diff petari-base -- decomp` shows them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
