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
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)
@@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
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.
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.
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.
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.
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’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.
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.
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.
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.
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.
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!
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.
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!
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.
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.
Haven't you ever fantasised about having a time machine, going back to japan in 1995 and optimize 100% Super Mario 64 code at Nintendo, watching their faces melt by your skills?
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
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.
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.
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 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
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!!
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.
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.
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 this make me really appreciate the challenge of commercial software production, just thinking about how far ahead you would have had to think to implement things like this makes it kind of obvious why they didn't everyone just had to deliver their part on time and it will never all be perfect or exactly coordinated.
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.
I love programmers who go back to really push the limits of these machines. These videos you've made and the programmer who made his own R-Type (turbografx) modifications to get R-Type running on SuperGrafx are so cool.
Your optimizations are insane. I dream of one day visiting someone with an OG N64 and mario 64, just to show them an overhauled 60fps/30fps splitscreen M64 and your full rom hack running on their console. Your work is seriously impressive.
@@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
Learning about technical quirks of the N64 like the slow-ass RAMBUS really hammers home why it was hard to develop games for and why so many games had low framerates. You must be a really skilled programmer to do this, Kaze.
This is much more fascinating and interesting than expected! All this work is also something that the devs never could do themselves, since you're working with their finished product, but the devs were, well, developing the game, so they couldn't know which plans would change and what features might go unused.
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.
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!
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.
I know the tinkering done to the code directly goes back into expanding the game further via improved visuals and all, but I honestly really like just hearing, or reading, about people putting in the work, cleaning up and optimizing what's already there. Prefer that over things like new features, bigger worlds etc. It takes a lot of learning, patience and care, and I have nothing but respect for that.
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
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.
Sorry for my ignorance but has anyone ever before tried to reverse engineer N64 games before (for optimization purposes)? This is so cool. This is so amazing to watch. Danke for your work!
i dont unironically nice post very often but i dig what youre doing a lot, its fascinating to see just how much you can wring out of n64 hardware when everything is optimized.
I love your videos so much. I'm also into 'retroversing', but in a different way, for different platforms (long story). If you had a subscription service that went into detail about everything you are doing, I'd sub in a heartbeat.
100 points to whoever can tell me what this technique is actually called because I'm pretty sure I'm not the first to invent this.
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.
its called blockingcache obviously
Holt Kazed
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!
He can vroom vroom more now
For that true authentic feel, you could give him a patent infringement notice for not filling said mug with Rambus-licensed liquids.
it's sad he doesn't watch kaze because he could learn a lot about what it takes to make a mario
That's both adorable and funny. Glad to hear your father likes the gift.
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
Yeah he addresses this at the end of the video
wall code rework would remove the glitchy wallkick, but its for the better because it makes wall kicks.... less glitchy.
Or better yet... a Coop version of SM64 with no fps drops on real hardware.
i will pay 1 birrion kekistan dollerinos for this unfucked build any time
As mentioned, some optimization changes will affect the current status of the game play mechanics
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
Gameboy Port when
@@MarioKartSuperCircuit Game & watch port soon
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)
@@z00t91 rambus go super vroom vroom
@@brianchan8 They are the Rambus go Vroom Vroom!
console-compatible hacks are going to be crazy after this source code release. very impressive work as always!
I think this moreso opens the doors for better running hacks that try more with the engine
@@shanerpressley did u just try to partially disagree to paraphrase the dudes comment? lol
@@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
@@Blernster he's talking about console compatible hacks, I'm talking about emulator only
@@Blernster even an emulated console will lag if too much is going on. These optimizations apply to emulated consoles just as much.
as little as I understand coding, I love hearing about optimization like this. it’s like watching someone solve a puzzle never meant to be solved!
Low-level programmers (Not Assembly, well they are too) are the backbones of our society.
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.
What does OoT do with Hyrule Field?
Are you saying that if Kaze isolated just the audio subsystem improvements, it would be able to be ported to other N64 games like OoT and MM?
@@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.
@@darkychao What the fuck. Is that genuinely true?!
The original running at 60 fps on an actual N64 is going to feel weirdly awesome.
And surprisingly far closer than any mainstream Pokémon game running at 60 fps.
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.
As far as i know they are talking about microcode for the GPU.
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!
Reminds me of þe demoscene for old computers
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.
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.
at some point i think this is just technically magic
Thanks for all you do in VR Chat. Some of the best content on UA-cam
I'm sure he's gone way past that by now.
I'm an expert in things I don't know and that's definitely magic.
No. You are pretty much correct. The technical term of code that uses heavy abstraction is Magic. Its literally on wikipedia atleast.
@@waterpickervery true. Whenever the source of this hack is released the README is just gonna say "Black magic, do not touch"
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.
I'm pretty sure he DID replace them with 3d models
He wasn't the one that made the coin model.
@@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.
It's great that the N64 CRT footage said "60 FPS" but the video itself was 30fps. =P
Awesome work, dude! =)
lmao phone camera moment
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
Seems vaguely disrespectful but I guess some may be amused.
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?
Probably
Obviously
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.
@@KazeN64 They don't mean, 'put it in the base game', they're asking whether or not a from hack could be built directly off of your code
@@mirabilis wdym?
I truly hope this doesn't get you DMCA'd, this is amazing work and dedication to this community. Thank you.
They'll DMCA it and then release Super Mario 64 HD.
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...
@@Wheelz_
Nintendo _sees_ property.
Neuron activation.
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.
@@dennisanderson8663 Yep. Patching to save our poor little rom hacker souls from the evil Nintendo!
Doing God's work 🙏
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.
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.
0:37 Kaze acknowledged the existence of MattKC
Also, now I know how you got CD quality music into SM64
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.
After seeing all the shit you did after the last video, I had no idea there was any significant headroom left!
neither did i, until wiseguy mentioned cache mappings lmao
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!
There’s a lot on these technical videos that I don’t understand but simply knowing how much went into doing all of this is incredible.
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.
Kaze, I don't see a "remastering Mario 64's code" playlist on your channel. I'd very much like to watch such a thing.
I am absolutely addicted to these optimization update videos of yours
What impresses me most is that Kaze is not only a great programmer, but also an incredible artist!
And game designer!
Not saying Kaze isn't a good artist, but I'm pretty sure his wife, TheLegendOfZeina, does most of the art for his hacks, now.
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!
This is a Great Revolution to evolve N64 Emulators and Real Hardware.
It's amazing how much you can optimize something with several years worth of experience, documentation and a known scope to a project.
Your videos are pure gold, very impressed in all the engineering that you have given to this project
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.
@@adamadequate4596 so they didn't record or mix any audio files?
@@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.
@@adamadequate4596 uh huh. okay
It's like watching a black and white movie on a modern TV. The ability to do color is there, just not being used.
Absolutely blown away by your amazing knowledge of your hardware. Keep up the great work. Keep the videos coming (please) :)
It is mindblowing to be able to see 60fps Mario 64 running on real hardware... amazing work Kaze!
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.
Haven't you ever fantasised about having a time machine, going back to japan in 1995 and optimize 100% Super Mario 64 code at Nintendo, watching their faces melt by your skills?
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
Kaze after spending 3 weeks optimizing one single line of code in Mario 64 (it increased performance on real hardware by 0.001 FPS)
This is actually legendary. To fix the game code to run better than programmers in 90s ever could, given the limitations.
5:32 it would be cool to explain in depth what are those headphone modes some N64 games have that no one ever explained what is the difference
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.
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.
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 should find a project to do that. It must be kind of relaxing.
@@plume642 It can be. It can also be infuriating.
oh my gosh I love that you gave the chainchomp animated eyes and he looks so cute when he squints when he attacks you.
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
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!!
I can't wait for this hack to come out. How done is it?
60%
@@KazeN64 If this is 60% i am really hyped about what the 100% are going to be! You are yo creative and talented!
Fr Koopa Karnival looks awesome
I...have barely any idea what you're talking about at first, but the way you visualize and explain helps in understanding. You're a mad genius Kaze!
At this point I’m convinced this man could get warzone running on a Nintendo wii on ultra
Happy to support this amazing, creative and developer guy! Greeting from El Salvador
2:50 if it's not 562 MB/s what is it actually? Just out of curiosity.
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.
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.
So you did manage to make it understandable for everyone. Impressive!
This is exactly the kind of content I want to see on my sub feed. You're a god among men Kaze.
Now I'm wondering if it might be a good idea to write a n64 compiler backend that takes more of this stuff into account.
What have you brought upon this cursed land
None of this is a particularly good idea. Really cool but very unnecessary and unpractical
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.
I don't have words to tell how much I enjoy what you are doing.
Someone, get this man a Sillicon Graphics MIPS workstation and let him loose on it. We'd have some really good new games for the computers.
I wonder if there's an emulator for that...
@@raz0rblade06 MAME, although having the physical hardware would allow for more thorough testing and the ability to test multiple configurations.
I love the funny images passing by when you just keep talking about what you have done optimising code, keep at it!
and as always, kaze doing incredible things... hey, so far which of all the courses is your favorite?
So impressive. I suck at coding so you being able to understand all these functions and how they relate with each other is just wild.
TLDR - Confident that full 60fps in SM64 will eventually happen!
I wonder if there will be a new "speedrunning" trend where programmers optimize old games for maximum fps
You're the first person I found that acknowledges the headphone mode! Always wondered what it did exactly
I wonder what lower-spec devices could play SM64 with all these optimizations, which couldn't before
Lots of these changes are very N64 specific
All this make me really appreciate the challenge of commercial software production, just thinking about how far ahead you would have had to think to implement things like this makes it kind of obvious why they didn't everyone just had to deliver their part on time and it will never all be perfect or exactly coordinated.
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.
@@KazeN64 that reply was immediate!
Your work is so appreciated!!
I love programmers who go back to really push the limits of these machines. These videos you've made and the programmer who made his own R-Type (turbografx) modifications to get R-Type running on SuperGrafx are so cool.
Dude, this man is jesus, he IS the N64 Code at that point XD
Your optimizations are insane. I dream of one day visiting someone with an OG N64 and mario 64, just to show them an overhauled 60fps/30fps splitscreen M64 and your full rom hack running on their console.
Your work is seriously impressive.
this man's doing more for gaming than EA or ubisoft have done in the past 2 decades.
Hey now, they've done _lots_ for gaming. Just not in a good way.
They did invent the rabbids though
That doesn't make sense. Comparing some coder optimizing one old game vs two game publishers!?
@@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
I would love to see you livestream your process of making this. It's extremely interesting.
eventually we'll able to get Mario 64 running in 480i on real N64 hardware and it'll still run better than the original code did in 240p.
dont forget anamorphic widescreen :P
Learning about technical quirks of the N64 like the slow-ass RAMBUS really hammers home why it was hard to develop games for and why so many games had low framerates. You must be a really skilled programmer to do this, Kaze.
Kaze delivers he's not wasting anyone's time. Patrons, support this man
This is much more fascinating and interesting than expected! All this work is also something that the devs never could do themselves, since you're working with their finished product, but the devs were, well, developing the game, so they couldn't know which plans would change and what features might go unused.
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.
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!
35/10, VROOOM CERTIFIED
Ich habe nichts verstanden, aber deine Videos faszinieren mich, sodass ich bisher jedes gesehen habe! Großartige Arbeit, mach weiter!
kaze be like: today I will rewrite 30 year old code.
I'm just trying to imagine anyone who worked on this game or any other n64 games looking at this and being really impressed.
i grew up with the n64, please never stop optimizing, i wanna replay most of the games at one point
Kaze you are unstoppable holy crap. Every time I turn around you've done something really cool for SM64
Optimize by removing all the audio code.
You don't need music!
Thank you so much for everything you've done for the sm64 community Kaze! And for keeping my favorite game of all time alive. You are a legend bro
Imagine loving a game so much you rewrite the entire source code better than the programmers could ever.
Love that your voiceover audio also got an upgrade this video
My god... does this mean that MIDI may one day be inserted without having to learn SEQ64? Or am I aiming too high? 🤣
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.
@@TheBester7 ...I had no idea you could do it that way, wow! Thank you very much, I'll look into it 👍
@@RiposteBK but the midi either doesnt loop or use the wrong sounds from the same soundfont (depends on the program you use)
I know the tinkering done to the code directly goes back into expanding the game further via improved visuals and all, but I honestly really like just hearing, or reading, about people putting in the work, cleaning up and optimizing what's already there. Prefer that over things like new features, bigger worlds etc.
It takes a lot of learning, patience and care, and I have nothing but respect for that.
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.
This is satire right
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
1. That's connected to a Nintendo 64.
2. This was only a couple times, it shouldn't bother you.
3. He also showed PC footage, now quit whining.
@@CeIIHunter No, if you were a true Kaze fan you would know that his rom hack is on the PC Port.
@@Arthurtilly you never know these days man
I love you man. I know it's not a lot but knowing my dollar a month helps you do all this amazing stuff it's so worth it. Keep up the great work Kaze!
I just cannot believe how extremely talented you are! Absolutely insane in a good way!
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.
Sorry for my ignorance but has anyone ever before tried to reverse engineer N64 games before (for optimization purposes)? This is so cool.
This is so amazing to watch. Danke for your work!
I know absolutely nothing about programming but I love these videos.
i dont unironically nice post very often but i dig what youre doing a lot, its fascinating to see just how much you can wring out of n64 hardware when everything is optimized.
Dude, you're a freaking 1-Man Army!! Love your craft
My god whats next? How i optimized the n64 hardware? Like always a crazy job man and a big thumbs up!!!
We're getting the lawsuit papers with this one 🗣🗣🗣🔥🔥🔥🔥🔥
I love your videos so much. I'm also into 'retroversing', but in a different way, for different platforms (long story). If you had a subscription service that went into detail about everything you are doing, I'd sub in a heartbeat.