Add mouse-based gyro emulation#18113
Conversation
This change adds a hardcoded mouse-based motion sensor emulation feature, inspired by how Cemu handles mouse-driven gyro input. While the game window is focused, holding the right mouse button enables gyro emulation: - Mouse X movement feeds Motion X - Mouse Y movement feeds Motion Z - Mouse Wheel feeds Motion Y The axis mapping and behavior were tested with the "Spark Runner" minigame in Sly Cooper: Thieves in Time and Bentley's Hackpack. In accordance with this minigame, a top-down view motion control scheme relies on the X/Z axes. While the right mouse button is being held, mouse deltas are captured via the Qt native event filter and accumulated in the frontend, then consumed by the pad thread. On right mouse button release, motion values are reset to the neutral center to avoid residual drift. This input path is intentionally independent of pad configuration and works even when a keyboard-only profile is selected. This implementation thus resolves issue RPCS3#13883 by allowing motion-only gameplay without requiring a physical motion-capable controller.
|
Here is a screenshot of the referenced "Spark Runner" minigame that uses motion controls. 
|
|
Wouldn't be better if instead mouse movement does x-axis and y-axis, and instead of using the mouse wheel for Z-axis movement you just have a keyboard shortcut to enable this mouse-gyro emulation?; then, pressing/holding left mouse button does backwards movement on Z-axis, while pressing/holding right mouse does fordwards movement, with the speed of movement on Z-axis being adjustable in real time with mouse wheel (something like mouse wheel up= faster - mouse wheel down= slower). In my opinion that would be more confortable, but anyways this is already a very nice addition. |
Co-authored-by: Megamouse <studienricky89@googlemail.com>
Co-authored-by: Megamouse <studienricky89@googlemail.com>
Moved events to gs_frame
Merged some lines
Adjusted unnecessary memory order
|
Great addition. Killzone 2 could be tested further than just the first half hour or so, since the planted explosive charge requires gyro to finish that first level. Thanks! |
…o be more correct Moved mouse gyro to its own struct, adjusted mouse to gyro behavior to be more correct
Some comment fixes
|
@Megamouse I'm done making your requested adjustments. Please review and let me know if you need any more improvements. |
Moved mouse_gyro_state into its own class
Moved qt event part to class too
Made atomic_t
Megamouse
left a comment
Megamouse
left a comment
There was a problem hiding this comment.
You're also still missing the cmakelists addition of the cpp file
Commit suggestion Co-authored-by: Megamouse <studienricky89@googlemail.com>
Commit suggestion Co-authored-by: Megamouse <studienricky89@googlemail.com>
Commit suggestion Co-authored-by: Megamouse <studienricky89@googlemail.com>
Commit suggestion Co-authored-by: Megamouse <studienricky89@googlemail.com>
Commit suggestion
Commit suggestion
Changed class name
Changed class name
Wrapped to a hotkey
|
Fixed CMakeLists
Fixed |
Fixed public/private
|
@Megamouse @elad335 Okay, done resolving the requested changes. Ready for another full review. |
|
Thanks for cooperation and merging |
5 participants
This change adds a hardcoded mouse-based motion sensor emulation feature, inspired by how Cemu handles mouse-driven gyro input.
While the game window is focused, holding the right mouse button enables gyro emulation:
The axis mapping and behavior were tested with the "Spark Runner" minigame in Sly Cooper: Thieves in Time and Bentley's Hackpack.
In accordance with this minigame, a top-down view motion control scheme relies on the X/Z axes.
While the right mouse button is being held, mouse deltas are captured via the Qt native event filter and accumulated in the frontend, then consumed by the pad thread.
On right mouse button release, motion values are reset to the neutral center to avoid residual drift.
This input path is intentionally independent of pad configuration and works even when a keyboard-only profile is selected.
This implementation thus resolves issue #13883 by allowing motion-only gameplay without requiring a physical motion-capable controller.