Nearly all Nintendo 64 games can now be recompiled into native PC ports(tomshardware.com) |
Nearly all Nintendo 64 games can now be recompiled into native PC ports(tomshardware.com) |
He has already completed all games, but the videos are waaay behind (he's releasing one video/game a week).
Why? Surely it's more straightforward to do binary-to-binary translation. No human input needed!
https://andrewkelley.me/post/jamulator.html
There is also Winlator for running Windows programs on Android:
https://github.com/brunodev85/winlator
Also is the youtube video linked in the article using an AI voice?
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."
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.
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.
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.
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.
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.
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.
I would love to play a source-port of arcade “GTI Club”! <3
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.)
https://www.nintendo.com/us/store/products/nintendo-64-contr...
Why do people even bother when they know they'll get lawyers at their door in 3... 2... 1... ?
This project isn't distributing any of Nintendo's code, game assets, or other intellectual property.
https://www.nerd.nintendo.com/files/Secu%20Job%20Offer%20202...
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.
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/
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.
[1]: https://cs.stackexchange.com/questions/155511/why-is-static-...
[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.
[3]: The Majora's Mask recompilation repository contains a lot of handcrafted patches to make it work: https://github.com/Mr-Wiseguy/Zelda64Recomp
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.
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.
On Debian, I found I had to run
dpkg --add-architecture i386 && apt-get update
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.
It's funny how the Mac is more compatible with old Windows programs than old Mac programs.
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).
An example of this can be found here: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
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.
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.
https://www.libretro.com/index.php/category/parallel-n64/ for a more detailed description of how this changed things.
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.
EDIT - But hey, you can always just add another layer of emulation via Proton to run it in Linux.
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.
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.
Intel does want to get rid of most of the compatibility modes, including all 16-bit support, but they haven't done it yet: https://www.intel.com/content/www/us/en/developer/articles/t...
Hilarious proof: https://imgur.com/gallery/Xw4tN#FoRAGl7
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.
[1] https://docs.google.com/spreadsheets/d/1KDNGI76HoMNyYLL6RqWu... [2] https://youtu.be/PB_LMW72crY?t=3997
Setting aside the part about purists finding it unacceptable, I appreciate the tenacity of the devs that find these problems worth solving.
https://youtu.be/0B095eHBrCg?t=24m40s
Not saying that supporting glitches like that is a hard requirement for these ports though
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.
[1] https://ultra64.ca/files/documentation/online-manuals/man/pr...
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.
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.
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.
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.
The UK C64 disk for “Skate or Die” had copy protection that did exactly that, as an example.
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.
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.
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)
There are some plugins for the java edition server that allow bedrock clients to join, that might be an option for you.
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.
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.
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 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.)
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.
There is an unofficial Linux launcher that can run the Android build
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.