Closes#18856
Moved the three download database actions from the game list context
menu to Manage -> Databases submenu, since they are not related to a
specific game entry.
The "Dirty hack for sound" in AudioSetNotifyEventQueue() is gated on a
named constant c_mxr000 that is supposed to equal the IPC key of the
_mxr000 event queue created by the game's _cellsurMixerMain thread
(0x8000cafe02460300, e.g. Virtua Fighter 5 FS / SEGA AM2 CRI titles).
When the inline literal was refactored into the named constant in
730badd37 ("cellAudio: Move and partially fix _mxr000 hack", 2023) a
trailing hex digit was dropped: 0x8000cafe0246030 instead of
0x8000cafe02460300 (the value used by the original 2018 hack in
cc0d7c598). As a result `key == c_mxr000` never matches and
lv2_event_queue::find(c_mxr000) looks up the wrong key, so the
surmixer-queue serialization path is effectively dead for every
_mxr000 CRI game.
Restore the correct 16-digit key so the gate and lookup match the
queue the game actually creates.
Note: this corrects a real latent bug but does not by itself resolve
the cellSurMixer null-deref in VF5FS (#17066), which is a separate,
flaky CRI channel-strip init divergence.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The PPU/SPU recompilers emit i8mm intrinsics (ummla/smmla, used by the
SPU GBB/GBH gather paths) gated on utils::has_i8mm(). The JIT's MAttrs
list mirrored dotprod/sha3/sve from HWCAP but never added i8mm, and the
resolved -mcpu on Apple silicon is the cortex-a78 fallback (no i8mm), so
the backend aborted with "Cannot select: intrinsic %llvm.aarch64.neon.ummla"
on every game. Mirror i8mm into MAttrs like the other features.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
(cherry picked from commit 52d121fee79cc569c9ac273852edd0e493ae51fc)
This adds a dropdown in the emulated G27 settings dialog ("Force
feedback direction encoding") with three options: Steering Axis
(default), Cartesian, Polar. Default is Steering Axis so existing users
see no change.
RPCS3 right now hardcodes SDL_HAPTIC_STEERING_AXIS for the spring and
constant-force effects it sends to the host wheel. That's SDL's
recommended encoding for wheels and works on the hardware the code was
written against. Some Windows DirectInput drivers (like my MOZA R3) do
not react to these affects at all. This now allows changing it to an
encoding that works.
- Compiles down to just 2 instructions on Neon, instead of falling back to scalar instructions
- Remove this workaround when LLVM fixes this issue upstream: https://github.com/llvm/llvm-project/issues/200325
