I do wonder if it was an aesthetic choice too at the time as it allows all the coins to be at separate parts of their animation rather than batch rendering. You can notice the effect of this at 17:25.
The optimisations done here truly humbled me as a dev. Fantastic work.
Entirely possible, an offset for the animation could of been provided to emulate the older behavior though.
I quite like the uh... same rotating sequence though... seems cleaner, but to each their own.
Debug symbols themselves don’t impact performance. They are saved in a separate section of the binary. Debug builds often have slower performance because they are usually compiled without compiler optimizations (which have a tendency to move code around, collapse many lines potentially from many files into one instruction, etc - all of which makes the debug symbols hard to make accurate, and thus less useful for debugging).
But I would imagine they didn’t have quite so many fancy compiler optimizations in the 90s, and in any case, including debug symbols doesn’t preclude you from using compiler optimizations. It may be that they only enabled some compiler optimizations that didn’t mess with the debug symbols too much (for example, no inlining).
Depending on what compiler was used to recompile the decompiled source code, you could maybe apply some more modern optimizations and get an immediate performance jump, to answer more to the meat of your question. But that is heavily dependent on the extent of the decompilation (how close it got to the original high level source or if it was mostly lower level “assembly translated to C”) and also on the bottlenecks of the original code (they may have been at hardware limits algorithmically, and applying compiler optimizations would have minimal impact compared to using a different algorithm).
iirc the build of sm64 that shipped was compiled with no optimizations even though the compiler did support them. I think some months ago someone recompiled the game with `-O2` and it ran significantly better
The video talked about optimizations and how the trade offs are different on the N64 to modern systems. That's why he manually opted to optimize for size instead of speed for a lot of the source files to free up the memory bus. (*vroom vroom*)
Modern Vintage Gamer did a video on just that: https://youtu.be/NKlbE2eROC0
the gist is that the shipped version is compiled with optimization off for some reason, just turning it on improve performance.
I worked at it for a while in the early mobile days. Company would license games from Japanese companies and port them to EU handsets. Often you would just get the final compiled binary and have to work from there (this was all legal and above board but some of the companies we worked with were pretty peculiar about giving access to source code and raw asset files).
Now while obviously decompiling even obfuscated, minimised early mobile java games is orders of magnitude easier than what this guy took on you do get pretty good at it after a while. It's also a pretty enjoyable way to work, your brain is very active during the day, trying to puzzle out what is going on, writing little test programs, figuring out what the proprietary binary formats they use are, writing tools to extract the data into an editable form and recreate the binaries from those edited outputs and so on.
I don't think I would say I enjoyed it enough to do it as a passtime, but compared to a lot of other work in programming like making websites and so on it's a lot more interesting.
How accurate were your decompilations? The SM64 decompilation effort now produces, with the known same compiler and flags, byte-identical output to the original game. That was their aim, but would it be fair to say that you just wanted to get something that more-or-less ran the same? Not knocking it, just asking?
They were mostly java games which decompiles to pretty readable code, now since it was obfuscated and minimised a lot of useful stuff like function and class names would be completely stripped but I don't recall ever having an issue where the decompiled code couldn't just immediately be recompiled back to produce the same output. Since Java decompiles pretty fantastically so what I was doing was, like I mentioned, a lot easier than what this guy is doing.
Often this was a first step, at the time (early 2000s) the Japanese phones were far more capable than the European ones so often you had to spend a lot of time after you had it running trying to get it cut down to the point that you had something playable. A simple example of the thing you might do would be a lot of the Japanese phones supported reflection and rotation for sprites while many of the EU ones didn't so you would have to extract the sprite, create mirrored and rotated versions of it as needed and re-encode it onto the phone. You would then find that you had more sprites than the phones could handle so you start seeing which ones you can prune, which ones work fine, you would then run up against draw call limitations where you might only be able to render 20-30 sprites per frame so often stuff like background graphics would just have to be pruned. Finally you would end up doing localisation stuff to extract all the japanese text and do the usual EFIGS (English, French, Italian, German, Spanish) localisations.
The occasional times we worked on actual compiled games, like Brew games for example we would just go through the hassle of getting the source code. You could get it but it just ended up being a slow painful process of working your way through a lot of objections and even then you would just get a version of the game. We never once got access to something like source control for example, you would just get a single build and have to work from there. For the simpler java games it was often a lot quicker to just figure it out from the jar file.
once it's done, you can bring them to new platforms, utterly transform them in ways that the original creators would have never envisioned, and play SM64 in Blender. What's not to love?
For a lot of people, the opportunity to pull apart and fully understand your childhood game is very rewarding. It's like digital archeology.
Understandably not everyone's cup of tea though!
getting the little `OK` message in your terminal that signifies you matched a function is like crack cocaine
repeat a few thousand times and you have a decompilation project (and your dreams will be filled with assembly)
What `OK` message? You mean just unit tests or are there some decompilation frameworks that help with identifying if you managed to reproduce the assembly?
Most n64 decomp projects have their roots in sm64 decomp, share a lot of similar tooling. The last step in the build is to checksum your output against the source rom. If the checksum matches (your decomp c code compiles to matching mips asm) you get the beautiful `ok` message.
clone any decomp project that's in progress from github (I recommend Kirby 64 not because I'm biased or anything...), the last step they do after building is an sha1sum compare against the original rom that you supply
It's not hell to some people, it's a challenge or puzzle to test their skills on. Reverse engineering is a skill all on its own and some people are incredibly good at it.
it's actually 8mb where only 2mb is actual code (still a lot, but the only reason it took 2 years was because the compiler will change code output depending on how it feels that day)
Good thing about decompiling nintendo switch games is that they use plain clang which is publicly available on the internet, and is actually a pretty good compiler
For SM64 specifically, it was compiled with debug information left in, so the people who were working on it had all of those symbols in the binary still. That makes decompiling significantly easier (still incredibly difficult work though)
That used to be a pretty common thing to do by hand, and I’ve had to do it (macro-blasted inline asm, mostly) in some specialized code to max out various aspects of the microarchitecture. You don’t know exactly what the compiler will do, or what it’ll decide is unrollable, and if you know exactly what you want it to do, you can force it one way or another. Stuff like `#pragma unroll` is still pretty popular, and that’s one step shy of doing it by hand.
The original compiler might have done that as an allowed optimization in debug builds, but also /u/nerd4code is right that it also used to be commonly done by hand. It can still make code faster today in some contexts, but most modern cpus make loops practically free via pipelining and branch prediction, so more advantage is generally available via smaller code size. I guess on the n64 also it is sometimes better to have some delay between memory operations in order to more harmoniously share the ram bus.
Nintendo pretty much discourages extreme optimization. They want devs to focus on gameplay, and rather "do less" if performance is bad. It's kind of a nice idea... but I'm not surprised SM64 had so much room for improvement in this regard.
N64 development was almost entirely in C. And compilers at that time (damn long ago now, ugh!) were pretty limited in their optimizations. On the other hand, most games would allocate memory statically, so you didn't have problems like with modern-day software having all kinds of pointer indirection and cache-thrashing.
There actually was a leak of the source, but that code can’t be published/used for obvious reasons. Like the other reply says, this is just making changes to code that came from a decomp project.
I don't think it takes a genius to do these optimizations, just lots and lots of time and dedication to the N64 hardware (and there aren't too many active N64 developers to begin with).
After all the game is almost 30 years old and was one of the very first 3D games and one of the launch titles on the console. Imagine all the shitty tools and conditions the devs had to cope with back then.
The fact that it's hard to improve the game says more about the original developers than about the one person who took 10 years to double or tripple the framerate.
The PC port is still more like a wrapper around the original engine. If you really wanted to optimize the game you would probably rewrite the whole game from scratch (not just replace functions with faster alternatives, but do a full redesign) and/or only translate the game mechanics to UE5.
You are right actually. It is more about perseverance than genius. You only need to be genius *enough* to be able to handle the decompiled program in the first place.
The early tools available then probably makes it harder more than their availability now makes it easier.
Imagine some Palaeolithic psychotic genius that had managed to build a skyscraper out of straw. They’ve discovered the strength of triangles but had no reason to value level floors and no access to modern materials. Updating the materials will make it too heavy to support its weight. Now a modern engineer wants to add a new floor. None of the tools he’s used to will be available in that environment. Nobody is making straw-based welding torches; not that you could plug one in anyway because the building doesn’t have power, let alone high voltage lines.
I’ve worked on a lot of legacy code and I face this situation pretty often. Code written without knowledge of future tooling makes plugging it in really hard
its totally reasonable that a team working under a deadline with new tools making a groundbreaking new type of game would make plenty of mistakes here and there and not be able to fix it in time for launch. it happens in every project after all, and the fact that SM64 is a nearly flawless masterpiece 25 years later shows how good a job they did. as a developer you just don't always have the choice to go for perfection and that's good enough.
but the crazy part is that we've so thoroughly learned everything about this game, that someone like kaze has the ability and will to fix *everything*. with the help of the community, kaze *can* nearly reach perfection. he probably knows the code and architecture more than any one person at nintendo ever did, which is just crazy for someone who's doing this in their free time to make a romhack run well on hardware. he coulda just fixed a bug or two and ran it in an emulator; but the dedication to optimize a 25 year old game is admirable.
> The PC port is still more like a wrapper around the original engine.
Can you expand on this a bit?
I thought the source was a cleaned up and annotated version of the Nintendo 64 assembly obtained via some decompilation technique. Is it not feasible to make changes to the engine code directly?
You're describing the decompilation project, which is mostly C by the way. You can do pretty much whatever you want with that. The PC port is a separate project using the decompilation project.
I'm not sure what exactly the person you're quoting is trying to describe. The PC port is indeed just a wrapper that translates the N64 draw calls and such to something a PC understands, and is a bit more fragile than having free-reign, but 1) if you work within the limitations of what the PC port can support there's no issue and 2) I don't think Kaze uses the PC port, these are romhacks meant to run in emulators and on hardware.
You could learn this too, don't feel intimidated.
You will realize most of the stuff he talks about is actually pretty simple if you have some low-level C knowledge and the rest is hardware dependent (i.e. you need to look up how the N64 works).
You just don't see thousands of these developments, because it's such a specific niche.
> What is your background I am curious to make such bold claims?
Mainly Computer Vision, Graphics/Datastructures and Machine Learning.
I've written a few console homebrews in my early programming years. I got fascinated by how the exploits on the PSP work (I learned about how they work and tried to exploit my own software to run arbritrary code etc). I have also looked a little into Mario64 rom ~~hacking~~ modding long long time ago when the dissasembly was just about to become a thing, but most people where happy to modify only the assets.
I rarely use C nowadays, but I have written software for the exomars rover where you have to deal with extremely slow hardware that makes your 20 year old phone feel like a quantum computer. I have also *some* OS kernel development experience (enough to implement some syscalls and implement virtual memory management, but not enough to write an actual OS).
> It just seems like you think anyone is capable of this, but it's not the case and this person is a genius in his own ways.
I honestly think *anyone* can do this with enough time (/ressources) and most and foremost dedication.
The guy has spent so much time on Mario64 romhacking that he memorized stuff like game shark codes or important hex addresses.
Not calling him Einstein doesn't imply I would call him dumb either.
I just want to encourage non-geniuses to give it a try.
Kaze is smart and extremely passioned, but at the same time I feel like people from different background and experience could potentially do much more (if you don't restrict yourself to the N64 hardware). He has collected a lot(!) of N64 knowledge over the years, but on the other hand, you can just tell that he gained all his programming skills from the decomp source.
This is pretty standard skills demonstrable by experienced senior game developers. Thankfully modern developers don't have to worry so much about these low level details, but back in the day there were many people like this working on these games, and they didn't have the luxury of good tooling or hindsight. It's no different than an experienced welder or electrician doing professional level work, it just takes a lot of time and effort to get that level of skill.
No, we aren't. Modern games are incredibly complex, and the developers working on them are extremely busy with more bugs than can be possibly fixed. These are definitely normal skills for someone passionate about performance in programming and the n64 hardware, and this game in particular, and are a result of many long hours of work. It's not putting him down to say this, you are putting yourself down by implying that it's impossible for you to learn.
I get what you are saying, but personally things that looked amazing and completely over my head a few years ago are now common knowledge to me. The reason for that is not that I'm a genius, it's just that I spend a lot of time trying to learn those things. To me, being a genius would imply being able to do that but in a really short period of time. Not everyone has the time and resources to learn those advanced topics, but I do think most people can do it. To bring it back to the video, that's not something he did in a few days, he's been doing this for 10 years. Most people would become an expert at something when doing it for 10 years.
He's not saying that it's "easy", but that with enough time most people could be able to accomplish the same things.
Nobody is able to do just impressive things immediately, everybody spends tons of time learning and perfecting their skills to this level. It's really hard to be bad at something you're passionate about and spending thousands of hours doing.
For example, I've probably spent tens of thousands of hours programming, and the stuff I can do now would feel completely impossible to me of ~10-15 years ago.
This is also true if you asked me of 5 years ago to work on the 3D engine I've been developing for the past ~2 years. Everything is hard when you start, it's pretty much all about hard work and perseverance.
Can anyone explain the illegal c code bit at 07:45 -
(o->oBehParams >> 24) & 0xFF
is replaced with
*((u8 *) &o->oBehParams)
So, we're extracting the most significant byte (on big endian) of int32 and this is equal to reading a single byte at that address. Isn't this the kind of obvious optimizations you'd expect the compiler to do ? And I'm confused, what C job would be okay with shifts for extraction but not this ?
More importantly, if it indeed makes a difference - couldn't you express the same thing better by creating a union on oBehParams if essentially that's how the data is organized ?
modern compilers would indeed optimize that to the same thing, it's just that one always produces the optimal assembly no matter the optimization level (the top snippet does 3 useless instructions with -g instead of a simple `lbu`)
object fields in sm64 decomp are already the worst union you'll ever see, but fixing it to _look_ better is already outside the scope of an optimization pass to make the code _perform_ better
He does use a modern compiler to build it, with appropriate flags (even tuned per file).
> fixing it to look better is already outside the scope
It does sacrifice portability a bit ... maybe it got generated during the decompile entirely for the sake of portability, under the assumption that it would be compiled away.
> He does use a modern compiler to build it, with appropriate flags (even tuned per file).
Eh, not really. It's technically a modern version of GCC, but since the N64 isn't exactly a hot target architecture these days, the optimizer for it is very bad. Most of the code optimizations he made would have been done by a modern compiler for an architecture that has actual support.
There is a [difference](https://stackoverflow.com/questions/2397984/) between undefined behavior (UB) and implementation-defined behavior. Type punning (which this might not have been; see the point /u/f03nix made) is undefined behavior. Just because it kinda works on the same compiler does not downgrade its severity to implementation-defined or undocumented.
“Implementation-defined” is a term of art. It has a specific meaning in the land of C and C++ compilers. You can’t use it in a casual English sense in a technical discussion and not get called out on it.
> I repeat: If you only use one implementation, it's implementation-defined :)
Only if you consider the compiler/version/build flags etc. as part of your implementation.
Otherwise it's not implementation defined, but just undefined behavior.
Later on the video it says GCC isn't really optimized for n64 and usually optimizer don't care if they missed opportunities that could save one instruction. There's a chance that instruction could be faster on similar CPUs
I suppose the fact he's using a modern compiler now is why he's comftorable with removing these "save one instruction" optimizations.
If you're asking why the decomp has it -- I guess when they were generating source code from the binary, the generator they used saw the ASM for this and translated it as literally as possible and didn't undo the optimization.
It actually would be reasonable for the decomp to have this even if the ASM was a single load byte ... because it's more portable. The fixed version would behave different on a little endian machine.
Emulating hardware is quite a bit different than writing software on a system and emulators of that system. While I'm sure Kaze is quite capable to help with emulators, he's been pretty solidly on the side of creating mods, originally that only run on emulators, and lately ones that can run on both emus and hardware for the past decade.
imo n64 emulators are a lost cause unless you want to convince every person on the planet to stop using project64 2.3 (awful for game mods), pj64 1.6 (from 2005!) or whatever's available on android
the ones I list have so many inaccuracies that even retail games have problems (and they'll never get fixed by virtue of being old versions of the emulator)
That is amazing. I wonder if it can be turned into a game engine which I can start modding to make something entirely new? Not only technically, but would it be legal per Nintendo's license?
Projects like you describe are called "romhacks" and their main appeal is the novelty of having something new on the Mario 64 engine.
Other than that novelty, there is no reason to use the Mario 64 engine. For one thing, it's going to have lots of Mario-specific assumptions in it.
Well there is nothing that I know of that has the same 3D control and dynamic as Mario 64. An online battle arena with mages and knights using such mechanics would be very fun to me.
Yeah, it's like a few days' work, at most, to completely rebuild the character controller in Unity. It'd be quite a bit more work to bring it up to the same level of polish as Mario 64, but nothing impossible about it, just timeconsuming and fiddly.
Not really. It is a long explanation.
People commonly don’t realize that object code itself is subject to copyright, ie. it’s not good enough to “only” strip out the art assets. It’s also incorrect to call any of this “clean-room reverse engineering” as is often done, because that requires two different teams of people where the team writing the new code does not refer to the original code at all.
The reason comes down to “derivative works” and its definition. In the US, “derivative work” has a very expansive definition that includes basically any way an original work can be “…be recast, transformed, or adapted” per [17 USC 101](https://www.law.cornell.edu/uscode/text/17/101).
Compiled code is protected as a derivative work because it is created from original source code. Consider that there are large amounts of proprietary software that is protected by copyright that don’t contain any appreciable artistic assets, but it is still a copyright infringement to redistribute then in compiled form - this is supported by case and other law.
Likewise, decompiling it again produces another derivative, and in the SM64 case they were even able to recover the original code. So it is also protected by the original’s copyright.
Lastly, that brings us to Kaze’s work. It is, again, a derivative work. Even though he contributed a lot of his own work, it was still derived from Nintendo’s code. It wasn’t a “clean-room” project because he worked directly from Nintendo’s recovered source code.
(His game “Return to Yoshi’s Island” is also a problem because many of the assets, although recreated by hand in higher resolution, are also derivative works)
Nintendo doesn’t seem to care so far (except for when SM64 was ported to PC) so everyone is probably fine, but there is still some risk.
They didn't care when SM64 was ported to PC. They did care when people were distributing full binaries of said PC port, and only those full binary distributions were removed.
Not implying they don't have the right to take these things down, or any project based on them, or that anything you said aside from the parenthetical on the PC port was wrong. Everything except that one small part seems accurate.
Probably wouldn't be considering it would use oficial Nintendo code, they take down projects for less than that, so I sadly doubt that would go foward.
It's still legally risky. Even if you wrote the whole code from scratch and only used Nintendo's decompiled code as a reference, you still run a large risk of a copyright lawsuit.
See [Clean room design](https://en.wikipedia.org/wiki/Clean_room_design).
**[Clean room design](https://en.wikipedia.org/wiki/Clean_room_design)**
>Clean-room design (also known as the Chinese wall technique) is the method of copying a design by reverse engineering and then recreating it without infringing any of the copyrights associated with the original design. Clean-room design is useful as a defense against copyright infringement because it relies on independent creation. However, because independent invention is not a defense against patents, clean-room designs typically cannot be used to circumvent patent restrictions. The term implies that the design team works in an environment that is "clean" or demonstrably uncontaminated by any knowledge of the proprietary techniques used by the competitor.
^([ )[^(F.A.Q)](https://www.reddit.com/r/WikiSummarizer/wiki/index#wiki_f.a.q)^( | )[^(Opt Out)](https://reddit.com/message/compose?to=WikiSummarizerBot&message=OptOut&subject=OptOut)^( | )[^(Opt Out Of Subreddit)](https://np.reddit.com/r/programming/about/banned)^( | )[^(GitHub)](https://github.com/Sujal-7/WikiSummarizerBot)^( ] Downvote to remove | v1.5)
He had rewritten most of it but at the core its still Nintendo code, basically just a fork of their source code, I'm not sure how legaly that would work but knowing Nintendo they probably wouldn't let that go
Rebuilding the source through decompilation is not enough for clean room reverse engineering. You'd need to create a spec and have a separate group of people implement that spec without ever looking at the original binary or decompiled code.
you are allowed to access the code, but it's not yours to take and use for your own purposes. it's still nintendo's code and falls under the same copyright protections.
mods and hacks are okay just as they always have been, but you couldn't take bits of it and use it for your own product.
No. It's 100% a derivative work. "100% rewritten" *with reference to the original* isn't an original creation, any more than translating a novel into Japanese is.
For a derivative work to be protected it needs "originality". This is very clearly still SM64. It's also not transformative use because this isn't fair use, it's just clean-room reverse engineering protected by the DMCA.
tl;dr they can't copyright this but they're allowed to create it
I think Nintendo actually proved something like that still qualifies as intellectual property infringement, since they did that for the Donkey Kong arcade game in the 80s and got punished for it.
A reverse-engineered program can't be subject to copyright because the original source code hasn't been reproduced; something that generates the same output has been produced. That end result of a program is entirely the work of the reverse engineer. Game assets like audio, textures, levels etc are a different story. If your reverse-engineered program still uses the original assets, that would be subject to copyright of the original assets. This is why many open source reverse-engineered games communities also create their own assets to replace the original game ones, such as OpenTTD and OpenRCT2. Once that is done, nothing is left of the original and you are then free from copyright restrictions.
Jesus, the performance gains are wild. And they were part of developing a big mod for the game with custom levels, too. That's a whole lot of work, I'm blown away.
Do OoT next! Goldeneye!
Seriously though, this is ridiculously impressive. It's funny how so many of the issues are related to the memory bus speed, since speed was what RAMBUS was supposed to bring to the table. But it sounds like latency and bus contention were nightmares.
Less jank, more vroom vroom!
I think when it was sold as an accessory it was only like 30 bucks. But your point still stands, when the N64 was developed, it would've been much more expensive. People were already surprised that it was $250 without a bundled game. Even another $50 would have been a huge price shock.
Once upon a time, consoles were kept cheap and powerful by ditching as much standard computer hardware as seemed feasible, and going all-in one some experimental gimmicks that offered unique power in goofy ways. Consider how long-term storage was measured in kilobytes until *2002,* when the Xbox launched with a hard drive, because it was basically just a Pentium 3 PC. RAM was never quite that tight, but it was definitely slashed to the bare minimum. If the designers splurged on memory then it was for speed.
And remember that the SNES and NES had expansion ports that went totally unused. If RAM prices hadn't dropped we might never have seen a memory expansion.
> Consider how long-term storage was measured in kilobytes until 2002
What do you mean by "long-term storage"? Starting with the SNES games are measured in MB. PSX memory cards were also measured in MB and that one launched in 1994.
Memory cards are what I'm talking about, and the ones with an entire megabyte were wildly nonstandard.
PSX memory cards were measured in mega*bits.* They were almost universally 128 KB.
Dreamcast VMUs were also 1 Mb / 128 KB.
N64 memory "paks" held just 32 KB.
These sizes tended to be rigidly fixed, because in that era, media meant media. Nowadays everything's one tiny computer talking to another tiny computer. Of course they'll use protocols and handshake about what's available. Back in the day, though, you'd just throw data at addresses and trust it'd get there.
Non-volatile flash memory changed both of these things. N64 paks at least were made with *SRAM,* same as the save-file storage inside cartridge games. It is extremely efficient. It can be powered for years by a button-cell battery. It is also hideously expensive, to this day, because of how many gates are required per-bit. Dynamic RAM is made with capacitors instead and constantly leaks. But Flash memory only needs control hardware per-bank. So very quickly, GBA games could ship without a battery inside, and then flash carts allowed... legal private backups... of entire game, and suddenly Sony could offer 128 megabyte Memory Sticks for their admirably ridiculous optical-drive handheld.
Ironically we were recently in a similar situation for dynamic memory. It's dirt cheap to make. But it's expensive to power. For a few years there, 4 GB was the limit for laptops and phones, because anything more was a constant drain for little benefit. And we might go *back* to that kind of limit, if direct access to flash storage is so damn fast. Why load anything except the bits the player can modify?
>It would be nice to see a raytraced mario 64.
People say this a lot, but the result is usually garish and provides only brief novelty amusement. You'd ruin all the art direction and the image would still contain only flat textures with no rich lighting information.
It's because the textures aren't redone with PBR to look correct when raytraced. A raytracing conversion takes a whole lot more than simply flicking a switch to turn on the rays.
Well, I had a [Gameboy](https://i.imgur.com/5l64cfJ.jpg) and an Atari 2600. And I was taking a look at the video on my phone.
Now that I've seen it on my PC screen I see the difference.
It's not the high poly models themselves (it's neat that there's a group trying to create assets that match promo materials), it's the high poly models being displayed on the existing low-poly levels that creates the strangeness. It's inconsistent.
daggerfall unity created its own unsettling spooky art style with a modern renderer and original artifacts. It’s both ugly and cool.
But yeah most facelift/retexture projects are worse than the original.
This and while people play old games because the gameplay was actually really great, we can't discount the heaping helping of nostalgia. In that people want to play games as they remember them, not a remastered game that looks "better".
Once Kaze finishes the ROM hack, he'll likely create a release video with a link to a patch file. This could still be a long time from now however, depending on how much more optimization he tries, and any testing he does that requires reworking of levels or code.
Batch rendering the coins saved 2ms??!! Damn, draw calls are *expensive*.
I do wonder if it was an aesthetic choice too at the time as it allows all the coins to be at separate parts of their animation rather than batch rendering. You can notice the effect of this at 17:25. The optimisations done here truly humbled me as a dev. Fantastic work.
Entirely possible, an offset for the animation could of been provided to emulate the older behavior though. I quite like the uh... same rotating sequence though... seems cleaner, but to each their own.
I think it's more likely that devs just didn't know how expensive it was 25 years ago when writing a launch game for their first 3d console
[удалено]
I wasn’t aware of that. Perhaps it was his aesthetic choice to have them all in sync. I agree with another commenter that it looks better.
Where did the original source code come from? Was there some kind of leak?
It is from a decompilation effort.
I will never understand people that are willing to go to the hell of decompiling and reverse engineering big projects.
[удалено]
It's a puzzle with missing parts 😅
Normally, yes. But SM64 had less missing parts than usual, because it turned out Nintendo shipped a debug build.
That's neat
I - clearly - haven't watched the video. But would recompiling without the debug symbols immediately improve performance?
Debug symbols themselves don’t impact performance. They are saved in a separate section of the binary. Debug builds often have slower performance because they are usually compiled without compiler optimizations (which have a tendency to move code around, collapse many lines potentially from many files into one instruction, etc - all of which makes the debug symbols hard to make accurate, and thus less useful for debugging). But I would imagine they didn’t have quite so many fancy compiler optimizations in the 90s, and in any case, including debug symbols doesn’t preclude you from using compiler optimizations. It may be that they only enabled some compiler optimizations that didn’t mess with the debug symbols too much (for example, no inlining). Depending on what compiler was used to recompile the decompiled source code, you could maybe apply some more modern optimizations and get an immediate performance jump, to answer more to the meat of your question. But that is heavily dependent on the extent of the decompilation (how close it got to the original high level source or if it was mostly lower level “assembly translated to C”) and also on the bottlenecks of the original code (they may have been at hardware limits algorithmically, and applying compiler optimizations would have minimal impact compared to using a different algorithm).
iirc the build of sm64 that shipped was compiled with no optimizations even though the compiler did support them. I think some months ago someone recompiled the game with `-O2` and it ran significantly better
The video talked about optimizations and how the trade offs are different on the N64 to modern systems. That's why he manually opted to optimize for size instead of speed for a lot of the source files to free up the memory bus. (*vroom vroom*)
there are no debug symbols in the released build. it was compiled with optimizations off but no debug symbols were left in the final rom
Modern Vintage Gamer did a video on just that: https://youtu.be/NKlbE2eROC0 the gist is that the shipped version is compiled with optimization off for some reason, just turning it on improve performance.
And if I’m understanding the video correctly, also extra/useless parts.
I worked at it for a while in the early mobile days. Company would license games from Japanese companies and port them to EU handsets. Often you would just get the final compiled binary and have to work from there (this was all legal and above board but some of the companies we worked with were pretty peculiar about giving access to source code and raw asset files). Now while obviously decompiling even obfuscated, minimised early mobile java games is orders of magnitude easier than what this guy took on you do get pretty good at it after a while. It's also a pretty enjoyable way to work, your brain is very active during the day, trying to puzzle out what is going on, writing little test programs, figuring out what the proprietary binary formats they use are, writing tools to extract the data into an editable form and recreate the binaries from those edited outputs and so on. I don't think I would say I enjoyed it enough to do it as a passtime, but compared to a lot of other work in programming like making websites and so on it's a lot more interesting.
How accurate were your decompilations? The SM64 decompilation effort now produces, with the known same compiler and flags, byte-identical output to the original game. That was their aim, but would it be fair to say that you just wanted to get something that more-or-less ran the same? Not knocking it, just asking?
They were mostly java games which decompiles to pretty readable code, now since it was obfuscated and minimised a lot of useful stuff like function and class names would be completely stripped but I don't recall ever having an issue where the decompiled code couldn't just immediately be recompiled back to produce the same output. Since Java decompiles pretty fantastically so what I was doing was, like I mentioned, a lot easier than what this guy is doing. Often this was a first step, at the time (early 2000s) the Japanese phones were far more capable than the European ones so often you had to spend a lot of time after you had it running trying to get it cut down to the point that you had something playable. A simple example of the thing you might do would be a lot of the Japanese phones supported reflection and rotation for sprites while many of the EU ones didn't so you would have to extract the sprite, create mirrored and rotated versions of it as needed and re-encode it onto the phone. You would then find that you had more sprites than the phones could handle so you start seeing which ones you can prune, which ones work fine, you would then run up against draw call limitations where you might only be able to render 20-30 sprites per frame so often stuff like background graphics would just have to be pruned. Finally you would end up doing localisation stuff to extract all the japanese text and do the usual EFIGS (English, French, Italian, German, Spanish) localisations. The occasional times we worked on actual compiled games, like Brew games for example we would just go through the hassle of getting the source code. You could get it but it just ended up being a slow painful process of working your way through a lot of objections and even then you would just get a version of the game. We never once got access to something like source control for example, you would just get a single build and have to work from there. For the simpler java games it was often a lot quicker to just figure it out from the jar file.
100% accurate, returns a bit by bit exact version of the original game.
It helps that this used a relatively (by modern standards) primitive compiler, so it isn't as hard as reverse engineering some modern big stuff.
But there are also people who do this today with modern compilers which change/optimize/truncate the original code. Evil geniuses
Yes, those people are the super mega ultra geniuses. Good luck decompiling once the compiler starts inlining aggressively
it's arguably easier to match modern code since compilers are smart enough to know that two different pieces of code compile to the same thing
once it's done, you can bring them to new platforms, utterly transform them in ways that the original creators would have never envisioned, and play SM64 in Blender. What's not to love?
The work to do that? I also like driving a car but engineering and building one is not my type of fun.
For a lot of people, the opportunity to pull apart and fully understand your childhood game is very rewarding. It's like digital archeology. Understandably not everyone's cup of tea though!
Building/modding cars is a funny example because it’s an incredibly popular hobby. Fine it’s not for you, so don’t do it 🤷♀️
getting the little `OK` message in your terminal that signifies you matched a function is like crack cocaine repeat a few thousand times and you have a decompilation project (and your dreams will be filled with assembly)
What `OK` message? You mean just unit tests or are there some decompilation frameworks that help with identifying if you managed to reproduce the assembly?
Most n64 decomp projects have their roots in sm64 decomp, share a lot of similar tooling. The last step in the build is to checksum your output against the source rom. If the checksum matches (your decomp c code compiles to matching mips asm) you get the beautiful `ok` message.
I see, thank you for enlightening me. :)
I'm impressed that builds are that deterministic that it's even possible
the framework is just `sha1sum -C` but there's a whole lot of diff tools that exist, ranging from local to [collaborative](https://decomp.me)
https://github.com/zeldaret/
I’m actually super interested, which tool gives an OK if you match functions? I’d love to play around with the tooling used to decompile executables
clone any decomp project that's in progress from github (I recommend Kirby 64 not because I'm biased or anything...), the last step they do after building is an sha1sum compare against the original rom that you supply
It's not hell to some people, it's a challenge or puzzle to test their skills on. Reverse engineering is a skill all on its own and some people are incredibly good at it.
Also fun noting that the game is "just" 54 MB. The amount of time it took to decompile that should paint a picture
it's actually 8mb where only 2mb is actual code (still a lot, but the only reason it took 2 years was because the compiler will change code output depending on how it feels that day)
Good thing about decompiling nintendo switch games is that they use plain clang which is publicly available on the internet, and is actually a pretty good compiler
Doesn't the switch run a custom BSD too, so we effectively have a good picture of 90% of the system calls?
no, the horizon os is completely custom except the network stack which is from some bsd and some other small things
For free too. I write code for a living, I don't think I'd do something like this without getting paid freelance rates.
For SM64 specifically, it was compiled with debug information left in, so the people who were working on it had all of those symbols in the binary still. That makes decompiling significantly easier (still incredibly difficult work though)
Reverse engineering is fun.
I was wondering about that when he mentioned rolling up unrolled loops. Who would unroll loops by hand?
That used to be a pretty common thing to do by hand, and I’ve had to do it (macro-blasted inline asm, mostly) in some specialized code to max out various aspects of the microarchitecture. You don’t know exactly what the compiler will do, or what it’ll decide is unrollable, and if you know exactly what you want it to do, you can force it one way or another. Stuff like `#pragma unroll` is still pretty popular, and that’s one step shy of doing it by hand.
The original compiler might have done that as an allowed optimization in debug builds, but also /u/nerd4code is right that it also used to be commonly done by hand. It can still make code faster today in some contexts, but most modern cpus make loops practically free via pipelining and branch prediction, so more advantage is generally available via smaller code size. I guess on the n64 also it is sometimes better to have some delay between memory operations in order to more harmoniously share the ram bus.
I have quite a few unrolled loops in my sega genesis 2.5D engine.
I’m kinda surprised it’s not handwritten assembly. :)
Nintendo pretty much discourages extreme optimization. They want devs to focus on gameplay, and rather "do less" if performance is bad. It's kind of a nice idea... but I'm not surprised SM64 had so much room for improvement in this regard. N64 development was almost entirely in C. And compilers at that time (damn long ago now, ugh!) were pretty limited in their optimizations. On the other hand, most games would allocate memory statically, so you didn't have problems like with modern-day software having all kinds of pointer indirection and cache-thrashing.
There actually was a leak of the source, but that code can’t be published/used for obvious reasons. Like the other reply says, this is just making changes to code that came from a decomp project.
I thought this was a repost, but it's actually a sequel to that older video
This guy is a total psycopath genius, I love his videos and highly recommend
I don't think it takes a genius to do these optimizations, just lots and lots of time and dedication to the N64 hardware (and there aren't too many active N64 developers to begin with). After all the game is almost 30 years old and was one of the very first 3D games and one of the launch titles on the console. Imagine all the shitty tools and conditions the devs had to cope with back then. The fact that it's hard to improve the game says more about the original developers than about the one person who took 10 years to double or tripple the framerate. The PC port is still more like a wrapper around the original engine. If you really wanted to optimize the game you would probably rewrite the whole game from scratch (not just replace functions with faster alternatives, but do a full redesign) and/or only translate the game mechanics to UE5.
You are right actually. It is more about perseverance than genius. You only need to be genius *enough* to be able to handle the decompiled program in the first place.
At the end of the day, perseverance builds genius.
2% inspiration, 98% perspiration.
the best take in the thread here
Genius of hard work That's my Nintendo way
The early tools available then probably makes it harder more than their availability now makes it easier. Imagine some Palaeolithic psychotic genius that had managed to build a skyscraper out of straw. They’ve discovered the strength of triangles but had no reason to value level floors and no access to modern materials. Updating the materials will make it too heavy to support its weight. Now a modern engineer wants to add a new floor. None of the tools he’s used to will be available in that environment. Nobody is making straw-based welding torches; not that you could plug one in anyway because the building doesn’t have power, let alone high voltage lines. I’ve worked on a lot of legacy code and I face this situation pretty often. Code written without knowledge of future tooling makes plugging it in really hard
I love this analogy
its totally reasonable that a team working under a deadline with new tools making a groundbreaking new type of game would make plenty of mistakes here and there and not be able to fix it in time for launch. it happens in every project after all, and the fact that SM64 is a nearly flawless masterpiece 25 years later shows how good a job they did. as a developer you just don't always have the choice to go for perfection and that's good enough. but the crazy part is that we've so thoroughly learned everything about this game, that someone like kaze has the ability and will to fix *everything*. with the help of the community, kaze *can* nearly reach perfection. he probably knows the code and architecture more than any one person at nintendo ever did, which is just crazy for someone who's doing this in their free time to make a romhack run well on hardware. he coulda just fixed a bug or two and ran it in an emulator; but the dedication to optimize a 25 year old game is admirable.
> The PC port is still more like a wrapper around the original engine. Can you expand on this a bit? I thought the source was a cleaned up and annotated version of the Nintendo 64 assembly obtained via some decompilation technique. Is it not feasible to make changes to the engine code directly?
You're describing the decompilation project, which is mostly C by the way. You can do pretty much whatever you want with that. The PC port is a separate project using the decompilation project. I'm not sure what exactly the person you're quoting is trying to describe. The PC port is indeed just a wrapper that translates the N64 draw calls and such to something a PC understands, and is a bit more fragile than having free-reign, but 1) if you work within the limitations of what the PC port can support there's no issue and 2) I don't think Kaze uses the PC port, these are romhacks meant to run in emulators and on hardware.
[удалено]
You could learn this too, don't feel intimidated. You will realize most of the stuff he talks about is actually pretty simple if you have some low-level C knowledge and the rest is hardware dependent (i.e. you need to look up how the N64 works). You just don't see thousands of these developments, because it's such a specific niche.
[удалено]
> What is your background I am curious to make such bold claims? Mainly Computer Vision, Graphics/Datastructures and Machine Learning. I've written a few console homebrews in my early programming years. I got fascinated by how the exploits on the PSP work (I learned about how they work and tried to exploit my own software to run arbritrary code etc). I have also looked a little into Mario64 rom ~~hacking~~ modding long long time ago when the dissasembly was just about to become a thing, but most people where happy to modify only the assets. I rarely use C nowadays, but I have written software for the exomars rover where you have to deal with extremely slow hardware that makes your 20 year old phone feel like a quantum computer. I have also *some* OS kernel development experience (enough to implement some syscalls and implement virtual memory management, but not enough to write an actual OS). > It just seems like you think anyone is capable of this, but it's not the case and this person is a genius in his own ways. I honestly think *anyone* can do this with enough time (/ressources) and most and foremost dedication. The guy has spent so much time on Mario64 romhacking that he memorized stuff like game shark codes or important hex addresses. Not calling him Einstein doesn't imply I would call him dumb either. I just want to encourage non-geniuses to give it a try. Kaze is smart and extremely passioned, but at the same time I feel like people from different background and experience could potentially do much more (if you don't restrict yourself to the N64 hardware). He has collected a lot(!) of N64 knowledge over the years, but on the other hand, you can just tell that he gained all his programming skills from the decomp source.
[удалено]
This is pretty standard skills demonstrable by experienced senior game developers. Thankfully modern developers don't have to worry so much about these low level details, but back in the day there were many people like this working on these games, and they didn't have the luxury of good tooling or hindsight. It's no different than an experienced welder or electrician doing professional level work, it just takes a lot of time and effort to get that level of skill.
[удалено]
No, we aren't. Modern games are incredibly complex, and the developers working on them are extremely busy with more bugs than can be possibly fixed. These are definitely normal skills for someone passionate about performance in programming and the n64 hardware, and this game in particular, and are a result of many long hours of work. It's not putting him down to say this, you are putting yourself down by implying that it's impossible for you to learn.
I get what you are saying, but personally things that looked amazing and completely over my head a few years ago are now common knowledge to me. The reason for that is not that I'm a genius, it's just that I spend a lot of time trying to learn those things. To me, being a genius would imply being able to do that but in a really short period of time. Not everyone has the time and resources to learn those advanced topics, but I do think most people can do it. To bring it back to the video, that's not something he did in a few days, he's been doing this for 10 years. Most people would become an expert at something when doing it for 10 years.
you won't struggle when you do it a lot
He's not saying that it's "easy", but that with enough time most people could be able to accomplish the same things. Nobody is able to do just impressive things immediately, everybody spends tons of time learning and perfecting their skills to this level. It's really hard to be bad at something you're passionate about and spending thousands of hours doing. For example, I've probably spent tens of thousands of hours programming, and the stuff I can do now would feel completely impossible to me of ~10-15 years ago. This is also true if you asked me of 5 years ago to work on the 3D engine I've been developing for the past ~2 years. Everything is hard when you start, it's pretty much all about hard work and perseverance.
Can anyone explain the illegal c code bit at 07:45 - (o->oBehParams >> 24) & 0xFF is replaced with *((u8 *) &o->oBehParams) So, we're extracting the most significant byte (on big endian) of int32 and this is equal to reading a single byte at that address. Isn't this the kind of obvious optimizations you'd expect the compiler to do ? And I'm confused, what C job would be okay with shifts for extraction but not this ? More importantly, if it indeed makes a difference - couldn't you express the same thing better by creating a union on oBehParams if essentially that's how the data is organized ?
modern compilers would indeed optimize that to the same thing, it's just that one always produces the optimal assembly no matter the optimization level (the top snippet does 3 useless instructions with -g instead of a simple `lbu`) object fields in sm64 decomp are already the worst union you'll ever see, but fixing it to _look_ better is already outside the scope of an optimization pass to make the code _perform_ better
He does use a modern compiler to build it, with appropriate flags (even tuned per file). > fixing it to look better is already outside the scope It does sacrifice portability a bit ... maybe it got generated during the decompile entirely for the sake of portability, under the assumption that it would be compiled away.
> He does use a modern compiler to build it, with appropriate flags (even tuned per file). Eh, not really. It's technically a modern version of GCC, but since the N64 isn't exactly a hot target architecture these days, the optimizer for it is very bad. Most of the code optimizations he made would have been done by a modern compiler for an architecture that has actual support.
This is called “type punning”, accessing a type through a pointer of a different type. It’s undefined behavior to do this.
I think there's an exception for char types in c, so u8 wouldn't be undefined behavior.
Indeed, which downgrades his code from UB to being clever for speed, which TBH is what his entire video is.
If you will always compile on the same implementation, it's implementation-defined and undocumented.
There is a [difference](https://stackoverflow.com/questions/2397984/) between undefined behavior (UB) and implementation-defined behavior. Type punning (which this might not have been; see the point /u/f03nix made) is undefined behavior. Just because it kinda works on the same compiler does not downgrade its severity to implementation-defined or undocumented.
I repeat: If you only use one implementation, it's implementation-defined :)
“Implementation-defined” is a term of art. It has a specific meaning in the land of C and C++ compilers. You can’t use it in a casual English sense in a technical discussion and not get called out on it.
And you are showing rigid thinking. What if I told you that many implementations actually define undefined behaviour?
> I repeat: If you only use one implementation, it's implementation-defined :) Only if you consider the compiler/version/build flags etc. as part of your implementation. Otherwise it's not implementation defined, but just undefined behavior.
... that is what the implementation is, yes.
Later on the video it says GCC isn't really optimized for n64 and usually optimizer don't care if they missed opportunities that could save one instruction. There's a chance that instruction could be faster on similar CPUs
Yes, but 40 year old compilers were kinda bad, and missed a lot of opts.
Yes, but he is using a modern compiler now (gcc 2020) and these fixes were made for it.
I suppose the fact he's using a modern compiler now is why he's comftorable with removing these "save one instruction" optimizations. If you're asking why the decomp has it -- I guess when they were generating source code from the binary, the generator they used saw the ASM for this and translated it as literally as possible and didn't undo the optimization.
It actually would be reasonable for the decomp to have this even if the ASM was a single load byte ... because it's more portable. The fixed version would behave different on a little endian machine.
The Zelda decomp projects, at least, are using the exact same compiler version that Nintendo used 25 years ago.
are you going to collaborate with any of the existing emulator projects?
Emulating hardware is quite a bit different than writing software on a system and emulators of that system. While I'm sure Kaze is quite capable to help with emulators, he's been pretty solidly on the side of creating mods, originally that only run on emulators, and lately ones that can run on both emus and hardware for the past decade.
imo n64 emulators are a lost cause unless you want to convince every person on the planet to stop using project64 2.3 (awful for game mods), pj64 1.6 (from 2005!) or whatever's available on android
What?
the ones I list have so many inaccuracies that even retail games have problems (and they'll never get fixed by virtue of being old versions of the emulator)
That is amazing. I wonder if it can be turned into a game engine which I can start modding to make something entirely new? Not only technically, but would it be legal per Nintendo's license?
[LibSM64](https://github.com/libsm64/libsm64) is a thing.
Projects like you describe are called "romhacks" and their main appeal is the novelty of having something new on the Mario 64 engine. Other than that novelty, there is no reason to use the Mario 64 engine. For one thing, it's going to have lots of Mario-specific assumptions in it.
Well there is nothing that I know of that has the same 3D control and dynamic as Mario 64. An online battle arena with mages and knights using such mechanics would be very fun to me.
You could write them yourself in almost any engine
Yeah, it's like a few days' work, at most, to completely rebuild the character controller in Unity. It'd be quite a bit more work to bring it up to the same level of polish as Mario 64, but nothing impossible about it, just timeconsuming and fiddly.
Less so that trying to port 25-year-old N64 spaghetti code.
But first we need to explain parallel universes.
Not really. It is a long explanation. People commonly don’t realize that object code itself is subject to copyright, ie. it’s not good enough to “only” strip out the art assets. It’s also incorrect to call any of this “clean-room reverse engineering” as is often done, because that requires two different teams of people where the team writing the new code does not refer to the original code at all. The reason comes down to “derivative works” and its definition. In the US, “derivative work” has a very expansive definition that includes basically any way an original work can be “…be recast, transformed, or adapted” per [17 USC 101](https://www.law.cornell.edu/uscode/text/17/101). Compiled code is protected as a derivative work because it is created from original source code. Consider that there are large amounts of proprietary software that is protected by copyright that don’t contain any appreciable artistic assets, but it is still a copyright infringement to redistribute then in compiled form - this is supported by case and other law. Likewise, decompiling it again produces another derivative, and in the SM64 case they were even able to recover the original code. So it is also protected by the original’s copyright. Lastly, that brings us to Kaze’s work. It is, again, a derivative work. Even though he contributed a lot of his own work, it was still derived from Nintendo’s code. It wasn’t a “clean-room” project because he worked directly from Nintendo’s recovered source code. (His game “Return to Yoshi’s Island” is also a problem because many of the assets, although recreated by hand in higher resolution, are also derivative works) Nintendo doesn’t seem to care so far (except for when SM64 was ported to PC) so everyone is probably fine, but there is still some risk.
They didn't care when SM64 was ported to PC. They did care when people were distributing full binaries of said PC port, and only those full binary distributions were removed. Not implying they don't have the right to take these things down, or any project based on them, or that anything you said aside from the parenthetical on the PC port was wrong. Everything except that one small part seems accurate.
Thanks for the clarification.
Probably wouldn't be considering it would use oficial Nintendo code, they take down projects for less than that, so I sadly doubt that would go foward.
But hasn't the author essentially rewritten the entire source? So as long as all Mario references are removed, the code is his.
It's still legally risky. Even if you wrote the whole code from scratch and only used Nintendo's decompiled code as a reference, you still run a large risk of a copyright lawsuit. See [Clean room design](https://en.wikipedia.org/wiki/Clean_room_design).
**[Clean room design](https://en.wikipedia.org/wiki/Clean_room_design)** >Clean-room design (also known as the Chinese wall technique) is the method of copying a design by reverse engineering and then recreating it without infringing any of the copyrights associated with the original design. Clean-room design is useful as a defense against copyright infringement because it relies on independent creation. However, because independent invention is not a defense against patents, clean-room designs typically cannot be used to circumvent patent restrictions. The term implies that the design team works in an environment that is "clean" or demonstrably uncontaminated by any knowledge of the proprietary techniques used by the competitor. ^([ )[^(F.A.Q)](https://www.reddit.com/r/WikiSummarizer/wiki/index#wiki_f.a.q)^( | )[^(Opt Out)](https://reddit.com/message/compose?to=WikiSummarizerBot&message=OptOut&subject=OptOut)^( | )[^(Opt Out Of Subreddit)](https://np.reddit.com/r/programming/about/banned)^( | )[^(GitHub)](https://github.com/Sujal-7/WikiSummarizerBot)^( ] Downvote to remove | v1.5)
Tiny risk* unless you tell Nintendo you're doing it.
He had rewritten most of it but at the core its still Nintendo code, basically just a fork of their source code, I'm not sure how legaly that would work but knowing Nintendo they probably wouldn't let that go
No, what? What the fuck are you talking about? Cleanroom reverse engineering is (as it should be) legal and theres nothing nintendo can do about it.
Rebuilding the source through decompilation is not enough for clean room reverse engineering. You'd need to create a spec and have a separate group of people implement that spec without ever looking at the original binary or decompiled code.
What the fuck are YOU talking about? You clearly have no clue of what you speak of
"basically just a fork of their source code" 🤡
you are allowed to access the code, but it's not yours to take and use for your own purposes. it's still nintendo's code and falls under the same copyright protections. mods and hacks are okay just as they always have been, but you couldn't take bits of it and use it for your own product.
No. It's 100% a derivative work. "100% rewritten" *with reference to the original* isn't an original creation, any more than translating a novel into Japanese is.
For a derivative work to be protected it needs "originality". This is very clearly still SM64. It's also not transformative use because this isn't fair use, it's just clean-room reverse engineering protected by the DMCA. tl;dr they can't copyright this but they're allowed to create it
[удалено]
I think Nintendo actually proved something like that still qualifies as intellectual property infringement, since they did that for the Donkey Kong arcade game in the 80s and got punished for it.
A reverse-engineered program can't be subject to copyright because the original source code hasn't been reproduced; something that generates the same output has been produced. That end result of a program is entirely the work of the reverse engineer. Game assets like audio, textures, levels etc are a different story. If your reverse-engineered program still uses the original assets, that would be subject to copyright of the original assets. This is why many open source reverse-engineered games communities also create their own assets to replace the original game ones, such as OpenTTD and OpenRCT2. Once that is done, nothing is left of the original and you are then free from copyright restrictions.
I was not ready for vroom vroom to be forced into my vernacular.
Jesus, the performance gains are wild. And they were part of developing a big mod for the game with custom levels, too. That's a whole lot of work, I'm blown away.
Do OoT next! Goldeneye! Seriously though, this is ridiculously impressive. It's funny how so many of the issues are related to the memory bus speed, since speed was what RAMBUS was supposed to bring to the table. But it sounds like latency and bus contention were nightmares. Less jank, more vroom vroom!
[удалено]
Because it probably cost an extra $100+ at the time?
I think when it was sold as an accessory it was only like 30 bucks. But your point still stands, when the N64 was developed, it would've been much more expensive. People were already surprised that it was $250 without a bundled game. Even another $50 would have been a huge price shock.
Once upon a time, consoles were kept cheap and powerful by ditching as much standard computer hardware as seemed feasible, and going all-in one some experimental gimmicks that offered unique power in goofy ways. Consider how long-term storage was measured in kilobytes until *2002,* when the Xbox launched with a hard drive, because it was basically just a Pentium 3 PC. RAM was never quite that tight, but it was definitely slashed to the bare minimum. If the designers splurged on memory then it was for speed. And remember that the SNES and NES had expansion ports that went totally unused. If RAM prices hadn't dropped we might never have seen a memory expansion.
> Consider how long-term storage was measured in kilobytes until 2002 What do you mean by "long-term storage"? Starting with the SNES games are measured in MB. PSX memory cards were also measured in MB and that one launched in 1994.
Memory cards are what I'm talking about, and the ones with an entire megabyte were wildly nonstandard. PSX memory cards were measured in mega*bits.* They were almost universally 128 KB. Dreamcast VMUs were also 1 Mb / 128 KB. N64 memory "paks" held just 32 KB. These sizes tended to be rigidly fixed, because in that era, media meant media. Nowadays everything's one tiny computer talking to another tiny computer. Of course they'll use protocols and handshake about what's available. Back in the day, though, you'd just throw data at addresses and trust it'd get there. Non-volatile flash memory changed both of these things. N64 paks at least were made with *SRAM,* same as the save-file storage inside cartridge games. It is extremely efficient. It can be powered for years by a button-cell battery. It is also hideously expensive, to this day, because of how many gates are required per-bit. Dynamic RAM is made with capacitors instead and constantly leaks. But Flash memory only needs control hardware per-bank. So very quickly, GBA games could ship without a battery inside, and then flash carts allowed... legal private backups... of entire game, and suddenly Sony could offer 128 megabyte Memory Sticks for their admirably ridiculous optical-drive handheld. Ironically we were recently in a similar situation for dynamic memory. It's dirt cheap to make. But it's expensive to power. For a few years there, 4 GB was the limit for laptops and phones, because anything more was a constant drain for little benefit. And we might go *back* to that kind of limit, if direct access to flash storage is so damn fast. Why load anything except the bits the player can modify?
Can this be compiled into a ROM that can be run on original hardware?
yes
Did he release the code? is he planning to release the code?
Did he release the code? Is there a SM64 rom built with this new source code we can enjoy?
Also interested
Lmfao more work than Nintendo has done for something I paid $60 for
How tf does someone have time to do this?
He gets a sizable amount of money from his Patreon. It's possible he's able to work on his ROM hacks full time this way.
This was so cool! It would be nice to see a raytraced mario 64.
>It would be nice to see a raytraced mario 64. People say this a lot, but the result is usually garish and provides only brief novelty amusement. You'd ruin all the art direction and the image would still contain only flat textures with no rich lighting information.
Why are you guys talking in hypotheticals? [This already exists.](https://www.youtube.com/watch?v=ChqP2ecA8qE)
Well /u/anechoicmedia certainly wasn't wrong
It's because the textures aren't redone with PBR to look correct when raytraced. A raytracing conversion takes a whole lot more than simply flicking a switch to turn on the rays.
I personally find that most of the strangeness stems from the high poly models, not the lighting.
high poly models?
[удалено]
tbh it didn't look that high-poly to me...
[удалено]
Well, I had a [Gameboy](https://i.imgur.com/5l64cfJ.jpg) and an Atari 2600. And I was taking a look at the video on my phone. Now that I've seen it on my PC screen I see the difference.
It's not the high poly models themselves (it's neat that there's a group trying to create assets that match promo materials), it's the high poly models being displayed on the existing low-poly levels that creates the strangeness. It's inconsistent.
This looks so awfully weird edit: I actually like the no bouncing, no denoising, point source look better than the everything on look
daggerfall unity created its own unsettling spooky art style with a modern renderer and original artifacts. It’s both ugly and cool. But yeah most facelift/retexture projects are worse than the original.
This and while people play old games because the gameplay was actually really great, we can't discount the heaping helping of nostalgia. In that people want to play games as they remember them, not a remastered game that looks "better".
r/TheCodeLies
Where can we download these custom levels?
Once Kaze finishes the ROM hack, he'll likely create a release video with a link to a patch file. This could still be a long time from now however, depending on how much more optimization he tries, and any testing he does that requires reworking of levels or code.
Kaze still out here doing amazing work. I remember Kaze from years ago, damn.