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
This is a continuation of my work on #18113.
Addresses issue #18197.
Adds a new checkbox in the I/O settings tab that enables mouse-based
gyro emulation at game startup, making the feature more discoverable to
users.
Two small fixes that stop the emulator from writing past buffer
boundaries.
RawSPU: when loading a program onto an SPU processor, it now checks that
the program actually fits in 256 KB before copying it. Before this, a
corrupted file could write past the buffer into random host memory.
PPUInterpreter: a one-character typo fix. A modulo operation used % 127
instead of % 128 when computing cross-boundary data sizes. This caused
reservation checks to compare the wrong number of bytes on every load
that crossed a cache line. This fix was pointed out by @AniLeo in the
spam PR #18795 (Discovered by Opus 4.7)
The PS3 hardware enforces these limits:
- Each SPU has exactly 256 KB of memory (from Cell Broadband Engine
Handbook v1.1)
- The PPE cache line is 128 bytes — all reservation logic uses this
granularity
Neither fix should affect the usual games. They only applying to
corrupted or malformed files. Will highly appreciate feedback and
suggestions for this PR
Tested on CI: CI passes on my fork 9 of 10 platforms (Mac Intel failed
downloading a dependency).
Title and Desc written by Codex
- Some SPU programs inexplicably fail to compile when TBL2/TBX2 are used.
- As an insane workaround, first try to compile with TBL2/TBX2, if LLVM crashes while compiling, try to compile the same program without TBL2/TBX2.
- Saves 2 instructions in MPY, 1 instruction in MPYU, 2 instructions in MPYS, 2 instructions in MPYA, 1 instruction in MPYI, and 2 instructions in MPYUI
- Fragment state just reloads some constant buffers.
- Fragment program state recalculates the program.
- This is overkill for a variant reload, but that can be optimized later.
I observed under macOS (although the bug seems platform agnostic to me)
that when restarting a game, then subsequently quitting it, I'd get
stuck in a 'restart loop' where the game would restart upon completely
shutting down, and this would repeat every time I tried to close the
game until I gave up & force quit RPCS3. Seems like for whatever reason,
the use of std::move didn't actually guarantee that after_kill_callback
got nuked if at all, so all I've done is take a hammer to the fucker and
manually set it to nullptr after being called.
Co-authored-by: Elad <18193363+elad335@users.noreply.github.com>
The shuffle in step_track() used std::default_random_engine with a
default (fixed) seed, causing the playlist to be 'shuffled' into the
same deterministic order every time. Use std::random_device to seed the
engine so each shuffle produces a genuinely random order.
Fixes#18672
Users frequently close the game list accidentally and then can't
figure out how to restore it. Remove the DockWidgetClosable feature
so the close button is not shown. The game list visibility can still
be toggled via View > View Game List menu action.
Fixes#18518
## Summary
Fixes the GUI language dropdown to show territory variants when
translation files include country codes.
**Before:** "Portuguese" for both `pt_BR` and `pt_PT`
**After:** "Portuguese (Brazil)" and "Portuguese (Portugal)"
Also fixes the same ambiguity for Chinese and any other language with
country variants.
## Implementation
Uses `QLocale::territoryToString()` alongside the existing
`QLocale::languageToString()` to construct display labels. When no
territory exists (e.g., `en`, `ja`), the label is unchanged.
## Edge cases
- No-territory locales (`en`, `ja`): unchanged —
`QLocale::territoryToString(AnyTerritory)` returns empty, guard
preserves plain language name
- Territory names are locale-translated (not hardcoded English) — they
follow the current UI language, same as `languageToString()`
- `zh_CN` → "Chinese (China)" / `zh_TW` → "Chinese (Taiwan)"
(territory-based, unlike the PS3 system language dropdown which uses
Simplified/Traditional script names — this is appropriate for the GUI
translator selector context)
## Test Plan
- [ ] Language menu shows "Portuguese (Brazil)" when `rpcs3_pt_BR.qm` is
present
- [ ] Language menu shows "Chinese (China)" when `rpcs3_zh_CN.qm` is
present
- [ ] Plain languages (`en`, `ja`) continue to show without parens
---
<details>
<summary>Review note: territory strings in UI locale</summary>
Territory names render in the current UI language (not forced English).
This matches `QLocale::languageToString()` behavior and is consistent
with how the rest of the menu renders. If hardcoded English labels are
preferred, that can be added after review.
</details>
Fixes#18215
Address review feedback on #18701 (cc @elad335): combine the SPU
worker fix from #18701, the SPRX Loader fix from #18703, and three
additional similar W^X leaks discovered while auditing the codebase
for the same pattern. Use Allman-style braces to match RPCS3 coding
style.
Background:
On AArch64 Apple Silicon, MAP_JIT pages enforce W^X per-thread.
pthread_jit_write_protect_np(false) enables write mode and
pthread_jit_write_protect_np(true) restores execute mode. When code
takes an early return or throws between these calls, the thread is
left in write mode, which can cause segfaults on subsequent code
fetches or inconsistent state at thread teardown.
Fixes applied (all gated on __APPLE__):
1. Emu/Cell/SPUCommonRecompiler.cpp - SPU cache worker thread
Add RAII guard so execute mode is restored on worker exit.
2. Emu/System.cpp - SPRX Loader thread
Enter write mode (was missing entirely) so ppu_initialize() and
ppu_precompile() can write to MAP_JIT pages, and pair with an
RAII guard. Reproducer: Red Dead Redemption (BLUS30418) crashes
~12s into boot at 0x300010000 without this fix.
3. Emu/Cell/SPULLVMRecompiler.cpp - SPU LLVM compile path
The compile function enters write mode, then has an early
"return nullptr" path on rebuild_ubertrampoline failure that
skipped the explicit restore. Add RAII guard so execute mode
is restored on every exit path. The existing explicit restore
before the cache-flush asm directives is preserved.
4. Emu/Cell/PPUThread.cpp - PPU LLVM worker thread (operator())
Worker entered write mode but never restored it on operator()
return. Add RAII guard.
5. Emu/Cell/PPUThread.cpp - ppu_initialize() main path
This scope alternates write/execute mode and contains an early
"return compiled_new" at the empty-jits check plus a final
return that both leak write mode. Add RAII guard so execute
mode is always restored on exit. Intermediate explicit
transitions for the symbol-resolver invocation are preserved.
No behavioral change on x86_64 or non-Apple ARM64 (all changes are
inside #ifdef __APPLE__ / #if defined(__APPLE__)).
Supersedes #18703.
## Summary
The "Left" and "Right" strings in `pad_settings_dialog` were shared
between DPad/Stick direction labels (which have ample space) and offset
value labels — Squircle Values, Stick Multipliers, and Stick
Interpolation (where space is tight). Translators couldn't abbreviate
the offset version without also affecting the direction binding labels.
## Change
Added disambiguation via `comment="Offset direction"` in the `.ui`
file's `<string>` elements for the six offset labels:
- `label_squircle_left`
- `label_squircle_right`
- `label_stick_multi_left`
- `label_stick_multi_right`
- `left_stick_lerp_label`
- `right_stick_lerp_label`
Qt now generates separate translation entries, allowing translators to
use shorter abbreviations in the tight offset areas while keeping full
forms for direction bindings.
**English UI is unchanged** — no visual difference for English users.
Fixes#18691
### FIXES + MINOR IMPROVEMENTS:
- Fixed issue18685: Not a real issue. PR18648 added some logging that made
evident a missing check on the validity of the paths in `games.yml`
before trying to manage the path as a possible ISO file. That missing
check was already present but simply invisible due to missing log
- Fixed `bytes_to_hex()` function used to store file hash hex string: In
some cases the integrity check wrongly reported the check as failed
- Optimized `fs::get_optical_raw_device()` function: Moved under
`_WIN32` block a check valid only on `Windows` and simplified the logic
to detect a CDROM / BD as raw device
- Used `iso_file` objects instead of `fs:file` in `ISO.cpp`: It allows
to use proper `bool()` operator on some checks
- The main thread may bind the program before the compiler context has published the binding instructions
- Once bound, late bindings are not updated so the program remains with uninitialized bindings and rendering breaks
Fixes regression from #18546 and #18679.
## Problem
The is_from_yml ISO branch constructed iso_archive unconditionally,
bypassing the cache check inside add_game, making the cache write-only
for yml-sourced ISOs.
## Fix
Added a lightweight index cache entry (iso_path + "//index") storing the
subdir list + mtime. On hit, skips archive construction entirely. On
miss, walks as before and writes the index
Append to `CMAKE_PREFIX_PATH` and `CMAKE_SYSTEM_PREFIX` instead of using `include_directories()` and `link_directories()`.
This avoids include/link path
pollution and reduces clashes with vendored dependencies. This means that conflicting homebrew packages no longer have to be unlinked to build rpcs3, as system paths are searched last.
0.85 elfs break here due to them not having a version header offset.
Very unlikely these elfs will ever load but its useful to be able to decrypt them at least.
Co-authored-by: Elad <18193363+elad335@users.noreply.github.com>
Follow up of #18345 to add support (currently only on `Windows`; see
notes below) for playing a PS3 disc game directly from a Blu-Ray Disc
Drive.
### HOW IT WORKS:
- The BD drive can be added as any other game so from `VFS games` or
from `Add Games` menu. In case it is selected from `VFS games`, any
attempt to write files is discarded, e.g. file `Disc Games Can Be Put
Here For Automatic Detection.txt`
- It scans the default redump keys folder `<rpcs3>/data/redump` (it
currently needs to be manually created due it is not yet provided by
rpcs3 installation) to find a matching decryption key
### NOTES:
- Support is currently provided on `Windows` where I can fully test it.
I cannot test under other OS. However, the additions needed for the
other OS are limited only on `fs::file.h/cpp`. In particular inside the
following new functions:
- `bool is_optical_raw_device(const std::string& path);`
- `bool get_optical_raw_device(const std::string& path, std::string*
raw_device = nullptr);`
- Icons etc. are always refreshed (ISO cache cannot be used due `mtime`
on raw device is not available and any cache check would always fail)
- Code in `ISO.h/cpp` needed some rework to properly manage a read on a
raw device (alignment on offset, size and memory is mandatory). The BD
drive needs to be detected as a file, not as a folder
### MINOR FIXES:
- Fixed wrong specifier used in logging on `ISO.h/cpp`
The passthrough path was fake-completing zero-length bulk/interrupt IN
URBs to mirror the emulated path, so games that drain-poll between
transfers wouldn't stall the libusb worker thread. This baked an
emulator-side assumption about device behaviour into the host stack.
Real PS3 USIO devices issue a ZLP on the read endpoint after any
transfer that would otherwise leave the host's drain URB outstanding
(notably after a CMD_WRITE). Devices that follow the same protocol
(e.g. ITAIKO firmware) are expected to do the same; faking it here
masks firmware bugs and diverges from real hardware behaviour.
Drop the workaround and let libusb submit the URB normally. The IN
URB now completes when the device sends its ZLP, matching real PS3.
Refs: https://github.com/RPCS3/rpcs3/pull/18636#discussion_r3143290987
The PS3 USB stack routes both bulk and interrupt requests through
usb_device_passthrough::interrupt_transfer. The old code unconditionally
called libusb_fill_interrupt_transfer regardless of the endpoint type,
which on Linux's usbfs backend is rejected with EINVAL whenever the URB
type doesn't match the endpoint's bmAttributes. Reads against bulk IN
endpoints therefore never completed and the worker thread stalled.
Look up the endpoint descriptor and dispatch to libusb_fill_bulk_transfer
when bmAttributes indicates bulk. A new usb_device::find_endpoint helper
walks the descriptor tree once per submission.
Confirmed broken on Linux and working on Windows pre-fix; macOS
untested. WinUSB silently accepts the type mismatch, which is why this
went unnoticed. Reproduces with any passthrough device that has a bulk
IN endpoint, e.g. a Bandai Namco USIO (0b9a:0910) under Taiko no Tatsujin
S111 [SCEEXE000]: the game's boot-time the I/O board check runs and then hangs.
Two related defensive fixes uncovered while debugging the above:
- Zero-length bulk/interrupt IN URBs hang in libusb until the device
sends a ZLP. The emulated path fake-completes them immediately; mirror
that here so drain-polls between transfers don't stall the worker.
- An unexpected libusb_submit_transfer error used to leave
UsbTransfer::busy = true forever. Mark it as a fake completion with
EHCI_CC_HALTED so the USB manager processes the failure cleanly
instead of deadlocking the request.
The color/depth alias collapse heuristic at get_framebuffer_layout()
picks depth whenever depth_test_enabled or stencil_test_enabled is set.
But test means read, not write - so deferred renderers that run a
Z-prepass and then a G-buffer pass with depth-test ON, depth-write OFF,
color-write ON get classified as a depth pass even though they're
writing color. The color writes get silently dropped.
In Starhawk this killed every lit surface - characters, skybox, anything
that goes through the deferred lighting path rendered black or
invisible. Terrain, particles, and emissive geometry kept working
because they don't go through that same pipeline.
Fix is to check writes instead of tests:
if (zeta_write_enabled && !color_write_enabled)
keep_as_depth(); // Z-prepass, shadow gen
else
keep_as_color(); // G-buffer / lit pass
For the both-writes case I went with color since losing color is much
more obvious visually than losing depth (the engine's Z-prepass usually
still has the depth around).
Tested with Starhawk [BCUS98181] in menu and gameplay - before: missing
characters and sky. After: matches PS3 reference. Logged every aliasing
event during a couple minutes of gameplay and they were all the G-buffer
pattern (depth-test ON, depth-write OFF, color-write ON), all handled
right. The depth-keep branch wasn't actually exercised in Starhawk, but
it's there for games that do use a Z-prepass to an aliased buffer.
Fixes#11877.
The constructor inserted rows into m_list_captured_frame for the command queue but never did the same for m_list_captured_draw_calls. GetMemory()'s setItem() loop for draw calls then no-op'd on missing rows, so the Captured Draw Calls tab always appeared empty after a frame capture.
The previous approach used munmap followed by mmap without MAP_FIXED
(since Apple rejects MAP_FIXED | MAP_JIT). Between the two calls,
another thread could claim the unmapped address range, causing mmap
to return a different address and triggering a fatal verification error.
Under concurrent load (e.g. PPU LLVM compilation with many worker threads),
this race manifests reliably as "Verification failed (object: 0x0)" crashes
across all PPUW threads in memory_decommit.
Fix: Use MAP_FIXED without MAP_JIT instead. This atomically replaces the
mapping without any window for other threads to interfere. The MAP_JIT
attribute is lost on the replaced pages, but the application's code signing
entitlements (allow-unsigned-executable-memory, disable-executable-page-protection)
permit executable mappings without it.
Applied the same fix to memory_reset which had the identical pattern.
Replaces the plain text "Show Details" changelog in the update dialog
with a QTextBrowser that converts PR references like (#1234) into
clickable GitHub links.
**Why? :** Easy to check PRs you are interested in beyond the title.
Switch from API to direct download.
Fixes 403 error code.
jammy-aarch64 needs `unzip` from universe in the Dockerfile.
eg:
```
add-apt-repository universe
apt update -qq
apt-get install -y unzip
```
Fixes https://github.com/RPCS3/rpcs3/issues/18560
Every launch constructs a fresh iso_archive for each ISO game, which
calls iso_form_hierarchy() and walks the full directory tree. On top of
that, qt_utils opens a second iso_archive just for icon loading, so
every ISO game ends up doing two full directory tree walks on every
launch.
This adds a metadata cache keyed by ISO path + mtime stored under
fs::get_config_dir()/iso_cache/. Each entry stores the raw SFO binary,
resolved icon/movie/audio paths and raw icon bytes.
- On cache hit, iso_archive construction is skipped entirely for both
game list scanning and icon loading
- On cache miss archive is scanned as before and the result is persisted
to disk
- Cache is automatically invalidated when the ISO file's mtime changes
Tested with a decrypted PS3 disc ISO (God of War III):
- First launch writes cache files correctly to iso_cache/
- Second launch reads from cache with correct title and icon
- touch game.iso correctly invalidates the cache and triggers a rescan
fix compile errors and suppress minor warnings
strip minor bug fixes and cleanup
minor cleanup
minor cleanup
Fixed crash at boot parsing an ISO with a empty directory entry at file head
applied suggested changes
added missing break in switch
Update rpcs3/Loader/ISO.cpp
Co-authored-by: Megamouse <studienricky89@googlemail.com>
use hex_to_bytes() instead of self made functions
minor cleanup
rewrite nested if()
add explicit support to .key
minor cleanup
optimize partial sector read
minor optimization
fix conflict
On Apple ARM64, memory_reserve unconditionally applies MAP_JIT to all
reservations. However, regions marked as is_memory_mapping are later
replaced by file-backed MAP_FIXED mappings via shm::map/map_critical.
Overlaying a file-backed MAP_FIXED mapping onto a MAP_JIT region causes
the resulting pages to be inaccessible, leading to a segfault when the
SPRX Loader attempts to write module data into PS3 memory (g_sudo_addr).
Fix: Only apply MAP_JIT for non-mapping regions. Memory mapping regions
don't need JIT capability since they use shared memory for the PS3
address space, not executable JIT code.
Tested on Apple M3 Max, macOS 26.3.1. The SPRX Loader now successfully
loads all modules and emulation proceeds past the loading stage.
- If only the threshold changed or the surface is below threshold anyway, nothing will change
- In those cases, just update the internal data and continue
- Delays demuxing a bit to let the game finish initializing FMV
playback.
- Also includes the missing half of #18450 which I forgot to Commit ^^"
- Sets cellDmuxPamf to HLE by default again
- Can introduce dfdx/dfdy discontinuities on the midline as the distance changes direction
- The seams can sometimes become visible if a border is applied on some GPUs
- If the radius exceeds any half-dimension then the box-shrink subtraction yields a negative.
That negative introduces a second transition boundary when the classification happens as it transitions back to positive.
Normally not a big deal but when rendering borders at the transition points it can introduce artifacts.
- If there is no IF block but ELSE block exists, treat the branch as being inverted and the ELSE block as the main IF body
- Rare but seen in some games
We need to initialize the emu callbacks before creating the main window.
Otherwise CallFromMainThread segs since call_from_main_thread is null.
The same goes for the CallFromMainThread connect in gui_application.
If we create the connection too late, we will simply never wake up the
caller and therefore softlock eventually.
We were basically writing two rows into dst for each other src line.
This means we were writing 480 lines in total instead of 240,
overwriting one of the lines written in the previous iteration.
This led to writing one line out of bounds last iteration.
Let's just use a simple debayer technique which perfectly matches here.
This also applies the previously missing gain factors.
I also tried to first demosaic and then drop every other pixel.
The result was comparatively blurred and the performance worse.
From https://releases.llvm.org/22.1.0/docs/ReleaseNotes.html:
The alignment argument of the @llvm.masked.load, @llvm.masked.store, @llvm.masked.gather and @llvm.masked.scatter intrinsics has been removed. Instead, the align attribute should be placed on the pointer (or vector of pointers) argument.
They also changed(not in changelog for some reason):
vpdpbusd_128: [v4i32] -> [v4i32, v4i32, v4i32]
to
vpdpbusd_128: [v4i32] -> [v4i32, v16i8, v16i8]
-CallFunction empty function/jump elision was never gone through as cond was always false
-MSelf duplicate offset detection never triggered because set was reset each loop
-Rel executable memory size calculation used wrong section type
option(protobuf_DISABLE_RTTI"Remove runtime type information in the binaries"OFF)
option(protobuf_FORCE_FETCH_DEPENDENCIES"Force all dependencies to be downloaded from GitHub. Local installations will be ignored."OFF)
option(protobuf_LOCAL_DEPENDENCIES_ONLY"Prevent downloading any dependencies from GitHub. If this option is set, the dependency must be available locally as an installed package."OFF)
@@ -20,27 +20,27 @@ The following tools are required to build RPCS3 on Windows 10 or later:
with standalone **CMake** tool.
- [Python 3.6+](https://www.python.org/downloads/) (add to PATH)
- [Qt 6.10.2](https://www.qt.io/download-qt-installer) In case you can't download from the official installer, you can use [Another Qt installer](https://github.com/miurahr/aqtinstall) (In that case you will need to manually add the "qtmultimedia" module when installing Qt)
- [Vulkan SDK 1.3.268.0](https://vulkan.lunarg.com/sdk/home) (see "Install the SDK" [here](https://vulkan.lunarg.com/doc/sdk/latest/windows/getting_started.html)) for now future SDKs don't work. You need precisely 1.3.268.0.
- [Qt 6.11.1](https://www.qt.io/download-qt-installer) In case you can't download from the official installer, you can use [Another Qt installer](https://github.com/miurahr/aqtinstall) (In that case you will need to manually add the "qtmultimedia" module when installing Qt)
- [Vulkan SDK 1.4.341.1](https://vulkan.lunarg.com/sdk/home) (see "Install the SDK" [here](https://vulkan.lunarg.com/doc/sdk/latest/windows/getting_started.html)). Note that future SDKs may not work.
The `sln` solution available only on **Visual Studio** is the preferred building solution. It easily allows to build the **RPCS3** application in `Release` and `Debug` mode.
In order to build **RPCS3** with the `sln` solution (with **Visual Studio**), **Qt** libs need to be detected. To detect the libs:
- add and set the `QTDIR` environment variable, e.g. `<QtInstallFolder>\6.10.2\msvc2022_64\`
- add and set the `QTDIR` environment variable, e.g. `<QtInstallFolder>\6.11.1\msvc2022_64\`
- or use the [Visual Studio Qt Plugin](https://marketplace.visualstudio.com/items?itemName=TheQtCompany.QtVisualStudioTools2022)
**NOTE:** If you have issues with the **Visual Studio Qt Plugin**, you may want to uninstall it and install the [Legacy Qt Plugin](https://marketplace.visualstudio.com/items?itemName=TheQtCompany.LEGACYQtVisualStudioTools2022) instead.
In order to build **RPCS3** with the `CMake` solution (with both **Visual Studio** and standalone **CMake** tool):
- add and set the `Qt6_ROOT` environment variable to the **Qt** libs path, e.g. `<QtInstallFolder>\6.10.2\msvc2022_64\`
- add and set the `Qt6_ROOT` environment variable to the **Qt** libs path, e.g. `<QtInstallFolder>\6.11.1\msvc2022_64\`
### Linux
These are the essentials tools to build RPCS3 on Linux. Some of them can be installed through your favorite package manager:
- [Vulkan SDK 1.3.268.0](https://vulkan.lunarg.com/sdk/home) (See "Install the SDK" [here](https://vulkan.lunarg.com/doc/sdk/latest/linux/getting_started.html)) for now future SDKs don't work. You need precisely 1.3.268.0.
- [Vulkan SDK 1.4.341.1](https://vulkan.lunarg.com/sdk/home) (See "Install the SDK" [here](https://vulkan.lunarg.com/doc/sdk/latest/linux/getting_started.html)). Note that future SDKs may not work.
- [SDL3](https://github.com/libsdl-org/SDL/releases) (for the FAudio backend)
**If you have an NVIDIA GPU, you may need to install the libglvnd package.**
@@ -123,7 +123,7 @@ Start **Visual Studio**, click on `Open a project or solution` and select the `r
##### Configuring the Qt Plugin (if used)
1) go to `Extensions->Qt VS Tools->Qt Versions`
2) add the path to your Qt installation with compiler e.g. `<QtInstallFolder>\6.10.2\msvc2022_64`, version will fill in automatically
2) add the path to your Qt installation with compiler e.g. `<QtInstallFolder>\6.11.1\msvc2022_64`, version will fill in automatically
3) go to `Extensions->Qt VS Tools->Options->Legacy Project Format`. (Only available in the **Legacy Qt Plugin**)
4) set `Build: Run pre-build setup` to `true`. (Only available in the **Legacy Qt Plugin**)
@@ -23,6 +23,16 @@ If you want to contribute as a developer, please take a look at the following pa
You should also contact any of the developers in the forums or in the Discord server to learn more about the current state of the emulator.
### AI Use
Use of AI tools for research and reverse engineering purposes is permitted. However, contributors are expected to fully own and understand all code they submit. Any communication with the team — including code, code comments, and GitHub comments — must come from the human contributor, not an AI agent acting autonomously.
We have unfortunately seen a rise in untested and unverified AI-generated slop being submitted to this project. This wastes maintainer time and, in worse cases, such changes get merged and break functionality for all users. Repeated violations will result in a ban from the repository. Please be respectful of everyone's time.
**Pull requests opened by AI agents or automated tools must include a disclosure in the PR description** stating the scope of AI involvement — which parts were AI-generated and what human testing or review was performed prior to submission. PRs that omit this disclosure may be closed without review.
If you are unsure about your work, open a discussion issue to talk it through with the team, or reach out to a maintainer on [Discord](https://discord.gg/RPCS3).
## Building
See [BUILDING.md](BUILDING.md) for more information about how to setup an environment to build RPCS3.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.