i gotta ask, what kind of career path does one have to have to figure out how to make this sort of thing? just hacking nights and weekends for 2 years straight? because i dont know how anyone gets paid to do this and yet there is so much incredible depth to learn that is probably undocumented because of legal issues
I've worked on large projects for almost 10 years before I started working in the field, though perhaps not as complex as an emulator.
I dropped out of college due to medical reasons and was given the "opportunity" to receive disability benefits for the rest of my life. I accepted this and just continued my hobby doing programming. In that time I met many hobby programmers online who didn't seem to work or were temporarily taking breaks from studying to eventually find a job.
Eventually I felt a bit lonely not knowing anyone in real life who were interested in programming, so I found the meetup website and started going to events to get to know people. The friends I met there told me I should try working professionally as a programmer, so I tried and now I've been 5 years in the field and really enjoy it.
In retrospect being outside of the professional field, I knew it existed but it never crossed my mind that I could be part of this as it was for educated and highly experienced programmers only. Because of this maybe I never bothered to even try.
One issue for me entering the field was that I was highly specialized, but the field required me to be more general and perhaps specialize more in other things. Luckily for me I found the right people from the start with similar interests (game engine development, graphics rendering, etc) to help me understand the professional landscape.
I still find it satisfying to work on hobby projects in my spare time. I don't have as much time as before because of work and family, but I do manage to find the time now and then. :)
I fell into professional programming basically by accident... was a web developer by education and ended up being offered a position as a mobile developer for iOS as my first out-of-college career. Wasn't what I intended but they extended the offer and said offer included paid education in the field, so who was I to argue?
Years on I've gone through a few jobs and basically never used my web development degree for my day job, only really using it for side-gigs building websites for local businesses.
Good for you! Too many people are in it for the money and pure self interest.
Now, I like the money our profession pays, it’s great - but I’d by doing something with computers either way, so what a blessing to get rewarded financially as well.
Also, as an erstwhile professor who was at a top 3 program, a motivated and curious student is the best. If you had finished college you’d have done well with your attitude.
Right. In my experience, in nearly any professional discipline, words like 'passionate' and 'hungry' are often management euphemisms for 'has trouble drawing boundaries with work, and cares more about getting it done than work/life balance and their own wellbeing.' I think most of us get nerd sniped and spend half the night working on something every now and then, but that's not something any employer is entitled to.
I feel the opposite. I've been programming for fun since 13 and have a similar experience as op - where I did my own projects for ~10 years before I got a job. I always hated professional programming.
It's boring, problems I'm solving are technically trivial. Most of the real problem is tied to a domain I give 0 shits about and am so bored by that I have to force myself to stay focused. Things I build have practically no value to me, and often no value to anyone except that someone decided to allocate a budget that way.
I would never work on these projects if it didn't pay well. I would prefer craft work if it paid the same.
I'm not complaining though ! I live very comfortably, I came from extreme poverty and I don't see any realistic alternative path that would end me in a better situation.
But I think expecting people to do most programming jobs out of passion is not realistic. If you're really good maybe you'll land in a role that gets you doing something technically innovating that also pays well but I'd say that's top few % of devs, most of us are in the dredges where enthusiastic people are a detriment (worst projects I've seen were a result of someone trying to be too clever for their own good, not lacking skill)
You yourself say the financial rewards are a blessing. Sounds like you’re in it for the money, too. If you’re not, your boss might OK a 20 or 30% salary decrease should you request it.
It is possible to be involved in something for various reasons, but it does not mean that one should willingly forego a benefit. "In it for the money" implies that the primary motivation is high pay, whereas "not in it for the money" indicates a strong preference for the type of work and a willingness to accept lower pay if market rates were to decrease.
Replace programmer with dentist, trading or lawyer, how many work on it by passion ? On evenings unpaid side projects? For guitarists, or artists its not the same (hint: which pays generally more?) , so I would say programmer is a middle ground, from cobol bank programmer to gamedev
I'd bet you've got a very skewed view of how people who make their living programming do this outside of learning something to help them get a better job.
Yes, just hacking nights and weekends. I've done my fair share of console reverse engineering, developing software for console devices (mostly GBA and NDS development, but a fair bit of SMS and Genesis reverse engineering), etc, and it's seriously some of the most fun I've had as a developer. But it takes an enormous amount of tenacity to push through the inevitable challenges.
This 1000X ! I'm currently working on emulating the Apple 2+ speaker better. It's been a 2-3 spare time hours a week for about a year now :-)
But the joy of working on a machine that's part of your life, without the need to please end users (which is cool too but sometimes induce pressure), well, that's basically coding like when I was a kid. Except that now I have a TON more knowledge to work with !
And, while working on disk emulation I had the pleasure ot discover those many copy protections that "prevented" me to get many games :-)
And the other thing I love about it is the communities are typically super open and collaborative. I remember back when I first got into GBA development, there was a ton of docs, tools, libraries, and other things that folks had put together and then shared with one another. It's a lot of very passionate people sharing some very niche interests, which can be incredibly fun (of course it can also be a drama filled nightmare but such is life with passionate people).
To this day I consider TONC (https://www.coranac.com/tonc/text/) to be the greatest software project I have ever worked with. It touches everything you need to develop games for the GBA. The documentation is awesome on many levels. The book is great. I am just thankful that I found it when I was younger as that introduced me to a whole lot of critical knowledge.
Agreed 1000%. The issue I have is that its a bit of a shame that we don't have current fun platforms apart maybe from embedded (current gpus are closed, cpu and memory are often not a challenge if you are just a little, unless you use it for huge projects). Or am I mussing something ?
how do you guys find the energy to hack nights and weekends? I do enjoy hobby programming but it takes me at least one week of vacation to detox from the work grind so I end up doing it only when I have extended vacation
> how do you guys find the energy to hack nights and weekends? I do enjoy hobby programming but it takes me at least one week of vacation to detox from the work grind so I end up doing it only when I have extended vacation
Namely passion, curiosity and probably not having much more other hobbies beside programming or hacking stuff around.
I recently went to try to improve a Linux kernel input device driver for a USB headphone: adding unit tests (whose execution is nearly instant). I have learned a ton of things about Linux development, C (I don't know C at all), input devices driver system (hid), the USB protocol and my device specifications.
I have never managed to boot it live to test with my actual device. That is despite spending probably despite spending probably 40 hours including a 10pm - 4am session on a Saturday night. But I had lot of fun doing it and I think that was the point.
Working with code day to day has almost fostered in me a sense of contempt for computers. In high school/college, I spent a lot of free time doing rom hacks, etc. I just can't now. Now my tech hobbies lay more around arcade repair/modding. Knowing what I know now, I wish I could muster up the energy to combine the two and work on projects similar to UMK3+ [0], but I just don't feel like sitting in front of a debugger all evening after coding all day at work :|
I guess in my case, I had to find a hobby that was not exactly like work, even if it was work-adjacent.
When I was more junior, or not doing programming as a full time job, I was more motivated to work on personal projects. Now I am more senior and programming/managing people full time, I can't get motivated to work on code-related projects in my downtime. It sucks :/
Same, I never code personally as much as when I'm in a management position. When coding during the day (which I like very much), I have less side projects or they tend to languish.
Honestly, it happens when I get some weird idea in my head that I can't stop thinking about, and a sort of mania takes over and gives me the energy and drive to work on it for hours on end.
Ditto, that kind of mania is a force to be reckoned with. On one hand you get insane productivity and momentum from it and on the other hand can cause you to momentarily neglect some responsibilities. I have a love/hate relationship with that side of mine.
That's about the only time I can do honest work programming. It makes me avoid doing programming tasks at work and try to find more writing-related stuff ...
It helps when the end goal is really well defined like a software emulator. Nearly everything that could slow you down is a known quantity. Conversely, the unknowns, like how to implement native hardware API X on non-native non-accelerated platform Y, are naturally where community emulators are weakest.
(not that you should take advice from random strangers on the internet, but) that sounds like classic ADHD hyperfocus to me. Giving a name to it might help in figuring out how to maximize its benefit.
I experience the same hyperfocus, but I don't have ADHD, I'm quite the opposite really.
My background is design and when I was a child I could easily 'get lost' in various forms of art etc for hours. I've met plenty people over the years that are the same, so I'd argue it might be something more aligned with some creative and analytical thought process, and a drive etc to understand/solve the problem at hand.
In terms of where to find the time, there are 24 hours in the day, at least 8 for working the 9-5.
I have spurts of this, occasionally I’ll spend a month of evenings/weekend time doing a project. It’s usually when work isn’t scratching the right sort of itch, so I scratch it elsewhere.
Personal projects are often embedded coding of some sort, though I spent some time poking at the PS3 firmware when that was first cracked too.
Spending months reversing and emulating a console… that takes dedication I don’t have though. I guess these guys are really itchy? Or it’s in a really hard to reach spot?
The key for me is that it has to be 100% fun. As soon as I start thinking about external recognition or trying to make money off of a personal project I lose motivation. Right now despite coding all day at work I still have the energy for coding on my own time on a NES emulator just because it's really fun.
in addition to what the others have said, I go home every day at 5 pm, no crunch or grind, no work calls outside of working hours. (luckily I live somewhere where that is guaranteed by law).
I think keeping a schedule that way has prevented me from every souring on programming in my free time.
This is a good place to start. Named "the ultimate game boy talk" dives into the CPU used, the instruction set(s) used by the CPU, how the video instruction sets work(ed) etc. The game boy from 1989 is a pretty simple device to start learning from. From there you can look at how various people emulated the system.
I second this. I also have a web background, and last year I started with this video, and the Gameboy is a great place to start with this sort of thing.
Start making a game, and you'll soon realise how the CPU works, and making a simple emulator will start to seem very possible.
"Maria Markstedter – a noted author, assembly language expert, and security researcher who's written extensively about Arm at the websites she operates – received a cease-and-desist demand from Arm's lawyers. Her offense? According to the letter she shared on Xitter, using the trademark "Arm" in the domain name arm-assembly.com that she used to promote a book she wrote about the ISA."
So, to be clear, I spent my time reverse engineering software rather than the hardware itself. That said, my observation is that a lot of hardware reverse engineering is software reverse engineering since the software helps you understand how the hardware works (the Asahi guys literally built a hypervisor so they could watch macOS interact with hardware).
And software reverse engineering is just grunt work. I'd start with a very well known existing hardware platform with a very simple CPU design--the GBA is actually a really nice platform as the ARM has a very sane ISA and it's all memory mapped I/O--and get a devkit and start experimenting by writing software to run in an emulator so you can get a feel for how the hardware works.
> just hacking nights and weekends for 2 years straight?
Yes. Believe it or not, the primary author of the ARM translation engine used in the other major Switch emulator is a medical doctor ("IRL white mage", as she sometimes puts it).
Emudev is largely a hobby field. It takes skills from many fields to accomplish. You need the combined efforts of hardware engineers, reverse engineers, diligent documentarians, software engineers with specialized skill sets, etc. Everyone building on top of each other.
You'll see one-person operations, but they're usually relegated to older hardware and they still utilize documentation from many disparate sources. Even nesdev wiki was built on top of 6502 researchers, Taiwanese clone manufacturer reverse engineers, decappers, older NES emulators, heaps of existing documentation, etc.
There are many jobs for emulation development though. Every company that makes chips has an interest in having software emulators of them since it's easier to try out a new feature in an emulator than to write it in hardware. For example any GPU maker (AMD/NVIDIA/ARM/Qualcom/Imagination/Apple etc) will have a team of 10-100 people working on one or several emulators for their products.
My very first paid job in 1997 was extending a PC emulator product for an ARM desktop computer with a 486 co-processor. I was a teenager who knew a bit of C & ARM code, otherwise no hardware or x86 knowledge at all. Obviously PCs have always been quite well documented, and there were other emulators to look at for comparison. But where I couldn't work it out, and the few books I had were no use, I just had to experiment: write a bit of code, see what the response was (usually crash, sometimes the whole computer).
A lot of it is building a mental model of the enemy (for me: Windows NT early boot, DirectDraw initialisation) and writing code that got it to the next step, and the next step... It was always slow work, but therapeutic once you find a thread to pull on. When you get it right, the reward is sudden: you have this alien world that is running where it shouldn't, like a fish swimming in a tree.
"This sort of thing" is actually really simple to get started with. You just read a few docs about the object-code format and instruction-set of the device you want to emulate, and then start writing a simple interpreter loop that reads and executes instructions from any arbitrary existing program ROM. Compare and contrast the results of running it on your emulator with running the same thing on real hardware (or on some other emulator.)
As soon as you get one well-known program working and displaying something on the screen — congratulations, you've made "an emulator"! Now all that's left is "just" debugging the inevitable compatibility issues that your emulator will encounter with every other program ever compiled for the target architecture. It's like Test Driven Development, but your test suite is "the complete game library of the console"!
(And then, once you've got 100-ish percent compatibility, maybe you can spare some time to optimize performance!)
If you've never done this before, it can be great fun! I'd recommend starting with a Z80 (Gameboy) emulator — it's an extremely well-documented architecture, fairly simple (no weird concepts like clipping masks or MMU mapper chips), fast to get to the "rewarding" point where you've got something displaying on-screen, and so low-powered that on modern hardware it'll run at full speed even with the most naive implementation.
" i dont know how anyone gets paid to do this and yet there is so much incredible depth to learn that is probably undocumented because of legal issues"
- There IS a path to commercial emulator development. Most of these "retro collections" you see being sold on video game online shops are a frontend, a custom made emulator to avoid any legal/license issue (Avoiding GPL code as much as possible), a cool frontend and some extras depending on how much the team could unearth and license from the original developer/publisher/rights owner.
Hell, Nintendo and Sony had teams making official emulators for the Playstation 1 emulation on PSP/PSVita/PS3 or almost every nintendo console before the GameCube for Virtual Console games
- Each country has its own set of laws, but using US cases as an example, developing an emulator for research purposes only (or at lease not competing directly with whatever you're emulating) and not using any file or code snippet from the original hardware can get a pass.
That's how some emulators go by without getting a Cease and Desist from Nintendo or Sony. And that's why they never bundle the BIOS with the emulator, even if it needs it to emulate... well... Basic Input and Output Systems.
You start spending all your time programming in middle school. By the time you enter college you know everything needed to write simple emulators, and then you meet other students that motivate you to up your game and complexify your projects, like working on a Nintendo Switch emulator.
It doesn't require being a genius or a fast learner, it just requires the good fortune of having programming be your passion.
If you want to catch up to these guys when you only start to learn programming in college, it's doable but it requires you to be a fast learner and also be somewhat passionated in programming.
Reverse engineering. Systems programming. Firmware.
Sometimes yea, people have a career in an adjacent field and hack on emulators on the evenings. Other times I've ran across incredibly talented individuals with significant contributions that have never been employed in tech. I've seen multiple instances of this when a younger individual gets involved in a project they don't feel comfortable putting their real identity on for fear of hassles with Japanese companies known to be litigious.
Most of the people that work on emulators do it for fun, not to get paid. Some do, but almost all have other jobs to support them, or are in places in their life where they are supported by other people: children and students, for example.
There’s a lot of work that goes into a modern emulator, for what it’s worth. Obviously there are people that reverse various parts of the console but it’s really an amalgamation of all sorts of talents. Someone’s going to be a graphics expert. Someone is going to be a compiler and codegen genius. Someone needs to work on reimplementing APIs and improving game compatibility. Someone needs to do UI work. Someone needs to port the emulator to platforms people want to run it on. Someone needs to do design, and PR, and copywriting, and translation. For smaller emulator projects many of these roles may be performed by the same person. For a large project it’s really a team of people working together, often organized in an ad-hoc fashion. It’s really a gem of open source development, where people can bring their own skills to the table and make something better than the sum of their parts, all the while improving themselves.
Indeed. Reading the emulator progress reports (Dolphin, Ryujinx, and Yuzu publish them on a regular basis) gives a really good idea of all the different jobs it takes to pull off a complex project.
Sort of starts by being intrigued. You start wondering how a simple emulator works. Then you realise that the simplest high level CPU emulator is just a big switch statement, a block of memory, variables for registers and the Program Counter... Then you realise you need memory read/write functions. Then you start looking at the other systems involved...
It's never ending, it's great fun, and a huge sense of achievement. I'll never forget the first time I saw a BBC Basic prompt when I devved my first emulator.
I'd say just being curious, reading and tinkering a lot. I recently wrote a GameBoy emulator to give myself a better understanding of the inner workings of CPUs. It's anything but precise, but it passes all the CPU instruction test ROMs and it's able to run all my childhood games so that's mission accomplished for me. Maybe I'll try to emulate something more complex next.
Writing an emulator is very frustrating at first (when nothing works) but it eventually gets more rewarding as you get to the point of meaningfully running preexisting software. IMO every programmer needs to write one at some point.
For most, it is a labour of love. For some it is how their OCD expresses itself. And some just refuse to give up until they beat the problem into submission.
Note that none of those are career paths. Some career paths might help you do emulator development (embedded C work, EE work, reverse engineering work), but none align with it perfectly.
The basic skills for this are taught in Electrical/(Computer) Engineering. In fact depending on your college you may end up writing a instruction set emulator lol. So it's not something that requires a 20 year career experience background.
It just takes a lot of dedication and time/energy to reverse engineer. People basically do it as a hobby. Usually the most hobby interest is nostalgia vibes from old stuff but even getting new stuff to run is done for the mental excercise fun
The only thing that allows these sort of projects to exist is a very unhealthy obsession. And believe me, I spent 2 years hacking Fujifilm cameras. Still am. Can't stop.
I had a friend get into it by being interested in middle school and just getting deeper and further with time. I think the fact that "they don't want you to do it" while many people do want you to do it is part of the allure: feels like being an intellectual Robin Hood, even if it's really not that; but also it's just a satisfying puzzle in its own right.
>because i dont know how anyone gets paid to do this
The reward here isn't a paycheck, the reward here is fun. Things like console emulators by and large exist on volunteer time and effort provided by nerds and enthusiasts who find pleasure in the act itself with no concerns given to finances.
I started programming mainly because I wanted to make a bot on an online game. I learned how to use Wireshark, how network protocols worked (the game used a binary protocol I learned to reverse engineer, and I wanted my bot to integrate with IRC which uses a text protocol so I read its RFC), I learned how to decompile and read obfuscated code (the game was an SWF, and I could get my hand on bots made by other people), and even some design patterns to make my code slightly maintainable.
I did it to have fun with my bot on the game, but in the end I barely used the bot, I had way more fun making it and learning how to improve it.
I suspect the people making these emulators spend way more time writing the emulators than using them, that's where the actual fun is.
Because you really enjoy programming and hacking? And obviously are very capable.
The emotional part is critical as human beings. I wonder why we need to remind it again. A lot of human activities don't have anything to do with money.
I’m sure they’re not doing it for the money, but their Patreon brings in over 2k/month. Not enough to quit your day job, but pretty good side money. Plays Zelda better than the Switch too!!
It's more high-level than it used to be but GPU is the main problem. The graphics APIs that games use usually expose various hardware specifics so games could be fine-tuned to get most out of that specific hardware. It takes a lot of work to translate these hardware-specific API calls into OpenGL/Direct3D/Vulkan/Metal.
It helps that many console devs don't bother with low-level optimisations, because they can get away with a bit worse performance. Just cap the framerate to 30 like most other console games do.
It wasn't an option during the NES era. Every clock cycle counted back then.
NES-era games also ran on bare metal. Modern consoles run proper modern operating systems with everything you'd expect to find in one — preemptive multitasking, virtual memory, hardware abstractions, kernel- and user-mode with syscalls, etc. PlayStation OS is a Unix system (something-BSD IIRC), Xbox's is obviously based on Windows NT, and Switch runs something Nintendo built from scratch.
Cycle-counting doesn't make much sense for code running in a preemptive-multitasking OS because no matter how much you count cycles, the actual execution time for a piece of code would be non-deterministic. That, and I suppose most modern games are bottlenecked by the GPU, not the CPU.
fwiw, the switch actually uses cooperative multitasking. This causes emulation headaches of its own, because sometimes retail games are buggy, but due to the relative determinism of scheduling nobody ever noticed (e.g. race conditions that are reliably won on real hardware will suddenly start breaking in emulation).
For the Switch specifically, it has an ARM CPU so an ARM emulator is still necessary on x86 systems, but on native ARM systems it's possible to run CPU code almost natively, and this has already been done (a now-dead emulator for android called Skyline did it, and apparently Yuzu will also implement this feature in the future)
The bigger problem is the GPU, it's an Nvidia Maxwell GPU but uses its own custom API made specifically for the Switch (internally named NVN) so a full translation layer including shader recompilation is still necessary.
Great that you're having fun. Consider buying a real Switch as well. For me it excels in two use cases:
* Playing (Nintendo) games with the entire family (4 people, all holding a small controller): every Nintendo game is very thoughtfully designed to get 4 people through the "flow" before the game starts (pick your character, set the options etc.)
* Playing games in the portable/detached mode, it is a joy to hold and unlike a tablet you have physical controls. Most games are so much better than your average iPad game (or better said, the "match three" or mindless clicker games do not rise to the surface as easily as on iPad).
It also creates a ton of e-waste for a few hours of entertainment when you already have the compute power available to you in another portable device you already have to own anyway.
False equivalence (at least). Software we want to run is not just about raw compute available. Licensing of Nintendo's software aside, what if the pocket computer I have isn't mine? If I buy a Switch, I own it.
Just about everything creates waste. Being into any hobby is expending energy in pursuit of leisure. You're opting into excess from the jump.
I've messed around with emulators in the past. To be honest the tweaking and fiddling with things drove me mad. It was 100 times easier to just switch on a dedicated device and dive into a game.
Then again I'm not buying the latest games or consoles, I've got some other ones that I dive into every now and then for a distraction.
For BOTW specifically you're better off playing on CEMU (Wii U emulator) as it's the exact same game(not a more limited version as one would assume) but significantly faster. TOTK you'll need RyujinX.
Exact numbers are hard to give: native game resolution or native macbook resolution? Docked or undocked? Shaders cached or not? Graphics mods (some of which are efficiency/performance related) or not? Generally though most games run at native size at native speeds once you get everything going. BOTW/TOTK are some of the heavier ones though and, ignoring BOTW as I play that on CEMU, TOTK runs alright as long as you don't push it or expect high FPS mods.
Dont know OP, but I am playing pokemon scarlet on it, m1 max macbook 15, and its pinned at 30fps.
Don't know if the game just wants to run at 30fps, or if my macbook can't go any faster. But since its stable at exactly 30, I assume it's the game
From my experience with yuzu and ryujinx, in order to exceed 30fps, most games need to be modded. Almost all popular games have a mod available though.
Most Switch games don't run at 60fps in docked mode because they can't nearly hit the framerate at 1080p. The Switch has dynamic resolution scaling but it still lags.
For this reason many games only run at 60fps in handheld mode.
I believe Ryujinx actually translates the ARM code to .NET IL, which is then JIT compiled to machine code by .NET. As far as I know it’s a pretty innovative approach to emulation!
And on Apple Silicon, it just runs the Switch’s Arm64v8 instructions natively using a hypervisor! [1]
This isn't true anymore. It was their first approach, but since then they have switched to their own JIT recompiler. You can read their rationale here: https://github.com/Ryujinx/Ryujinx/pull/693
For the MacOS port, they also added an ARM-to-ARM JIT in case hypervisor runs into issues.
> they have switched to their own JIT recompiler ... they also added an ARM-to-ARM JIT in case hypervisor runs into issues
Having worked in industry for some multiple of decades, I can say with some confidence that if a small team were to successfully build and deploy their own JIT recompiler to solve an actual customer problem, they would be considered gods by management and given bonuses and promotions. Realistically the project would never get off the ground because their management would be pressuring them to hurry up and add some random new API within the next quarter. Most devs just looking at the existing code and are more or less doing a copy-and-paste with some minor tweaks for their new "feature." They're trying to slap together quick demos that are little more than, "And now this thing makes an RPC call to that thing." The level of performance I see from people who pull down well into 6 figures of income typically falls well below the level that I'm seeing in this Switch emulator project.
Usually for something like that to actually happen it takes a VP mobilizing an org of size 20+, with multiple layers of management taking a year or more to hire or steal talent from other orgs. Some companies are built differently (i.e., Apple) and can pull cross-org talent together for something like "get Intel binaries running pretty well on M1." But I find that tends to be the exception rather than the norm for larger tech companies.
That's the difference between people working for a paycheck and people working for a passion project. Even if 90% of the people working at a company are doing it for the passion and not the paycheck, they still have to contend with the other 10% who do not have the passion (but may be good at hiding this fact).
With a passion project, you start and stop whenever you want, and if you're not interested, you're not working on it anymore. So only the people who are truly intrinsically motivated will continue.
A paycheck is a form of compulsion. "You could be do anything, but you're doing this for me specifically because I pay you." You might also be very interested, but it's the only thing that specifically binds you to the company vs bound to the work itself.
I don't get it. For me the biggest problem isn't the "ulterior" motive of the paycheck but rather that you simply don't get to work on exciting problems to begin with.
If you told me I have eight hours a day to work on this and I have to spend those eight hours a day, you will get a far better emulator than if I had to do this only on the weekends and I could quit at any point and that is how most personal projects end up. In some half baked state and nobody uses it.
I think that first approach (Part of the name RyujinX from RyuJIT?) while not optimal did get them off the ground quickly, now with a bit of traction (people into the project since it actually functions) they can could easily find takers(or the time) to write the improved JIT.
I'm actually tinkering on a WASM runtime and emitting MSIL code from WASM trees is quite straightforward so far (tho running into some more complicated cases now that I'm integrating the test-suite), compared to the non-trivial (code stamping) pure native JIT's I've done in the past it's quite a big timesaver (and those still only did target one CPU platform).
C#, especially with in recent releases, has really been turning into somewhat of a systems programming language.
They keep adding tools that allow for very low-level memory management/manipulation and the ability to run on so many platforms/generate native code makes it very attractive. It's also just fun to write.
> They keep adding tools that allow for very low-level memory management/manipulation and the ability to run on so many platforms/generate native code makes it very attractive. It's also just fun to write.
I've been having issues with golang's opaque GC when targeting wasm. Does C# offer anything on that front? Can I at least control when it triggers?
You can pause the GC, run it yourself and tweak it a bunch, but in my experience it usually causes more trouble than it's worth - you have to be really careful with it.
Oh, in terms of emulators written in C#, never heard of Run[1]UO[2]? C# revolutionized the UO world back like 20 years ago(?) it has(d?) the right balance between simplicity, clarity and performance
RunUO is what turned me from a player into a programmer. I believe there’s still a forum comment out there from 2001 where I was asking about the mess of squiggly brackets {} and if this is really how programming is done. It’s a really fun reminder of what that first exposure to programming felt like.
I’ll never forget how magical it was to make my first edits to the code and see it reflected in the game. Created a feedback loop that has continued to reward me over 20 years later. :)
It probably goes C/C++ (it's really hard to disambiguate the two, in this case; few codebases are pure either way) then Rust (for hobby emulators, it's probably third or fourth for serious efforts), C# and Java.
JavaScript and Python are very common for hobby efforts, but generally exceptions for serious codebases (excepting WASM).
It is kind of annoying that Irdeto, the makers of the oft-maligned Denuvo DRM, have made one that specifically targets Switch emulators, even though emulators are legal.
Emulator users are generally only pirates because they cannot just buy the software and dumping carts is costly due to proprietary formats. There is tons of evidence that most piracy is due to unavailability.
I would 100% pay $70 to buy Zelda that just runs on PC at 4K...but nope, gotta have it at 720P @ 28FPS.
Modchips are available for every switch console now, and the early ones can be softmodded pretty easily.
It's a bit hit or miss on other consoles, but it's often pretty straightforward to dump your own games. IMO, it's kind of dumb to make people "do a little dance and magical incantation" to make what they're doing "more legal" especially when there's little case law about it.
Also, everything on the switch is ID-tagged. If nintendo wants to, they can ban carts, consoles, controllers, accounts, and more for arbitrary reasons.
Having tried both, I prefer Yuzu for playing Tears of the Kingdom: https://yuzu-emu.org/
Both are great, though, and the rapid speed of development on both projects means that whatever impressions I formed earlier this year are likely already out of date!
If you have anything less than a flag ship from the last year or so, don't expect to be playing Zelda on your phone anytime soon though. Even then I heard people saying their phones were getting very hot.
Source: researching this about 3 months ago to see if I could play BotW on my S21 FE. I can't.
Yes, for Yuzu you need a Snapdragon SoC otherwise the games crash instantly. If you have a Mali GPU you have to wait until they add support for it. Skyline supports Mali but performance is reduced. Btw Skyline ceased development, some of the devs forked it and will continue development on Strato (https://strato-emu.com).
If you guys use Android handhelds I recommend using Beacon Game Launcher (https://play.google.com/store/apps/details?id=com.radikal.ga...)
Also Yuzu has asynchronous gpu shader building which means you don't need to find and download a pre-built shader cache for a game for it to run smooth. Yuzu can build itself a shader cache while playing and it doesn't cause the game to stutter and hitch like crazy.
Yuzu just seems to me to be the technically superior option at this time.
Is there any way to play games (legally) on this if you don't have a Switch to dump them from? Is it possible to buy Switch games through a web browser?
So every new one you buy is almost definitely a patched V2, and all the Switch Lites and OLEDs are not jailbrakable either, without soldering a modchip.
> But if you own the game, does it matter how you got the ROM?
It does from a legal standpoint. In many countries, making your own backup copies of your games for personal use is legal (although anti-circumvention laws like the DMCA blur the lines here) but obtaining a backup copy from someone else, regardless of whether or not it is a copy of a game you already own, is not; at best it is a legal gray area.
Most countries allow downloads. They usually specifically target torrent users because a typical torrent user is making the file available to others while downloading. It doesn't apply if you download with a protocol (like http/https/ftp) that doesn't make you share the file.
So you can pretend it is not clear and you don't know it is illegal then?
I promise I thought that website was legit and was offering free licences for Super Mario![1]
[1] Apparently it works with software, you can purchase licence keys of Microsoft products (OS, Office) at roughly 5% of the original price through "reputable vendors".
Dutch courts don't accept the excuse that you don't know, you're supposed to know the law and do a bit of research in what the normal price and suppliers of goods are.
It's comparable to buying a bicycle worth 800 euro for 20 from a drug addict. Even if you don't know it's stolen, you're guilty of fencing.
You aren't reproducing, distributing, performing, publicly displaying, or making a derivative work. *The uploader is the one reproducing the work, see Disney v. VidAngel
And under fair use 3 of the four points would be in your favor, but that isn't determinative
A finding that VidAngel violated copyright doesn't mean their customers didn't also violate copyright. Their customers weren't the ones being sued, that doesn't mean the customers were in the clear.
I don't see where you are getting the uploader is the one reproducing the work rather than both parties were? Also that appears to have been a streaming case so not really relevant?
VidAngel clarified what "distribution" meant in the context of "digital piracy". Receipt is not a qualifying symptom to make you an offender, you need to actively make available for others.
As far as I am aware, in US law, there is no subject code specifically for and simply for possessing/receiving pirated material (unless it's legislated in some other manner: CP, private govt documents, etc). Despite many court attempts to argue that "downloading" is equivalent to "making a copy".
This is why, during the MPAA/RIAA war against p2p, they specifically targeted the fact that all users were mesh sharing files. It's why one user was charged millions for "sharing a file a multitude of times" and another was let off completely free for sharing a minuscule percentage of many downloaded files.
"As far as I am aware, in US law, there is no subject code specifically for and simply for possessing/receiving pirated material"
You have to look at the case law.
This article on contributory infringement seems relevant and states:
"One who knowingly induces, causes or materially contributes to copyright infringement, by another but who has not committed or participated in the infringing acts themselves, may be held liable as a contributory infringer if they had knowledge, or reason to know, of the infringement. See, e.g., Metro-Goldwyn-Mayer Studios Inc. v. Grokster, Ltd., 545 U.S. 913 (2005); Sony Corp. v. Universal City Studios, Inc., 464 U.S. 417 (1984)."
"This is why, during the MPAA/RIAA war against p2p, they specifically targeted the fact that all users were mesh sharing files."
They probably did that because they wanted to make an example of someone, so they went with whoever would be easiest to win a large judgement against. If someone merely downloaded a copy, the judgment against them would be smaller.
I certainly don't see how someone downloading pirated content isn't a contributory infringer at the very least.
VidAngel covers the requirements for copyright infringement and cites all relevant previous cases
It is true that doesn't mean customers were in the clear. But it's impossible to prove a negative. There are zero copyright cases for streaming customers or downloading without also uploading via p2p.
Are you aware of any case law that finds otherwise?
"VidAngel covers the requirements for copyright infringement and cites all relevant previous cases
"
It's a streaming case against a single plaintiff, a lot of previous cases are not going to be relevant.
"Are you aware of any case law that finds otherwise?"
I'm aware how courts tend to view these sorts of things in general. For example I'm aware of the concept of contributory infringement, here's one you may want to read that covers copyright contributory infringement: https://www.law.cornell.edu/wex/contributory_infringement#:~....
I love Yuzu and Ryujinx both. It’s crazy that they can provide a superior experience to the native console. I suspect the party’s about to be over thanks in no small part to Denuvo.
I doubt it. So far Denuvo's claims to prevent emulation are just that, claims. Even if they do, people have an unlimited amount of time to work on bypassing it.
Eh, I'm less skeptical. Denuvo has a proven track history of being exceptionally difficult to crack (and last I'd heard, only one hacker even possesses the skill to do so.) If they're as competent with locking down Switch titles (or, as is rumored, future Unreal Engine games) the gaming community at large is in for some chop.
its best to wait and see, but their strategy seems to hold water.
think about it, emulated GPU´s are an approximation of the output, like "mathematically inexact" output pixels, even through perceptually they are as good and often better than the original.
even if you just draw a textured triangle, the texture sampling quality/output varies from different gpu families (even from the same vendor), so "drawing and testing against the framebuffer" is a somewhat strong check to see if the gpu is an tegra X1.
game code that renders using a shader and checks for the precise expected outputs in the framebuffer will fail in emulators (unless the thing is cycle accurate and has no enhancements!), so the games might need to be cracked.
and cracking/bypassing denuvo is a pain in the ass.
what this probably wont solve or seems to be tackling is switch piracy on real switch hardware.
Why doesn't Nintento release their games to other platforms? I would love to play Zelda, but I am not going to buy a console just because of one game..
Nintendo is just Nintendo, and enough people have bought a console just because of one game (or several games) for them still have enough money to keep being Nintendo.
I don't really want to defend them, but you need to look at the North American video game market crash of 1983 to understand their current stance. The entire video game market collapsed, because any old crap was being released as a game. Consumers lost confidence in the "platform" of specific games consoles. If they bought a home computer instead, there would still be games and it had other utility.
The NES was the antithesis of this. A walled garden of Nintendo, and plenty of first-party game development. The approach worked, it brought them fortune and made them a major player in the video game market. Why would they abandon this approach if it's still working for them almost 40 years later?
I think you're answering the wrong question. Parent post wanted to know why Nintendo doesn't want you playing their games on other people's hardware, you answered why Nintendo locks out other people's games on their hardware.
Nintendo has occasionally licensed out their brands for other hardware, but it's rare. Examples that come to mind are:
- Home ports of Donkey Kong, most of which came out before the NES
- Various Mario-branded edutainment games and typing tutors[0], which were available for IBM-compatible/WinTel PCs (probably also Mac OS but I don't remember)
- Phillips CDi games such as Hotel Mario and the two Zelda games it got[1]
- Nintendo's spinoff mobile games such as Super Mario Run, Animal Crossing Pocket Camp, etc
A general unifying factor is that many of these were garbage. The mobile spinoffs are better, but those were made primarily to appease shareholders angry that the Wii U wasn't selling well. So I imagine Nintendo has had such a bad taste in their mouth from working with third party platforms that they'd rather just not. Furthermore, doing so means having to pay 30%, instead of receiving it from other developers.
[0] One of which was also Charles Martinet's first stint as Mario
[1] Notable for having lots of animated cutscenes that provided ample YouTube Poop material
I bought a Switch OLED to play Tears of the Kingdom, plus the game - $420 all in. If I could play it on my laptop which has a better screen and speakers, I would only pay $60. Plus, now I’m more likely to buy another Nintendo game to increase the utility of my new gizmo. As a business I’m pretty sure I’d rather have 7x the revenue.
Beyond what some of the other comments mentioned, Nintendo also took a different approach to their consoles compared to Microsoft and Sony which kind of forces them to lock down their first-party titles.
The Nintendo Switch is very underpowered compared to the other consoles of the same generation (PS4/5, Xbox Series X) but has a huge advantage of being the ultimate handheld / travel console. While Sony and Microsoft consoles can generally push out more FPS or better graphics (usually they lean towards better graphics), the Switch is very limited since it needs to strike a balance of form factor (less space for hardware) and battery life (what's the point of the handheld if you can only game for 30 minutes?).
For a big chunk of their user base, including the folks interested in these type of emulators and using them legally, they would probably prefer to use their other consoles and/or a PC/Mac from a pure performance perspective.
I also suspect that they would get less revenue per copy sold on other platforms compared their own platform, especially with games released by in-house studios.
With the above in mind, releasing a game on other platforms will cut into their revenue stream pretty significantly.
they are obsessed with trying to force there products to be only used roughly like intended
Or else they e.g. probably wouldn't patch out item duplication glitches which are close to impossible to accidentally ran into, or they would allow you to change control a age old basic features missing from Nitendo games instead you can only use controls in the intended (and play tested) ways. Similar they where quite obnoxious when it comes to streaming, reviews or other content containing game-play video for quite a long time. To some degree they still are.
Through for many people it's not just one game I mean Nintendo has quite a bunch of successful exclusive titles, to list some: Zelda, Mario Cart, Smash, various jump and run Mario titles you could split into 3D main titles and 2D complementary titles, Splatoon, Mario Party, Fire Embleme, Xenoblade, Kirby and more. In practice you tend to have at least 10 high quality enjoyable (but expensive) exclusive games. (ignoring Wii-U which flopped and leading to some strange results like Mario Cart 8 being republished with the DLCs pre-included and later a large expansion pass instead of releasing a Mario Cart 9).
Other console makers make a profit on their consoles as well. Typically it's either a small margin at the beginning, or maybe they're eating it somewhat, but as time goes on the components get cheaper, production is improved, or they make revisions to reduce complexity in the circuit boards, or they release a newer smaller version of the console as well. But it's not fair to say that Sony and Microsoft lose money on their console hardware but Nintendo doesn't.
However as someone who purchased BoTW and played it years ago on Switch, and again recentishly on CEMU, the experience on CEMU in 4k @60hz, it was a whole different game.
I’d pay Nintendo 3x the cost of ToTK to play a version that ran on my PC with improved resolution and frame rates. Until then, I watch the status updates for Switch emulators, and will play ToTK once emulation is reported to be ~perfect. I’ll buy ToTK, but I won’t be playing on hobbled Switch hardware.
What's the problem with your PC? I've been playing TotK on PC since before it launched and, after the rock-texture problem was fixed, high framerate and 4K work just fine. There's even a TotK mod manager now. Way better than my wife's experience on Switch.
I considered this, but I decided that the 100% confidence I had in a bug-free-experience (including crashes and risk of save-game loss) on the native hardware was worth the better experience I was likely to have at a higher risk playing on the MacBook M1 Ultra at 4k. I don't really regret it. My TV added "simulated HDR" and I played with frame-smoothing on for a simulated 120FPS. Yes there was latency but in this game it never mattered. Not even a little bit. I enjoyed every one of the 175 hours I spent in TOTK.
To each his own I suppose, but a crash every twenty or thirty hours is, to me, a fair trade for never having frame slowdown. Save-game loss is a non-thing. Even if you managed to kill the emulator while it was saving, every save is a separate file so you'd only lose the time since your last auto-save.
I guess I still see announcements of updates around bugs and edge cases. I'd rather be patient and wait for some thousands of other people to stumble across bugs for a while to minimize my chances of frustration. For video games, I'm only willing to do so much work for the experience. There are other domains where I'm happy to charge in first to file bug reports, but games aren't one. I assume I'll enjoy ToTK just as much next year or the year after, and even more so if I don't have to deal with any glitches.
What is really wild to me is that they could 100% ship Zelda for iOS and make a killing. The Switch has absolutely nothing on a modern iPhone/iPad, even heatsoaked and it would immediately be the best game on iOS.
They can run any code. You can use checksum and such a site centralizing would be in the clear as it doesn't contain any copyrighted material, only hashes (perhaps including cover art would be a problem?)
As far as I know there exists one specifically for switch (nswdb.com, which is used by a common dumping tool to verify if your dump is valid or not) and another for basically every console but the switch (for some reason) run by no-intro (datomatic.no-intro.org)
Another site that only cares about disc-based releases is redump.org, which has quite a few dumping guides in their wiki.
In general emulated code should only be able to interact with the emulated machine, not the host machine running the emulator. But there's no specific sandboxing and there have been cases of bugs in emulators that allowed specially crafted roms to execute code on the host (https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit...)
The developers shouldn't have to be anon for this type of amazing project. They should be publicly celebrated instead of having to hide for fear of being buried in legal trouble. Sad state of the world.
I still don't see how China's IP violations lead to a "sadder world state". The article you linked seems mostly sympathetic to foreign trademark-infringing sellers, and I certainly don't lose sleep over small-time trademark problems. I'm not happy about the copyright infringement and full-on fraud that happens in China, but there's certainly an argument to be made that the current rules (or absence thereof) were necessary to make China the superpower it is now. If I was Chinese, I'd be pretty happy about it.
