Help:Using different versions of RPCS3
In this guide, we'll go over which are the best RPCS3 builds (versions) to use and where to find them. RPCS3 is an open-source project, hosted on GitHub, that follows a rolling release system. This means that every time a new pull request is merged on GitHub with an improvement or fix, a new build for RPCS3 is generated and given a unique identifier number. Over the course of the many years of the emulator's development, there are now over 1,800 builds of RPCS3! With so many builds available, it's natural that users have a few questions about it. Let's look at the most common ones below:
Which is the best build of RPCS3?
For the majority of users, using the latest master build is the best course of action. Using the latest master ensures that users take advantage of the latest improvements and bug-fixes made by the developers. It also allows for the best compatibility as the latest versions will be optimised for new hardware revisions and operating system updates as well.
The only exception to the above statement would be in the scenario where a game regression is present i.e. the game previously worked on the emulator but no longer works on the latest master due to a bug that has been introduced down the line.
How to update my version of RPCS3 to the latest master build?
To update your current version of RPCS3 installed on your computer to the latest version:
- download the latest master version from the RPCS3 website
- extract all files from the archive to your current RPCS3 install folder
- when asked, confirm that you want to overwrite and replace all files
Don't worry all your settings, installed games, and save data will not be touched
How to downgrade my version of RPCS3 to the an older build?
In certain rare occasions, newer builds may have game regressions or bugs that were not present in older builds. Or you may simply wish to test an older version of the emulator. In such cases, you need to downgrade your current RPCS3 installation in the following manner:
- download the build you intend to from the build archive
rpcs3.exeonly, then rename it to
rpcs3.<version>.exeor to anything you prefer
- put this exe into your current RPCS3 install folder
This way you will be able to use older versions of RPCS3 in the existing installation folder and easily run the games already present. If you see a QT-related error message, copy all folders present inside
qt\plugins\ to the main RPCS3 folder.
How to download builds from a pull request on GitHub?
If you wish to try the changes made in a pull request before it is merged into the master builds, you can do using the method mentioned below:
- Go to the specific pull request's page
- Click on the Commits tab
- Click on the ✅ at the bottom (always click on the bottom-most green check mark)
- Click on the details link next to the first Azure Pipelines (the one with the blue 🚀) item on the list
- click on the View more details on Azure Pipelines link
- In the Azure DevOps site, click on the 2 published link under the Related column tab
- Download RPCS3 for Windows for Windows builds or RPCS3 for Linux for Linux builds
Where to find older builds?
Most recent RPCS3 builds can be found at our website's build history page (you can find a link to it in the Download tab). While this archive lists all the master builds to ever be created, it does not host all the builds. See below for the oldest version available for download on our website:
Operating System Version Date Windows 0.0.5-6906 2018-06-08 Linux 0.0.5-7644 2018-12-31
How to find the build that caused a regression?
Often games regress due to changes made to the emulator but are uncovered much later by testers. In such cases, it is necessary to find the exact build that caused the regression to effectively debug and fix the issue. However, having to test over 100 older builds to find the correct build can be a monumental task. Lucky for us, this is not necessary and easier methods are available.
For users familiar with Git and willing to compile local versions of RPCS3, git bisect can be used to easily identify the offending commit. However, all other users can also follow a similar approach by using the builds available at our build archive.
- Find a build that has the regression (generally latest master build) and name it bad
- Find an older build where the regression does not exist and name it good
- Find a build released in between the good and bad build (for example, if the good build is from January and the bad build is from July, find a build that was made released in April)
- Test this build to see if the regression is present:
- If the regression is present, name this new build as bad
- If the regression is NOT present, name this new build as good
- Repeat Step 3 and 4 with the new build until you narrow it down to the build where the regression first appeared
Using this method, users can easily skip avoid testing every build in favor of testing builds at specific intervals between the original builds.