August was a month of bug fixes and rewriting old code. In this report some general emulation improvements will be explained, followed by a closer look at some popular and representative games. Lastly, individual contributions will be covered and plans for the future will be detailed.
Table of Contents
First and foremost are the compatibility numbers for August. Finally there are more games that are playable than completely not working! In fact, less than a quarter of all tested games do not at least show something on the screen. Just a year ago there wasn’t even a compatibility database or listing of games that did nothing as almost every games was expected to do nothing or at best be loadable! A lot of the improved games are actually the result of LLE GCM from July as testing and updating the forums and the compatibility database took quite some time. That said, a lot of games improved from new changes this month, which will be covered below.
Looking at the GitHub statistics, 20 authors have pushed 179 commits to the master branch. Here 190 files have changed and there have been 8,587 additions and 3,876 deletions of lines of code. Below some of the major improvements from these code changes are summarized.
Major RPCS3 Improvements
Rewritten Vertex Processing
This is the first step of reworking how vertices are processed in the graphics emulation. In the absolutely simplest term possible, computer graphics are usually drawn by a method called rasterization. If a game programmer wants to show a basic triangle on the screen all one needs to provide are three dots which are then connected to form the triangle. These dots are also called vertices. Every game seen in this progress report is rendered with this method, there are just a lot of vertices to connect. Previously the processing of vertices was done on the CPU which was a real bottleneck in many games, especially games with complex graphics. But vertex processing is now moved over to the GPU where the process belongs. This is a potentially huge performance boost, especially on slower CPUs. One example can be seen above, but many of the game mentioned later in this report also got faster from these changes by kd-11.
However there is more to computer graphics than just connecting some dots together. To color the scene, add a sense of depth, and other such things games make use of shaders. Shaders are pieces of code that run on the GPU itself and modify the graphics. A simple shader could, for example, make things behind other things darker, giving you a form of shadows in the game. As vertex processing was moved from the CPU to the GPU, so were shaders. Unfortunately, this also makes the shaders much more complex. For various technical reasons it is not possible to ahead of time go through the game code and precompile every shader to be compatible with your GPU. Therefore a shader has to be compiled to something your GPU can work with when it is encountered. This causes catastrophic lag that makes some games absolutely unplayable. Very unfortunate. Can this catastrophic loss of performance be fixed? Yes! There are a number of steps, some of which are in progress, while others will be worked on in the coming weeks.
First of all, every shader must only be compiled and saved to the disk once. This creates a shader cache. In theory after playing a game for a while most shaders should be compiled and saved, and everything should be fine. For some games the current implementation is working just fine. After loading into the opening bit of Atelier Escha & Logy and doing one or two battles it is all done, basically no more shaders will be compiled and the game runs better than ever.
Other games do not work quite as well. The PS3 version of Mafia II is an extreme example one such game. After playing through a few very stuttery minutes of that game one will have compiled literally thousands of shaders. This is not intended. The game does not use 2,000 different shaders in five minutes of one room. Think of it instead as using the same shaders in different ways. This will be improved in September, not only in Mafia II but in (hopefully) every game. In reality it seems incredibly unlikely that any game would actually have more than a few hundred shaders. The end goal is to reach that point where every game only see a few hundred shader compiles, ever.
One may also look at the incredible job the Gamecube and Wii emulator Dolphin did of fixing their own problem with shader compilation induced stutter, through a new method called Ubershaders. Read about it in great detail here. The question comes up, “can RPCS3 implement ubershaders?”. The answer to that is basically no, however the essence of the question is probably actually “can RPCS3 completely eliminate shader compilation stutter?”. The answer to this question is yes, but it will be very complicated. As the current pixel pipeline is being reworked hopefully the number of compiled shaders will be reduced to no more than a few hundred as mentioned earlier, and from there the situation can better be assessed and more long term plans can be laid out.
Lastly here is a separate post by kd-11 going into more detail, both in terms of performance numbers and such, and also in greater technical terms.
SPU Improvements and liblv2 fixes
During the last few hours of August, Nekotekina pushed a mega commit containing various changes mostly in the areas of SPU and liblv2. The PS3 processor has six special SPU cores and then there are various options for game developers to manage these. Nekotekina fixed RawSPU which is basically a way of managing synchronization primitives on the SPU cores and allows great freedom for game developers. This isn’t commonly used but some high end games like the PS3 versions of the Crysis games uses this. Incidentally Crysis now goes past the RawSPU crash it had and… dies 0.1 seconds later on something else. There were also other SPU related changes around how code can be loaded and managed.
Nekotekina also fixed liblv2 and made it the default option of loading system modules for games. liblv2.sprx is a single system module that is always loaded on a real PS3 when running a game, and games can load and unload additional system modules by interacting with liblv2. Previously this was inaccurately done with high level emulation (HLE) but now liblv2.sprx is loaded and used like on a real PS3. This can fix various games that crash or behave strangely when starting up.
The SPU and liblv2 improvements together didn’t fix Crysis as we had initially hoped for (no “but can it run Crysis?” meme) however it did fix the PS3 port of Far Cry 1 which can be seen in the video above. It has a few graphical issues but seems playable otherwise meaning it went from doing nothing at all to going at least ingame with these changes. As these fixes by Nekotekina were the last things merged in time for this progress report it is still unclear to what extent various games improved, but a few things are known already and mentioned throughout the report.
Savedata Manager, Input Manager, and Initial Trophies
pi_rho_man added a savedata manager in RPCS3. This allows one to easily view every save file in every game and also to delete them. The image says it all really. It is a very useful little tool to check for example playtime, or if a save taken from a real PS3 got decrypted properly.
GalCiv with the help of hcorion added the option to configure multiple and mixed controllers. It is now possible to play games with co-op or splitscreen with, for example, an Xbox controller for one player, keyboard for another, and a PS3 controller for the third person. One game that this works very well in is Scott Pilgrim vs. the World: The Game which many people have played co-op on already.
Lastly, pi_rho_man started to fix the backend of trophies and also add some graphics when they are unlocked. This is still work in progress and not finished or available on the master branch yet, but seen above is a first test of a trophy unlocking. First make it work, then make it work better. Naturally, the look and feel of this system will be improved before it is merged.
Dedicated Forums, Improved Compatibility List, and Website Dark Mode
Ever since RPCS3 was started by DH and Hykem back in 2011 emunewz.net had been the home of the project, providing an RPCS3 subforum that was for many years only used to discuss the few homebrew and later commercial games that even displayed a black screen. However, since those good old days and especially this year when full time development happened thanks to Patreon, RPCS3 has come to outgrow the old emunewz forums. Therefore we made our own forums here on rpcs3.net, and there is a post going into much greater detail on why the new forums were started and what the future looks like. Visit the new forums to learn more. Of course every old post was imported and old user accounts can very easily be too. If you want to import your old account, the forum post above explains how to do so.
The biggest improvement lies in the quality of life for RPCS3 staff. New forum moderators were assigned, and because we now have our own forums, Ani has integrated our compatibility list with the forums. This means the database can now be automatically synced with the corresponding forum topics with just a click. This automatic process removes days of man-hours previously spent on manually updating the database.
Web designer DAGINATSUKO also added a dark mode to rpcs3.net! It is still work in progress, but for now simply press the invisible button in the top right corner of the header to switch it on.
So many games were improved this month that it would be impossible to cover all of them. Instead, here are 11 select games or groups of games that are either interesting in some way, popular with our users, or that represent a certain change in a clear way.
Atelier Escha & Logy, Atelier Shallie, and Ar Nosurge
Atelier Escha & Logy, Atelier Shallie, and Ar Nosurge are the last three Gust games to be released on the PS3 (Atelier Sophie also got a PS3 release, but only in Japan). They run in the same engine and were all improved in the same way. Performance was improved greatly with the vertex rewrite. The Atelier Escha & Logy screenshots above were captured on an i5-4690k and the game essentially doesn’t drop much below 60 FPS, and in low intensity scenes it can run at over 100 FPS. The game engine handles any frame rate, so it doesn’t run too fast or slow. Moreover, as seen above characters have a black outline to fit the anime art style. Previously, due to a bug that lied in the vertex decompiler, this was rendered with a random color. Thankfully, this bug was fixed by Jarves. This also fixed various graphical problems in other games, including Kingdom Hearts HD and broken text in LittleBigPlanet, not that it shows much more than some initial loading screens for now.
In the cult classic Atlus game Catherine there were major performance improvements thanks to the vertex rewrite and the very fast Vulkan renderer. The video above runs the game at a stable 30 FPS with no drops whatsoever, on a 3.7 GHz Skylake i3! In fact, users have reported the game running at a stable 30 FPS on much slower hardware. More than one person played it with no issues even on old AMD FX CPUs, and these have historically performed terribly. But by far the most interesting user report comes from someone who ran it at around 20-30 FPS on an ultra low voltage i3 in a NUC. However, the very buggy Intel Vulkan drivers made graphics look fairly broken, even if performance was much better than expected. On Nvidia and AMD graphics cards (with updated drivers) the game is definitely playable on basically any real CPU now.
Devil May Cry: HD Collection
The DMC HD Collection is a bit of a special case. Overall it runs excellently after the vertex rewrite, achieving 60 FPS with no problems. Historically the initial launcher used to select the three different games didn’t work, although users could still manually boot the individual game executables. This was fixed along with liblv2 and SPU fixes by Nekotekina. However, the launcher doesn’t properly pass every parameter when starting an executable and thus the alternative Lucia campaign in DMC 2 still cannot be started. Otherwise the rest of the collection is playable with practically flawless performance.
Dragon’s Crown by Vanillaware became playable this month. In the video above, several areas of the game are shown to run just fine. Previously the game was simply crashing when starting up. Contributor GalCiv stared at the assembly for an uncountable number of hours and figured out why: it is actually a game bug. Every PS3 is the same, and it takes a fixed amount of time for certain operations to finish. Because some things around PPU and RSX interaction are still not accurately emulated in RPCS3 the timing is off and the game can hang. GalCiv committed some improvements to this area and also made a patch for the game using the RPCS3 patch/cheat system. This move may be considered controversial by some.
Metal Gear Solid 2, 3, & Peace Walker HD
The PS3 HD versions of these three Metal Gear Solid games went from not doing much at all to being ingame and kind of playable this month. The work on LLE GCM from last month along with various other fixes such as a tiny two line fix to sceNP (NetPlay, also known as PSN) HLE code accomplished this. The games work entirely, and someone even beat all of Metal Gear Solid 3. The problem is that they can run a bit slow, even on very high end hardware. This is much less of an issue with Peace Walker HD however, originally being a PSP game. That one mostly runs at full speed already.
Ni no Kuni: Wrath of the White Witch
The improvements to Ni no Kuni came in two areas. First of all, overall performance increased with the vertex rewrite. Secondly, broken depth with Vulkan was fixed, making that renderer usable for the first time with this title. Moreover Vulkan also provided an additional speed boost compared to OpenGL. Rewritten vertex processing along with making Vulkan usable resulted in a significant performance improvement overall, as seen in the video above. The game is basically playable, although some patience is required. Video cutscenes hang when they end and the workaround is to skip them right before they finish.
NieR RepliCant & Gestalt
Like many other games, the original Nier saw performance improvements from the vertex rewrite. Somewhere along the way various graphical issues were fixed too, and only a somewhat broken HDR seems to remain along with occasionally low performance. Nier is nearly playable now however, and a lot of crashes that plagued this game have been fixed over the last few months.
Red Dead Redemption
Red Dead Redemption saw improvements to overall graphics and performance. It is a bit hard to quantify, some areas of the game are unchanged, others are a decent bit faster. For example, in the top right screenshot we see how the game nearly hits 30 FPS which was definitely impossible before the vertex rewrite. Graphics are also looking mostly good. Grass and trees are a bit broken but overall lighting, shadows and characters seem to look correct.
Shadow of the Colossus HD
Shadow of the Colossus HD went from a crashy, broken mess to being ingame and mostly correct looking. That said performance is quite poor, often dropping down to single digit framerates. Regardless some brave soul played through quite a bit of the game to take the screenshots seen above, and also to confirm that the game works well enough otherwise.
Performance improved in Skate 3 thanks to the vertex rewrite. Some parts of the game can still be slow, but overall it is much better, and many areas now run at full speed as seen in the video. Earlier, cars were completely broken and basically seemed to roll around randomly on the streets. This is now fixed as shown in the screenshot below. One would at first glance at a bug like that assume it to be a CPU issue, but it actually lied in graphics emulation this time. When the broken cars were fixed alongside the vertex rewrite the game logic also corrected itself.
Yakuza 3 & 4, Yakuza Kenzan Translation
Below we see two new screenshots from the English fan translation of Yakuza Kenzan running in RPCS3. This game was sadly not officially translated but thanks to RPCS3 is is now easier than ever to test and debug changes. Read more about this translation project here.
Below are screenshots from different games that saw improvements this month. Usually around performance and improved graphics, but refer to the corresponding forum thread for each game for more information.
As always, this is not a complete list of PRs or commits, nor does it necessarily list every single thing done by a given PR. For a full list, see PRs merged in August. Many of the unmentioned PRs are simply small updates, fixes, and other small improvements, sometimes only to the GUI.
#3366 – Improvements and fixes to SPU, liblv2, and more. This was detailed in much greater detail earlier in the report.
#3354 – This is one out of several changes to how logging works. The log file is now automatically compressed to make it easier to share, among other advantages.
#3324 – SPU fixes among other things. Definitely improves Heavenly Sword and likely more games.
#3286 – Various bug fixes, for example in moving disc games incorrectly placed in the hard drive folder.
#3199 – Fixes various bugs and adds a warning when non master version builds are used.
#3142 – Fixes various bugs. Improves handling of bad config files.
#3315 – Improvements to z-culling and shader compilation.
#3241 – Fixes various bugs such as drivers crashing when the Vulkan window is resized.
#3168 – Bug fixes for z-culling and some better logging.
#3135 – A big PR that implements z-cull occlusion statistics using native occlusion queries. Z-cull occlusion statistics are used by games to determine whether a section of the world is visible or not. This fixes various problems in different games.
#3287 – This fixed some old regressions with the on screen keyboard (OSK).
#3214 – Renames the D3D12 (“DirectX 12”) renderer to D3D12 [DO NOT USE] to hopefully make things clearer.
#3158 – Fixes a small problem in the RSX thread improving Dragon’s Crown and possibly other games too.
#3128 – Adds support for installing multi part .pkg files which a few games uses.
#3267 – Various graphics fixes. Fixed for example shadow bugs in Kingdom Hearts HD and broken character outlines in Atelier Escha & Logy, Atelier Shallie, and Ar Nosurge.
#3244 – Various fixes to evdev controller support on Linux. Fixes running in certain games.
#3220 – Adds an optional dark theme to RPCS3.
Across several different PRs Megamouse improved theming in RPCS3 which enabled Ani to make the dark theme.
#3256 – Fixes an old on screen keyboard regression where deleting text was not working correctly.
#3207 – Fixes a bug where custom config would be created for a game without the user actually saving anything.
#3223 – The previously mentioned savedata manager.
#3153 – Major refactoring around how input is handled. A base for support for multiple and mixed controllers.
#3202 – Fixes evdev input issues on Linux. Fixes problems with the Xbox One S controller in particular.
#3176 – Makes RPCS3 build on Mac again. However since Apple supports neither modern OpenGL or Vulkan it isn’t very usable (no games will show anything).
#3114 – A code review correcting various things.
#3307 – This first time contributor to RPCS3 added a new audio backend for Linux: PulseAudio. Reportedly this reduces audio stuttering and such for many users.
#3290 – Fixes Lost Planet with Write Color Buffers and likely other games too.
The Patreon roadmap is now structured with per month goals. Perhaps the biggest things next month are that kd-11 will improve the shader compilation stutter situation and also get started on high resolution rendering. Nekotekina should also be able to start working on the new LLVM based SPU Recompiler.
Also, a certain major AAA title will improve a bit in September…
This has been a month of great improvements to RPCS3. If you want to help out Nekotekina and kd-11 and make RPCS3 progress even faster you can check out the Patreon page here. Right now we are very close to the $3000 goal of having kd-11 work on RPCS3 full time which would greatly increase the rate of progress in the future.