All sorts of N64 games are being decompiled ever since the compiler for SM64 was made usable on a modern system 2 years ago! Off the top of my head there's:
-The Zelda titles (led by Ocarina of Time at 64% completion)
-The HAL titles (led by Kirby 64 at 5% completion)
-Conker's Bad Fur Day (and other Rare games)
-Dinosaur Planet, which quite literally came out yesterday (which goes to show how easy it is to get an N64 decomp going, as long as the game doesn't use GCC)
That game was ahead of its time, but tripped over its own frame rate. Besides that, a huge weapon sandbox, dual wielding, co-op, secondary weapon functions, the ability to peek around corners, better AI than in Goldeneye, multiplayer AI "simulants", bonus missions, an alien sniper rifle that shoots through walls, the laptop gun, a surprising amount of dialogue for AIs(considering it's N64), and I'm sure other things I'm forgetting. Rare probably should have held off and instead released it for Xbox.
And actually, you can play a remastered version of it on Xbox through Rare Replay.
Decompilation will be pretty cool, I think, because the newer Rare Replay assets could be imported and then I'm sure that many other improvements could be made as well.
I think I heard that Perfect Dark is what Rare wanted Golden Eye to be, but I guess didn't have time to fully develop. It's a shame that it never got the same level of attention as Golden Eye, I assume because of lack of marketing & being second to come.
The marketing wasn't good and I think that was also an era where the relationship between Rare and Nintendo was in decline(they probably weren't that interested in a game that was going to compete with Tomorrow Never Dies).
There were definitely issues with Rare during the development of Perfect Dark. Nintendo probably wasn't that interested in a game that would compete with their IP(Tomorrow Never Dies). A bunch of key people left Rare out of dissatisfaction during the middle of development.
This wasn't entirely a bad thing. According to Mark Emmonds:
> Although the story and ideas for the game were kept intact, the new team contributed so much to the development that it was seen as a fresh start. The team worked in a very isolated and free environment and did not have a production manager, a schedule, meetings, commercial pressure, or any sort of deadlines. According to artist Brett Jones, "People would just do things they thought were cool and would work"
It sounds like half the original team were looking for a more organized process, but the new developers thrived. The problem, however, was that the Nintendo 64 could barely handle all the features they'd packed into the cartridge, which is why the game suffers a bad frame rate even with the Expansion Pack.
To summarize, I think a lack of top-down enthusiasm for this game from both Rare and Nintendo lead to a lack of marketing effort, and problems with development actually lead to more creativity, but that creativity caused the game's performance to suffer. Back in those days, I remember some kids not even wanting to play multiplayer because of the frame rate. Multiplayer was a big deal for Goldeneye, and Perfect Dark's multiplayer performance was objectively inferior.(despite being better from a feature standpoint)
Fun fact: an ex workmate who once worked at rare told me why perfect dark required the extra memory cart: The maps were apparently compiled into the game as part of the code by the lead dev.
That's false. All stage-specific data (geometry, collision info, scripting and even language files) is stored in a compressed format on the ROM, and only the current stage is unzipped to RAM.
That challenge gets a little bit more doable if you deploy the laptop gun at the capture point (as much as possible)! Also the cloaking device pickup is helpful...
So there is a rumor that Nintendo forgot to switch an optimization flag when compiling Mario 64 and that is why we have lag in the water levels.
Since we are talking about the source code, I’m sure someone much more knowledgeable than me might be reading and could maybe confirm or deny the rumor.
The lag in Dire Dire Docks is because the collision for the submarine (which is either 200 or 700 triangles, i can't remember) is recalculated every single frame. O2 is like a bandage to the overarching issue.
The only real cause for lag in SM64 is that the RDP graphics chip has a fixed rate for how many pixels it can draw per frame, and that's quickly filled up by large triangles, transparency, any 2-cycle effects like fog, overdraw, etc. (and that's not even taking texture loading latency into account)
I read somewhere that SM64 collisions have no fancy optimization but are just brute force and a first glance at the source seemed to confirm this. Which shows that
1) you really don’t need to optimize prematurely
2) something is very wrong with engines used in modern (indie) games of similar complexity when they perform badly on modern hardware
I don't know how fancy these optimizations are, but it is optimized.
* Tris are sorted by whether they are static (level geometry) or dynamic (moving platforms). So only dynamic tris need to be reinitialized every frame.
* Tris are further sorted into which cells they touch. A cell is a spatial partition of a level. So collision detection only needs to check against tris in your current cell.
* Tris are further sorted into walls, floors, and ceilings (depending on their normal). The find_wall_collisions, find_floor_collisions, etc. functions are each optimized for that particular kind of tri.
* Tris extend their hitbox along a coordinate axis (the up axis for floors/ceilings, the one closest to their normal for walls), instead of along the normal itself. This is cheaper to test, since you can just project down along that axis and it becomes a point-in-tri test in 2D.
MVG regularly gets key technical information wrong and barely cites any sources, so I'd take this with a grain of salt.
Example: he claimed in [1] that a Nintendo leak contained "the entire source code of IOS" (IOS being the Wii operating system) and "the Verilog for the entire Nintendo Wii". Both of these claims are completely wrong and have been refuted by both console hackers and emulator developers for the Wii. I told MVG on Twitter, he replied saying approx. "oh it's not my fault I just read what was written online and haven't looked at the details myself" [2]. To this day the video is still up, there is no errata either in the description or in comments. This is not the only example, just the freshest one in mind and one I was directly involved with.
Well, in this video it's not like he's stating it as absolute fact that they didn't forget to use -O2. He just presents another much more plausible (IMO) explanation. And he backs it up with direct references to original documentation and a tweet from a developer experienced with early N64 development.
I think his claims here looks pretty solid, if you have reason to doubt them based on the content of the video, it'd be nice if you shared that.
More examples would be interesting too if you can remember other cases. To me, getting a fact like that wrong on a breaking news kind of video and not taking the time to correct it later isn't that big of a deal to be honest. If it was really important to me what the content of the leak was I'd check myself.
Looking at the SM64 video, he: 1. misrepresents the work from the SM64 decomp project (some of the decomp developers even commented in the video comments); 2. misreads and/or misunderstands the toolchain errata, what he describes in his audio track doesn't match at all what he shows on screen. But there isn't much of a claim to debunk, because it's all hypothesis that "Nintendo wouldn't make such a basic mistake, it's deliberate".
Anyone who has experience working on emulation and reverse engineering of Nintendo games can tell you that Nintendo keeps doing basic technical mistakes when shipping production games. Dolphin's wiki has a whole category for "games that shipped with debug symbols". Pikmin has a freakin' mostly-working PC port of an early version of the game on the GameCube disc. There's also no evidence that other N64 launch titles had the same idiosyncrasy of compiling in -O0, and the whole SDK is compiled in -O2 as he even mentions in his video. How does that fit with the "early toolchain" line of reasoning?
TL;DR: Actually forgetting to build with optimizations enabled is completely in line with what emulation developers and game reverse engineers have seen from Nintendo in the past 20 years. MVG just states his own theory as fact, without the Nintendo console hacking / RE / emulation experience, and with very little evidence which doesn't even match his own claims.
EDIT: See also [1] hidden in the 2nd page of YT comments on that SM64 video, from someone who was involved with the SM64 decompilation project.
The first comment said Nintendo just forgot to switch on optimisations. If they didn't forget, but instead did it deliberately, then that is indeed a debunking.
AFAIR the DK64 thing was about a memory leak that couldn't be fixed before launch date and the quick-hack workaround was to just make the game require the expansion pak, which made the memory leak take a few days instead of hours to happen.
I recently installed custom firmware on my 3DS and was amazed that I could scan a QR code on Twitter using the camera, and a few minutes later have a fully working port of SM64 running.
Even more amazing is that Nintendo haven't taken it down, as it's the full game including all art and music.
Yeah... I absolutely love what the hacking community has pulled off with the 3DS. It's pretty much my favorite gaming handheld right now, even over the Switch!
Anyone knows where to get the source of that PC port some dude did? I know it was randomly released somewhere but Nintendo took it down before I was able to get a copy
Actually I don't think so. They have been very careful not to include any copyrighted material in the repository. For example, all game assets are not included. I believe the decompiled code itself can not be copyright protected by nintendo since the decompilation is written from "scratch"... Although I am not fully sure how the law are in regards to that.
I really, really doubt it's legal, or if it is not in a way that would be easily defendable in court. Disassembled code is not a clean room implementation, which is what's needed to reimplement e.g. GNU licensed code legally.
>I believe the decompiled code itself can not be copyright protected by nintendo since the decompilation is written from "scratch"... Although I am not fully sure how the law are in regards to that.
Even if it is from "scratch", it is still a copy. Which is then protected by copyright. Same way music covers are still protected by copyright even if I perform it myself.
Ok, you are probably right! I just seemed to recall hearing that if you write a code from scratch, that then “happens” to compile exactly into the same binary, then it is a bit of a “gray area” as to if the original owner has copyright or not.
Again, I honestly don’t know for sure, sorry for the confusion.
Decomp modding is the next unexplored frontier in SM64 modding. Kaze (the figurehead of the community) uses decomp ever since SM64 Splitscreen, and with brand new features being added by more technical users, there's a ton of cool mods being developed, such as:
There is a somewhat active community, including a model exporter for Blender (which exports Blender models to the format that Super Mario 64 uses). New maps, too.
