Ryujinx - Meet the Team Vol. 2

Interview with Ryujinx Team Developer Thog

What is your software development & reverse engineering background? How did you find out about Ryujinx?

I started programming at the age of 11 mostly by necessity. Back then, I was in need of complementary tools to help with my experience at school without spending any euros. I continued that way for some years and picked up an interest in modding games and embedded software development later on.

On the reverse engineering side, I recall starting to reverse java bytecode for Minecraft back in 2013 but I only really started reversing software seriously in 2016 with 3DS sysmodules and tools for FabricMC.

I joined the hacking community around the Nintendo Switch essentially from the start back in March 2017, and made some homebrews but also a lot of research around how to interact with the Switch  operating system. One of my projects I had back then was to be able to run a very small subset of the Nintendo Switch OS to be able to interact with some normally inaccessible service APIs. The result of one of my debugging sessions, and Ac_K’s/roblabla’s recommendations, was my first contribution to Ryujinx in May 2018. After that, Ryujinx has continued to pique my interest and I’ve kept developing for  it to this day.

For those less familiar with reverse engineering, can you explain in layman’s terms what all is involved in the process?

Reverse Engineering is a process or method allowing to understand, in a deductive way, how a device, system or an application accomplishes a task. In the context of Ryujinx, we analyze and dissect how games interact with OS components (or even directly interact with hardware for the GPU or audio side) and implement replacement code that mimics, as closely as possible, the intended behaviours of those OS components.

Rather than frequently contribute small incremental changes to the emulator, you seem to instead drop complete works on occasion like Amadeus (complete audio renderer), Salieri (disk shader cache), and Haydn Part 1 (audout/audin full re-implementation). Have you always focused on larger-scale components/projects?

I don’t think it’s about large projects or components here but more about what I consider is lacking in Ryujinx. For example, when riperiperi started working on 32-bit support back in early 2020, I worked in parallel on a complete reimplementation of the Mii service to fill the missing bits to get Mario Kart 8 Deluxe fully playable. Same goes for Amadeus: when I started tackling it, the audio renderer hadn’t been touched since 2018 and was lacking essential features.

Of all the contributions you’ve added to the emulator thus far, which are you most proud of and why?

I’m mostly proud of all my rewrites so far, but if I had to pick one it would be Amadeus for sure.

There are multiple reasons why Amadeus is my most precious rewrite so far. First of all, I took this as a challenge for myself to learn audio signal processing from scratch. Secondly, it’s one of the longest running projects I have carried in my whole life. It took me 10 months to fully reverse and implement while learning audio processing theory. Even if I took break from it here and there by working on other bits like the mii service or the reimplementation of the "Surface Flinger", it surely was quite an adventure during the first French lockdown in 2020.

Are there any implementations you look back on now and wish you had chosen a different approach for?

The worst implementation I provided would be the unified configuration system in my book. This allowed a concrete way to handle configuration version and hot configuration changes in a generic way, but at the cost of depending even more on the configuration system. This is terrible, in a way, because it makes it very hard to dissociate the emulation components from the configuration for testing or porting to new systems, for example.

I have some plans to improve that situation at some point to decouple the configuration from every subproject of Ryujinx and make it easier to do unit testing of every subsystem.

Which aspects of the emulator do you enjoy working with most?

To be honest, I don’t really have any preferences when working on the emulator.

I kind of like to tackle new fields that I never tackled before but also things that could help the Nintendo Switch hacking community back via clear documentation of real hardware and service behaviors.

This also explains why most of my contributions center around the HLE side of things.

What are the biggest factors when you are deciding what to tackle next?

One of the biggest factors would be to “fill the missing bits”.

If something is a blocking matter for another project within the team and no one can (or is willing) to handle it, I’m usually the one that tries to unblock the situation by giving a hand. Otherwise, most of the motivation are things that I see in the code that tickle my perfectionist side to rewrite everything ✨

Can you share a sneak peek of what you’re working on currently?

As some of you might already know, I have been helping fellow team developer emmauss on getting a new UI using Avalonia in place. This is a necessary piece to have a unified and robust UI system for the upcoming Vulkan backend. I’m also still working on the part 2 of Haydn that will bring better audio device support for the SoundIO backend.

Are you working on any other projects outside of Ryujinx?

In terms of projects, I currently am working actively on four of them.

The first is writing a brand-new NVIDIA driver targeting Maxwell to Turing cards in Rust. So far, I’m still researching device initialization but my objective for this project would be to get a working proof of concept of a display working with it on Linux by the end of summer 2021.

The second project is creating a bare-metal bootloader and hypervisor for the new Apple Silicon SoC named m1saka. I currently work on poking/prodding and understanding the audio hardware interface to do a driver for m1saka and document it.

The third is writing a helping tool to allow automatic generation of C# interfaces to interact with Apple Objective C APIs. This one is mostly done and will likely be published in the coming weeks.

Finally, my last project is a custom backend for the LLVM compiler infrastructure that targets the MINA32 architecture. This is a fun project to bring a complete C compiler to an architecture designed by ladystarbreeze.