mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
jpolo1224
d1e1d9975b
Rumble did nothing in any game. Everything needed for it existed and none of it was wired to anything else. The core side was fine throughout: the virtual pad is created with CELL_PAD_CAPABILITY_ACTUATOR, its two VibrateMotors are initialised, and _rpcsx_getPadRumble reads them, so cellPadSetActDirect had somewhere to land. Above that, three dead links in a row. The pump that polls getPadRumble and drives the phone's vibrator was written and never started -- startRumblePump had no callers at all. The core cannot notify the JNI layer when the guest writes the motors, so with nothing polling, no guest rumble could ever reach the device. It now runs for the VM's lifetime, started once the emulator is past boot and stopped in a finally, so the abnormal-teardown path that exits via stopRequested cannot leave the motor buzzing on whatever value a dead guest last wrote. The enable flag was two flags. NativeApp.sRumbleEnabled had three writers -- the settings toggle, the in-game menu and app start -- and no readers. The pump consulted a private copy in Rpcs3Bridge that only setPadVibration wrote, and setPadVibration had no callers either. So the toggle wrote one store and the pump read another. There is one flag now; the private copy is a read-only accessor onto it. Rumble is polled on port 0 only. The device has one vibrator, so there is nothing to spend a second port on.