Since it's relevant, I should probably note that dumping your own game cartridges is perfectly legal. Using someone else's dumps or sharing yours is not legal. Many emulator projects have had issues with the latter and are extremely testy if you look like you are doing it.
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.
Belated disclaimer: I am not a lawyer, and I am certainly not your lawyer :) If you are interested in this kind of thing there is a lot of interesting casework in this area.
Yes, some locales pin the crime specifically on _distribution_ of copyrighted material. Downloading or possessing aren't restricted in the same fashion.
It seems like it's just a more old-school approach, based on a more centrally controlled market. If a publisher printed and distributed a book without authorization, would the buyers be liable?
Its one of those urban legends. There is article 23 defining "personal use":
Art. 23. Copyright
The scope of the work's own personal use
1.
Without the author's permission, you may use an already disseminated work for your own personal use free of charge. This provision does not authorize to build on the basis of someone else's architectural and urban planning work and to use electronic databases that meet the features of the work, unless it concerns own scientific use not related to profit-making purposes.
2.
The scope of personal use includes the use of single copies of works by the circle of persons remaining in a personal relationship, in particular kinship, affinity or social relationship.
But software is explicitly excluded by 77:
Art. 77.[32]
does not apply to computer programs art. 16 pkt 3-5, art. 20, art. 23, art. 23 ....
Personal use defined in article 23 might have something to do with copy tax we get on computer media like CDRs, USB drives and even ordinary HDDs.
I like how two of your sentences complement each other. You are in fact right about not trusting people on the internet - Its ILLEGAL to download pirate software in Poland. Movies and music on the other hand are perfectly fine.
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.
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.
Well, as long as you have internet, it's not like that makes things less mobile, it just gives you a local cache with your games where downloading is faster.
Yeah, if you file a bug with Yuzu, or join their chat channels and request support, and there's any hint that you didn't use your own switch you'll be banned instantly. They really do have a 0 tolerance policy.
For good reason, this is an emulator for a current-gen system, and from what I've seen on Youtube, a lot of games are fully playable.
Companies are likely not that bothered by legacy systems being emulated, but this is the current Nintendo flagship console. Thankfully the Switch seems to be selling amazingly, which should mean Nintendo don't really care that much.
Another factor is that you will likely need a pretty beefy PC to play games in full speed, and compatible controllers.
Not to mention that a significant portion of the value prop of the switch is its unique hardware, and the ability to seamlessly transfer an in-progress game between your TV and handheld.
I used chiaki. It works with any controller connected to your phone or even a built in touch control system that probably would suck to use, though i did need it for the home button and did have to remap controls bound to the touch pad buttons. We were even able to play borderlands on local coop that way despite only owning one dualshock 4.
They're right to be paranoid. Nintendo is one of the few game companies that's extremely aggressive about protecting their IP (particularly when it comes to emulation and ROMs). They've forced a lot of sites to stop distributing ROMs of games for their consoles and I don't doubt they'd come down with a massive life-ending hammer if they caught whiff of piracy in the Switch emulation scene.
If you say that, then I don't think you've paid attention to what they did to ROM sites in recent years. No other company has been as aggressive as they've been on this front.
Most projects of this sort are fairly touchy about that kind of thing, because they're at the risk of being canned if it seems like they are promoting piracy.
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 think almost all the interesting games on the X-Box either already being available for Windows or else having a just-as-good version available for another console is a lot of what kills interest for emulating it. You can play Halo and such just fine on a PC without an emulator.
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".
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.
The fact that its performant is tangential to the fact that its running on ARM android. IIRC Drastic still does a traditional JIT to recompile the guest ARM code into ARMv7a for phones (I might be misremembering, but I recall they had a whole lotta headache trying to update to support 64 bit ARM in time for the Android deadline for that. Also I remember them talking about tons of headaches dealing with the new storage APIs for Android)
Its really fast because of the tons of optimization that went into the application. It does many cool things to cut out overhead on the CPU side, but also it does a lot on the graphics emulation side, including hand rolled ARM NEON code for SIMD processing polygons. I'm not very familiar with DS emulation, but one of the devs for Drastic contributed to another project I worked on, so I had some chats here and there about these sort of things.
The DraStic developers have commented that they don't gain much if anything because it runs on ARM [1]. It's just an efficient emulator. If/when it is open sourced as promised, it will run very fast on x86 systems too most likely.
In any case, DraStic is a completely different style of emulator compared to Yuzu. The Nintendo DS is nothing more than a pair of microcontrollers with (from a modern perspective) primitive 2D+3D acceleration hardware, whereas the Nintendo Switch is a multiprocessor system with a modern GPU and mulitasking operating system. The DS CPUs are actually quite far removed from modern smartphone chips, whereas the Switch chip should be mostly standard ARMv8. Things that apply to one don't necessarily apply to the other.
Next step: emulating nintendo switch games on linux on their nintendo switch. Switchroot (https://download.switchroot.org/) makes Ubuntu (based on L4T) and android releases available for running on older switches.
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
But there is one for Linux distributions, released more than a year ago as binary only (not sources at the moment) called "Spine" (like as Wine Spine is not an emulator) that's pretty real and can run a few/couple of commercial titles.
Yeah, more a POC that a full emulator but I can assure you that it works, assuming you can decrypt the supported titles, so you'll need an exploitable PS4 or find a dump on the Interweb...
I find this interesting. But I'm not sure if I follow why I would want to do it. If I own a Switch(which I do) and the games, I'm perfectly happy playing on the telly! Sorry, just wondering.
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.
Thanks man. I honestly had no idea. I'm not a gamer. The reason I like the Switch is because it offers some fun cartoonish sort of games. Nothing serious. I can barely beat my wife in Super Smash Bros Ultimate! :D I like MarioKart and Rocket League (I suck at it too). I'd probably be more interested in running Linux on the Switch! It will probably brick it. hahaha.. I reckon I'm part of a very small segment of "gamers", even for Nintendo!
Actually, you're the target group. The Wii-WiiU-Switch are all based on "hey, that looks neat, let's try it" with a massive number of games designed for the casual crowd.
People like you aren't vocal in gaming communities or anything but boy do you buy games.
The disconnect becomes obvious in cases like Pokemon Sword/Shield where the community was OUTRAGED about a number of things (some complaints valid, some less so), threatening boycott... then the game comes out and sells millions in the first day. Do you realize that most people don't go to r/switch, r/nintendo or r/pokemon daily? Who knew!
You should try Zelda: Breath of the Wild or Mario vs Rabbids: Kingdom Battle, they're single player games and a lot of fun.
That is true. I have bought several games and I don't even play that much. I don't know much about Pokemon. I read somewhere that when the Switch first came out it was just a Zelda machine. I've seen my colleagues play it at work. It looks great. I'll give it go then. I've been mostly playing Asphalt 9 recently.
Although I don't play much games, I like to read about them for some weird reason. I was browsing the eShop today and saw Crysis listed there. Isn't that notorious for being very heavy on computing resources? I wonder how that'd run on a portable device like Switch.
(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.
This - 4K BOTW at 60FPS is really something. It's a shame the 60FPS messes with the physics a bit (it's not super noticeable if you're not already familiar with the game, but there's some fairly big differences)
Ah framerate breaking things always makes me think of Dark Souls at 60fps, making a bunch of jumps and skips harder, falling right through the floor sliding down some ladders, etc.
I was actually under the impression that BOTW ran at 60fps when docked, but I probably got my wires crossed and I'm thinking of resolution.
yeah, I'm sure. Someone who is passionate about these things will go the distance to use advance features like these. I know that the Switch isn't capable of running at 4K. I play it at 1080 on the telly. It's relatively large at 60 inches but I rarely notice any frame drops or low fps. Even if it did, I wouldn't be able to notice! But it's good to know that I could theoretically use 4K, with a powerful enough PC. I've a Ryzen machine and might buy a GTI 2070 or something like that for Machine Learning purposes in a few months. I'll save this link in case I want to experiment.
Ignorance is bliss. If it doesn't bother you now, don't go removing the veil by running it at 4k, you might not want to go back :)
This is mostly in jest though, the convenience of just using the switch wherever I want rather than futzing around with emulators still mostly trumps wanting it to look prettier.
hahahah.. True indeed. Ignorance is bliss! :D Yes, the Switch is pretty neat as it is. I guess serious gamers would consider a PS Pro or one of those fast Xboxes! :D
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.
There are various reasons you may wish to use it on another computer, and you may have the cartridge, but if you can't dump/decrypt it, then that won't work, so they will need to figure out how to work such a thing, so that if you do not have a compatible Nintendo Switch system then you can still dump the cartridge and use the necessary keys to decrypt as needed.
Pretty much every single switch game has already been dumped and will continue to be dumped and every single game +updates fits on a 5TB HDD. And I've never heard of any particular RCM vulnerable switch not being able to play specific switch games either.
So what you've said doesn't make much sense to me.
That’s a lot of steps upfront to avoid any hint of piracy, but you’re almost certainly breaking the license agreement by dumping the cartridge, so what’s the point in trying to avoid piracy.
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.
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)
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.)
Of these two emulators, Ryujinx is almost certainly never going to achieve a good level of performance, because they chose to write it in C# of all languages. Take my advice: if you're going to write an emulator, do it in C or C++, preferrably C. Ryujinx is a mind bogglingly massive amount of wasted effort.
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.
C# is consistently a worse performer than most javascript runtimes currently, and it's not much better than Python, Ruby, and PHP.
It's not just that. Basic patterns in C# are known to have pathological performance problems (implicit boxing, implicit heap allocations) that you simply don't run into programming in C or C++. These are things that tank performance in day-to-day programming that do not show up in carefully tuned benchmarks.
Source: Helped profile lots of C# games (not IL2CPP with Unity, although that's pretty bad IMO as well), not pleased with what I saw.
> C# is consistently a worse performer than most javascript runtimes currently
This is a bold claim. Please provide evidence that the most current .NET implementation (.NET Core 3.1) is slower than any JavaScript implementation.
This doesn't pass the smell test since you're comparing an ahead-of-time statically typed approach to a dynamic scripting language, both of which have had highly tuned JIT implementations, both of which are using garbage collection. You can implement things poorly in C#, sure, but you're making a much stronger claim of consistently poor performance.
C# currently 1st place in this webserver benchmark. Ahead of C/C++/Go/Java/D.
No offense to JavaScript, I like it and it has its uses. But surely your OP is joking when saying JavaScript is faster than C#. Even after all the performance improvements that V8 received.
At least C# has things like the struct keyword to prevent heap allocations for simple data structures. I don't know if recent Java has caught up with this, but it was one of the innovative features MS came up with for .NET to avoid unnecessary overhead.
I feel like it's possible to write careful C# for performance. It just won't be entirely idiomatic. Things like buffer re-use, ordinary techniques you'd need to apply manually for C and C++ in similar domains too.
A large part of C#'s advancements are that additional abstractions have been added in .NET Core to make at least some of those concepts a bit more idiomatic, especially around passing segments of memory around.
>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.
It really doesn't matter how much headache it saves you in debugging. The problem simply cannot be solved at the required level of performance if you use C#.
>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.
The only legitimate use of this project is as a research bed for future emulators, so I agree with you there.
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.
C# is garbage collected. Even if the performance potential was as high to begin with (it's not), that's a non-starter for heavy games because you need to be able to control & predict the performance spikes that GC creates. That's even more important for an emulator, which needs more predictability than a regular game.
Emulation involves a lot of large byte arrays and static structs that your code updates a lot to represent the hardware. It isn't necessarily creating a ton of objects all the time. I do not have specifics on hand for these emulators but it's not hard to imagine that they could well be running the GC for a few microseconds every few minutes or something [1]. It is a very different type of program than a traditional game, or, indeed, almost any other kind of program.
There does seem to be this odd semi-subconscious idea in the "GCs aren't appropriate for any high-performance" world that they intrinsically work by stopping the world for 50ms several times per second or something, but that does not have to be the case.
[1]: I actually have a number of servers in Go that run on about this schedule. If you eliminated 100% of my GC cost for these servers, I wouldn't care at all, or even notice.
> Emulation involves a lot of large byte arrays and static structs that your code updates a lot to represent the hardware
Things work a bit differently for "modern" emulators, where the emulators recreate the kernel/OS at a high level. In these emulators, the games will call into the system, and the kernel will be expected to do all thats necessary for the call. In the high level approach, this means that if a call allocates, so does the emulator (edit: note that this is a simplified view, as both emulators map a 4GB page that they work in for the guest system memory, but theres still a ton of side allocations that happen "outside" of the guest kernel). There is a lot of work that goes on in this layer of emulation, and theres going to be objects that the emulator allocates and later destroys. Process tables, thread lists, scheduler information, timing events, kernel synchronization primitives like mutexs, and so on to name some. I'm not intimately familiar with Ryujinx to make any statements about how they handle GC of course, but its something that they'll need to take into consideration. That said, there's plenty of other things like JIT compilation, shader compilation, caches filling up, and on and on that all also cause micro stuttering, so its not uncommon for even C or C++ emulators to have annoying pauses too.
There are a number of ways to control the GC in comfortable ways in C#. https://adamsitnik.com/Array-Pool/ comes to mind, especially for games. So you can lean into GC when possible, and switch to an unmanaged approach when you are seeing perf issues.
Building contrived tests which "prove" the performance of C# in the face of mountains of evidence to the contrary is on a much different scale from emulating an entire complicated hardware system.
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.
redream is a Dreamcast emulator written in C only. libretro (the core API behind Retroarch) and Retroarch itself are primarily C. mupen64plus is in C, although the common 3rd party plugins and frontends are not always in C.
qemu, a dozen gameboy emulators, dosbox, the 9front emulators (NES, SNES, GB, GBA, C64, 2600), xemu, z80e, and many, many more. Lots of the C++ emulators you're familiar with have the performance critical parts written in C as well, excepting some newer emulators which leverage something like LLVM for JIT emulation.
I once spent 3 years on a C project and I realized it's strength is that it does not change. I didn't feel the need to rewrite it with latest features like one might with C++
Pretty much all (modern) HPC I'm aware of is C++. Now I'd be the first one to agree researchers aren't the best programmers, but I also think that is not the only thing that matters. C++ allows huge teams to cooperate in getting a lot of stuff done (there isn't a single CERN result that isn't verified against C++ generated data for instance).
C++ is like a natural language at this point: very crufty and layered, hard to use sometimes, even ugly, but you can do a ton with it and if you work with the language you can even write poetry in it ;)
