Keep the maintainer's 1.04 build support, calibration and documentation from main. Retain the missing PATCHGO flag check and a regression fixture that is larger than the base package.
The game takes loudness for blowing (-21 dB for half strength, -9 dB for all of it), and a
player whose blowing does nothing had no way to tell whether the game heard anything.
- The log, and the PC launcher's window, now say how loud the loudest moment of the last
ten seconds was whenever something was heard, and once when nothing but silence has come
from the microphone, with what to look at on a PC.
- mic_gain in the PC's settings (SHADPS4_MIC_GAIN) makes the microphone louder for the game.
- Held together, the PS button and square blow without a microphone, and so do X and Y on a
headset's controllers: for where a microphone is not to be had or gives too little (what
a headset's streaming app passes on of blowing is up to its noise suppression), and for
players who would rather not blow.
Issue #8.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A copy of the game at 1.04 is no longer warned about; other versions are told what they
miss (the game's own speed and the larger pictures), and the emulator's line naming the
build it found is shown. The check for a path that is too long ran only for copies that
were not warned about: it runs for all.
- A package that is an update of the game holds the files the update changed and no more.
It was unpacked as if it were the game when it was the only package there. The game's own
package is now taken before any update, whatever their sizes, and an update alone is
turned down with what to do about it; so is a folder that has only an update in it.
- What to do in the headset names the headset, not only an Index, for SteamVR, and says how
to move the gamepad in the game where nothing tracks it (PS + D-pad) and how the right
stick shoots as a touchpad.
Issues #1, #4, #7.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Without tracked hands, and on headsets that track none, the gamepad in the game hangs at
a fixed place before the player: the one the game looks for it at when it starts (17 cm
below the eyes, half a metre ahead), which is in the way of the view for some and out of
reach of what the controller has to be held to for others.
Held, the PS button now has the D-pad move that place (up, down, left, right; L1 nearer,
R1 farther; two centimetres a press) and triangle switch between the player's own place
and the standard one. Pressed and let go it resets the view, as before. The player's
place is kept (user/vr_controller.json); every start begins at the standard one, which
the game's first screen needs, and PS + triangle brings the controller to the player's.
For tests, input scripts know place=<right>,<up>,<nearer> and place=switch, and
finger=<x>,<y>: the right stick as it stands in for a finger on the touchpad.
Issue #4.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ASTRO BOT's catapult shoots for a finger that was down for more than a quarter of a
second and has been dragged over more than four tenths of the pad when it lifts (its
SlingShot settings, and the code that reads them). A finger that comes down in the
middle of the pad has half the pad to go: with the stick's full push worth 0.45 of it,
anything short of a full push was not enough. The finger is now at the edge with the
stick four fifths out, and a touch lasts 0.3 seconds at least, so a quick pull and
release shoots as well.
Issue #2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The right stick (of a gamepad without a touchpad, and of the headset's own controllers)
moved a finger that was wherever the stick pointed. A stick that is let go flies back to
its centre, so the finger went back to where it had come from before it lifted: the
catapult at the end of every level, which shoots by how far the finger was dragged when
it lets go, had nothing pulled, and getting it to shoot took many tries.
The finger now stays where the stick was before it started back and lifts from there
once the stick has come to rest; it comes down in the middle of the pad, so a push is a
swipe over all of its way; a stick can be moved through its centre without the finger
lifting (a drag from one edge of the pad to the other); and a stick that never rests
near its centre, a worn one that drifts, moves no finger at all. That last one matters
on a controller with a real touchpad too: the stick's finger stayed on the pad for good
there, and a real finger's swipes counted for nothing beside it. A real finger coming
down now also lifts the stick's first, as a touch of its own.
Input::StickFinger, tried by tools/tests/stick_finger_test.cpp at the rates a gamepad
and a headset's controllers are read at.
Issues #2, #12.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The console's address space was reserved after the headset had been looked for. What an
OpenXR runtime brings into the process when it loads could then lie where the title maps
its memory: with SteamVR, ASTRO BOT's heap at 0x300000000 no longer fitted, and the game
stopped at its start ("Mapping cannot fit inside free region", exit code -2147483645).
The address space now comes first. Found by evertec82, whose fork has the same change.
A session that is asked for no pictures was ended and made anew after a while. That is
for Virtual Desktop's runtime, which says nothing when its headset goes away. Other
runtimes ask for no pictures whenever nobody looks (SteamVR while the headset rests or
its dashboard is up) and say what becomes of their sessions through the states OpenXR
has for it: a session ended under them was one they were still using (evertec82 saw
SteamVR's client library crash when one of its sessions was ended that way). It is now
done for Virtual Desktop's runtime only; SHADPS4_XR_RENEW_UNWANTED=1 or 0 says otherwise.
Issue #14.
Co-authored-by: evertec82 <50994582+evertec82@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A gamepad that Windows lists and that cannot be opened (a virtual one that is just going
away, for one) counted as a gamepad: nobody was logged in for it, and nobody was logged
in for want of one either. ASTRO BOT takes its first player for granted and stopped at
its start with an access violation (0xC0000005, "The emulator ended with code
-1073741819"), its list of logged-in players empty. What decides now is whether the
first player has been logged in, not how many gamepads were counted; a gamepad that
cannot be opened is named in the log, with the reason.
Issue #9.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From its first update on, the game asks the tracker to find the controller anew on the
screen that has the player sit inside a silhouette, and waits there until it has seen the
controller's status go from calibrating to anything else. sceVrTrackerRecalibrate was a
stub: the status never changed, and the updated game stayed on that screen for good ("the
controller with the red light bar should also be in view"). The tracker now says what a
console's does while it finds a device anew.
The executable of 1.04 is laid out differently from the disc's, each part moved by an
amount of its own. Where its time step, its sizes and the memory for them are is in
known_title_builds.h, as found and tried by Clodo76 (issue #1) and checked here against
both executables. A build is told from the others by what its image holds when it is
loaded, before anything is written to it; tools/tests/known_title_builds_test.cpp tries
that on images made up for it and on real executables.
Issues #1, #3, #5, #7, #10.
Co-authored-by: Clodo76 <1511345+Clodo76@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Virtual Desktop takes its playback device out of Windows whenever the headset is not
streamed to; a stream opened on it then stayed silent until the emulator was restarted.
The SDL backend now moves a port to the system's default device when its own is gone and
back when it returns, and plays on "the default" where the wanted device is the default.
Also: sound devices coming and going are logged, an unhandled exception logs its call
stack, and tools to take a playback device out of Windows and measure what devices play.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tools/tests/launcher-test.ps1 loads the launcher's functions and tries them on made-up folder
layouts; tools/ui-drive.ps1 waits for the launcher's windows, saves pictures of them and
presses their buttons, which is how the first start of a release was gone through.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Until now the launcher wanted an unpacked game at games\CUSA12392\eboot.bin and pointed at a
text file otherwise. Now:
- it looks through the games folder, three folders down, for an unpacked game (a folder with
eboot.bin in it; the one whose param.sfo says CUSA12392 if there are several);
- failing that, for a .pkg there, which it offers to unpack into games\<serial> with PkgTool
(LibOrbisPkg, LGPL-3.0, put into the PC package by make-release.sh): into a folder of its
own first, so that an unpacking that was cancelled or failed leaves nothing that could be
taken for the game; the sce_sys entries the package keeps outside its file system
(param.sfo, pictures, trophies) are added; the result is the same, byte for byte, as the
copy the project was developed with;
- failing that, a window asks where the game is (its eboot.bin or its .pkg), and what is
chosen outside the games folder is written to settings.txt as game=;
- a game folder whose path is too long for the emulator to open all of the game's files is
refused with the reason, not started;
- a missing Visual C++ runtime is said, with Microsoft's download;
- a warning when Windows has less memory left to hand out than the emulator asks for at once
(about 14 GB), which is what makes it stop as it starts now and then;
- the launcher's windows open in front and at their normal size even when it was started
minimized.
The Quest app is unchanged; its version follows the release.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On top of the shadps4-arm64 core imported in the previous commit:
- PlayStation VR emulation: headset, tracker, reprojection, camera and social screen; the
player's seat and view reset; head velocity for head-butts; field of view settings
- Sound: a native Ngs2 engine (samplers, submixers, effects), the Audio3d spatializer, virtual
surround for headset speakers, microphone pass-through; libSceJson2; libSceFiber on FEX
- Fixes for CUSA12392 under emulation: real-time step, pace and resolution governor, larger
render sizes on the PC, save loading at start
- Renderer: geometry shaders fed with fans/polygons/loops, cube-array layers of light probes,
sample-count mismatches on Adreno, timeline semaphore hang, FXAA in place of the MSAA
resolve, sharpening, VR frame export
- quest-host: the Quest app (OpenXR host that runs the glibc core as a child process, frames
through AHardwareBuffers, DualSense mapping, hand-tracked controller placement, KGSL shim)
- PC: in-process OpenXR host (Virtual Desktop or any OpenXR runtime), Touch controllers as the
gamepad, launcher with a settings window; vendored OpenXR SDK 1.1.63
- Builds keep the build machine's folders out of the binaries (-ffile-prefix-map); machine
settings (Python, headset serial, signing key) live in git-ignored tools/*.local files
- tools: build, packaging and test scripts for Windows and the headset
- README with installation, license (GPL-2.0-or-later), third-party notices and thanks
No game files are part of the repository; .gitignore only lets listed paths in.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ODevStudio