Why is it all the big dick programmers are doing their best work on ancient hardware? More of a challenge? It used to be 8 bit, at least they are now doing it on 32-64 systems. I do wonder if this 'cache blocking' technique is worth applying to modern systems though... In principle I don't see why it wouldn't be, not having to got from L1 to L2, or L2 to L3, and especially L3 to RAM is always a huge boost.
It's a data locality optimization, a lot of games especially bigger AAA titles that use streaming also need to heavily optimize to avoid cache misses, which you do by putting stuff so that they can be fetched in 16 KB blocks (on x86_64, on arm you can go as high as 64k blocks).
@@abowden556 You can be rest assured that engine developers of any of the big game studios, heck even many Indies, do constantly think about hitting the cache as much as possible. Otherwise games wouldn't look and run as well today as they are. It's likely that it's not as "hard core" as Kaze is doing it, but that varies from studio to studio. Also on modern systems the caches aren't the only bottleneck.
My Dad liked his Father's Day present, the cobalt blue Rambus mug. He doesn't watch your videos or anything but he is a programmer and computer nerd so it fits him. Thank you!
I think seeing a copy of Super Mario 64 with only optimizations like these would be amazing to play. No changes to the game mechanics or anything, keep everything as is on the surface but optimize the crap out of it
@@fnytnqsladcgqlefzcqxlzlcgj9220 I was tryna talk about hacks that may not run on console and are in need of the performance boost to get consistent 30/60 on emulator
The year is 20xx. Kaze has optimized the entire SM64 codebase into a single block of instruction cache and the game now runs at 200fps. Rambus go vroom vroom
The year is 2035, Kaze has ported the Nintendo 64 to x86, you can now run Windows 12 inside a painting in Mario (and use an emulator in it to play Mario inside Mario)
Just FYI, the term you're looking for with "performance lottery" is actually known as "Code Locality" :P GCC actually has a few function attributes you can attach to instruct it to put "hot" functions into a special section to improve the locality and cache friendliness. Excellent work btw
as someone who makes custom music for MM Rando, I've actually used quite a few of the unused functions when creating sequences. it's always amazed me just how much stuff just never got used in _any_ "ASEQ"-based game. this code goes mostly unchanged and contiues to have the same functions in every first party game up to and including Dobusu No Mori (the original Animal Crossing game for N64), and every single one continues to use only the most basic of the music functions. the only thing that any of the games do that even comes close to being an interesting use of the format is how OoT deals with Hyrule Field's music.
@@Bonezones OoT's Hyrule Field is not just one continuous song, it's a bunch of separate sequences and they transition from one to the next procedurally depending on the situation. so, when you're moving around the field it plays adventurous music, when you're standing near the water it plays more calm music, when you're near an enemy it starts playing suspenseful music, and when you defeat the enemy it plays triumphant music.
@@angeldude101 potentially? there were quite a few changes from game to game ending up with 4 distinct "versions", I'm not sure exactly how many of these changes actually get used, or how many of the changes were actually intentional and not a result of breaking stuff by accident.
The Ocarina of Time and Mario 64 decompilation projects are the greatest gift in decades. I recently found that Jak and Daxter has been Decompiled too. "Project Jak". Did you know Naugty Dog developed a custom programming language they called GOAL and 99% of their game code is using it?. They've got a fully playable PC version and are already working on Jak II.
You're doing absolute wizardry with the code. I'm sure at least some of the original programmers on the N64 have been watching - and saying they could have done it if they had more time. Just think what could have been done on these old systems if everyone was as talented and had the time (or budget for a released game) as Kaze.
And don't forget the current knowledge available. Back when they made games for the N64, all programmers had basically small knowledge about this new system and the engines
@@AstorEzequiel any in house developers at Nintendo would definitely have had access to documentation files denoting the features of the architecture and engines, it's not like this was some magic new thing that popped into existence without a designer. Most of it is budget, as in does it play good enough, not is it as good as we can possibly make it.
@@HerbaMachina Point taken! Still, I think there's a vast difference of knowledge between the programmers and the +20 years of knowledge that we have right now. One example of that are the speedrunner community and their exploits! And let's not start talking about the TAS!
Kaze has: * No deadline * No budget limitation * No possibility that the hardware will change in the future and make his clever optimizations not work * No rules about what he can and can't do (eg changing microcode, avoiding potentially unstable things) * 25 years worth of advances in technology * Total control over the entire codebase * Total freedom to change assets/gameplay/etc as needed * Knowledge that the original developers may not have had (about eg hardware bugs) * An extra 4MB of RAM * Practically unlimited ROM * The ability to release patches Not surprising he's able to do things the original developers couldn't.
I wonder if this is the same technique used in Conker’s Bad Fur Day. The dev commentary videos they did, years ago, mentioned that someone had written a way for the audio to run on “a very fast part of the N64 that was very small.” Sounds a lot like the instruction cache.
I know this isn't the point, but you did a damn good job with those coins. I *know* they can't be 3D because they're way too round, but they *look* 3D way more than the coins in the original game ever did.
@@CouchPotator Nope, these are sprites with a bigger resolution. The camera zooms in on one coin during the video and you can barely make out the pixels of the sprite.
I think the original game tried to fit all frames of the coin "flipbook" into a single atlas, making them low res and with few animation frames. Kaze seems to have used a full texture for each frame, allowing to improve on both fronts.
This video style is super entertaining, it explains everything well and without overexplaining, the editing is on point... I could go on. Please keep making these! btw glad you did the funny at 4:00
I don't actually think Nintendo has any right to DMCA the project since he's using a decompilation/reverse engineered source to build off of, and not using any code from Nintendo directly. Of course, I could be completely wrong, but the Pokemon ROMs that have been reverse engineered haven't been taken down so there's that...
I doubt it. He doesn't need to provide a "final" rom. He can just provide a patch that you run on the actual ROM to turn it into the modded version. Don't think there is anything legally Nintendo could do if they did it that way.
I’m astonished by how much you’ve managed to optimize the sound in this game. You make it look easy lol. Btw, if you released the source code, does that mean other rom hackers can use it for their own rom hack?
the source is pretty difficult to put back into the base rom, but theoretically possible. i don't expect anyone to actually port it back. check what i've said at the end of the video.
You Mad Lad! - 2 Months Ago - Completely re-optimizes entire engine 2 months ago *dives deep into the audio libraries* *resurfaces* Completely re-optimizes the entire audio engine, took new things learned, and Completely re-optimizes engine again.
As an awful programmer, just watching these videos while you explain optimization is really interesting. Thank you for your work both in code and in these videos.
The crazy part to me is that the original developers managed to get the game to a point that was release worthy without having to release a day one patch.
Your whole series of videos is extremely inspiring and I wish more programmers would know about it. Especially, the notion that compiler optimizations can and will sometimes work against you is eye-opening: compiler writers often make assumptions about the target architecture that may not represent it accurately, and this is especially true of compilers like GCC or LLVM which target a large number of architectures. I'm sure a lot of programmers will be fast to dismiss those facts, arguing that the N64 architecture is just weird and those kind of problems would be no issue in a modern, sane architecture. That would be a fatal mistake. If anything, RAM access is MORE expensive nowadays (compared to register ops) and, in fact, modern processors are even more exotic, as the fastest implementation for many problems usually involves using extremely specific wide vector ops the compiler may not even know how to emit outside of an intrinsic. At the end of the day, the compiler is not a magic wand.
Ehh, a lot of this wouldn't be an issue due to how much more cache CPUs have now. The MIPS architecture is also rather unique in that unrolled functions, even those tgat fit in the cache, are slower than inline ones. This isn't the case on modern architectures thanks to their out of order nature.
Imagine cutting headphone mode, 0/10 romhack. Honestly though, how you make so many fun hacks while making videos explaining them is a real testament to your work ethic. Big fan!
now i want to hear SM64 with all those unused audio features activated. a side by side comparison video too. obviously i'm not requesting you do this, Kaze. i just think it would be cool.
Sadly that's not how it works. What he means, is they literally aren't used by anything. Not that they got implemented but were disabled. In this case the programmer(s) added a bunch of functionality to the library but the audio engineers that did the sound design never leveraged any of them for anything. It's like giving a plumber a giant toolbox of tools, but they only used the wrench. There's nothing to "hear" because nothing ever used those features to make anything hearable.
@@strider_hiryu850 No. The features describe were for audio generation (like the red coin sound, which he replaced in this video with a file to remove all that generation code) or audio processing. You need to actually use them to create something, they aren't themselves anything audible.
its super neat watching this series--i learned a decent chunk of these concepts in my university courses (ex: cache contention, in-lining, etc), but they felt pretty abstract in how they were taught. seeing a practical demonstration of these concept thru your videos is incredible to watch! i wish u good luck in your journey to 60fps!!
In my last company my colleagues looked at me as if I was a pervert when I told them how much I love refactoring legacy code. Now watching your videos just brings back this nostalgic feelings and memories about how the fuck my senior colleagues could've fucked their code up like this. "It's just historically grown code, you know"
i do >90% of the 3d modelling in this game. biobak helps a fair bit with model updates to make them prettier and my wife contributes textures and concept art for NPCs!
Once again, I'm mesmerised by just seeing the optimised code. Adjusting the source from code redundancies to memory rearrangement to produce this fine-tuned program is nothing short of impressive- well done!
Such great videos! I love romhacks and the homebrews, seeing what you're doing is fascinating. Lots of problem solving and patience obviously goes into your work. Thanks for these vids 👍
You have solved the key n64 issue for those of us spoiled to modern day high refreshrate standards. Sure it isn't 144fps, but going back to n64 even on a crt to me anymore feels unplayable due to 15 to 17 fps.
Thank you so much for giving away the source code and explaining it! I've been learning C for about a year and videos like yours help me get better and better.
the main change is usually panning. basically, any code that says "pan this code by [x] amount to [y] direction" will be modified to exaggerate or reduce the panning intensity depending on developer intention. some games also add phase inversion to some sounds in headphone mode (not sure about n64 titles, but i've heard it in GBA titles) on one of the channels to create a fake "surround" sound.
@@SleepingCocoon what do you exactly mean by "panning?" It seems to be a very specific change, it's some nice content for someone to create a video for
@@sanglish18 panning is how much something is moved left or right in the stereo field. so to move sound to the left, you reduce the volume of the right channel and increase the left, and vice versa. the amount of these changes will be adjusted by whatever the code specifies.
Thanks for answering about the optimisations release at the end, you're doing amazing work! I'm very much looking forward to this hack when it releases. Last Impact was fun but it was a little rough here and there and is definitely a product of its time, but even just the demo of this hack is amazing so I'm highly anticipating it whenever it is ready!
I hope and would love to see this have an effect on other n64 games. There's so many n64 titles I'd like to see be able to run at 60fps. or even a steady 30fps X'D
Wow, this is incredible. I want to make sure I understand; by defining the functions that are being used again within the audio file, it's able to cache all together rather than have to cache a separate file that would cause a reload to potentially occur? That's really fascinating
that 562mb/s is something they came up with by calculating how much the RAM could transfer under ideal conditions, i've been told. in practice you will never be able to write/read that many bytes though. reading from the zbuffer and filling pixel colors for a whole 320x240 RGBA16 screen takes the RDP just over 4ms. that'd put the actual practical speed you could get under ideal conditions within the whole system somewhere around 60MB/s unless there is a faster way to move bytes that i'm not aware of.
@@renakunisaki EA did actually do some good in the 2000s hell, Need for Speed Most Wanted on the 360 still looks great nearly 17 years after it launched, and that's a 360 _launch title_ we're talking about and hell, they singlehandedly made the colors on the 360 not shit because they exposed a software change someone at Microsoft did to the 360's firmware that made black levels go way up
@@TorutheRedFox most wanted 2005 on the 360 is just like the PS2/XBOX version with higher resolution and better lighting though i think BLACK or burnout paradise are much better examples of how good the graphics were in EA games
im really really excited to have more sm64 content useable on the og hardware, and therefor on my raspberry pi emulation box and arcade cabinet. i hope you realise how much mental happiness youve given the world.
Could you explain more how headphone mode is different from stereo? I saw headphone mode as an option as a kid, and I couldn't tell a difference between that and stereo. I've wondered what the difference was for years.
they use different panning tables and headphone mode has a "strongleft/right" concept that subtractively mixes audio from one side. i think it's meant to simulate sound in a 3d environment better.
That's pretty insane that you were able to get so much out of the audio processing time. Impressive as always-- and I find it very cool that you're able to diagnose what the original programmers did with the source code, such as running it through that source-to-source optimization, just based on the decompilation. I'd love to hear a bit more about all those unused features in the audio library. Was it perhaps a library that they ported in from somewhere else, or was there just an audio guy at Nintendo with really big ideas, or maybe they just wanted to have all that extra functionality for just-in-case future-proofing? Very interesting. It seems to me that if there's one part of game engine code that might have survived through many years and into future development libraries, the audio code is a pretty good candidate, so I think the most likely reason for all that extra bloat is that they had written a comprehensive library to use going forward in many other projects into the future, but that's totally a shot in the dark. Thanks for the video!
Actually, yeah it would be. I do compiler development myself, and given that the N64 is an unchanging target, being mindful of these limitations during optimization time would be important in the design of the backend. It's not impossible to do either, but it would likely look a little unorthodox.
All of Kaze's work reminds me about the original Crash Bandicoot's development back for the original PlayStation. The guys at Naughty Dog learned the ins and outs of the PS1 to an incredible degree to make their game a reality, arguably even better than the original developers and programmers.
I remember from an Ars Technica interview, Naughty Dog basically pestered Sony into giving them confidential information about the Playstation hardware because the SDK did such a terrible job at using it.
you can use tools to convert the midi file into an .m64 sentence file (the song format used in sm64). maybe i didn't understand ur comment. if its the case, then im sorry.
It's pretty interesting to hear about the audio programming being this thought out and extensive. It just goes to show how much Nintendo has always been putting their efforts into providing good game audio. Looking back at Mario Odyssey and how a lot of the sound effects were context-sensitive, depending on the background audio, it's pretty cool to hear about them having such a long history with it.
I don't understand why you keep hooking your PC up to a CRT monitor in order to show off your mod footage. Aren't you just ruining the graphical advantages you get from using the PC Port? Seems like an odd choice to me.
I can only assume it's not so let me just say he didn't hook his computer up to a CRT doofus. He's running his rom hack on an actual N64 to show off the performance. Y'all need to listen better
