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 13,000 builds of RPCS3! With so many builds available, it's natural that users have a few questions about them. Let's look at the most common ones below:

Which is the best build of RPCS3?

For the majority of users, the latest master build is the best to use for everything. Using the latest master ensures users are taking advantage of the latest improvements and bug-fixes offered by the developers. It also allows for the best compatibility as the latest versions will be optimized for new hardware revisions and operating system updates.

The only exception to the above statement would be when a regression is present i.e. the game previously worked on the emulator but no longer works due to a bug that was introduced later.

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:

1. Download the latest master version from the RPCS3 website
2. Extract all files from the archive to your current RPCS3 install folder
3. When prompted, 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:

1. Download the build you intend to from the build archive
2. Extract only the rpcs3.exe, then rename it to rpcs3.<version>.exe or to anything except for rpcs3.exe
3. Place this exe into your current RPCS3 install folder

This method allows you to use older versions of RPCS3 from within your pre-exsisting RPCS3 folder allowing your games, firmware, saves, etc to be used without reinstallation. If you see a QT-related error message, copy all folders present inside qt\plugins\ to your 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 they are merged into the master build, you can do this using the method mentioned below:

• Go to the specific pull request's page
• Scroll to the Checks message
• Click on Show all checks link next to the ✅ green check
• Click on Details link next to your OS. (image example Windows)
• Click on View more details on Cirrus CI link
• In the Cirrus site, click on Artifact under the heading Artifacts
• Download Artifact

• 

  Scroll to the Checks message

• 

  Click on "show all checks"

• 

  In the Cirrus site, click on "Artifacts"

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.

1. Find a build that has the regression (generally latest master build) and name it bad
2. Find an older build where the regression does not exist and name it good
3. 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)
4. 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

5. 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.