Nintendo's execs calling Boeing's execs: "Hey, can you refer us to your.....fixers? You know.......rhymes with shmassassin.....yeah you know, those guys."
Has nothing to do with their closed eco system. They basically did similar stuff with some of the stuff in the sm3d collection thingy.
Nintendo is a company that only wants make new stuff, innovations.
For example, they ( mostly miyomoto ) has been quoted to not understand that people want another f-zero, as the game's principals and ideas have been fully flushed out and no new ideas could make it feel like something new.
They also usually dont do remakes/remasters unless its so new/different it can be considered a new game ( see metroid 2 on 3ds ).
If that is a smart business position to have, i will leave for you to decide, but do get your facts a bit straight :)
EDIT: also, nintendo has used open source projects for internal projects before, so idk how "closed ecosystem" is part of their stuff :)
They basically did similar stuff with some of the stuff in the sm3d collection thingy.
They did not.
For Super Mario 64, they emulated it. They increased the resolution the game renders at (trivial with emulation of 3D systems) and they used basic LUA patches in the emulator to override HUD textures with higher resolution ones adjusted for the Switch controller.
They did not add any further enhancements in any way. Compared to even 64 DS, it was extremely sophomoric. Compared to the Super Mario 64 decomp project, and what its native switch port is capable of (more on that later), it's an incredibly lazy port. They didn't even fix the slowdown with Bowser's Sub that is as simple as adjusting a single compiler flag when you build the ROM from the N64 game source code.
For Sunshine, it's an admittedly impressive solution of mostly emulation with some sections of the game engine ported (I think it's the audio processing?). Once again, the game is rendered at a higher resolution, but they did not redo ot improve further any textures (besides some of the HUD again), graphical effects, or game content. Wind Waker HD this ain't.
For Galaxy they cannibalized the existing port of it to Android on the NVidia Shield. The Switch shares most of the important internals with it (CPU, GPU). It's a combo of emulation with certain key code ported, like Sunshine. Again, besides resolution and HUD, no improvements.
Beyond that, Nintendo has been content to sell straight up emulation through the Virtual Console service since the Wii. They've had multiple instances of straight ports over the years, and some of the most popular Switch games are straight ports with DLC bundled in.
There are numerous impressive remakes they have done over the years, but that is absolutely not the norm.
The Super Mario 64 decomp on the Switch supports (not available in Nintendo's official port in 3D All Stars):
Effectively infinite render distance for objects (coins, enemies, stars, etc)
60 fps (compared to the original/all stars 30fps at best)
True analog camera control using the right stick (All Stars is just the original's clunky button based control mapped to the stick)
All sorts of QoL options like collecting stars not kicking you out of a level, options for streamlined/faster message boxes
Optional bugfixes
Optional cheats
Variety of HD texture packs to choose from
Variety of higher quality 3D model packs to choose from
Support for an astounding variety of mods. Levels, entire new games, new characters, new movement and control options (Odyssey Mario in 64 with full cappy and enemy capture mechanics anyone?)
Support for many more languages
Nearly all of the above is toggleable mid-game from the pause menu.
I don't think anyone was expecting something amazing out of 3D All Stars, but they absolutely fucking phoned it in.
For example, they ( mostly miyomoto ) has been quoted to not understand that people want another f-zero, as the game’s principals and ideas have been fully flushed out and no new ideas could make it feel like something new.
This is also why we'll never get another Star Fox.
Damn you got mob downvoted for explaining exactly how Nintendo thinks. You're absolutely right. People don't seem to want to accept that Nintendo operates as an idea toy company. Once they've explored a new idea/gimmick they consider it completed and move on.
You're not wrong and I'm shocked this hasn't been shut down yet. Not to mention, the Nintendo 64 has been discontinued for years, but I have a feeling that won't stop Nintendo.
When that older DX game port was released, I think it took like 3 or 4 days for them to take it down. Probably even like a patch stomp tuesday situation when the interns hand off the script detections off to the lawyers.
It might take a bit longer if people stopped using sites like Youtube and Github, and tried not to include trademarked terms (or super-identifiable audiovisual content) anywhere.
a comment on that site really condescendingly claims this is how he would have handled it and that a script could be written in half a day to do the work.
my understanding is that an emulator effectively recreates the hardware's different components in software so that from the game's "perspective" it's running on a real machine more or less.
This process instead decompiles the game code and recompiles for a new target machine.
I suspect one can't just pump out a script in an afternoon to do this, but I am curious what is the complexity here?
For graphics, the problem to be solved is that the N64 compiled code is expecting that if it puts value X at memory address Y it will draw a particular pixel in a particular way.
Emulators solve this problem by having a virtual CPU execute the game code (kinda difficult), and then emulator code reads the virtual memory space the game code is interacting with (easy), interprets those values (stupid crazy hard), and replicates the graphical effects using custom code/modern graphics API (kinda difficult).
This program is decompiling the N64 code (easy), searches for known function calls that interact with the N64 GPU (easy), swaps them with known valid modern graphics API calls (easy), then compiles for local machine (easy). Knowing what function signatures to look for and what to replace them with in the general case is basically downright impossible, but because a lot of N64 games used common code, if you go through the laborious process for one game, you get a bunch extra for free or way less effort.
As one of my favorite engineering phrases goes: the devil is in the details
So, you're pretty much spot on with how emulators work. I also like using claymation to demonstrate it, like this. Your computer bends over backwards to give the game the exact environment it expects.
What makes recompilation more than a simple script is the rebuilding aspect. I brought up claymation because it's a great analogy for this, too. An n64 ROM is a complete set of characters, sets, and a script for a claymation movie. It's I in one studio right now, and that studio is the N64, but you need this to be in your PC studio.
First, you have to decompile your sets and characters. You take reference photos and rip out every tree in a forest set and roll each tree back into it's own ball of clay, with its own reference photo each time. Every little clay cobble on a road, characters outfits, hair, limbs, you meticulously separate every piece of clay that Nintendo shaped, ball them up, and pack them. You now have a million little clay balls and reference photos for every one of them. You take these back to your PC studio. Thankfully, with these reference photos, your clay 3D printer (compiler) can return these balls into something very close to their original shapes, except there's a bunch of little mistakes. One character's leg is slightly thinner and longer than it should be, which messes up their gait when you re-film this, so you manually tweak the leg to be accurate. The cobbles don't quite fit the same, they're a bit smaller, but you have extra clay because of that so you just make more cobblestones. The road doesn't look exactly like the original, but that's fine. The trees, again, don't quite fit right, but you've made similar trees in your studio before and you know those will work so you actually just use those as references instead of the originals. You get filming but this one scene just isn't lit right, and you can't figure out why, but you eventually figure out the N64 studio opened the blinds on their window to get natural sun in this shot, but your studio doesn't have a good view of the sun at that angle, so you have to get a good lamp.
You face a million little hurdles decompiling and recompiling. Its almost literally reinventing the wheel. Almost all the work goes into little details that almost seem unnecessary, but there's so many that it's absolutely necessary. I was watching a playthrough of a recompiled majoras mask earlier today, and the Dev of this project found his way there, too, and he said it took a few days to get majoras mask to decompile and recompile, and about a year to fix all those little details that in software become lag or new bugs. So the script guy isn't really wrong when he said he could do it fast, but he definitely wouldn't do it right.
IIRC, the original cartridge had an extra chip in it that emulation hasn't been able to use. I'm not sure if any progress has been made on this and a few other games that used these.
Nah it didn't have an extra chip -- but large portions of the game were written in microcode for the N64's processor specifically. It's part of what makes it and Rogue Squadron kind of a pain to emulate -- along with using their own audio drivers (MoSYS/MusyX that were later used as the basis for the GameCube sound systems).
IIRC there was an official Windows port at some point though. Not sure how well it worked or works on modern systems.
The keyboard controls are very janky. You'd have to do custom button mapping with a controller, and there's no analog input. At least not without some mods that I'm not sure exist.
I don't think there's grounds for a C&D here anyway. I don't think it uses any copywritten material. It transcodes the game into C I think, and that's all. It does not rely on anything Nintendo created.
It won't help emulation but on pc/steamdeck you can natively compile it so that there no need for it anymore. Not sure about smartphone but I'm sure that it should be possible!
Well, usually those re-compilers or transpilers just translate the binary to some sort of intermediate language and then any backend should be able to compile it for your target system. So, in theory those handheld could be targeted. Problem with this project is that it's not just "start transpiler, load rom, click go and your port is ready". It's more like "ok, here's your game logic. Now implement the rest (or use several other projects and duct tape their libraries together to get what you want).
Yes, that was kind of my point. N64 emulation on handhelds often sucks. So being able to have games recompiled to be better optimized on something like the Miyoo Mini would be great. While it is cool for the PC because it can allow for enhancements much more easily, just getting games up and running at a minimum is not an issue for any PC made in the last decade or two.
As with most of these decomps there is no copyrighted material included in the link and you have to provide your own ROM (and a very specific version of it) in order to build and get it to work.
After that I believe I just copied the folders to the Deck, mapped it as a non-Steam game, added updated artwork with the steamgriddb plugin etc.
I might have messed with the controls a bit but I don't recall. There is probably a more detailed Steamdeck-specific guide somewhere if you care to dig.
Will be interesting to see if this is useful for non-PC platforms as well; I've got a Myioo Mini Plus (basically an ARM SBC in a GameBoy-esque case designed to run RetroArch) - it's not really powerful enough to run a N64 emulator, but if I could recompile the games in my PC and run them natively then maybe that'll work better?
Idk about this, but the Mario 64 decompile was recompiled to run on my Anbernic 353 at 60fps, runs amazing. So I think it should be at least theoretically possible.
Yeah, I was a little surprised - the MMP can do PS1 emulation no issue, but apparently N64 is too much. I would have thought it would be the other way round
You can already do this with some N64 emulators with built in netplay like, Project64KSE. There is a small community dedicated to it with a website here.
Smash Bros Melee is much more popular to play online nowadays, and there is a great update for online play called Project Slippi. It works with the dolphin GameCube emulator and makes it very quick and easy to find games against similar skill level players. It also adds rollback netcode, stats, and other QOL features.
If Nintendo, themselves, put out an online Smash Melee remake, it would never be as close to good as Project Slippi already is.
Nintendo is preparing to sue the proper technologies out of existence. Anyway, what did you say the researchers last names were? First names too if you got them. Nintendo would love an address and possible information on their whereabouts around lunch time. It's all for the benefit of all players out there!
I thought there were many aspects of the games directly tied to fram rate.
I know that, at least in the case of mario 64, Speed runners abuse game mechanics tied to frame rate to perform tricks such as backwards long jump and other door hacks. Marios eyes blinking are tied to frame rate, they used this to identify faked speed runs in some cases.
Ok, any info on how that's being done? It sure sounds like Wiseguy figured how to compile the code that was meant for the specific VR4300 (RISC) N64's CPU for typical x86-64 architecture
Apple Rosetta 2 technically recompiles code from x86 to arm too in jit and sometimes aot, also there's box86/64 open source project, only difference between example I've said and OP is recompilation actually saves all results and not just cache, another difficulty is in OS difference, he needs not just binary translate but have something akin to WINE too while he recompiles code
If he's compiling from windows to windows, target OS shouldn't be a problem. Also, I just had to go one extra click to read Mr-Wiseguy's github 😅
He could also, in theory, use Cosmopolitan to generate an APE (Actually Portable Executable) that will run on linux, bsd, windows and mac. I had to find a video where Justine talks about it to understand how and why it works: it's basically a trick to rewrite the header of the executable, with the real magic being an "optional shebang" that lets both Windows and *Nix run the first bytes.
so. For dumb people like me (or just for me to be clear), how do I play those games? i watched the video and read the site. there's a link to the MM gamefiles on GitHub, but the video said you still need the ROMs? or this RT64?
I'm old and apparently at some point, you just lose tech savvyness... :(
can I get a step-by-step?
Yes you still need the ROMs since these PC ports contain no copywritten code. Like the other person said, you will need to compile the game yourself, but there are tools that automate the process. It's simply a matter of getting all the files you need in one place, and clicking a few buttons. The hard part is obtaining all the files (well, more tedious than hard, especially if you're not a programmer or a Linux user).
It was always possible with tons and tons of work; the news is that some dude made a tool that makes it a piece of cake to recompile the games directly from a ROM.
I wonder how much talent is wasted because of jaded programmers that think it's dumb (to them) to make something simple even if it would become very popular and maybe profitable
This is very similar to something we did in engineering school in like 2008. For a reconfigurable computing project we translated machine code into HDL.
This is something you could have done for a while if you had a few million dollars to pay a team of computer engineers to do it. The new part is the classic "some dude figured out an efficient way to do it in his garage over the summer."
Would the recompiled games effect how ACE works in some games? I'd assume since the machine code is different the exploits used to trick the pointers would be different.
Most likely. The documentation says it can change what was a single instruction on the N64 into multiple instructions, so those values will potentially be very different. It will probably close off some exploits, change others, and even introduce new ones.
This is really cool. I love emulation it is great to play old games with better options. I would love to see The N64 wrestling games get this type of treatment, I still play Virtual Pro Wrestling 2 often.
Didn't read the article, did Nintendo pay to develop this to be able to preserve the games history and release them for free so they can get some new fans for these retro games and IPs to maybe encourage them to buy some newer released games in the same series?
Maybe it was written that way to make you read faster as you get toward the end to convey a sense of facetiousness because I didn't need to read the article to know none of that's true, who knows. I'm probably just spending too much time online lately.
Exactly, with Nintendo's existing IP and old gamers dying, they need a way to get younger generation exposed to what kids in the 80s and 90s grew up with and make sure that it's plastered on all the streaming websites to get maximum exposure.