ryujinx
patreon
January and February Progress Report
🕑 Added 2020-03-02 20:09:18 +0000 UTCWhaaat, a Patreon progress report?
That's right! We will be releasing progress reports for patrons now! You can think as a way to thank you for your support. The plan is making monthly progress reports, and seasonal progress reports that will be released to the public, and will be pretty much a condensed version of those smaller progress reports.
Since our time is limited and writing those progress reports is very time consuming, we plan to reuse as much content as possible for the public progress reports.
The original plan was posting the january progress report at the start of february. But I delayed it a bit, and before I noticed february was already ending, and the progress report was still incomplete. So I decided to change my plans and post a single progress report for january and february. Anyway, without further ado, let's see the improvements we had in the last two months!
32-bits support
One of the biggest improvements we had recently was 32-bits support. Much like a PC, the switch is also capable of running 32 and 64-bits applications. To do so, the switch operating system puts the CPU in the 32-bits mode, you can think of it as a compatibility mode to run 32-bits applications. The switch as you may already know, has an Arm CPU, and the 32-bits Arm code is vastly different from the 64-bits one, so supporting it is actually a lot of work, it's almost like having to emulate another CPU.
Thanks to the hard work from riperiperi, we are now at a point where several 32-bits game are booting, some are even playable! Let's take a look at them.
On the screenshot above, we can see Captain Toad: Treasure Tracker running on Ryujinx. This game was originally released for the Nintendo 3DS and Wii U, but it also has a Switch port with a few enhancements, like new levels. In fact, most of the Switch 32-bits game are ports from the Wii U or 3DS.
Other 32-bits games includes Mario Kart 8 Deluxe, New Super Mario Bros U Deluxe, Rune Factory 4 Special and Tokyo Mirage Sessions FE Encore. The Switch ports usually contains some enhancements, which makes getting them properly emulated even more interesting.
There are also other 32-bits titles that are more widely available, with versions for PC and other consoles, but it's nice to see them properly emulated nonetheless.
Mii support
As we just saw, thanks to 32-bits support, a lot of games that previously didn't even boot on the emulator are now working. But even with 32-bits support, some of them were not playable as they use Miis, and so requires the Mii service to work. This service was not implemented, but thanks to the hard work from Ac_K and Thog, now it is almost fully supported!
Now let's take a look on some of those games.
The screenshot above shows the game New Super Mario Bros U Deluxe being played with a random Mii character, on the "Golden Rush" mini game.
Here we can see Toadette (a character only available on the Deluxe version of the game for the Nintendo Switch), transformed into Peachette after picking the Super Crown.
Now let's take a look at another great 32-bits title, Mario Kart 8 Deluxe.
This is another game that requires Mii support to work. As you can see on the screenshot above, the Mii is a playable character on this game aswell, and you can race controlling it. The Kiosk version doesn't require it as it is just a simple demo version, and some people was able to play it before the Mii support landed, but we're glad to say that now the full game is playable aswell!
There are also other (64-bits) games that requires Mii support to work, like Go Vacation and Super Smash Bros Ultimate. The latter also requires other things to work properly, so we don't have much to share right now about it, but we hope to have something for the next progress report.
GUI updates
Due to the lack of GUI frameworks for .NET Core, when the emulator was initially developed, it lacked a GUI. The only thing it had was a window where the emulated Switch screen was rendered. In the last year, thanks to efforts from Xploitr, a GUI was finally implemented. However, due to some limitations, the actual emulation rendering was still done on a separate window.
Thanks to the work from emmaus, the game is now rendered on the main window, as one would expect from a emulator. There's no separate window anymore!
Here are some screenshots that shows this change:
As you can see, the game is now rendered on the main window, which is easy to notice on the above screenshots with the menu bar on the top and system version information.
Please note that the above games are not currently playable on the emulator, the screenshots were taken with a currently WIP (work in progress) change to improve bindless texture support on the GPU emulation. We hope to talk more about that on the next progress report.
Fixing GPU bugs
GPU issues are usually not hard to fix, once we properly identify them. One of the issues that was recently fixed was a bug with shadows. Anything outside of the region the model was located at was completely black. Below you can see a screenshot that illustrates the problem, taken from Mario Tennis Aces, but the same problem also affected several other games:
Uh oh! Something is wrong.
Fortunately the issue was pretty easy to find and fix. It turns out those games uses a GPU feature that allows a configurable, fixed constant color to be used for pixels read outside of the bounds of the texture. This is called border color, and fortunately for us, OpenGL also supports it.
With the fix, now the game renders much better on the emulator:
Now let's take a look on a game that has been really broken on the emulator for a long time, Xenoblade Chronicles 2. First, let's take a look at how it used to render.
At a first glance, the game looks completely broken, but there's actually just 2 bugs on this image. First, you can see that the game has weird black lines all over the place. The second and most noticeable one is that most of the geometry appears to be inside out. You can see the interior of the models, but the parts that are supposed to be rendered are not there.
After some research made by riperiperi, we discovered what was causing both issues. Let's start with the black lines. Some investigation and tests revealed that the game was reading a depth texture on a shader, but then interpreting the value as a integer. But what that means?
I will not go into details about what a depth buffer or depth texture is here, but suffices to say that GPUs have something called depth and stencil buffers. Depth and stencil information is stored in the same place in memory, and they are very close to each other. The problem on Xenoblade is that the game was expecting to read Stencil information on the shader, but it was instead reading Depth information. After implementing support for Stencil access on the shader, we can see that the game already renders a bit better:
But... The main problem is still there. And no one will want to play the game in this state, or at least no one that wants to still be able to sleep at night.
This problem is caused by wrong face culling. Basically, the GPUs will not draw faces that are not directed at the camera. Those are called "front facing". Culling can be used to avoid wasting time drawing pixels that are not visible anyway (since they are facing the opposite direction and are not supposed to be visible). In this case, the emulator was telling the GPU to assume the wrong geometry as front facing. The result was that back faces were visibles, and front faces were not draw. This is the exact opposite of what we want! Flipping back and front faces fully fixed it:
Yay, now the game is not a horror show anymore!
Unfortunately the fixes on the last screenshot are not on our main builds yet, since they cause regressions on some games. But we hope to get it properly fixed soon.
GPU emulation optimizations
Graphics improvements are nice, but speed is also important for the playability of the games. Since our last public progress reports, the emulator has also received some optimizations that makes a significant difference in some games.
Since Pokemon is the game most people seems to ask about these days, let's start witth it. Even on decent hardware, speed has been at most at 12-13 FPS on overworld areas, which is rather poor and many people would consider the game unplayable with this speed, even with Pokémon being a 30 FPS game. But why is it so slow?
Some profiling revealed some clues. The function that the emulator uses to read data from memory and send it to the GPU was slow, very slow. That's because it had to copy the data in memory each time. With some simple changes, we improved it by removing the copy in most situations, and that already gave a very welcome FPS boost, around 4 FPS for one of the developers on a huge overworld area.
Another thing that affected the performance negatively was the way how we implemented memory barriers. Optimizing that also lead to more speed improvements, further increasing the speed on the same scene by about 2-3 FPS. The end result was that this game in particular was almost twice as fast as before! On this specific scene, the speed went from 7.5 FPS to 13 FPS.
Before:
After:
Users with better PCs can also now get 20+ FPS in the overworld, which is pretty close to full speed! We have more optimizations that will also impact this game, and we plan to talk about it in the next progress report.
Riperiperi also indentified other things that was affecting performance negatively. The first one was the shader modification checks.
The GPU emulator needs to check if a shader was modified before using it. Previously it did that by comparing word by word, which is slow. Optimizing the comparison method improved the speed a considerable amount.
The other issue was texture flush checks. It used to check among all loaded textures, if any of them was modified, and if so, flush to memory. This was optimized, and now it keeps track of modified textures in a more efficient way, using a separate list, which reduces search time and improves performance.
Now let's take a look!
Before:
After:
We can see a increase of about 6 FPS on this title, which is pretty good.
Game of the month
This is a new idea we had to show new titles working on the emulator. Every month, we want to pick a switch game released on that month, and show how it runs on the emulator! If possible, we will pick exclusive switch games, but since a exclusive is not released every month, we may pick ports aswell.
January
And the game of the month is... Well, not a full game, but a demo. Pokémon Mystery Dungeon: Red Rescue Team DX demo. This is a remake of the Gameboy Advance game of the same name (except for the DX part), released exclusively for the Nintendo switch. The full game comes in march, but meanwhile we can take a sneak peak of how it runs on this Nintendo Switch emulator.
The game starts with some very personal questions...
This game also has a custom keyboard, unlike other games that uses the system built-in keyboard applet (which is currently not fully emulated, we instead return a fixed name "Ryujinx").
And here is how it looks like ingame!
This title would certainly benefit from performance improvements, it is a bit slow right now, but other than that it seems to be fully playable, at least the parts we tested. And we are happy to say that this title has been working on the emulator since day 1, that's right, it works since release (minus a minor save issue, that was possible to work around).
February
For this month, we have an interesting indie exclusive from WayForward, Vitamin Connection!
The game has a main "story" mode (Solo Journey), and also some mini games.
You play inside the body of a sick person (or animal), defeating the bacteria using the beam on a JoyCon shaped ship (as you can see on the above screenshot, there's no doubt that this is indeed a switch exclusive). The two characters inside the ship are Vita-Boy and Mina-Girl, the heroes that will defeat the disease.
Here we can see one of the mini games. This one is called "Dance Festival". The mini games can only be accessed from the main menu after you complete them on the story mode. This one in particular is pretty simple, you basically need to press a button on the controller corresponding to the action on the screen. If you press too fast or too slow, you miss and lose points. If you lose too many, it's game over!
Now let's talk about the emulation of this title, afterall, we are not here to do free advertisement of this game. The game runs mostly fine, and the speed is also good (as expected from such a simple 2D title). However, the game has audio issues (the audio sounds really bad, even with the emulation running at full speed), and I also noticed a odd timing issue on one of the mini games, it seems to be running slower than the real console (even when the FPS counter indicates it is running at full speed). Animations seems to be playing at the correct speed though.
In general, the game is playable, and has also been working since day 1.
Closing notes
That's it for today! Please be sure to share you thoughts on the comments section, and give your suggestions!
As always, thanks for you continued support, and all the patrons and developers that helped shape Ryujinx on what it is today!
EDIT: This post was made available for patrons in March 2, and made public in April 7 of 2020.
Comments
keep the hard work you guys are awesome
