Introduction

RPCS3 is an open source Sony Playstation 3 emulator for Windows and Linux. Currently, it has two full-time paid developers, and numerous volunteer developers. RPCS3 has existed since 2011, but development took off a year ago when the Patreon launched and Nekotekina followed by kd-11 began working on the emulator full time. This post will summarize what interesting developments and progress has happened in the last year. If you want to see how the codebase has changed over time, you can head over to the full list of merged PRs for 2017 and check it out. As seen on the GitHub statistics page we had 630 pull requests merged during 2017, and many of these contain numerous commits. That is a lot of code!

RPCS3? What Does That Even Mean?

When you think about it there is a tradition of Sony emulator names in this style. You have ePSXe, PCSX2, JPCSP, PPSSPP, and now RPCS3 as examples of PS1, PS2, PSP, and PS3 emulators. There is a story behind all of these names of course, but in the case of this little PS3 emulator it was given this name by the founder DH (who no longer works on the project). It is an abbreviation and combination of Personal Computer (PC) and PlayStation 3 (PS3). PC + PS3 = PCS3. What does the R stand for? DH and BlackDemon recollect that it used to stand for Real as back in 2011 there were only fake malware emulators around. Then at some point DH who is from Ukraine started saying the R stood for Russian which is what we roll with today as Nekotekina who joined in late 2013 and quickly became one of the biggest developers and the architect, is from Russia. So RPCS3 stands for Russian Personal Computer Station 3.

In this image of the old branding from 2016 RPCS3 is written with the Russian letter я, though this letter is in fact not pronounced like a Latin R at all (it is [ja] as in “yard”).

A short introduction

Where Were We One Year Ago?

One year ago in January of 2017 RPCS3 development had stagnated. The emulator itself ran almost no games properly, only roughly 20 titles were playable, and most of these were simple 2D games. Quite a few more did show intros or even go ingame, but due to generally very poor performance, bugs, and crashes almost nothing was really playable.

January 15th, 2017, tkoham opened an issue suggesting that RPCS3 launch a Patreon. A long discussion starting on GitHub and moving on over to a new and at the time “private” Discord channel and a few days later, the Patreon was launched. Shortly after, the Discord server went public and the new website launched. At the time, only a handful of commercial games even booted, and only the simplest of games, such as the Arkedo series, were anything near playable. The UI was unwieldy, installing games was tedious, and manually picking LLE modules was an immense challenge. Development had slowed considerably, with only Nekotekina and a handful of others making occasional commits.

Where Are We Today?

Where to even begin? In the past year, we’ve seen colossal compatibility improvements, auto-LLE, the PPU LLVM recompiler overhauled, vast improvements to both HLE and LLE modules, a UI overhaul, implementation of saves and trophies, a new website and forums, high resolution rendering support, graphics renderer improvements, and many others that will be covered here. We’ve seen both Nekotekina and kd-11 come on as full time developers, and far more active volunteer developers than there were a year ago. In one year we went from some 20 playable games to at the time of writing 699 playable games!

The More Detailed History of RPCS3 Development During 2017

Below we will take a close look at some key developments that took place during 2017. This is not a complete listing of everything that took place, far from it. The individual progress reports on this blog covers a much wider range. However below the most major or interesting developments are covered in detail.

New Website, Blog, Forums, Compatibility Database, Branding, and More From Web Developers and Designers DAGINATSUKO & Ani

In January of 2017 as the discussion regarding the Patreon was going on, a user named DAGINATSUKO came along and offered to give RPCS3’s website a makeover. The quickly assembled WordPress based website RPCS3 was previously using looked “not great” in diplomatic terms. For some reason it literally used the dreaded comic sans font in places. Thanks’ to DAGINATSUKO’s hard work, rpcs3.net was made to look sleek, professional, and most important, useful. The QuickStart guide provided a go-to place to direct new users for initial set up, the about page allowed developers to introduce themselves, and the blog allowed for the publishing of the progress reports. It also contained links to the Patreon and the GitHub repository for those interested. While rpcs3.net is under constant improvement the most impressive thing is that DAGINATSUKO more or less started work on the initial version of the site and had it live in less than 48 hours!

The new RPCS3 website by DAGINATSUKO the day it was launched.

Once RPCS3 had a website worth using, Ani decided it was time to convert the somewhat haphazard compatibility list from the old emunewz forum in to a proper database of games, including links to threads and last known tested and working build numbers and links to those builds. At this time, there were not that many games tested with RPCS3, and games that did not work at all (so most games) were not even listed on the forums at this time. So compatibility database entries had to be added by hand by editing the database! However more and more functionality was added to the compatibility database over time, and later during the year Ani had the list compacted so that games with multiple IDs were listed together, game entries would update automatically based on the forum (a badly needed feature as the number of tested and to some degree working games exploded), and the list could be filtered by media type and compatibility category. He also added a history, showing which games moved each month, and a build history for master builds.

As many of these improvements were made, it became clear that RPCS3 needed dedicated forums. Some of the main reasons behind this were to enable integration with the compatibility list and the eventual wiki, as well as bringing the forums up to the same modern look as the rest of the website. All posts and threads were kept during the move, though new accounts had to be created and post histories transferred manually by administrators. The old forums over at emunewz.net had served us very well, ever since the beginning days of RPCS3 when it could only run Hello World level homebrew. Some of the people who were with RPCS3 since the very beginning came from the JPCSP project which also had its official forums at emunewz. However the move over to a dedicated forum doesn’t mean we cut all ties from emunewz, far from it! rpcs3.net and emunewz.net are in fact hosted on the same servers, owned by shadow with one s, who also founded emunewz back in the day, and later worked on JPCSP. Small world!

Throughout all of this, RPCS3’s administrators created a Twitter account, a YouTube channel, and a subreddit, with the goal being to expand the audience for the emulator, and to let people know that RPCS3 was a real, working PS3 emulator and not just another scam. Run by ssshadow and Ani, these efforts have yielded a growing community of users testing games, submitting reports and screenshots, and even contributing to the RPCS3 codebase. With these efforts RPCS3 has been mentioned by numerous outlets, even really big and respected ones like Ars Technica. On our YouTube channel we got 18 000 subscribers and the most viewed video, seen below, has over 406 000 views!

In fact our social media presence and popularity with users exploded to such a degree that even Atlus-senpai noticed us.

Improved PPU LLVM Performance, Compatibility, and Compilation times

What is a “PPU LLVM Recompiler”? To begin it’s important to note that the PlayStation 3 processor called Cell is a complex piece of hardware that essentially has two different types of CPU cores: One PPU core with simultaneous multithreading (what Intel would call Hyperthreading) and six SPU cores that games use, which among many interesting features have vector registers, something Intel and AMD would introduce with the AVX extension in 2012 with Sandy Bridge and Bulldozer. The PPU core of the Cell processor is for all intents and purposes quite ordinary CPU core that the main code of a game would run on. The PPU LLVM recompiler uses a fantastic piece of software called LLVM to translate PPU code into an intermediary LLVM representation that is then finally translated, and optimized, into native Intel/AMD code. And all of this is done ahead of time (AoT), before the game starts! The idea here is to get near native performance in PPU code execution and today that goal is pretty much reached. In simpler games with no SPU or graphics bottlenecks this recompiler is capable of reaching hundreds, sometimes thousands, of frames per second. For example Atelier Escha & Logy runs at an unlocked frame rate and can be played at an actual 120 fps sometimes on a fast CPU.

Atelier Escha & Logy running at over 100 fps thanks to the PPU recompiler.

But the PPU recompiler was not always this amazing. In January of 2017 compatibility was very hit and miss and it only worked for maybe half of all games, and not many games worked in general anyway back then. Even when it worked performance was not that great, you would be happy if you saw even 20 – 30 % higher frame rate. This relatively small increase in performance was a combination of the PPU recompiler not being well optimized yet, and mainly because there were a lot of bottlenecks elsewhere.

But by far the worst thing about trying to use the PPU recompiler back in January of 2017 was that:

• The recompiled game code was not saved to disk! Every time the game was started the whole compilation process would have to done from scratch again!
• Compilation was slow. Like really slow. It was entirely single threaded and also attempted to compile all PPU code at once meaning memory usage of rpcs3.exe alone could reach some 6 – 7 Gb with bigger games. Forget about even trying to use it with less than 8 Gb of system memory and everything else closed down.
• Compilation took forever, sometimes 20 minutes. There was no progress dialog or really any kind of feedback whatsoever. The whole RPCS3 window froze during the process. Your only indication of it seeming to do anything was the slowly increasing memory usage in task manager!
• Compatibility was very bad. After waiting for half an hour for the game to recompile you would often see it crash in no time.
• Also it didn’t work on Skylake. At all. Fun times.

Thanks to fantastic work by Nekotekina; today the recompiled game code is saved to disk and loaded near instantly. Compilation is extremely fast since it is fully multi threaded. On a Ryzen 7 with 16 threads it literally takes less than 30 seconds with most games. Memory usage is a fraction of what it used to be, never really going above about 1 Gb. And there are progress dialogs! Most importantly, compatibility is fantastic, off the top of my head there is only a single game where it still doesn’t work and the interpreter has to be used: The PS3 version of Oblivion.

The improved LLVM based PPU recompiler compiling 16 blocks of code at the same time on a Ryzen 7 CPU.

Speaking of compatibility, during May and June of 2017 Nekotekina spent a great amount of time to greatly re-engineer how the recompiler works and it was with this that game compatibility went from very hit and miss (mostly miss) to near perfect. Followers of RPCS3 will remember this change as “LLVM libfiber”. The original goal was to make this PS3 operating system module (libfiber.sprx) work the recompiler (remember, that certain unnamed game needed it). This task estimated to take two or three days opened a can of worms and basically ended with “LLVM Recompiler 2.0” more than a month later. But it was totally worth it thanks to the compatibility and performance improvements.

Full Linux Support

Ever since the project started in 2011 the usage of open standards like using OpenGL for the renderer had been considered to make RPCS3 easier to port to more platforms than Windows where development was started. And indeed at some point in time (it is hard to say exactly when, but around 2015 work was completed) RPCS3 was ported to Linux and ran the same games as it did on Windows (so basically only Disgaea 3 and Arkedo at this time). However RPCS3 had very few people even testing it at this time, and no one in this small handful of testers and developers were actively using Linux, so during 2016 RPCS3 on Linux fell into disrepair.

When Nekotekina went to work on RPCS3 in January of 2017 absolutely nothing worked when running RPCS3 on Linux. The project would compile, but nothing more, it crashed instantly when starting and didn’t even show the interface. Nekotekina fixed various things over time, taking RPCS3 on Linux from nothing to almost perfect. Later kd-11 worked on enabling the Vulkan renderer on Linux, and contributor kirbyfan64 added controller support via evdev. Most work was actually done quite early in the year, but yet we could only provide automated Linux builds in the form of AppImages in late July. There were two somewhat related problems that no one, and many people tried, could fix for the longest time. To make the LLVM recompiler work on every system, and especially to make it work when RPCS3 was packed into an AppImage format. Not even Nekotekina who made the LLVM recompiler and actually uses Linux (now as his main OS) could figure this one out. The technical problems here are basically unexplainable. In the end it would be contributor hcorion who solved every LLVM and AppImage problem in one go, not by changing a line of code, but by compiling RPCS3 and LLVM with a very special and obscure compiler flag he literally found in a StackOverflow answer! Today RPCS3 on Linux is a first class citizen and has complete feature parity with RPCS3 on Windows. We provide AppImages that work on every Linux distribution with no additional setup needed. The user can simply get the latest version from our download page and run it, even on old distributions like Ubuntu 14.04 LTS it will just work. You can check out the original announcement of full Linux support here.

RPCS3 running Nier on Linux with the Vulkan renderer.

Reservations Rewrite

This was perhaps the first major task Nekotekina worked on during January and February of 2017. All multi threaded software, and PS3 games are often very well multi threaded, use various “controls” to ensure that different threads stay in sync with each other. After much work Nekotekina had more of a reservations re-re-rewrite but the result was stunning. Great performance improvements across all games, many literally an order of magnitude faster. If a certain scene in “a certain game” was 1 fps before it became 10 fps after the reservations rewrite. This is perhaps to this day the greatest general performance improvement ever committed in one go like this.

The “Arkedo Fix”

In January and February RPCS3 compatibility was terrible. Almost nothing was playable and many games simply didn’t do much more than perhaps showing a logo at best. Even when some game would go ingame it would quickly crash or hang or exhibit very strange bugs. For example every single game using PhyreEngine that booted at this time would quickly go into an endless loop. Take a look at this literal endless loop in Ar Tonelico Qoga below:

That video is not edited in any way, often scripted event in this game, and every other game using this engine (there are many) would get stuck in some endless loop like this.

When it comes to development crashes are relatively easy to debug, you know exactly where the program stops and what happened leading up to that point. This is more or less also true if a game hangs. But if the game runs, keeps running, and the emulator itself keeps running, but some scripted event in the game behaves strangely? Good luck fixing that.

Many people ask questions like “Why don’t you fix The Last of Us”? The answer is complicated, but here is an analogy: “Build the Airbus A380”. One does not simply build an airplane like that, instead thousands upon thousands of individual components are built first, tested individually, and finally assembled and tested even more. If a very high end complex game like the Last of Us is the completed A380, Ar Tonelico Qoga above is some individual core mechanical parts of it, and a very obscure 2D game called Arkedo 01 is a tray table. Arkedo 01 (and 02) were the very first commercial games to go ingame with RPCS3 back in early 2014! But back in January and February of 2017 Arkedo 01 would randomly hang after a few minutes. So Nekotekina was in charge of figuring out why. Because if such a simple game isn’t working, what chance does more advanced games have? After debugging for a few days Nekotekina figured out why: there was a severe PPU bug that essentially made RPCS3 count time incorrectly. This of course fixed Arkedo 01, but it also fixed hundreds of other games at that time. The endless looping in Ar Tonelico Qoga and every other PhyreEngine games was fixed as well. Really, this bug affects almost every game, no matter if they worked at the time or not for other reasons as well. Now with these core components improved, the precision needed to make something as complex as The Last of Us run is closer as well.

Arkedo Series #2 SWAP! was the first commercial game to go ingame and also become playable. It started working in early 2014.

Numan & Demon’s Souls

Like most games at the time, Demon’s Souls didn’t work at all. Then a new person called Numan, now a respected RPCS3 developer, joined the Discord server and made it show a loading screen. From there a series of developments was set into motion where Numan, Nekotekina, kd-11, Jarves, and O1L would work together to fix problem after problem culminating in a spectacular #hype countdown on rpcs3.net where we revealed Demon’s Souls being ingame and kind of playable out of nowhere. This was huge in so many ways. In a very short amount of time RPCS3 went from not really running any generally interesting games, certainly not in any presentable way in regards to performance and graphics, to “here is Demon’s Souls and it pretty much works”. This event made so many people say “wait what, there is a PS3 emulator? And it runs Demon’s Souls!?”. Our video got over 200 000 views, the website crashed hard from the “Reddit hug of death”, and gaming sites all over the world wrote about us. The little advertising stunt with the countdown certainly worked…

There are a lot of interesting tidbits about how Demon’s Souls started to work in February and March of 2017. To write about it here is unnecessary for the original blog post from the announcement covers it all extensively. Take a look.

Also take a look at the video below from a bit later during the year, when the last serious bugs were fixed and the game became playable.

Auto LLE, Firmware Installer

The PlayStation 3 operating system (OS) provides many modules that games can use for various functionality. A simple example is the module libmp3.sprx that gives games all the functions they need to playback mp3 audio. In practice every game loads many modules like this, many of them on a much more fundamental level than libmp3.sprx, for example modules used for thread management on the SPU cores (libsre.sprx, libspurs_jq.sprx). RPCS3 started as a HLE (High Level Emulation) emulator meaning all PS3 functionality would be implemented with new code in RPCS3. However, in the coming years that the developers concluded that this approach was completely infeasible, that to reimplement the black box that is the PS3 OS would be a astronomically colossal task that is ultimately pointless because the real PS3 OS modules could simply be executed with flawless compatibility (it is the exact same code running after all) and with extremely good performance with the LLVM PPU Recompiler anyway. Support for starting to load and execute some PS3 OS modules (sometimes referred to as “LLE modules”) was added in late 2015 and early 2016. But ever since the beginning days users had manually select which modules to load for each game. Select too few and it would crash, select too many and it would crash, or use the wrong combination in some way and it would crash. Fun times. For example Catherine probably went ingame for quite some time, but it was not discovered for months because no ordinary users knew to load some rare modules related to video decoding and playback that it needed for the intro videos.

Completely automatic module selection was implemented back in March by Nekotekina. Coupled with the firmware installer created by cornytrace in February, this marked one of the single biggest steps forward for usability RPCS3 had to date. By allowing users to install the firmware modules directly from the PS3UPDAT.PUP file distributed by Sony, people no longer needed to manually get the modules from a CFW PS3. In addition, by creating an automatic selection, users no longer needed to manually pick which modules each game would need in order to run. This was the first of many steps towards the “install game and go” that we have now.

Automatic LLE has since been largely replaced with “load liblvl2.sprx only”, which has steadily been improved to bring module loading (and unloading) more in line with how an actual PS3 does it. It is this part of the PS3 OS known as lv2 that games interact with, and which does module loading on a real PS3. With the addition of cached PPU LLVM code covered above, this has made the emulator far more usable than it used to be.

The module selection part of the RPCS3 settings. While load liblv2.sprx is the default option and provides automatic module loading there are still clear traces of the old manual module selection days, with the checkbox list of modules and filter input.

Qt GUI

Back in June, RPCS3 moved away from the outdated WxWidgets GUI to a Qt based GUI thanks to the hard work of flash-fire, Megamouse, and many others. This transition sparked a wave of GUI development that led to many features being improved and to quite a few new ones. The save manager was finally hooked in to the back end, which allowed for users to create and use multiple saves in games that didn’t provide their own save menu. A toolbar was added, allowing the game list to be filtered and searched. Disc games were given their own folder and added to the game list properly. DAGINATSUKO, the talented designer behind RPCS3.net overhauled the design of the UI, which was implemented by MegaMouse, who then also adjusted all the layouts to work with high dpi scaling.

Since the initial overhaul, many other improvements have been made, including improvements to the debugger, CgDisAsm, and the settings dialogs. Logging has been reworked to create less bloated logs as well as automatically compress them. After GalCiv’s pad magic contribution that enabled the use of multiple interchangeable pads and keyboards, Megamouse – with the help of Jarveson – introduced pad customization and profiles, allowing full controller remapping and multiple layouts to be used. A trophy manager and trophy notifications were introduced, adding a feature that had been long requested. Thanks to the Qt team’s prior efforts to enable as much customization through stylesheets as possible Ani introduced a first dark theme for the GUI which was later on accompanied by other themes created by themitosan. Megamouse and Scribam added a new column to the game list, enabling users to download the latest compatibility database. This allows users and rpcs3’s testers to distinguish playable apps and games from those that still need improvements, just by looking at the list instead of opening the browser and searching for each title manually.

Many other changes besides these were made over the last six or so months, including innumerable bug fixes to old and new features alike. The best way to express these changes is to show them, so here is a screenshot from the last WxWidgets build, as well as some from a up to date build.

To the left the last build with the WxWidgets GUI, to the right the current Qt GUI

Below is the current GUI with an optional dark theme:

The current Qt GUI with a dark theme.

LLE gcm

gcm: graphics command management. This is in a sense (but not really) the OpenGL or Direct3D of the PlayStation 3. (Direct3D is a subset of DirectX, the part actually responsible for graphics while DirectX also contains functionality for audio, input, etc.). Anyway, every single game uses this to show anything at all on the screen. Since the very beginning of RPCS3 in 2011 gcm was purely implemented in HLE (high level emulation), that is the RPCS3 developers wrote their own code to mimic the functionality rather than executing the actual gcm code from the firmware (low level emulation, LLE). Low level emulation of gcm is not easy. Enter: Jarves, a contributor who was really only interested in running Kingdom Hearts but by implementing LLE gcm managed to fix hundreds of other games too. No one had anticipated that the HLE implementation of gcm would be so broken, but it was. Suddenly hundreds upon hundreds of games started to work better with plenty of seemingly random crashes and hangs going away. It was the work on LLE gcm that made for example Red Dead Redemption go ingame previously nearly instantly hanging on the main menu. And to reiterate, it fixed problems in countless of games. Every test result of a non-playable game from before the merge of LLE gcm could be considered outdated!

Here is a video from back when LLE gcm was implemented and Red Ded Redemption went ingame for the first time. Of course it will look a little better today than it did back then.

High Resolution Rendering & Graphics Enhancements

One of the highlights of the year for many RPCS3 users was when kd-11 implemented resolution scaling. It was now possible for users to play their beloved PS3 titles on PC in high resolutions up to an absurd resolution of 10k! For most users 4k is more than enough and the performance hit is so small that as long as you have a Vulkan capable dedicated GPU you can expect the exact same performance compared to running at the PS3’s native resolution (generally 720p). Check out the compilation video below to see the difference running these games at a real resolution makes.

But kd-11 didn’t stop there, the same update that implemented support for high resolutions also contained support for forced Anisotropic Filtering. This allowed users to apply a high quality texture filtering method that vastly improved visual quality on textures when viewing them on an angle. The difference between 16x Forced AF and automatic (default, uses the games inbuilt filtering) is night and day in many cases, especially when running the game in a high resolution.

Colossal Renderer Performance Improvements with Vulkan

Over the past year, kd-11, Jarves, Nekotekina, and many others have made a staggering number of improvements to the graphics backends in RPCS3. The improvements made to Vulkan and OpenGL have caused literally thousands of games to perform better, in many cases by entire orders of magnitude. In addition, fewer games have broken graphics or effects, and even more display anything at all.

It’s hard to really grasp just how many improvements there have been. One of the biggest improvements performance wise came from rewriting vertex processing to be performed on the GPU instead of the CPU. In the process of improving performance, kd-11 also found issues that were preventing games from showing visual output and fixed them. Along with improvements to the shader cache, many games now perform at playable levels as opposed to before when they barely ran at all. The (now a bit outdated) video below shows a few examples of this great performance improvement.

Over on the graphics quality side, we have just as many improvements. kd-11 implemented z-cull for Vulkan, which fixed the sun shining through walls in Demon’s Souls, among other bugs in various games. Jarves found a particularly annoying bug that caused flickering graphics in many titles. Several other developers have made commits that impact both performance and quality as well, each of which has brought RPCS3 that much closer to being graphically accurate to the PS3.

The 59.94 Hz Bug

This is not really a major development, at least not compared to all the things written before this section. However this so called 59.94 Hz bug is still quite funny. For years many games using the Koei Tecmo engine failed to boot and died in the exact same way with RPCS3. This affected multiple Dynasty Warriors, Dead or Alive, and Atelier games for example. However an earlier Koei Tecmo game, Deception IV, running in an older version of the engine worked. ssshadow decided to investigate further and noticed the initialization routine in Deception IV and some newer games using that engine was pretty much exactly the same. It could also be noted that cellVideoOutGetDeviceInfo() was the last function that was called before cellVideoOutConfigure() which would initialize graphics output. But in the more recent Koei Tecmo games running on the newer engine version cellVideoOutGetDeviceInfo() was followed by pretty much nothing, just the games entering a dead code path and doing nothing. ssshadow had the theory that perhaps the game didn’t like the screen information recieved by cellVideoOutGetDeviceInfo(), though changing various values didn’t fix anything. Finally Jarves disassembled the game binary and found the cause, the newer engine version was explicitly programmed to enter a dead code path if cellVideoOutGetDeviceInfo() did not return that the displays supports a refresh rate of 59.94 Hz. Nothing else is known to be affected except this handful of newer Koei Tecmo games, and indeed, after changing a single line of code 20 games were more or less fixed.

Why on earth did someone program that behavior? No clue. Perhaps it is some sanity check gone wrong. The PS3 OS will report than any monitor that supports 60 Hz (a requirement for the certified usage of HDMI) also supports 59.94 Hz, even if the display EDID does not mention it. So this behavior from the engine is grounded in something. Of course at some more physical level 59.94 Hz = 60 Hz for these monitors.

This is the diff for the git commit that fixed this silly bug and something like 20 games with it.

Playable Games

RPCS3 had roughly 20 playable games in early January of 2017. At the time of writing we have 699 playable games. It would of course be impossible to cover even a fraction of these games here, so instead we will simply dump some images and videos of a few favorites. Every game seen below is playable, meaning you can take it from beginning to end with good performance.

Atelier Escha & Logy: Alchemists of the Dusk Sky at 2560×1440

Catherine at 3840×2160

Catherine became playable pretty early in the year (March) and consistently improved to the point where the game can maintain a stable 30fps even with an i3 6100. Towards the end of the year even small issues like needing strict rendering mode to display text properly was fixed due to the countless rendering improvements from kd-11 graphics are now almost perfect in Catherine!

Demon’s Souls at 7680×4320

Do note that these 8k images are roughly 30 MB each.

Demon’s Souls at 3840×2160

Kingdom Hearts HD 2.5 Remix at 3840×2160

Ni no Kuni at 3840×2160

Odin Sphere Leifthrasir

Persona 4 Arena Ultimax

Ingame Games

The games below are now ingame. This means you can technically play them, but for one reason or another you might not want to. It could be poor performance or that the game sometimes crashes. Regardless what these titles have in common is that they did absolutely nothing one year ago, and now they are close to actually being playable!

Eternal Sonata at 2560×1440

God of War Collection

NieR RepliCant & NieR Gestalt

Ratchet & Clank I, II, III, IV (Deadlocked/Gladiator)

Red Dead Redemption at 3840×2160

Skate 3

Sly Cooper Thieves In Time

Uncharted 1: Drake’s Fortune

Uncharted 1 got tested quite a lot by the community, in the above video we see some gameplay from the second level of the game, which also proves it is possible to (slowly) progress a bit into it. That said, there are still occasional crashed every now and then.

In the above screenshot we see a user running Uncharted 1 with an ultra widescreen patch! That patch is truly changing the aspect ratio of the game and showing much more of the game on the screen without any stretching.

Here is also a bonus screenshot of the game running in 10k resolution!

Yakuza 4 at 3840×2160

Closing Words

2017 was by far the greatest year in the history of the project. RPCS3 went from being a curiosity that didn’t really run any interesting games to an actual usable piece of software. You can play Demon’s Souls in 4k with good performance right now on your PC. You can do the same with 698 other playable games. This would not have happened without the fantastic community behind RPCS3. Funded by at the time of writing 757 patrons Nekotekina & kd-11 can work on RPCS3 full time. Moreover dozens of contributors write code that improve various areas of the emulator. Take a look at this github statistics page to see how many commits, additions, and deletions, each developer made during 2017. Every single person here helped the RPCS3 project. As expected Nekotekina and kd-11 are in the lead. Then we have Megamouse with his insane PR spam of Qt fixes 😉

Of course there is much more to RPCS3: thousands of people contribute by testing games, finding regressions, reporting bugs, providing support for users, and spreading the word.

If you like in-depth technical reports, early access to information, or you simply want to contribute, consider becoming a patron! All donations are greatly appreciated. You can support lead developers Nekotekina and kd-11 here on Patreon. Your support will help speed up the development of the emulator so that one day every game will be perfectly playable from start to finish with perfect performance.

Also, come check out our YouTube channel and Discord to stay up-to-date with any big news.

Let’s look forward to another exciting year of progress!

This report was written by ssshadow, twdarkeh and Ani.