Emulating Nintendo Switch Games on Linux

Using? So I can dump my games but not play them?

I should also note that law is not universal and when advising people on the internet it should be noted as such. In Poland for instance downloading games dumped by others is perfectly legal, only sharing isn't.

What I wish we could do is to put our games on a network server, it seems like the space on the Switch is never enough and it's annoying to re-download things a lot.

Yes, you can get microSD cards but there's still not enough space and I'd rather avoid swaps entirely.

Dumping modern games is probably outlawed by the DMCA's anti-circumvention provisions in most cases, since it involves breaking DRM.

Don't forget, buying media grants you fair use ownership of that media. You are more than welcome to rip and upload your own ROM, and you are free to download (but not share) anyone else's ROM.

Just a warning, this method is considered piracy. Not that I'm placing judgement on anyone who goes his route.

It should be. Look at DraStic, for instance, a DS emulator which runs ARM code on Android. It's a fairly performant and accurate emulation option. https://play.google.com/store/apps/details?id=com.dsemu.dras...

Now if you're talking about trying to run one of these emulators on an ARM build of Linux, you wouldn't see these performance improvements since their designs are optimized around x86 CPUs, not ARM.

Edit: Several far more informed comments than mine have mentioned that running on ARM is only one small piece of the performance coming from DraStic.

Usually, no. Emulation generally goes through a JIT that couldn't really care less; there are some processor features that can be difficult to emulate sometimes but often even on a similar ISA you cannot just "use your processor directly".

One of the suspected main reasons why we don't have proper original Xbox emulation yet on the PC is because of the fallacy that "it should be easy to emulate an x86 console on x86 PCs". This has lead to many failed attempts to attempt "shortcuts" of running Xbox games on PCs, like converting executables statically, or extremely high-level emulation approaches like only emulating graphics calls. None turned out not to be so easy in practice. The notion "it should be easy to emulate architecture X on architecture X" does not tend to hold up very well, at least not for game consoles that also have complicated graphics and sound.

Compare this to Dolphin, which has been wildly successful in emulating the Nintendo GameCube. Besides the big popularity of Nintendo games, the GameCube was comparable in complexity and sales figures to the OG Xbox. But since it had a relatively non-standard CPU architecture and a non-standard GPU setup, it guided emulation developers to not put too much effort in shortcuts and tackle the emulation problem head on.

It's worth noting some recent progress has been made in OG Xbox emulation by the Xqemu and Cxbx-reloaded projects. The former tries to use qemu for x86 emulation (or even virtualization?) while "low level" emulating the rest of the Xbox hardware, whereas the latter started life as an extreme high level emulator that is going more and more low level over time.

I would especially wonder about nvidia's Jetson Nano boards. I think they're based on the same Tegra X1 platform, right?

It sure feels like an ARM based Switch Emulator should eliminate a lot of the complexity that comes with the emulation process

fail0verflow did this exact thing when they first got linux working on the switch actually! https://twitter.com/fail0verflow/status/988543541403160576 It'd be a pain and a half to get a "proper" fast port with CPU emulation (either some lightweight JITing or natively running the code with hooks on SVC and such) and a GPU backend for the switch graphics. Not nearly simple enough to attract someone to do it on a whim with no other reason that to say it happened haha

Game mods. Want to play custom Mario Odyssey levels? Fiddle with save game data? Boost the resolution or FPS count? Quick save game state so you can experiment with speed runs or just for your personal enjoyment? Emulators make a lot of fun things easier.

It's also perfectly fine to want to play things in the intended way, of course.

(with a powerful enough pc) you can run games at higher resolutions and much more stable framerates on an emulator compared to the original hardware. Breath of the Wild is a sight to behold running at 4k, or even native 1080.

Would you be more happy playing choppy 20 frames from real Switch or max locked intended framerate from the emulator?

Since you're using your own Switch for this method (right? :)) then I'd imagine you could use your joycons?

How bad is it to just not have accelerometer? I personally tend to disable motion controls anyways...

I'd say it's worth it to use JoyCons even if you're emulating the games on PC. When they're not drifting, they're great controllers (if a bit cramped). I sold my Switch but I do miss the flexibility of holding my hands in whatever lazy position I wanted or using the gyro for aiming.

That said, it's trivial to use any other control or input device. You just might run into issues if a game requires motion control. I'm not sure but you might even get away with using a Wiimote, but I'm not sure what the controller support looks like there.

I would have loved to give this a try but it appears to require RCM on my existing Switch... and it's not vulnerable. :(

Probably more to do with morality than lethality. Pretty subjective, but there are definitely plenty of people who are morally opposed to piracy but have no problem with illegal backups/rips/dumps of stuff they have legally purchased.

> Just because you bought a cartridge with a binary and a license to execute that binary on a switch doesn’t mean you have the legal right to back it up and play it on your PC.

Do you in fact! As long as it is your cartridge and you backed it up yourself, you can legally emulate it. (You cannot use someone else's dump, nor can you share yours.)

Depends where you live,but in a lot of places the ability to make backups of your own digital media is enshrined in law. And in EU "license agreements" are usually worth as much as toilet paper, especially if they are implied rather than explicit (like, saying "by using this software you agree to this agreement" is essentially worthless, you can agree to literally anything and it won't hold up in court)

Why are you so certain? It seems that even a decade ago C# performance wasn't far off from C++, if not slightly faster[0].

[0] https://journal.stuffwithstuff.com/2009/01/03/debunking-c-vs...

Why the hate on C#? Are you perhaps thinking of languages like Ruby and Python and grouping them into the same bucket as C#? This[0] shows an example of C# vs C++ having a 10% performance gap on ray tracing. There is also no reason that extremely performance sensitive parts couldn’t be rewritten in Rust or C or C++ and called from C# over a FFI.

[0]: https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-lang...

As sibling comments indicate, the overhead of C# isn't what it used to be and certainly isn't comparable to other languages like Python/Ruby/PHP.

Of course, there's always performance left on the table when you write in a language like C# or Java (and even a little performance matters a lot when it comes to emulation), but the memory safety that C# can provide over C++ can save the developers a lot of debugging.

I think such an application can perform perfectly well in a hardware generation or two and until that point compatibility matters more than speed anyway; that's where ease of development will shine. Running an unplayable game well is not a very interesting project for end users.

When the project reaches significant compatibility, other emulators can take ideas from its code and port them to C/C++/Rust/assembly if they desire to do so.

Are any significant current emulators written in C?

The main emulators off the top of my head, MAME, bsnes (and the related higan) and dolphin, are all in C++.

> preferrably C

Why?

The other sibling comments were talking about general C++ vs C# performance, but I wanna get into some emulation specific context here that's missing. I was one of the contributors to the yuzu project since it was first started, and so I'm fairly familiar with the challenges of switch emulation, albeit I'm not going to pretend like I was one of the all-star devs responsible for making the magic happen. (I've recently stopped contributing to the project in order to pursue other interests, so i'm going to keep the information here general and not specific in case somethings changed in the last month.)

Let's start off by breaking the core performance portions of emulation into a few broad categories. There's CPU emulation, for running the actual guest exe, Kernel and OS emulation for handling the system calls that games make, and GPU emulation for translating the guest's GPU work into modern graphics API that your PC can use. Now let's compare how language overhead will affect each of these main scopes.

CPU Emulation - Both yuzu and Ryujinx use JIT compilation to recompile the guest ARMv8 instructions into x64 at runtime. The specifics of the two emulators JITs are pretty different, and it'd be cool to go into more details, but the mile high view is a comparison of C# vs C++ isn't going to have much of an effect on the runtime difference. At least not near as much performance gap between techniques and optimization levels that the JIT is capable of. The goal of JIT compilation for CPU code is to remove as much interpreter overhead as possible, so if your choice of programming language is slowing down the JIT, that suggests that you have somewhere else to improve in the JIT ;)

Kernel/OS - This is the area that will have the largest performance difference between implementation languages, but with the major caveat that Kernel and OS emulation requires the least amount of processing power out of the 3 categories mentioned here. The Kernel and OS are responsible for managing and scheduling threads, handling network connections, and etc, but really most of these things have fairly low impact on final application performance in comparison to CPU and GPU emulation. As a side note, emulators aren't the only groups interested in switch OS/Kernel work. The open source Atmosphere custom firmware for the switch is working through recreating an open source kernel/os for the switch, and the two emulators benefit from their work too. (See the licensing exemptions here https://github.com/Atmosphere-NX/Atmosphere#licensing)

GPU Emulation - This is probably the trickiest part of Switch emulation, and once again, it comes down to how you emulate it, and not the language you use to write the emulator. The biggest performance differences between the GPU emulation of the two emulators will boil down to technique differences, and not the programming language. GPU emulation performance can be roughly broken into two parts, the "actual" gpu running time, and the state management/conversion. There's only so much an emulator can do about the actual GPU running time since at some level, you are going to need to run the game's GPU code, but the other half is a whole lotta code to avoid doing more work, and much of the GPU performance optimizations goes here. Things like managing the game's GPU memory, avoiding changing or querying GPU state unless necessary, converting nvidia shader ASM into SPIR-V or GLSL, and so on, are not generally going to be bottlenecked on the emulator's language of choice, but on the algorithms and designs that you use. Also a side note, the average comment about how "easy" switch emulation is because of "off the shelf nvidia parts" really misunderstands just how much work goes into this part. Switch emulation benefits greatly from the open source nvidia reverse engineering efforts from teams like nouveau, and others working on open source GPU acceleration on the switch like https://github.com/devkitPro/deko3d but also a great deal of effort from the switch emu devs themselves, writing tests cases to run on the switch to find edge cases and document behavior. It definitely is not easy work.

At the end of the day, every drop of performance counts, but some drops are much much larger than others. As such, the advantages of any language's performance characteristics will be heavily offset by the design choices the emulator uses. The creator of ryujinx is very comfortable with C#, and with good development practices, there's no intrinsic reason that one cannot achieve good performance in a C# emulator. And if one decides that it's worth the tradeoff to do some extra work for performance in exchange for a more comfortable development environment, then I say let them do what they want.

Shoutouts to both the yuzu and Ryujinx teams for all their hard work. I loved working on emulators a lot, and highly recommend anyone who's interested in contributing to give it a shot, its a really challenging and rewarding kind of project where there's always something new to learn about in a broad array of subjects.