The README and both guides start with building the archive from source
(WSL2 on Windows included) and then copying it to the Frame by USB stick or
SSH, since there are no ready-made builds. The two screenshots of the game
are gone from the README and the repository; the galaxy cover stays.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The notice says what the project is and is not (unofficial, no game data,
own disc, non-commercial) and how rights holders get something removed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Developer mode with a password for steamos in its settings turns SSH on;
the Konsole commands stay as the way without developer mode.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
STEAM-FRAME.md is ANLEITUNG-STEAM-FRAME.md in English; the two link each
other, the README names both, and the release archive carries both.
install.sh speaks German on a German system and English elsewhere.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
./install.sh <disc image or extracted folder> [--no-movies] extracts the
disc with Dolphin's dolphin-tool (the Flathub Flatpak, put into the user's
installation when missing: the system one asks for a password over SSH),
converts it with the converter the release archive now carries, moves the
result to ~/.local/share/GalaxyQuest/game and adds the program to Steam
with steamos-add-to-steam. Tried on the Frame from RMGR01.iso: 2 minutes
including Dolphin, and the same files as the game data converted on a PC.
The guide starts with it, on the Frame or from a PC over SSH.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SteamOS gives a game RLIMIT_NICE 28 (nice down to -8); the launcher takes
it before any thread starts, so every thread inherits it. On the Frame a
chat client in the same cgroup took two cores, and the frame loop missed
up to 67 refreshes in 10 s with its own work late; with the game's
threads at -8 (tried on the running game) one or none.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
X holds Z and adds A a game frame later: the long jump while running,
the backflip standing. Y and B spin as before. The pause menu (+) is on
the left controller's View button only; the right one's Menu is free.
120 Hz needs no setting by hand any more (the guide said so still), and
the release archive's documents lose the executable bit a Windows drive
gives them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Cross-build against the Steam Runtime 4 arm64 SDK (build_linux.sh,
cmake/steamrt4-arm64.cmake): the executable sits at 0x98000000 next to
the game's 32-bit window, with the OpenXR loader and jsoncpp beside it
(RPATH $ORIGIN); build_linux.sh also packs a release archive.
- OpenXR on SteamVR: EGL surfaceless through XR_MNDX_egl_enable, the
Frame controller profile (both names), a flick or a wrist turn as the
Wii Remote's shake, the D-pad as look; the refresh rate goes to 120 Hz
through vrcmd where the runtime offers only its current rate.
- Timewarp in the app: SteamVR shows frames that arrive in time as they
were rendered, so at 120 Hz every game frame stood still for two
refreshes while the head turned. The game frame's eyes now go into a
scene set, and every refresh composites the last finished set turned
to its own head pose (timewarp.h, checked by tools/timewarp_test and
by the simulator's PETARI_XRSIM_WARP); sharpening runs once per game
frame; the pacing changes only after a new display period has held.
- Fixes found on the way: libstdc++'s <cstdio>/<cwchar> against the MSL
renames (compat.h), language archives a disc carries damaged (cook.py
takes another language's), host allocations on the DVD and DSP
threads, quitting without waiting on the game's threads, case of two
include names.
- ANLEITUNG-STEAM-FRAME.md: the player's guide in German.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Version code 7, for the release with the American disc, the settings
panel's tabs, the language choice, the inverted camera turns, passthrough
around the giant screen and the screen picture that follows the GPU's
load.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With passthrough and the stereoscopic 3D on, a player's game ran at 35
to 42 frames a second on the giant screen: the GPU needed 13 to 17 ms a
frame where about 11 were left. The diorama's eyes lower their
resolution when that happens; the screen's picture had one fixed size.
- The screen's 3D pictures get a render scale of their own, moved by the
rules that move the eyes' (and by the runtime's counters only): from 1,
the full 2048x1152, down to three quarters of min_resolution. A
smaller picture is drawn into a target of its own size and shown
through the screen layer's image rectangle, as the stereo pair's
pictures already are; a pair's pictures are stereo_resolution times
the scaled size. Menus and movies keep the full size.
- Each of the two scales is judged afresh when the presentation changes,
and PETARI_FIXED_SCALE holds whichever is in use.
- Super Resolution's sharpening is asked for only while the eye layer
holds the diorama: around the screen it filtered a dark or see-through
layer.
- The panel's "Lowest resolution" row shows the picture's size while the
giant screen is on.
Checked headless with the scale held at 0.6 (one picture, a pair, and
without layers: the picture fills the screen), and in the app unworn
with passthrough and the 3D at full size: held at 1 the GPU took 10.6 ms
a frame and showed 578-590 of 600 frames in 10 s; following the load the
scale went to 0.6 within seconds and back up a step at a time, at
6.4-7.2 ms and 598-600 frames.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The settings panel beside the pause menu held nine of the settings of
petari_vr.ini; the others needed the file edited over adb. Players asked
for all of them in the game, for a choice of language, for the camera's
turns the other way round and for the room around the giant screen.
- One table of the numeric settings (vr::Setting in vr_game.cpp: key,
range, default, how to read and change it) now serves the file's loader
and the panel. Values outside a setting's range are clamped instead of
ignored.
- The panel (vr_settings.cpp) is drawn from tables of rows (a switch, a
stepper or a slider) on four tabs: Screen, Diorama, Picture, Game, with
a Defaults button for the open tab. It writes only the lines of the
settings changed on it, in one pass, so the rest keep following the
defaults. The refresh rate and the highest resolution now apply at
once; the clock levels and the language at the next start.
- language: each disc's languages (European: English, French, German,
Spanish, Italian; American: English, French, Spanish) with their
folders; SCGetLanguage answers with the one asked for when the copy has
its texts. The European disc's EuDutch folder holds the English texts
again and is not offered.
- invert_camera (on by default): the game moves its camera round Mario
the way the D-pad is pressed, so the view turns the other way. With
the setting CameraLocalUtil's two tests swap sides (and CameraInfo's
two arrows), and the diorama's snap turn takes the other sign: pushing
the right stick right turns the view to the right. Pages and menus
keep their sides.
- passthrough (off by default): XR_FB_passthrough, with
com.oculus.feature.PASSTHROUGH declared (not required) in the manifest.
The feature and a reconstruction layer are made when the setting first
asks, and paused while it does not. While they run the passthrough
layer goes out first and the eye layer blends by its alpha; around the
giant screen the eye images are cleared to transparent, fading over
0.3 s. The diorama's eye images stay opaque.
Checked headless on the headset (every tab and control, the saved file,
the camera's direction with the setting off and on, French and Spanish
texts on the two discs) and in the app unworn (the language from the
file, passthrough started, paused and started again without an error,
the refresh rate changed from the panel). Measured there with
passthrough: the compositor's GPU time goes from 1.9 to 3.1-4.2 ms a
refresh; worn, a player's heavy scene fell from 60 to 44 frames a second.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A player with the American disc (RMGE01) reported a crash at the start.
The game picks the folder of its texts from the disc's game code and the
console's language (Language.cpp), and the port had the European code
RMGP01 fixed in low memory: on American files the game asked for
/EuEnglish/MessageData/Message.arc and stopped ("File isn't exist").
- dvd.cpp reads the region off the language folders in the disc's own
file table (sys/fst.bin: EuEnglish, UsEnglish, JpJapanese, KrKorean),
boot.cpp puts the matching code at 0x80000000 and SCGetLanguage answers
with a language that disc has.
- The setup screen shows a folder whose file table names none of those
folders, or whose copy lacks the texts, as "Unknown disc" instead of
letting the game start on it.
- FileRipper names the file it did not find before it panics.
- run_headless.sh and galaxy_tour.sh take the game files and the save
folder from HEADLESS_DATA and HEADLESS_NAND, to test another disc's
files beside the app's own.
Checked on the headset with both discs' converted files: the prologue
and Good Egg Galaxy, and on the American ones the two galaxies whose
stage files differ from the European disc's (Gold Leaf, Rolling Gizmo)
plus Gateway, Honeyhive, the observatory and Battlerock.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Version code 6, for the release that keeps the stage music playing and
plays it at its full volume.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VIGetDimmingCount() returned 0, which tells the game that the console's
screen saver is on (five minutes without input). AudSystem then holds
the music at a third of its volume for as long as that lasts: here,
always. It now returns the full count, and the music plays at the level
the game mixes it at, 9.5 dB above what it was. Sound effects, whose
levels each scene sets again, were not held down in play.
No clipping in 14 minutes of recorded play in Good Egg Galaxy (peaks
around -4 dBFS).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A player reported a game that works but has no stage music. Every stage
theme is a stream (.ast), and all streams could stop for the rest of the
session:
- JASAramStream follows a stream's voice and sets up its loop (or its
end) once the voice is within 400 samples of it. A voice found beyond
the loop end is a fatal error to it: the stream's voices are paused and
no stream is loaded any more until the game is restarted.
- The console's DSP renders 80 samples between two updates of the voices.
The port's rendered a whole frame of seven sub-frames on the sync
command, so the game saw a voice move 560 samples at a time and missed
the 400-sample window on about one pass in four. Which pass is fixed
for each track: the file select music stopped after 55 s (a new player
choosing a file), Gateway Galaxy's after 64 s, Honeyhive's after 83 s,
the title's after 2.5 minutes, Good Egg's after 10.5. Sound effects
and sequenced jingles went on.
The DSP now goes as the console's does: the sync command only says how
many sub-frames to render, and each is rendered when the game has updated
the voices and released the last sixteen of them (the end of
JASDSPChannel::updateAll), then reported with its mail. Notes and
envelopes get the console's 2.5 ms timing as well, instead of 17.5 ms.
Checked on the headset, headless and in the app: a minute on the file
select screen and then a galaxy (no stage music at all before, music
now), the loops found in the recordings by correlation with the disc's
samples, 14 minutes of self-play in Good Egg Galaxy across six loops, a
cutscene skipped into its boss music, and six other stages.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Step 2 said to unzip "the platform-tools download" without saying where
it comes from. It now links Google's SDK Platform-Tools zips for
Windows, macOS and Linux (and the page they come from), says the zip
holds one platform-tools folder to drag into the converter's folder, and
warns that Windows' Extract All nests it one folder deeper than the
PATH line of step 3 expects.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The installing section took a developer's setup for granted. It now goes
through it in eight numbered steps for someone who has none: developer
mode on the headset (Meta's steps), one folder for the app, the converter
and adb, a terminal opened in it with adb on its PATH, the checks that
Python and the headset answer, the install, the disc, the conversion, the
copy, the first start, and what the usual failures mean.
- The Python files the steps use are a download on the release page,
GalaxyQuest-converter.zip: said up front, with direct links, and that
the repository itself is not needed.
- On Windows the command is py, not python (which does nothing or opens
the Microsoft Store); on macOS and Linux, python3. Said before the
steps and next to each command. The converter zip's README.txt says it
too.
The commands were run as written from a fresh folder in cmd on Windows
(py 3.14): set PATH, adb devices, and a whole conversion.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Version code 5, for the release with stereoscopic 3D on the giant screen,
the view that starts facing the player, the comet filter left out of the
diorama, and the converter as a download of its own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
To play, nobody needs the source: tools/package_converter.py makes
GalaxyQuest-converter.zip for the release page, with the disc converter
(tools/cook/cook.py and the modules it imports) and tools/push_data.py at
the paths they have in the repository, plus a short README.txt. The file
list follows the scripts' imports, and the zip is the same byte for byte
whenever the files are.
Converting a disc with the unzipped package alone gives the same 2375
files as from the repository. The README's first step now asks for the
APK and this zip instead of a download of the repository.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
The emulated accelerometer had its own axes (x right, y along the
pointer, z out of the button face) where KPAD's are x left, y out of the
button face, z along the pointer ((0, -1, 0) held level, KPADReset),
which the game then remaps (WPadAcceleration::update). A level
controller read as a remote standing on end: the surfing coach's "Point
your Wii Remote at the screen" never passed, and the Star Ball would
roll forward at full speed.
- wpad.cpp adds gravity in KPAD's axes. While the game steers by tilt
(port_input_use_tilt), it follows the right controller pitched up by
the game's neutral angle, so a level controller gives the grip the
game asks for; a controller whose orientation is unknown counts as
level. PortPadState carries which way is down from the controller
(xr_app.cpp) and, as accelerations, only the motion on top (shakes).
- Star Ball: neutral 80 degrees (90 - sCoreBaseDegreeYZ), not 100. Its
tutorial reads the tilt only while it checks that the remote is
raised, so aiming near the sign never counts as a shake.
- PETARI_INPUT scripts tilt the controller with PITCH= and ROLL=.
- docs/CONTROLS.md: the in-game instructions in controller terms.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- LICENSE: The Unlicense: the port's code, tools and documentation are
in the public domain, for anyone to use as they please. Petari keeps
its CC0 (decomp/LICENSE-Petari.txt) and the third-party parts their
own licenses (THIRD_PARTY_NOTICES.md); README.md says so in a new
License section.
- .github/FUNDING.yml: the donation link on the repository page again.
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>
