To operate this tool, you still need to disassemble the ROM up front and annotate it heavily before it can be recompiled. This tool is very nice, to be sure, but the hyperbole about anything close to one-click generation of standalone executables for an arbitrary ROM is getting out of hand.
To be fair, N64 is not the PS2 or Gameboy--there are only 388 games that were released for it. Going through all of the games that were released and shepherding them through this process is feasible.
if you're interested in this kind of thing, The Mexican Runner beat every NES game (over 700 of them [1]) including such gems as Miracle Piano Teaching System, which took 91 hours to beat and required him to become quite proficient at actual piano playing [2]
I really liked the N64, but if we're being charitable it's probably like 30-40 games. For any given console, even those that achieve legendary status, the game quality follows a Pareto distribution, 80% is crap, 20% is worth playing after the console has left the public mind.
What no one wants to revisit Nagano Winter Olympics or Tetrisphere? Its probably closer to 50 if you want to include some of the lesser-known but interesting titles IMO. One of the most interesting games was Body Harvest since its clearly a prototype for a lot of what became GTA3
> For any given console, even those that achieve legendary status, the game quality follows a Pareto distribution, 80% is crap, 20% is worth playing after the console has left the public mind.
Is this just your best guess? Because you sound confident and then cite the Pareto distribution, but just like a certain Internet personality, there’s no data to support a claim you’re making but it does _sound_ factual.
Every game on the system will have some people who are super nostalgic for it. When many of us were kids, we only had a few games, and we played the hell out of them.
The video also makes it clear that only games using a certain microcode works for now. I imagine there are many parts of HLE emulation that gets added to the recompiled software as wrappers and compatibility code to make it all work, so in a sense this may be more akin to an embedded emulator into a native binary (recompiled code), which can overtime be worked on to add new features, fix shortcomings of the original software and make it more "ergonomic"/compatible with it's new target platform. But such work can only feasibly be achieved by reverse engineering the software and giving it human readable symbols. In a sense there is almost as much work to do as on the previous decompilation projects, but you can get results (run the game) right away (or at least much faster than traditionally), assuming of course the game uses a compatible microcode and isn't doing anything fancy that depends on the intrinsics of the n64 architecture.
There’s also inevitably going to be timing/performance-related bugs - the N64’s devkit docs say it runs games under a thin OS for multi-threading[1] so that’s another opportunity for things to go wrong.
Also, after conversion these games are still designed and hardcoded for an N64 controller and 4:3 aspect-ratio - that’s hardly “native” as far as PC gamers are concerned.
I wouldn't count on it, it is still derivative work and I am sure the licences for the games forbid this. Some companies may let it slide, but Nintendo is known to be aggressive about their intellectual property.
And you will probably have a hard time arguing that it doesn't promote piracy. You can't get "ROMs" officially. You have to extract them from the cartridge with specialized equipment, or maybe in some other way, but it is not as simple as reading from a CD. It means that most people will simply get them from illegal sources. With an emulator, you can say it is for "homebrews", but if you recompile a commercial game, you can't use this argument.
I don't think that's right, I think it's essentially considered the same work under copyright law. Apparently compilation doesn't fulfil the criteria of derivative works.
A shrinkwrap license is not a real license. The game is copyrighted, and fair use applies.
And if you want to avoid the license just steal it from someone. You never agreed to a license, but you are still required to follow copyright. (I've obviously being a little sarcastic, but license agreements on software are meaningless, even if a company claims they have meaning.)
Nintendo hasn't been taking down any projects that can't work without a ROM input. They'll change that eventually, but for now they are not. You can't share a modified ROM but you can share binary patches.
> You can't get "ROMs" officially. You have to extract them from the cartridge with specialized equipment, or maybe in some other way, but it is not as simple as reading from a CD.
Nintendo has, in fact, sold the public ROMs before (and I don't just mean custom emulator executables wrapping ROM payloads that get delivered encrypted onto DRMed consoles.)
Specifically, I'm talking about the NES Classic and SNES Classic. These little boxes use multi-image emulators, rather than Nintendo's usual approach of a customized single-image emulator for each game. And the ROMs used by these systems are just sitting there as files on disk. The disk isn't encrypted, either; nor is the bootloader or kernel integrity-signed; or really anything like that. You don't need to "jailbreak" these things — they act like Android phones, where you can just reboot them into restore mode and plug them into a computer with a USB cable, and see a virtual disk. The "modding tools" for them just drop a new kernel with wi-fi support into their /boot partition! (And you don't even need to go that far to read the ROMs off the rootfs — any Linux PC will work to mount it.) So any DMCA "they used DRM, which means their intent was to license you X, not sell you X" arguments don't apply. They did nothing to stop people from extracting these ROMs.
By buying these systems, you're effectively buying "a box full of ROMs" directly from Nintendo (the IP rights-holder for said ROMs), at retail, as a "money for goods" transaction. So now, by the first-sale doctrine, they're your ROMs, and you can do with them as you please.
This is true as surely as buying a DVD box-set means you now own those DVDs, and can do with those as you please. (Part up and resell the DVDs individually? Sure, why not!)
Or — for perhaps a more interesting example — as surely as buying a stock images or sound-effects library on CD (even second-hand!) implicitly brings with it the IP rights to use those assets in derivative works you create. The primary-market purchaser didn't have to agree to any kind of license terms at point of sale? First-sale doctrine applies to that IP from then on! (Amusingly, Nintendo redistributed exactly such stock-image CD assets embedded into Mario 64 — so their lawyers are double-bound to agree that this particular interpretation of first-sale doctrine should pertain.)
The license also says “unless otherwise required by applicable law”, and applicable law here in the US is the DMCA, which says that you can make copies for the purposes of playing the game on different hardware [1]… so long as you don’t need to circumvent copy protection in order to do so. Since the system doesn’t have copy protection, the law permits you to do this even if the license does not.
This is the odd thing about the DMCA… rights holders can prevent you from doing something in their license, but then the law can override that by allowing you to said thing… unless there is any sort of copy protection involved, in which case the law doesnt override the license.
- [1] Here I’m interpreting this as “format shifting”, which has largely been considered fair use by the courts. It’s the reason Apple got away with selling the iPod with CD ripping software and told customers to rip their CD collections… since CD’s didn’t have copy protection, the DMCA provisions didn’t apply, and thus it was not explicitly illegal to copy your CD’s to your iPod. And the prevailing view was that copying your own CD to your own other device was fair use so long as you didn’t sell the copy or anything. I would wager that the ROM situation on the NES/SNES classic is similar.
I'm pretty sure all roads lead to either playing the game or otherwise not doing anything of value to Nintendo whatsoever (ie who cares if you bury a box of roms in your yard)
> You can share the prepared binary because it contains no trace of the rom.
This is wrong. Please do not confidently present your guesswork as fact.
If it were true, copyleft would have no chance of working; binaries compiled from copyleft-licensed source-code would not be subject to the copyleft licence.
Is it in any? Because I don't think just adding a "You need to own the game to download this binary" text to your GitHub repo is going to do a lot legally.
This is not true in Brazil. In Brazil, this is just an urban legend that several sites with ROMs spread in the 90s. By Brazilian law, you cannot download a ROM if you do not own a copy. It is possible that this rumor of 24hs is based in some old law that is not applicable anymore.
For example, Zelda (both of them) load segments of code from the cartridge at runtime. The recompiler needs to know which areas contain code, and the original relocation-applying code for MIPS instructions obviously won't work on x64 instructions either, so it needs to know how the relocations work.
I think "but using the tool takes time and effort" is a good but not perfect criticism of a tool that purports to reduce time and effort spent. As many asinine CEOs are making outsized claims about generic "productivity" improvements from various tools in this space and similar ones all the time, I get this instinct. However, it does not make sense when the use of the tool is anything other than "something you could already do, just faster"
This is really cool. Many of the foundational tools created for N64 decomp are finding their way into other system decomp packages. I recently came across https://decomp.me/ which allows collaborative decompilarion for a bunch of systems with presets for their relevant SDKs and hardware. I’d imagine this happening several more systems in the coming years.
I saw this when it came out, and as someone that doesn't follow the ROM hacking scene, I'm wondering - why did this approach take so long to come up with? Translating the assembly instructions to C and then recompiling them seems like an obvious method to try early on, but I'm wondering if there was some other breakthrough that made this possible in a way it wasn't before?
The N64 has a GPU, which is not the same as modern GPUs, and you need that GPU to render graphics.
Skimming the Github repo, looks like this uses rt64 under the hood for the raytracing support ( https://github.com/rt64/rt64 ), and that uses the ubershader technique to emulate the GPU. This excellent article talks about the what, why, and insanity that are ubershaders: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
Other emulators want to solve the problem generically, and this solution doesn't quite.
Static recompilation from one machine language to one other language is somewhere between extremely difficult to not being generally possible in practice [1]. To make recompiling something like this properly, you need some help from the binaries that make recompilation easier [2] and on top of that you need to patch certain things to make this work [3].
Dynamic recompilation doesn't have this problem. It allows you to create software you can dump the original binaries+assets ("ROMs") in and it will generally emulate it.
There's a lot of confusion about how generic this solution it. It's extremely impressive in how much work it saves making recompilations/"ports" much easier, and it will be very valuable. But it is not able to replace the need for traditional emulators.
[2]: N64 game binaries may happen to avoid a bunch of things that make general static recompilation hard that help this approach, but I don't actually know.
Emulating the hardware usually requires cycle-accurate emulation of things running in parallel, so it's not quite so simple as just the program in the ROM.
Yes and no, with the 8bits and probably 16bits like the C64, NES, etc you really want cycle accuracy and emulating something like the PS2 really well would probably need a fair bit of accuracy.
HOWEVER.. writing an recompiler (not feasible for 8bits due to the amount of self-mod code) you could probably insert pattern checks to detect writes to DMA-starting locations,etc (thinking back to our PS2 games) and transform it to safe sequences without accurate timing for most games that really only would be happy with some extra cycles.
With Skate or Die, it’d pull a byte off the genuine disk and use it to decrypt (xor) a loop immediately after the current PC.
I think it went through about five iterations.
My crack was to step it with the original disk to decrypt the encrypted part and modify the code to jump over the decryption. It was pretty sophisticated for the day.
To another extreme, Ocean disk games had a “IsGenuineDisk” style function. It returned 1 or 0 in the accumulator. I could crack it in under a minute with a disk sector editor.
Oddly, I ended up doing Mac copy protection years later.
Watching the video, it seems like the explanation is mostly "tag the code and transpile to C" - im assuming the tags are acting as the hardware-aware part?
Really surprised this topic didn't come up anywhere. I couldn't find anything in the linked repositories either. I guess there's no self-modifying code due to it being mapped into the address space from a cartridge?
You definitely do need code execution from RAM for high-fidelity emulation. How else are people going to implement Flappy Bird in Super Mario World? :) https://www.youtube.com/watch?v=hB6eY73sLV0
Basically every game is written in C on a modern processor (MIPS) so i highly doubt it. Maybe some weird homebrew stuff like that flappy bird video uses it but emulators tend to deal with problems like that by ignoring them (e.g. IIRC there is no emulator that can properly run that N64 linux port from a few years ago, and there have been plenty of SM64 glitches that work differently on emulators vs real hardware)
>Jamulator did this for NES way back in 2013 but nobody really seemed to care...
At least Mr WiseGuy seems to care. From the N64Recom Github repo[0]:
"This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
Jamulator was unsuccessful because so much extra hardware was on the cartridges. Recompilation complicates things and doesn't provide many benefits in that situation.
The N64 is fixed hardware, so it's a little bit easier. Even so, this project still uses emulation for the RDP. I don't know how it handles generated RSP microcode, maybe it doesn't. A lot of games just used the official libraries.
Jamulator didn't take it farther than what NES emulators could do beyond the way it ran. If Jamulator had released with similar enhancements for Zelda it probably would have been a lot more popular. I.e. the interest is more from what is now available with it than about how it does it.
That's just Nerrel, a real person, narrating. It's crazy (in an interesting way, not necessarily a doom and gloom way) how we have AI voices these days so good we start to suspect people who don't speak like we expect are AI.
I wish all game executables would be OS agnostic, something similar to WebAssembly: GameAssembly. For example you can no longer play 32-bit games on new macOS version, neither 32-bit Windows games under Wine. It's almost impossible to find 64-bit .exe files so they can run under fine under Wine/Crossover.
The code running on the CPU is arguably the smaller problem when it comes to games: At least for consoles, they're often depending on very low-level GPU implementation details, especially for older titles and platform exclusives.
Older consoles had even more dedicated chips doing relevant stuff other than "simple" I/O, like e.g. the SNES's sound chip, which was a completely independent CPU running its own little programs in parallel with the CPU and GPU.
Of course you could "mandate" a high-level VM for all future game development, but given the static nature of console hardware specs, that wouldn't be competitive for titles wanting to make use of cutting-edge graphics.
It is not enough to provide portable machine code to make games portable, there are lot of different APIs that games need: graphics API, windows API, input API, sound API, disk API and so on. Sometimes they need kernel modules for anti-cheat and anti-piracy features.
What saddens me is that open-source OSes do not want to provide a common set of APIs so that the developer only has to write and test the code once and it works everywhere. There is flatpak, but as I understand, it doesn't provide a set of APIs, it simply packs a Linux distribution into a virtual machine without any specifications or documentation. So ugly, and no compatibility for smaller non-Linux OSes.
I was able to run 32-bit Windows games in Wine on Mac, even on Apple Silicon. GTA IV on my M1 mini. There's some kind of "32 on 64" emulation built into whatever version of the 32-bit Wine that PlayOnMac installs. Impossible to Google so idk how it really works.
It's funny how the Mac is more compatible with old Windows programs than old Mac programs.
Old windows programs had the luck that intel fucked up Itanium, which left us with AMDs idea to just take the existing 16 bit compatible 32 bit processor and turn it into a 32 bit compatible 64 bit processor (that might also be 16 bit compatible, not sure on that one). As result new and old windows programs use a lot of the same basic instructs and emulating the newer programs includes a lot of the work needed to also emulate the older ones.
Modern x86-64 processors are still capable of running 16-bit code but, assuming you want to do it from within a modern operating system, it needs to be 16-bit protected-mode code, which isn't that useful since I think most 16-bit games run in real mode. Hence why DOSbox/Bochs are used instead (also, for emulating the original sound/graphics hardware).
AFAIK, no 64-bit version of Windows ever shipped with native 16-bit support, though. That means 16-bit support on x86-64 in practice was only ever usable on a 32-bit operating system, which means you still couldn't have 64-bit, 32-bit, and 16-bit code running side-by-side, even if the hardware could theoretically support it.
The JVM does this pretty well for Minecraft. I doubt Minecraft would support Linux, the BSDs, etc without it. Bedrock edition (the not-JVM version which supports Windows and consoles/phones) doesn't even support MacOS even though it obviously could.
If Minecraft were a Microsoft product from the start, they probably wouldn't have made the Java version compatible with Mac or Linux (even though it uses JVM, there are some natives included), or wouldn't have made a Java version to begin with.
Also it’s pretty ironic that Microsoft, who wants to convince the entire world that c#/netcore is the next multi-os platform isn’t capable of delivering anything else than Minecraft Java on Linux.
It’s a shame that I can’t play with my son from my Linux PC since he plays on switch (so the c#/bedrock edition)
If it were, targeting all platforms would have been fairly easy (assuming it would still rely on OpenGL), sometimes just specifying RID e.g. `linux-arm64`.
They could target Linux fine with their C++ code, they actually have secret builds for Linux for Marketplace creators (they have been leaked occasionally) but they don’t allow the general public to use them
There is an unofficial Linux launcher that can run the Android build
No it doesn’t. It’s a UWP app with DRMs everywhere.
Although there is an unofficial Linux launcher capable of running Bedrock natively using the embedded machine code in the Android version but it requires to buy the game one more time from the Google play store.
.NET would probably be as close as you can get given it allows you to have portable assemblies with pointers, structs and simd code which is very relevant to games.
It models statically-typed compiled languages in a much superior way to WASM, there are projects showcasing how well e.g. Rust maps to it[0], and C++/CLI existed for a long time (although it's not cross-platform, and is considered cursed).
C and C++ could be mapped in a perfect manner to IL and then AOT compiled in ways that GraalVM's Truffle can only dream of (given that .NET exposes a very wide set of intrinsics allowing a lot of code to be ported that way).
Wine (+ Steam's Proton) works incredibly well these days, a huge improvement from the old days when barely anything ran, and what did run required heavy tweaking or even custom compilation.
On Linux, my Steam library of about 300 games runs almost in its entirety without issues (except for Last Epoch).
I hope this eventually also works for Linux so that N64 games can be reliably played on very low end portable handhelds. N64 is notoriously tricky to emulate, but building them for the platform natively removes all performance problems.
Huh, I wouldn't have expected that. I don't know much about the specifics of N64 emulation, but I've had N64 emulators running perfectly since the early 2010s. I played mostly the big classics, so I'm unfamiliar with more niche title performance.
The N64 had a fully unified memory architecture, and weird custom silicon that also happened to be a fully programmable GPU kinda device. For decades, all N64 emulation was done by translating calls to that GPU (called the RDP) to openGL or DirectX calls, and that works horribly, but anything else would have had awful performance. Several years ago however, someone decided "Fuck it" and created a fully emulated version of the RDP that you could run, ie feed it real N64 instructions and it spits out pixel values. It was significantly slower than the translation approach, so you had to have like a powerful 8 or more core CPU to run it well.
Some other madlad then took that approach, and ported it to a GPU Shader, because fuck yeah thousands of cores! It actually greatly improved the situation, as you didn't need a super powerful GPU, just a somewhat modern GPU.
That development means devices like the steam deck actually have zero issues running awesome N64 emulation, including allowing for upscaling to much higher rendering resolutions without artifacts because you are literally telling a virtual RDP to do it, and it happily complies.
Before AngryLion and ParaLLEl, we were stuck with basically the same graphics plugins, glitches, and tweaks as the late 90s.
You'd be surprised, even Nintendo doesn't get it perfect themselves. When N64 games were first made available on the Nintendo Switch Online platform, there were several problems with graphical effects and input lag. Here's an MVG video from the time: https://www.youtube.com/watch?v=jSyBMSOfPxg
Haha I remember this launch and how awful it was an thinking about how a bunch of fans have done such a better job. Hell, even Nintendo did a better job for the Wii's Virtual Console.
Yeah it's an interesting pattern. Even the GameCube had decent N64 emulation early in its lifecycle. But the Wii U Virtual Console also had issues with N64 emulation. Specifically it added a dark filter for no reason, which could be removed with homebrew thankfully. You'd think Nintendo would have the best emulation of their own systems on their systems, considering how long people stick around you probably have people who developed for the N64 still there
Homebrew emulators will almost always work better than first-party ones which need to avoid copyleft code, and can be content with a small subset of games being "playable", or "good enough".
Console makers will often hire lead developers of open source emulators to sew something up for them, like what was used for the mario 35 collection (part of galaxy was recompiled too) or the "ps2 classics" software emulator for the ps3.
I think part of the issue is that some purists believe anything less than pixel perfect fidelity is unacceptable. I recall reading a report on N64(?) Wii(?) about how the flame flicker in one level of one game was off.
Inaccurate emulation can also result in stuff like altered physics, invisible objects, stuttering animations, etc. resulting in a different experience from the original.
I watched the youtube video this article links to the other day and it mentioned that it supports Linux, specifically mentioning that it should be usable on Steam Deck.
The steam deck has way more than enough resources to power through any and all N64 emulation so that wouldn't change much there. I'm specifically talking about something $50 retro handhelds and the like.
For example Mario64 and Ocarina of Time are completely reverse engineered and have native support for Windows and Linux and they run perfectly on those systems as where they really struggle when trying to emulate.
That will likely require full decompilation. This is akin to wrapping the emulator up with the rom, with a few common functions (found via decompilation) being updated to support more modern rendering approaches. This isn't so much "native" as it is a patched container in an executable form.
EDIT -
But hey, you can always just add another layer of emulation via Proton to run it in Linux.
I don't think that's true, it really does recompile the N64 games into native executables, you can compile them using any C compiler like msvc, gcc and clang.
One thing this could be cool for is games like Goldeneye, which is hard to play on PC because it expects that weird joystick input. It would be awesome to have a native Goldeneye port with normal mouse behaviour like other FPSes.
WASD with mouse aim control doesn't really work with the game though.
The modal aspect of aiming combined with the travel time/return-to-center of the cursor is a really fun part of the game. If you could just free-aim while running a la PC FPS it would kind of ruin the campaign since everything is designed around this. Picking your spots and keeping cool while aiming are the appeal.
That said, if you keep the modal aspect and have the mouse just 1) rotate Bond like left/right on the stick does and 2) control the cursor only in "aim mode" (hit R)..then I think that could be fun.
Tbh, I wish shooters didn't go straight to Quake-style WASD+mouse free-aim across the board. The modal aspect makes gives Goldeneye a certain physicality I really like.
Deus Ex has quake controls but you need to focus a little before aiming. Then, later you get upgrades and laser reticles allowing you to shoot near instantly.
I played this a couple of years ago and it was already really solid back then. Do you know if they've figured out a way to do gyro aim since then? That'd be perfect for the growing number of devices inspired by the Switch and more recently Steam Deck.
Something's wrong with it, maybe related to the framerate. I can run and shoot a lot faster than before, but enemies take just as long as the old version to aim. I was able to beat levels on 00 mode with ease, mostly by sprinting past enemies.
The native ports have additional features, which are easy to implement starting from the native compilation. For example, the native port of Zelda has gyro aiming and automatic autosave options.
It could be done with native mouse control. No joystick intermediate- instead modify the C code to allow direct control of the player character with a mouse.
This is pretty neat; can someone tell me if this could lead to a proper working version of Conker on the MiSTer? E.g. could this be used to assist in a decompilation and then someone could make a fix?
What's the advantage over an emulator? This is after all, a form of an emulator - one where you translate ahead. This sort of thing has been done in the past with things like Bleem so it can be more performant but on a modern PC any good emulator is going to perform well.
The goals of this project and the goals of N64 emulation are fairly different.
The goal of N64 emulators (generally) is to accurately recreate the behavior of the original console.
Conversely, there is a large crowd of people who just want to play SM64, OOT and MM with a bevy of "graphical enhancements" like 60fps, widescreen, texture packs, randomizers, etc.
For these people, the fact that these games originally ran on the N64 is practically irrelevant. In fact, it's a hindrance; The N64's graphical pipeline is cumbersome to emulate and actively stands in the way of modern 'enhancements.'
This project is more aimed at giving the games themselves modern treatments, removing the N64-centric aspects of the games from the equation entirely.
Honestly SM64 with new graphics in those demo videos looks worse than the original game. But Gamecube games running in an emulator look amazing because they use a lot more vector graphics, which the emu can scale up and apply antialiasing to.
What interests me more about recompilation is it can produce very efficient binaries instead of having to emulate everything. And also makes it easier to add new features.
Yeah, SM64 is weird because a lot of '3d' objects used billboarding, it was actually just a flat object always facing the camera, so they don't scale up well. Anything spherical (chain chomp for example).
The characters in Mario Kart 64 were like that too, they just prerendered a heap of different angles and inserted the appropriate one.
With recompilation we could change those things, but I'm not sure how much work it would be and how many people who care to play those games would want to alter them that much.
Early 3d games will always have those rough edges sadly.
A fair amount of 32-bit and later emulators do have JIT recompilation, but I'm not aware of any ahead-of-time translation unless that's how TeknoParrot works (you can run linux arcade games that use ELF binaries on windows with it for example), but I wouldn't call that emulation either way since the architecture is the same.
Modern Vintage Gamer over on Youtube has worked with Nightdive and Limited Run Games and helped design a C recompiler called Carbon Engine for various older consoles that are functionally the same as ahead of time compiled emulators.
There are lots of emulation methods but interpretation is probably(?) the most common or at least very common.
Interpretation involves writing a VM that represents the state of various parts of the machine, and executes instructions that change the state of the VM, with varying levels of accuracy.
As an aside, the perfect dark decompile port is really nice to play on the steam deck. Not sure why, but the Linux version tends to freeze on the villa level. Switching to the windows version and using proton works great.
In theory it will work for anything, but there is a LOT of work that must be done to annotate the binaries on the source platform so that tooling such as this can pull it apart and reassemble all the pieces into something that works on the target platform.
A straight recompilation is one thing, but what this tool does is recompile with the target system’s apis for input and output in mind. A straight recompilation would offer less than an emulator, really.
This tool knows (or is told) where rendering routines are, for example, so that they can be replaced with destination platform versions. That’s how higher resolutions and different aspect ratios are supported in a recombination.
Super impressive walkthrough video in the article. It does a great job of explaining Majora's Mask. Although, it's probably glossing over a lot of the upfront technical challenges of using it to port games.
I'm wondering if a wireless Xbox controller would work. It's what I use with Apple TV without issue. Button layout is close enough (runs to living room to compare Xbox controller to Switch Pro...), in fact they're basically identical.
OTOH, I haven't tried the Switch Pro controller with anything else but a Switch, so maybe it can be made to work? (EDIT: just tried it: my Mac connects to the Switch Pro via BT, haven't actually tried it, 'cuz damned work is in the way.)
Thanks for the correction. Of course as someone without an N64, I went with "sure, that Dvorak keyboard will be recognized!" without checking if it's actually fit for purpose.
I use the N64 controller with my PC, it's available for purchase by anyone who subscribes to NSO. It connects via bluetooth (the USB connection is for charging only).
Nintendo doesn't typically go after emulation projects. Yuzu was the exception, and there are reasons for that related to how the Yuzu team ran their project and distributed it that painted a legal target on their back.
This project isn't distributing any of Nintendo's code, game assets, or other intellectual property.
Nintendo has also gone after a handful of specific tools for circumventing the Switch encryption, which has led to speculation that this push is really about shoring up "Switch 2" against existing hacks and emulators being updated (in the event that it's substantially the same software platform with updated silicon).
To be fair, newer models of the old Switch do not have published exploits either. People solder chips onto them just like the bad old days of console modding. I'd like to think that it's inevitable more exploits will eventually be found, but the increased gap between discoveries may suggest Nintendo is finally learning key lessons regarding endpoint security.
This isn’t true. The smash community has suffered for over a decade because Nintendo refuses to let them use emulation for melee in tournaments. Any tournament that tries is immediately C&D’ed. https://youtu.be/fAmidph6QU4?si=wbJvpN6ZhUSxSR17
How anyone has any sympathy or hope for Nintendo not going after their users in 2024 is beyond me. This is GameCube era games, and they’re still litigious.
I appreciate you drawing attention to more nintendo beef but historically they have cared more about protecting copyright for current consoles.
You say the smash community has suffered for a decade (dramatic) but they still made Project M on GameCube and delisting Dolphin from steam is not that big of a deal. I don't need to get into Smash Tournament drama to tell you this with certainty and I have all the knowledge and history to back up this claim.
I've played Smash competitively for 2 decades and have been emulating since 1998 so I know the history better than most; my statement was not opinion. I'm not saying they absolutely don't care about older emulation but they care much more about their bottom line e.g. Yuzu.
> historically they have cared more about protecting copyright for current consoles.
This is categorically false, and I even linked to evidence of it being false in the present day. I don’t know how you could say this as a smash player, but you’re acting like they won’t come after these people for doing what they’re doing. In reality it’s entirely up to the whims of Nintendo.
You did not link evidence to my statement being false, you posted a Hungrybox video of him complaining about his tournament issues he's having with Nintendo. Current Smash Tourney problems with Nintendo does not supplant Nintendo's history with emulation.
I simply stated Nintendo doesn't care as much, which is true, I didn't say "Nintendo absolutely doesn't care and won't do anything ever unless it's Switch related." I'm uninterested in replying any further since it's not getting across that I'm not diminishing the Smash issues, it's clear you're passionate and Nintendo are being real arseholes for sure.
