5 Commits

Include renames

Author	SHA1	Message	Date
bigmak94andClaude Opus 5.5	d4094454ed	0.19: what players wrote elsewhere: the launcher's runtime check, the game's language, controllers that take turns on the PC, a view that turns by steps ... From the project's thread on Reddit and the comments under the videos about it, all written before 0.18. What 0.18 had not answered: - The PC launcher asked for the Visual C++ runtime again and again, however often it was installed (one player cut the check out of the launcher to play). Started from a 32-bit program, "powershell" is the 32-bit one, to which Windows shows the 32-bit system folder under the 64-bit one's name, and vcruntime140_1.dll only exists in 64 bits. The launcher hands over to the 64-bit PowerShell first (which also puts the OpenXR runtime's registry entry where it looks), looks for the files where a 64-bit program finds them and next to the emulator, names the ones it misses, and its question can be answered with "start the game all the same". When the emulator ends with "DLL not found" it says what that is. - The game was in English whatever the console's language should have been: the emulator's console was set to English and nothing offered another. SHADPS4_CONSOLE_LANGUAGE takes a language tag ("fr-FR", "pt_BR", "zh-Hans-CN") or the console's number (Common::ConsoleLanguageFromTag). The PC launcher passes the language Windows is shown in, or the one chosen in its window from the game's 28 (language=); the Quest app passes the headset's (language= for another). - On the PC the headset's controllers did nothing while a gamepad was connected, even one that only lay there. Whichever was used last plays (Input::PadSource): a button or a stick of the headset's controllers takes over once the gamepad has said nothing for a quarter of a second, which leaves a gamepad that a streaming program makes of those controllers playing as before; the gamepad takes back with its first button, stick or touch. While the headset's controllers play, GameController leaves the gamepad's input aside, and the runtime believes a host that says where the controller is over a gamepad's sensors. - Turning the view by steps, asked for by a player who cannot turn round where they sit: Runtime::TurnView turns the seat about the head (the head keeps its place in the title's world, the controller comes round, a reset of the view undoes it). Asked for with a button the game has no use for in play, held, and the right stick flicked to a side (Input::ViewTurn): L1 on a gamepad, the grip of the hand that does not hold the controller on the headset's own; from the Quest app as two new flags of the pad pose message. 30 degrees a step (SHADPS4_VR_TURN, turn=). The Quest app's card names it. - "Save Migration", a question in a box behind the game's window at the first start (reported from Linux, where the package's ready-made folder was not used): only asked where an older shadPS4 left something to move. README: common questions (getting the game, headsets, controllers, SteamVR, why the picture looks reprojected, language, Linux), and a player's recipe for Proton, as reported. Tried: the unit tests (console_language_test, pad_source_test, pad_router_test with the turn, launcher-test under 64-bit and 32-bit PowerShell, the launcher's hand-over from a 32-bit one); the game on the PC in French, Japanese and Arabic, and in English for a language it lacks; against a simulated headset with a test gamepad and test presses of the headset's controllers (SHADPS4_TEST_VIRTUAL_PRESS/_TURN, SHADPS4_XR_TEST_PRESS/_TURN): each takes over from the other, the view turns by either, the picture turns and the head stays in place; on a Quest 3 without wearing it: the language reaches the game, the self-test's new HOST_TURN turns the view with a tracked and with an untracked controller alike, the card shows its new line. Not tried: any of it worn, and Virtual Desktop's own gamepad emulation. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 15:22:17 +02:00
bigmak94andClaude Opus 5.5	9a2b8b8178	The touchpad's gestures on buttons, and a stick's finger the game can follow ... The first worn try of the Quest app with the headset's own controllers ended at the catapult of the first level: the right stick pulled back and let go did not shoot it. And nothing told the player that the pad is pressed (the water cannon) by pressing that stick in. Why the catapult failed: the game reads the pad once for every frame it draws (the newest of the states it is handed), and takes the place it first finds the finger at for the start of a pull. A stick is at its end within a few hundredths of a second, so the finger that followed it there had, for the game, begun where it ended. By a model of the game's rule (tools/tests/touch_game_model.h: read at 0xc04cc3, y = 1 - raw / 950, the catapult of 0x436fc0 wants more than 0.25 s and more than 0.4 of the pad) one fast pull in four failed at 60 frames a second and two in three at 30, which is what the reports of Issue #2 say and what the headset draws. - Input::MovedFinger: a finger that stays where it lands until the game has seen it there, goes no faster than a finger flicks and counts as arrived once it was seen at its end. - Input::StickFinger is built on it: the finger comes down behind the pad's middle, on the side the stick comes from, and is dragged to where the stick points. - Input::PadGestures: what the game asks of the pad, done by buttons it has no use for in play (it only asks about them in a few menus, and is still told of them): the pad pressed while a button is held, a swipe forward for each press of another, a pull back that is held and let go with a third. On the headset's own controllers the trigger and the grip of the hand that holds the controller in the game and the other hand's trigger; on a gamepad without a touchpad R2, R1 and L2. In the Quest app's router, the PC host's code for the headset's controllers and the PC's gamepads. - The Quest app shows a card over the game that names those buttons, when the game starts and whenever OPTIONS is pressed (the game's pause). - SHADPS4_PAD_TOUCH_TRACE=1 has the log say what the game was given of the touchpad at each of its reads; input scripts can press the gesture buttons (gesture=press|swipe|pull); the Quest app's dry start pulls the right stick and presses R1. Tried: the tests (stick_finger_test and pad_gestures_test against the model at 26 to 60 frames a second, pad_router_test); with the trace, in the game on the PC (62 reads a second) and on a Quest 3 without wearing it (48 in its sandbox, 36 through the whole app): a pull is given as 0.74 to 0.76 of the pad over 0.34 s and more, a swipe as 0.67 over a dozen reads, a press for as long as it is held. Not tried: the catapult itself going off (a script did not get through the level to it), and all of it worn. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 13:42:32 +02:00
bigmak94andClaude Opus 5.5	ee4f9aa03f	Quest app: the headset's own controllers play the game, and what other gamepads lack is made up for ... The app was made for a DualSense and took everything else for a lesser one of those. Players without one could play on the PC, with the headset's controllers, and not on the headset. The headset's own controllers: the app reads them through the headset's runtime (OpenXR actions, the layout the PC host has: A cross, B square, X circle, Y triangle and both together to blow, grips L1/R1, triggers L2/R2, right stick the finger on the touchpad, left menu button OPTIONS, both sticks in to reset the view), the right one is the controller in the game with where it is and how it points, both shake with the game's rumble. The gamepad the system makes of them for other apps is no longer taken for a gamepad: it says neither where it is nor whether anybody holds it. Which of the two: a small router (quest-host/cpp/pad_router.h) between the activity, which hears of gamepads, and the session, which reads the controllers. The game is played with the one used last. From a gamepad only a button under a thumb or a stick takes over, never a trigger or a grip: while a gamepad is held it is hands the headset sees. What buttons mean about the view besides (the first press of X takes the seat, OPTIONS held resets the view) moved there from the activity, so that it is the same for both. The start-up menu takes either; what confirmed it is not pressed in the game. Gamepads that are not a PlayStation's: - The right stick as the touchpad's finger is Input::StickFinger now, as on the PC: the finger lifts where the stick was let go, which the catapult at the end of a level needs. A button that presses the touchpad touches it in its middle. - A gamepad without motion sensors followed the hands to where they were and kept pointing straight ahead. Now the hands turn and tilt it (quest-host/cpp/held_pad.h): the line between the palms is its sideways axis, the way the hands point is its tilt. The app says so with a new flag of the pad pose message (HeldInHands), and the emulator lets go of a controller that was a tracked device once it no longer is (it stayed where that device was last seen for as long as no motion sensor of its own spoke up). - Motion sensors are only taken from PlayStation controllers: which way is up for one is each maker's own affair. - A right stick on RX/RY, triggers that are only buttons, a Back button the system takes for its own "back". For trying a build on a headset whose owner plays with the installed one: quest-host/build.sh --test-package builds the app under another name, which installs next to it; the test tools take ASTRO_PACKAGE. The self-test can report a controller the way a session does (HOST_PAD) and keep pictures of it (HOST_SHOTS). Tried on a Quest 3 without wearing it: the runtime takes the bindings, the app starts and plays with a made-up gamepad, and in the game's picture the controller is where and how the self-test says a tracked controller or hands around a gamepad are, and comes back when they are lost. tools/tests/pad_router_test.cpp and held_pad_test.cpp try the rest on the PC. Not tried: any of it worn, and no gamepad other than a DualSense. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 11:38:59 +02:00
bigmak94andClaude Opus 5.5	d96618af1d	Quest app 0.14 to 0.17: a field-of-view menu at the start, counted from the headset's own view ... Work of 2026-10-04, committed as it was (README-QUEST-VR.md tells each step): - 0.14: every start shows a panel in the headset to choose how much of the field of view the game draws (left and right on the D-pad or the left stick, X to play). Less is the same pixels over fewer degrees, a sharper picture; the choice is remembered. Below all of it, each eye gets a soft-edged squircle border, drawn where the host copies the frame. - 0.15: the percent is of the headset's own view, read from OpenXR before Play is offered and handed to the emulator before the game starts (SHADPS4_VR_HEADSET_FOV_TAN), 50 to 100. - 0.16: the border sits around each eye's straight ahead, which a headset's uneven view does not have in the middle of the picture. - 0.17: both eyes draw the same, even view around straight ahead that takes in the headset's own (SHADPS4_VR_FOV_SYMMETRIC), so that what one eye shows the other shows too when the view is narrowed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 10:15:43 +02:00
bigmak94andClaude Opus 5.5	b5f400bbbd	AstroQuest 0.11: ASTRO BOT Rescue Mission in VR on Meta Quest 3 and PC VR ... 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>	2026-10-03 15:00:43 +02:00