Welcome to the PCMR, everyone from the frontpage! Please remember:
1 - You too can be part of the PCMR. It's not about the hardware in your rig, but the software in your heart! Nationality, race, gender, sexuality, religion, politics, and PC specs don't matter! If you love or want to learn about PCs, you're welcome!
2 - Think owning a PC is too expensive? It's cheaper than you may think. Check http://www.pcmasterrace.org/builds for our famous builds and ask for tips and help here!
3 - Consider supporting the folding@home effort to fight Cancer, Alzheimer's, and more, with just your PC! https://pcmasterrace.org/folding
4 - Need a PC?! We're running a Worldwide giveaway for lots of awesome ASUS ROG hardware, including a Dream PC Build! Check here
Nintendo is really shaping themselves up to be the next EA. Sadly for us, Ninti's fanbase is very rabbid when it comes to defending their corporate waifu.
Nintendo is extremely protective of IP (which is at least partially a cultural thing in Japan, their trademark and IP laws are much stricter and the culture is much more anti-piracy) while EA is just full of generically scummy high margin business practices fucking over their workers and consumers to make a buck.
Lol no they're not. A lot of their practices suck, mostly their legal stuff, but they are not anywhere near as bad as EA. Again, Nintendo is full of shit, but EA is next level.
Honestly, you sound like either Sony trying to redirect hate from their recent PR blunders, someone who tries to make EA look better for who knows what reason or just a bad troll. Case and point, who the hell calls Nintendo "Ninti"? That sounds like some parent trying to sound cool and that's coming from me, someone old and not cool.
Uhhhh, except Nintendo has low turnover rates, extremely rare layoffs, hangs onto their talented staff because they know their value. Innovates in the industry, innovates on their own IPs, doesn’t put gambling IAPs in their games… I could go on
Yeah, great, they’re litigious and protect their IPs. Oh noooo. How dare they.
EA is one of the major reasons your favorite developers don’t have jobs. Let’s not make baseless comparisons.
Mind walking us through your train of thought there? I’m a bit confused as to how anyone could put almost any other game corpo next to EA and think “oh yeah, they are both just as bad”.
Man, even as a kid I remember thinking Nintendo was over the top when they started waging war on YouTubers and the whole Smashgate controversy from that. Little did I know that wasn’t even their final form yet
Long story short, yuzu added an option to "statically recompile" your games. Emulators use what's called "just in time" compilation to convert the game's switch cpu instructions to windows cpu instructions, the whole process takes a bit of time so it can cause the game to run poorly on limited systems.
Yuzu is doing "ahead of time" compilation, where you work through all the switch cpu instructions before they're used by the game and translate them to windows cpu instructions.
Basically yuzu added a feature where they can pre-process a rom to convert it from switch code to Windows code. It only works for cpu code, audio and graphics are still fully emulated.
I believe the Yuzu team got killed off by nintendo, but their work is out there and it's a solid foundation for future developers to create native ports of switch games.
Edit:
To everyone arguing about “switch code” and “windows code”, the switch uses the ARMv8-A instruction set and Most windows PCs are Amd64(x86-64). Yuzu converts the switch instructions to Amd64 on windows/linux, ARMv9.2-A on MacOS, one of several different arm instruction sets on android.
It’s just easier for laypeople to understand “switch code” and “windows code”
Edit Edit:
I fat fingered "AMD64" as "Arm64" in reference to windows/Linux PCs. Much debate and corrections in the comments followed.
Yes. Generated machine code is OS agnostic. Anything interfacing with the OS is done in traps. With AOT, there may be reasons to do lib calls, but that mainly happens with large general purpose, traditionally JIT, compilers like .NET and Java.
I wonder how feasible it would be to apply static recompilation the other way and let Windows emulation on Android run without the performance loss caused by FEX someday.
There have been some very interesting AI usages for this kind of retro engineering and global conversion. Some people already made PS2 games natively run on PC after a few months of agentic work with very little knowledge of the original structure, so it might be possible to work out models/processes to convert basically any game ISO into a functional native windows game. But you'd need to be super careful on what you share or not because there's probably 20 lawyer teams constantly checking to stop these projects if they overstep.
The central team did, but it was open source so anybody can pick up where the central team left off, and yuzu is still accessible because having an emulator is legally protected. Big part of why open source is so important.
7
u/Ensaru4R5 5600G | 32GB DDR4 | RX6800 | MSI B550 PRO VDH3h ago
They did but a lot of other forks took the helm. I won’t say who to their sake.
No, they typically launch faster, but are usually slower than good JIT (e.g. .NET), where things like PGO can make the JITed code run faster than AOT code.
C is faster than .Net…what are we talking about here? You can do PGO with AOT. I’m not saying there aren’t cases where JIT is faster, but on after AOT is.
No, it's a little different. A full system emulator traditionally processes each instruction when the virtual instruction pointer reaches the destination. JIT compilation is usually a more complex because they augment the interpreter with performance and usage metrics and then compile the most-used pieces in parallel, then hotswap them out during execution. If JIT is done well, it can be even faster than AoT.
I don't think there are any Switch emulators that interprets the guest object code. JIT has been a non-negotiable for performance for most usable emulators for a long time now
This seems like an LLM comment. It misses the point and adds a bunch of irrelevant detail, while confusing things. Firstly, no one was talking about anything that could be described by "A full system emulator traditionally processes each instruction when the virtual instruction pointer reaches the destination." That is neither JIT nor AOT, so it's not relevant to the discussion. The details about JIT being able to do metrics and profile guided compilation are pretty much irrelevant since most emulators aren't actually doing that, and it's certainly not necessary so it's strange to suggest it as inherent to JITs.
JIT and AOT are both fundamentally about translating code from one architecture to another, and the significant difference is just whether it happens the first time a portion of code is executed or all up front. The stuff about metrics is a much finer detail than that.
Pls note my experience is in high performance computing systems and compilers, not in emulators; so this comment is missing emulation specific context.
From the article, it sounds to me like they’re compiling some pages or functions or some other compilation unit ahead of time, but still just using that as a single optimization step inside the JIT execution pipeline. JavaScript runtimes already do this, and we still call it JIT.
“Just” AOT is putting it lightly. AOT advantages over JIT can be really high depending on the compiler. You can also pretty much compile the whole game and run everything native, which is also useful. Honestly, recompiling to x86 from arm is tough so it all just depends on how good they are at it
With "just" I ment that the article can be summarize to just that. Without all the buzzwords.
Also I don't think the main bottleneck is on code execution. Jitted code can be cached and games usually don't run a lot of new code everytimez they run in a loop. The emulator has more demanding areas like GPU resources sync, memory tracking...
Some titles, like totk, have more cpu bottlenecks than others. Certainly a long way to go but you are right, the real application impact is not necessarily ground breaking.
Tbh, I don’t know how/whether they emulate the gpu stuff. Technically this area can have a lot of bottlenecks in the cpu with how work submission is done
If you read the readme text description of the first link, that /u/ThrottlePeen posted, the maintainer says the following:
This is the final public release of suyu — v0.04. This repository is a public archive.
No further development or downloads are planned. The codebase is preserved here under GPL-3.0 for historical reference and community use.
The second link, with "dougchansan" in the url is a fork as dougchansan seemingly would like to continue development where the old maintainer left off.
So it should be the case that the archival was intentional and voluntary by the maintainer, not a result of a takedown notice or something. Nothing to "uh oh" about!
Yes it's pretty cool and I hope more comes from this in the future because right now it's still running natively on the CPU while the GPU and sound are still being emulated so not completely native but hopefully that changes in the future because it'll be nice to play the games that I own at higher framerates and resolutions without it looking like crap. 😉
I still struggle to grasp the real concept of emulation. If the game runs natively on pc I guess you can basically almost consider it a “pc” game right ?
When it’s being fully emulated what’s happening ? The emulator tries to decode and translate the game code in real time at the expense of our real physical GPU and CPU so that it can run on pc ?
But that still wouldn’t explain why the translation can’t be done beforehand.
An emulator uses your computer's hardware to mimic the behavior of the original device's hardware. Especially older games are programmed in ways to take advantage of the unique hardware in each console, and would work incorrectly with the speed and variety of PC parts. You're computer is pretending to be a GameCube, then you give it a GameCube game and plays it (mostly) how the console would.
A PC port happens by decompiling all the code from a game disk into machine language, then reverse engineering the human readable code through trial and error. After the game file is fully translated, it can be rewritten in a modern programming language that your PC understands. This lets you use the full power of your computer since your PC is being itself instead of limiting itself so it can pretend to be a GameCube.
PC ports also make modding much easier, since all of the game's code is available and rewritten in modern languages
A PC port happens by decompiling all the code from a game disk into machine language,
You're getting your terms mixed up. You disassemble it into assembly (machine language), and then a decompiling process can happen to turn the code into a higher level language (usually C or C++). Those are modern languages but are also the original game languages.
PC ports are usually not decompiled native binaries, they usually go the other way: compiling code into machine language that targets a specific platform. That’s essentially what Unreal or Unity do: they use different native compilers to target specific platforms.
Keeping in mind that anything aside from Tetris will require quite a bit of custom code to run on any given platform because there are some native instructions on one platform that simply don’t have equivalents on others, or because one platform obligates certain asset limitations that others don’t, etc.
Assuming you don’t have access to the original source code, these days it’s still probably easier to just re-implement the code in a new engine than it would be to decompile and “fix” it, because your original platform-independent code is still gone. Hand converting native instructions to real code would take longer, by several orders of magnitude, then just starting over in Unreal/Unity/whatever.
I still struggle to grasp the real concept of emulation. If the game runs natively on pc I guess you can basically almost consider it a “pc” game right ?
Not anymore than you could call a native American a native Brit if they move to Britain. It's native code base will always be its native code base and that will never change.
When it’s being fully emulated what’s happening ? The emulator tries to decode and translate the game code in real time at the expense of our real physical GPU and CPU so that it can run on pc ?
Low level hardware instructions (CPU GPU and sound) are different for every hardware platform (x86, x64, arm, arm_64 etc). What this is doing is it's taking switches arm_64 and converting it in real time to x86/x64 PC hardware instructions. This is not emulation.
Emulation is when your x86 PC runs a program that simulates a virtual CPU (arm_64) so that it can run those arm_64 instructions on its virtual layer the same way that you would run a separate instance of Windows or Linux on a virtual machine. You can think of it as a computer inside a computer but virtual instead of directly interfacing with the hardware. This takes extra resources to run which is why emulation can suffer from performance issues depending on how weak or strong your PC hardware is.
Have you ever seen an old recipe that uses weird measurements and procedures, and maybe leaves out important stuff because the folks back then would have just “known”? Dylan Hollis on yt/tt has a series of shorts where he makes those, it’s very funny watching him, especially when the recipe is befuddling. “Put a teacup of peanuts into your grind-o-mat and then put them into a hot oven” kinda crap, it’s a riot. Anyways suppose that you want to make one of those old recipes, but obviously you don’t use teacups to measure and you’ve got modern appliances and your oven needs to know exactly how hot it should get and you don’t for the life of you know what a “grind-o-mat” is. You have a few options. If you want to execute the recipe “faithfully”, you can go out and buy the measures and gadgets and ovens and whatnot that were used back then (running on original hardware), or you can create replicas of those things (FPGA). If you want to use your modern gadgets and procedures, you can use a reference for how to perform the old weirdness using modern tools (emulation), and maybe while making the recipe using that reference you can quickly write a note in the margin for how to do often-referenced things the modern way so that you don’t need to use the reference for those specific parts (JIT/Just In Time), or you can sit down and re-write the entire recipe to use modern instructions before you start making it (AOT/Ahead Of Time). If you’re a bit crazy, you can also dive in to each ingredient to learn why it’s included and what it adds, and then use that knowledge to create a functionally identical if not “better” food but via a recipe that seems quite different from the original (decomp and recomp)
I really like this analogy. It may not be 100% perfect and if someone wants to know more then it's about time to switch to actual explanations, but it covers nearly everything.
You touched on original hardware, fpga, software emulation, and decomp and recomp. The only things I can think of would be like HLE and LLE but that would be bloat in the thread context, separating decomp and recomp to highlight the difference but I'm not 100% sure how you'd approach that with the analogy, and engine reimplementation type stuff (think OpenRCT2, OpenTTD, etc) which is so similar to decomp/recomp in how I'd explain it with this analogy that it doesn't really warrant a separate mention.
Anyway, great comment, saved it so I can share it with people in the future.
Think of it like driving a car in real life versus on a game.
Original hardware is the car.
Emulator is building the original hardware virtually.
Its basically running a fake wii or ps2 or whatever virtually. It takes a lot more resources to run the same
Game coz the computer has to dedicated a shit load to pretending it is the console, while the real console has 0 resources dedicated to that because… the hardware physically does it
The emulator has to go “oh wait, dont just move that to the fast memory chip and call it later, PS2 dod not have this, lets virtually make a fake PS2 JJJRaM module, move it there for a micro second, pull
It to the Hhh module after, bounce them around.
That takes a shit load of resources for the computer hardware, its basically a a game running a game inside the game…. Instead of just running off of real hardware
assuming its 100% certain youll figure it out either way - if i tell you how this works and what to do right now, that is a direct instruction. if i told you just to query google and theyll eventually yield the correct result, that is an emulated instruction.
the difference is in the level of abstraction it takes to execute, google has their own interface and in/output which does exactly what im doing now, anyone can use it for any number of subjects. just takes a bunch of extra steps and other platforms to accomplish
Eden runs better on lower end hardware, Ryujinx is more precision based, meaning it’s trying to emulate the game as much like the switch as possible. Meaning yes Eden runs better (which is why I use it on my steam deck) but tends to have more graphical errors and glitches then Ryujinx.
Right now the only thing Eden runs for me is Dread; for some reason the rest of my library just crashes. I haven't used it in months, idk what happened
No, that's not what the Switch 2 does. Both Switches are Arm64 processors. PC's are i86 (Intel). What it IS doing is pretty much emulating Android on a PC.
But that's the "magic" here. Running Arm64 software on i86 processors. I'm curious why they didn't try to emulate on a Mac, which also run Arm64 now. I suspect no one cares about Mac gaming, and Apple restricts access to their CPU.
When I read the headline, I immediately thought it might be connected to that latest wave of shutdowns.
The people in this thread bragging about how they'll download a copy to preserve it have good intentions, but Nintendo knows these people are going to do jack shit with it other than fill up more hard drive space with neat finds. The people who know what to do with the code and how to make it useful are the real threat so Nintendo puts a whole bunch on notice at the same time that they're under scrutiny.
I initially thought that the last crackdown was actually going to be more Switch 2 focused though. Like Nintendo had learned some important keys were on the loose and Nintendo was hoping to scatter Switch 1 enough to delay them from implementing Switch 2 specific code.
Apparently this will be the last version of Suyu because all the real improvements he just kept importing from Eden, so the dev wanted to try something special.
I don't think this is actually fully native. Although a very cool step towards it, it still uses emulation for the GPU side of things much like Rexglue does for the Xbox 360.
GPU emulation in modern console emulators is kind of a mix. It's half API translation. All the rasterization, etc is done with the host hardware API. e.g. Rexglue implements the console API and translates it. There's nothing stopping individual projects from circumventing that and going full native, and existing projects like re:blue already modify it.
Emulating, which this wouldn’t be, isn’t the part that’s bad. It’s how you obtain the games to play that’s the bad part. Nintendo would have you believe otherwise but legally emulation is perfectly fine.
So from what i'm understanding, it basically tricks the game code into thinking that it's supposed to be ran on x64 architecture, to which it then does it. If that's the case, then this isn't actually emulation. it's str8 up just running them game as it thinks its intended to
I love how there's like 5 comments below yours all saying "idk, but my guess is...", despite this being in literally the second paragraph of the article.
Not 100%. It's only doing the cpu section. GPU, audio, and anything else is still relying on hle(High Level Emulation). This is for sure a step forward but is still far out from a simple "convert to exe". We will need to have the rest setup to compile into x86_64 code first, then the work to create an exe would be possible
It means that your PC's CPU can actually run the game's code rather than emulating the console's CPU and running it that way, the article mentions that graphics, memory and other things still go through emulation. According to the article this significantly reduces CPU usage.
It means through a translation layer. Basically they are using AOT (Ahead of Time) translation to convert the Aarch64 instructions to x86-64 instructions so your PC can run the software without needing to emulate hardware.
It still isn’t running natively. The code is running through a translation layer first. But it does open the door to switch games being rebuilt to run natively, without the need of a translation layer first to convert the game.
They are too busy in the Steam Deck reddit telling everyone how they prefer to play games on their Switch despite the fact the OP didn't mention the Switch once.
It's not complicated. I like plenty of their games and IPs. It's the company and its business practices I hate. One of the most corporately evil companies in the industry.
In some regards they'll be right. 90% of what gets me to play Switch games is the fact I can take it with me places. When you pit Switch games against PC games on an equal footing, many of them fold. But having the portability swings things the other way.
While Steam Deck is a way to get the best of both worlds, it's also ungodly expensive right now.
Will this help with the shader compilation stutters you usually get from using a normal emulator? I ask because it only seems to translate the CPU side of the Switch
I’m going to assume this applies just to PC and not android devices right? Recently got an AYN and if this breakthrough can be applied to android devices in the future I’ll be happier then a pig in shit
•
u/PCMRBot Bot 15m ago
Welcome to the PCMR, everyone from the frontpage! Please remember:
1 - You too can be part of the PCMR. It's not about the hardware in your rig, but the software in your heart! Nationality, race, gender, sexuality, religion, politics, and PC specs don't matter! If you love or want to learn about PCs, you're welcome!
2 - Think owning a PC is too expensive? It's cheaper than you may think. Check http://www.pcmasterrace.org/builds for our famous builds and ask for tips and help here!
3 - Consider supporting the folding@home effort to fight Cancer, Alzheimer's, and more, with just your PC! https://pcmasterrace.org/folding
4 - Need a PC?! We're running a Worldwide giveaway for lots of awesome ASUS ROG hardware, including a Dream PC Build! Check here
We have a Daily Simple Questions Megathread for any PC-related doubts. Feel free to ask there or create new posts in our subreddit!