Did Nintendo really forget to Optimize Super Mario 64 ? | MVG
ฝัง
- เผยแพร่เมื่อ 2 ก.พ. 2020
- A recent discovery from the N64 Super Mario 64 De-Compilation Project appears to show that Super Mario 64 USA release for the Nintendo 64 was not optimized and was released as a debug version. However things are not that cut and dry. In this episode we take a deep dive in to what went on with development of Nintendo 64 games in 1996 and how this theory may not be accurate.
N64 Footage was captured with an UltraHDMI and trdrop was used for framerate analysts. Big thanks to SpawnWaveMedia for the N64 captures.
► Consider supporting me - / modernvintagegamer
Links:
► MattKC Nintendo's big mistake that made Super Mario 64 Super Slow - • Nintendo's big mistake...
► Ghidra Reverse Engineering Tool - ghidra-sre.org/
► N64 Decompiling Guide - www.retroreversing.com/n64-de...
► N64 DevKit Manual - n64devkit.square7.ch/
► Super Mario 64 Decompilation - github.com/n64decomp/sm64
Social Media Links :
► Facebook : / modernvintagegamer
► Twitter : / modernvintageg
► IG: / modernvintagegamer
► BandCamp : modernvintagegamer.bandcamp.com/
► The Real MVP Podcast : player.fm/series/the-real-mvp
#Nintendo #Mario64 #Optimization - เกม
There was a reply on the original video about the -02 thing by Kaze Emanuar, who is a very knowledgeable Mario 64 hacker and modder. According to him, most of the slowdown in Dire Dire Dock is from the submarine's collision being dynamic, instead of static like most every other object in the game, and he even fixes it in his SM64 Multiplayer mod.
I wonder if the submarine collision was just an oversight by the dev team, or if they actually had a reason for it being dynamic.
Perhaps time constraints and cut content?
@@ABVW92 They probably thought it needed to be dynamic since the submarine eventually disappears.
@@Kaleidio I genuinely hadn't even thought about that.
Interesting :p
YOU'RE dynamic
@@scottmjohnson1980 What a hilarious and witty comment. Thank you, Scott Johnson, the artist famous for his promotional art made for Marvel comics, specifically his drawings of Spider-Man that could be found on all sorts of merchandise throughout the 2000s and early 2010s.
So the answer is, they didn't "forget" out of some negligence or incompetence, it was a safety decision. But there is no denial the game runs better with -O2, and not insignificantly! 1 or 2 frame difference is a lot when you are in a
So true so this video turned almost to be just a (f) waste of time,almost.
@@johneymute I wouldn't say it was a waste of time at all, it finally puts to bed any question of Nintendo not optimising sm64
Safety from what?
@@Poever
It was safety against an unplayable mess of a game.
Whilst the game may run better with further optimisation, it may cause unintended stress on the hardware over time, or have other unknown effects on the game itself, that preliminary testing didn't find.
So for safety, they used a less Intrusive optimisation, trading a few frames for a more stable experience.
@@ABVW92 Well, it may just need more cooling, likened to using AVX on recent PC processors. Like when Intel reportedly has a lower frequency, when AVX instructions are being used. Still not noticeably slow like Goldeneye is in spots on a real Nintendo 64.
>"mistakes werent made"
>"werent" missing an apostrophe
A mistake was made!
Mistakes were indeed made after all.
the irony...
This phrase has no mistaeks
Thank you. I am glad I didn't have to be the one to point out both the error and the irony.
Profound!
It's actually kind of funny to see Nintendo intentionally disabled optimizations, as around the same time I was writing completely different software and our team found a compiler bug that forced us to release unoptimized code for a while until Microsoft fixed their bug. I guess it was just a thing to do that year. LOL
My assumption was similar: a codegen issue that only occurred with optimization enabled so they hand-optimized during development, and then not wanting to risk "breaking the build" even after the issue was fixed.
Mistakes WEREN'T made?
My world is shattered. The cake is a lie.
Marco your response is much better than what I had in mind 👍
@@joesshows6793 I appreciate it. Thank you!
But feel free to make your comment anyways! All comments help MVG.
Is it to do with the 60hz/50hz region differences?
@@davkdavk No. Thumbnail.
davkdavk thats what I was thinking but then why would it work in one region and not another?
This topic makes me wonder about other games like Donkey Kong 64 that crashes randomly on the console and requires a expansion pak to work.
From what I remember, it has a memory leak and will eventually crash due to running out of RAM, they made the expansion pak required to increase the amount of time before the crash to 8 hours by basically just give it more RAM to leak to, it didn’t actually need that memory for anything else
The problem with DK64 is a memory leak and it was "fixed" with the expansion pak because more memory meant the leak took more time to crash the console.
I was livid when I found out about that. I was so convinced that the expansion pak was some magical thing that made the n64 more powerful. Damn marketing 😂
@@KuroAno I know that but this was never really well documented on any channel on TH-cam whatsoever, the memory leak problem has never been explained properly here, just the "it's a memory leak lol".
@@ShaunDreclin I mean, technically it did, but not by much. It doubled the RAM from 4mb to 8mb. It just wasn't something that would affect games not designed around it.
You're glossing over a lot of facts and several incorrect statements were made in this video.
1. We did not use Ghidra. We only sometimes used our own custom decompiler (mips_to_c) but most of the work was completely handwritten from static analysis. We were able to do this since the unoptimized code basically read literally out directly to C mannerisms with few exceptions.
2. It's not actually certain O2 "caused" issues. We are only certain of the compiler for US/JP: IDO 5.3 (IRIS Development Option) with -g for the main game code. Why Nintendo either left it in or deliberately used it is unknown but we do have a few hypothesizes, some of them match the accidental side and some of them are the on purpose side. What we do know also is that since the collision routine slowed down by -g causes the major DDD sub lab being an indicator of the flag also means the Spaceworld 1995 build is unoptimized. If that ever leaks out, decompiling that would be easy pickings for us. (Please get out!)
3. Compiling US/JP builds with O2 (as-is, no AVOID_UB) they can complete 0 star and 120 star TASes respectively. Since inputs arent accepted on lag frames, they can pass these since it appears the functionality is identical. Hell, I even tried modern gcc, and they *still pass,* but only if we define AVOID_UB. gcc actually makes a ROM that crashes the n64 if we don't. IDO doesn't seem to care.
4. The mulmul bug was patched way before the N64's release, and I believe before SW95's showcasing. This was patched at the assembler level by SGI which that patch is IDO 5.3 only, made default in 7.1 (released in November 1996 after sm64's release) and gcc got its own version of the fix with gcc 2.8.x (2.7.x builds that had it were available by Cygnus and the N64 SDK.)
It is possible though earlier builds with O2 spooked them into not using it, but it either had to have been before or after sw95 [Spaceworld 1995] (which would mean it was originally -g but they tried O2 to see if they could). There's a bug in the Disk Drive version that crashes Wiggler's room which is caused by an out of bounds read for a float value. This crashes real N64 hardware because that value just so happens to be a denorm on the O2 build (but we arent sure if O2 shifted it into place) but not the original US/JP releases which just so happen to read a valid float and dont crash.
This was miles better than the other video, but I do wish it dived deeper into how we actually figured out it was IDO 5.3.
MVG gotta see this comment.
Hey thanks Revo.
Also hi Pablo c:
I stumbled upon this video and comment by accident and ngl it's like I am reading some ancient alien language.
First off I appreciate your hard work and it is truly fascinating, however this comment sort of makes you come off as a dick. Just as you took the information given and interpreted it he did the same thing. Instead of accusing him of not diving deep.enough or comparing him to that other asshat help him understand and get the correct info out.
so in the end mistakes were made...
For real frame rate slowdowns, see Goldeneye 64 or Perfect Dark multiplayer with grenade launchers. We really, REALLY didn't mind as much back then.
Even more recently with games like Dark Souls. I don't remember seeing a lot of hate for the console framerates until PTDE came out.
I think anything involving explosions can be excused for dropping frames as long as the damage done is appropriately powerful. It gives the grenade launcher a feeling of "ah crap, that is a lot of hurt, give the machine a moment"
You can feel when there's not enough frames, it feels worse.
The multiplayer modes of those games weren't intended to be the most common mode, so it's better to just have it than remove it. Same thing happens in for example, Mario kart Wii, on 3 and 4 player mode, it locks to 30fps instead of 60.
@@intron9 I'm not talking about 30 fps. I'm talking about 1fps. Those explosions just ate the whole system if they filled the screen.
The real question is why was - O2 enabled on the pal version
Released 5 months later in EU.
I think the better question is why they never put out an revision built with -O2 for USA. I mean, they had to print new cartridges at some point; why not toss in an optimized ROM now that you know it doesn't break anything?
Perhaps I'm just unfamiliar with the logistics of cartridge manufacturing.
@@LonelySpaceDetective Sometimes when you fix one bug you end up creating more
Maybe something to do with PAL versions only getting 25 FPS instead of 30 to begin with.
It's pretty strange to get variable framerates on a console actually. Usually at the end of a frame a console game waits for the next frame, so if it takes longer than one frame to process one frame, when it waits for the frame to end it's actually waiting for the next one, and it ends up taking whole 2 frames total, therefore (assuming it started at 30 FPS) getting 20 FPS (3 frames per frame) or 15 (4 frames per frame) instead of 30 (2). IDK how you can get 27 FPS that way.
@@alexc4924 would the drop in frame rate be because it didn’t process the information soon enough? And by information I mean both gameplay variables and graphics rendering.
My biggest question is how does it ensure that the tv still drawls “perfect” images with variable frame rates. My best guess is that it will hold a frame until the next screen reset. But I have yet heard anyone mention that before. Also there the issue, which I think you were trying to get at, of frame buffering stacking. But eh
If ghidra wasn't open source, I'd use ghidra to decompile it and release the source.
Hacking 100
h a c k e r m a n
there wouldnt be any reason to not make it open source. if it wasnt open source, ofc people would decompile it with itself.
@@skrubbed that's what I said
@@deanmoncaster no i was just saying how there would be no point in it not being open source
"the game was criticized for its camera"
aren't they all though?
Not really I really like Sunshine's and oddiseys camera
joão prudencio I think he’s talking about 3D games of the mid to late 90s.
DanROW All 3d games in that era had some type of camera annoyance
I quite like the Mario 64 camera
@@r-ea hahaha just play Tick Tock Clock and you will """love""" the camera even more
Decompilation of Panzer Dragoon Saga for the Sega Saturn would be interesting, considering that the original source code is lost.
This actually amazes me, as Sega generally keeps very good track of it's source code.
@@TheXevNights into Dreams was also lost.
5:01 "As someone who is a C program" Holy shit I knew it.
I've never understood why black people and the British hate the letter R so much
@@bigstar66 [’prəugræmə] r is ə, no hate at all
except he uses pico
@@bigstar66 Nothing to do with hate, just normal language change. Consonants tend to weaken over time, especially at the end of words. What you're noticing are just dialects where the "R" sound has weakened or disappeared more than usual.
James Jensen yes, but they don’t usually this much this quickly. I think the British and African American spurned the letter r for the same reasons - they didn’t want to sound like white Americans.
I think they didn't want to risk releasing the game with potential critical bugs caused by -02 optimization since it was a launch title and it was crucial that it was polished to show off the N64
But if they did it with eu then that's not right
@@Anon.G I think it released maybe a bit later in EU, so they tested more and started to feel comfortable with it.
@@CounterFlow64 Quite a bit later indeed! US, in September 1996 and in Europe, March 1997. So yeah.
@@Anon.G The EU release came out 6 months later.
Is the shindou version-02 optimized?
23 years later:
*_Did Nintendo really forget to Optimize Zelda Link's Awakening for Nintendo Switch?_*
B10K PlaysGames 23 years later:
is people that never worked on an released a AAA title themselves still arrogant to use their spare time to draw quick assumptions without thinking before claiming “I could have done it better”
Haha nice one. Remembering that swamp area in the game.
Actually yes, the homebrew community has already figured that
It seems to be a problem with the engine Grezzo made for loading stuff in, rerouting the game to load files off the SD card significantly speeds up the game
@@akj7 Yeah the swamp had bad frame rate drops!
Minecraft was made in Java and thus was horribly optimized.
That lag while swimming will always be a part of the game for me lol.
Sort of reminds me of FF7's development: basically they toyed with the release candidate for a while until it finally ran from beginning to end, then they were too afraid to make adjustments.
if it ain't broke...
@@TheSwillMan fix it (dont)
Hi from the future FF7 remake is out and it is GLORIOUS
FF7 is held together with duct tape and prayers. :D I am in the FF6 modding scene, and even that game had 180+ separate bugs when the first battle system disassembly was made. Like the fact that evasion is never checked, or that the Genji Glove doesn't reduce your attack stat to 80% like it should. Ah, the things we didn't notice as kids....
Like a jenga tower where you are too afraid to pull that one block because it may fall apart.
Usually in almost all game development cases, accusing companies of not doing something out of "laziness" is almost never correct. There's almost ALWAYS more to the story, and laziness should always be the last resort for deciding why something happened the way it did. Good work!
lazy comment
0/10
And when there isn't a "good" reason, there's usually a "shit we only have three days left it works get on to the next task!" reason.
4 player Perfect Dark with all bots enabled. The ultimate lagfest.
Turn hi-res mode on and put it in 16:9 too for """""""""best""""""""" effect.
Luke Hero can’t believe I use to love playing that
Hahahahah
I love that you dive into great detail, while at the same time can explain complex subjects in a manner which is easy to understand.
I remember seeing SM64 for the first time and it was jaw dropping even for me who is no Nintendo fan.
Yup I remember playing it either in a Best Buy or a blockbuster or something and fighting King Bobomb. I’d only seen it in a commercial to that point and just never wanted to leave the store 😂
@Franky Padilla what??? the nintendo 64 was released in 1996
@Sadist Fake Bootleg Tiki Nice bait wee man, try a bit harder next time though:)
@Sadist Fake Bootleg Tiki so how's middle school going?
Same thing when I first played Zelda BOTW a few years ago, I became a fan boy after that and brought 3DS WiiU Switch Switch Lite to enrich my collection over the years.
One thing to add: the sm64 project was started before ghidra was released, and it wasn't the method used, at the very least for most of the development. The reason they got such accuracy that they could produce a byte-for-byte identical ROM was the compiler test-casing that was done. The exact IDO compiler version that was used was found based on testing a set of specific code until the correct patterns were found, until enough version-specific behavior was found to be sure of the exact compiler used. Once that was known, different ways of representing effectively the same algorithm with slightly different tweaks was used in order to figure out the way the original code was likely written, based on the compiler output. Eventually you can do something like making your own pattern matcher which can output likely C-code that was started with originally. Pretty cool details, imo. In any case, nice video, glad someone covered this topic with the proper measured approach :)
7:14 did nintendo really use comic sans in the development documentation?
Back then, it was a common font to use. It looks a lot more professional on smaller and older monitor screens with low resolution.
@@kadekiger276
You beat me to it by a whole year!
Also, for more context: comic sans was actually _invented_ to be optimally readable on then-modern monitors. It wasn't until we got high definition ones that it looked awkward.
Hey there, thanks for showing my N64 plugin at 1:48 :D
the best Plugin ;)
Cheers WV
*"Mistakes Weren't Made"* hahaha, i love that
aah, quite a different meaning once you've been through the video. great upload 💙 i always learn so much here
@@PaulMeranda *werent, they left out the apostrophe which was a really clever joke.
the short answer is basically, "no, they did not" - it was a different time.
the long answer is everything else in the video. haha
I'm amused that, on my account, your comment is beside mine.
@@MarcoGPUtuber sweet irony. we just need one more commenter to make this a "beetlejuice" xD
@@MinisterSandman lmao. Are there any more Marcos in the 300000 or so MVG subscribers? May the real Marcos please stand up!
@@MarcoGPUtuber i second this statement. Lol!!!
The correct answer is:
"They did not forget but have actually written code so sloppily that it relied on undefined behaviour left and right and the compiler - rightfully - would screw that up"
I love that your channel is both comprehensible to just listen to because you break it down so easily, but also provides screenshots and references to c code if you want to know more.
As always, thank you so much on your work on these videos! You provide a very unique perspective and recorded history of vintage games that can't be seen anywhere else. This was a really interesting video and was well done.
“Piqued my interest” is the proper phrase.
it's not "peaked"? my life is a lie
What an amazing gem. Still have my N64 and a copy of SM64. I think I remember having access to a family PC back then, and early 3D games. Many 3D games were really quite poor in execution compared to SM64.
Man I love modern strongly typed languages! However, a few years ago when we had a client crazy enough to want us to use Swift Beta 1 for their project, we would frequently run into issues where compiler optimization would optimize away entire classes that were being used. So in the early days we had to turn it off.
What time was this? Around the early 90s?
@@ChristopherGray00 I doubt that Swift, a language released 2014 was worked on 20 years prior.
I actually remember liking slowdown in many games... it often coincided with explosions and action and felt epic and was occasionally helpful lol; heck, I’d try to make it happen as much as possible in Goldeneye
It happens in "real" life also, during important events time can slow down
yeah, i actually thought that the slowdowns were intended, like a bullet time mechanic to give you a little wiggle room to operate in case of overwhelming odds
@@Arigal3 It's evidence that we live in a simulation ; )
I immediately thought of Goldeneye too, when explosions were happening, it could slow down to like 1 FPS lol! I had no idea what was happening as a kid.
Having MVG talk about O2 and Makefiles sure is amazing.. Hope we get more videos like that..
Quick Question: Why not compile it with O3?
I compiled with O3. The game crashes at random
gcc -O3 is pretty unreliable as mattkc says
@@surrodox it doesn't really. if you're using latest gcc and on x86 it will work fine %90 of time. Its suprised me that -03 made it crash.
Also it do make sense that nintendo didn't push optimisation to everything since compiler are came a long way too. in early 2000's maybe the compiler wasn't as good as of today.
@@user-ro1cc8tz6dHe needs to compile using Nintendo's compiler that is really old, he's not using gcc
@@user-ro1cc8tz6ddon't the -03 optimisations all have some kind of space/speed tradeoff and thus tend to increase memory usage/size of the resulting binary? If you're already running at redline for memory at points I could see it pushing you over and crashing the system due to running out of memory.
I doubt the developers were leaving much memory on the table for a dedicated device like a games console not designed for multitasking, and rather to run one application at a time.
Today, on a modern multitasking operating system memory is by necessity comparatively more available and that's less of an issue
There may be another reason: I've seen some games written to work reasonably well on NTSC and then put through optimization to run at comparable speed on PAL.
& then you get the opposite, like Rare on Goldeneye & Perfect Dark. Both written & optimised for PAL, & duly running far worse in the NTSC versions
I was thinking the same thing.
Fantastic work and investigation MVG. Was curious to find out more about this after seeing the original video MattKC made. As always, you do not disappoint! Excellent work!
Loved that you used the File Menu music at the end. I used to just leave that playing as background music in my room when I was a kid.
This was really interesting. This is definitely the type of content I'd expect from this channel. Great work.
2:59 The dragon logo for Ghidra is freaking awesome.
Excellent video, love your perspective and commentary on this issue. Long time viewer, now a subscriber
This is the shit that makes my monday worth waking up for
just got off a 12 hr shift on 3.5 hr's of sleep and it was still worth it lol
Wow. Truly dire times we live in.
I'm a bit surprised this flag wasn't added and recompiled in a later release of the game, such as for the Player's Choice version. It looks like it would have been worth revisiting with the newer tools available!
Probably because Nintendo didn’t give a goddamn.
Poo
@@gibraltar4841 ah yes, another man of "culture"
poo is good
@@gibraltar4841 China's president?
As a fellow developer and retro gamer yours has to be one of my favourite channels on TH-cam. Really thorough explanation of the situation as always. Keep up the good work!
This is indeed an interesting little bit of gaming history. Granted, it doesn't change my view of one of my favorite childhood games, it does bring to light some little things I'm slowly learning as I start entering more and more into the programming world. Thanks for taking the time to do this, MVG.
Props for getting Dylan Cuthberg on the show! Man started my most favorite Nintendo franchise (Star Fox)
As far as I know, Ghidra wasn't used for the decomp project at all. It was mostly done by hand.
This is true, the project started way before ghidra was released to the public
Amazing.. these guys are wizards wasting their talent on meaningless things like this. Like saints of the programming world utilising their talents so youtubers can make bank with clickbait videos for a week
Yes, this was my main reaction upon seeing this video. Claiming that Ghidra did most of the work is really selling the decompilation team short -- tools like that are nice in general, but are close to useless if you're aiming for perfect byte-for-byte accuracy. This project was mostly done manually, which no doubt took _tons_ of time and effort.
Victoria Meets World those people did it for fun because they love video games. It’s their passion for their community and also most TH-camr like these guys make very little bucks unlike those who cash in millions, also, how is this clickbait. These you tubers are like those guys who did it, they love gaming and want to help it.
@@pian-0g445 it's click Bait because of U watch the video he rushed or our and didn't do he research and on turn disrespected the talents and the assumptions of those who put in the hard work. He was in a rush to make money while the topic was hot and he substitute d his opinion as facts rather then just going over and looking at the project and ppl that worked on it
This was well written and thoroughly researched. Thank you!
The video quality on 4k is insane bro. Good job with your recording, it's amazing. What camera do you use?
mvg is such a brilliant channel:
interesting and relevant topics,
technical but well explained,
aussie accent
Shane holy shit I’ve never considered the fact that he sounds more Australian than Australians
I am Australian
He has the perfect “radio” or “TV” voice
Emphasis on Aussie accent
@@phr33z10 Bye for now
Squish Mastah ?
He fucking copied the material off others... bald bitch...
When MVG's thumbnail says Mistakes _weren't_ made:
**Confused Screaming**
I love your channel. Great photography, editing and commentary.
I’m pretty sure I remember the release version of Croc: Legend of the Gobbos was without C compiler optimisation. I don’t think there was anything intentional about this, but as mentioned, a lot of code back then was hand optimised in assembler, so the gains to be had with C optimisation is less drastic. And I certainly remember bugs being introduced by optimisation back at that time period. Tools are much more stable now... :)
Not the PC version, for sure (I worked on that); and I'd be very surprised on the PS version too
@@MattGodbolt This was PS. I have memory of Tony discovering this while getting stuck into Croc2. It may be a false memory, of course, it was a while ago... ;)
@@RetroHQ hahaha cool! It's entirely feasible it was fixed up pre PC! By the time we got it (ahem) when porting I'm pretty sure the nmake file had O2 hardcoded
In the initial makefile, there's a conditional that specifies 02 optimization if a version condition is met. I assume this is part of the reverse engineering and not something from Nintendo's original code?
The EU version wasn't released at the same time as the US and JP ones, so somewhere in between the releases, Nintendo enabled O2. The condition in the Makefile is the reverse engineering team's way of replicating that.
I'd like to see how various retail games would run with all the optimizations changed to O3
those that don’t already use it would break. otherwise they would have used it.
This is why I love your videos, in depth research followed by a very interesting presentation.
I saw the other TH-cam video a few days ago, I really appreciate your follow up. Thanks for the extra details on the SDK, it’s a lot more believable that Nintendo choose not to enable optimizations given the cost/ benefits.
MattKC is such an underrated content creator. Glad you mentioned him for others to be made aware of what he does
Edit: just realized y'all both Aussie
5:00 I've just now noticed that canvas with the health/oxygen indicator is supposed to be Mario's profile. It's 2020 and I played this at launch.
I still have my copy bought in November 1996 together with the console. All with their boxes.
Isn't it fascinating how we can see a film, or play a game and miss a detail until revisiting years later?
Lol u must be blind
Better late than never I guess
I noticed it while hacking the game and thought I'd accidentally enabled an Easter egg.
Please do more videos about these subjects, also very interesting your videos about how emulators work, there is no other channel that provides content like this. Huge fan of your videos.
Please keep mashing more games and code/development topics!! This video was fantastic!
When I saw the original video, my main thought was “this is cool but I need MVG to confirm.”
MVG is like your pastor.
When I saw the original video I came to the same same normal conclusion as this video...
It's so nice of you to credit MattKC instead of stealing the idea.
of course. his video is excellent
MattKC has been making great videos. He has just recently getting into vintage videogames but worth a view.... Just don't go back to far or there is a bunch of cringy eye liner videos lol.
@@joshsadowski8869 everyone starts somewhere
Besides, one poorly-researched video (which was more a failure of his knowledge of consoles, and knowing where to look in order to verify the actual tools used for development) isn't going to wipe away his work on preserving Lego Island for modern systems.
Figuring out how the game handles audio *by himself* and releasing a free tool to update the game with the uncovered full-quality audio tapes is still commendable.
@@VirtuousLiberty me 2
Stealing his idea?
What's next I'm stealing other people who came before me for being alive?
always great and interesting vids, appreciate all you do!
Super useful info! Great video, man. Love your channel
"Redefine the platforming genre." As a clip shows mario falling from a platform while trying to simply walk across a short bridge.
I'm joking of course, it was just a funny juxtaposition.
One of the most interesting videos never seen. Thank you!
Videos are always so interesting! Love the channel.
I am also an Embedded Systems Developer and I loved this video. By the way, is the Shindou Edition any different from the standard ones regarding the compilation flags?
I was shocked when I heard there was an "easy fix" improving performance..
Up to a certain level - the speed differences often aren't that groundbreaking & limited to a couple of percent points. Beyond that thinking about using different algorithms & data structures as well as different game logic is more fruitful.
Well usually the “easy” fix is not that easy in a real world scenario.
@@litjellyfish as stated by the reverse engineering team... No, it really is that easy.
Vyor and again yout forgot to read “real world scenario” so sorry no it’s not that easy.
Technically it’s that easy. Nintendo is not that stupid. Risk wise it’s not that easy all. So Nintendo took the right decision and not go for the optimizations. Nintendo are not stupid.
Nintendo have of course more skill, experience and resources than this reverse engineering team. Also what indeed IS easy is to conclude this about the optimization now many years later with emulators time and more.
@@litjellyfish Nintendo is stuffed to the brim with shit coders, worse leadership, and a terrible track record of technically competent design.
Just look at smash ultimate: broken and buggy. BOTW: laggy as shit. Sword and Shield: incomplete rush job. Mario 64: too many bugs to count and horrid optimization.
This video made me realize I optimized my first child, and then figured the second one would be just fine so I didn’t bother.
Normally its the other way around spending years trying to debug the first child while the second tends to be programed better.
Celebrating 25 years of Nintendo 64 and Super Mario 64 in this year!
👏🏼👏🏼👏🏼👏🏼👏🏼 🥳🎉🎊🍾 🎮
Some of the best content on youtube. Always looking forward to your next video!
The tortured soul of Lara Croft appears to be trapped inside the Silver Play Button on your wall
Fitting, considering the first Tomb Raider came out around the same time as Mario 64.
I'd love a video giving us a technical overview over the engine. Could be interesting.
Thanks for sharing your developer perspective on this! It was very insightful.
Really top quality content, mate. Fascinating. Thanks!
Golden Eye would be worth a look, although I get the feeling it's probably just a problem with the game code rather than the compiler settings.
Wasn't GoldenEye a first project for a lot of its dev staff? Or just their first project at Rare.
GoldenEye uses older drawing methods. no depth buffer, etc. all triangles had to be z sorted which has a good bit of overhead and more or less totally screws optimized display lists, where triangles can share vertices, flat surfaces could be quads, etc. the 64 is really kinda based around being given optimized display lists (they have a limited vertex cache, between 32 and 128 depending on the microcode) since the rsp only has a 4k data cache (think ram) for any 3d data to be passed through, any time it has to stop and change out its data it's gotta throw an exception/interrupt and have the cpu send it another chunk of data.
all in all it also saves ram as there's no depth buffer, so another 320x240(or whatever the game runs at)*2 bytes freed up. the pixel fill rate is also increased substantially because it's not having to constantly check the depth buffer when it's drawing.
tldr GoldenEye used old styles of rendering that would have fit the psx but don't work out so well on the 64.
Goldeneye has been optimized by minimizing the explosions among other things you can also just play it on PC to have a faster game on PC normal speed is turbo mode and turbo mode is even faster.
@@blahblahbleeeblahh7053 totally irrelevant. getting rid of features is not "optimizing"
@@Jombo23MC it doesn't remove the explosions entirely only minimizes them because too many explosions lag it hard just check out Goldeneye NGPA edition you will see what I mean it feels nice.
I might be mistaken, I remember hearing back in the day that NTSC games used to run slightly faster than PAL due to the screen refresh difference. Could that account for the optimization difference between the versions, to produce a more consistent final product?
Loved me some Pilotwings... The terrible blood-curdling screams of Robin when she crashes and burns still gives me chills... but... infinite rockets, the birdman suit, and the amazing soundtrack kinda made up for that in the end. Go Pilotwings!!
Really great video! I loved the explanation about c and assembly.
It's always a good day when MVG pops up in my subs. I don't understand any of this technical stuff but the way in which you present it gives me a somewhat sort of understanding. Another great video as always MVG.
Was there any additional optimizations or changes to the code done to the Super Mario 64 Shindou Edition?
The only big one is patching out BLJ, and in Japanese SM64, when you got a key, it would turn into a star
Shindou is not supported yet by the decompilation, but afaik the optimizations were just change to the second level of optimizations.
Regarding changes, those are a bit more complicated. They updated their audio and main libultra files and added rumble support. They also did patch BLJ's, but there are likely other unknown fixes to the base. For example, we only recently discovered they patched a bug that allowed bullies to clip OOB if hit in lava while burning. In a few months, we will likely have a full answer to this question.
Love your content man. Super interesting stuff!!
My initial thought when I saw that video was that it was probably because Mario 64 was made using early sdk and there were probably very good reasons Nintendo didn't use the 02 optimization.
Thank you for digging into this further.
"piqued"
Not trolling. You're most likely my number 1 favorite TH-camr.
Compiler bugs - I ran into a bunch of those more times in my career than I'd care to enumerate. Usually they were with proprietary compilers!
I would never hire a guy telling me that in such a context (there exist compiler bugs - of course, even more so in proprietary compilers - but programmers declaring to have run into numerous of them - relative to themselves writing code with UB - is usually a big red warning sign indicating incompetence and dunning-kruger. I am not implying this here - that would be ridiculous from a one-line comment on youtube). However, it is rather clear that the compiler was not really to blame in the case of SM64 but its input was crap.
steefant GCC was notorious for bugs in optimisation in the 90s when mario 64 game out. so much so that you could only compile linux kernel with specific gcc versions that had the “right combination of known bugs” the source code had taken into account. it was ages before anything newer than GCC 2.7.x was supported
What an excellent video. Love it. (Even) more like this MVG, great stuff.
Another awesome video MVG. Thanks for breaking it all down!
Have you seen Kaze Emanuar's recent video where he optimized the game to 60fps?
One of the best things about Super Mario 64 is that unlike most games from the era it doesn't feel old, dated or boxy thanks to it's super dynamic gameplay and cartooney graphics
That’s always it. When a game goes for realism, it dates itself instantly. The next gen makes it look bad. That doesn’t happen as much on cartoony graphics. I can play modern mario games and then go back to a gamecube one or DS one and barely see a difference (resolution and such aside). Its different with sm64 because its marios first 3D game and the design just wasnt... *there* yet.
Personally I don't agree. It looks and feels *OLDER* than it is. I'm all for cartoony graphics over realistic ones, and I can more or less get over the graphics. But the camera makes the game literally fucking unplayable. I want to enjoy the game so much but it's just unfathomably clunky and claustrophobic for most modern gamers. I understand rating it on the time it came out, but rank it by modern standards and the gameplay becomes bottom of the barrel.
I very much disagree.. then again not really because of the graphics just the camera is fucking ass. The first "realistic" 3d titles are now all but unplayable unfortunately :D
@@ThatPianoNoob absolutely
@@ThatPianoNoob I'm gonna install Mario 64 again to see what's up cause I don't remember any trouble with the camera.
Maybe you guys are not moving the camera?? And just expect it to point to where you want automatically?? Or you expect it to move it using the mouse?
Absolutely amazing the content of all your videos!
Yay someone else who remembers Pilotwings! Very interesting video. As someone who is not a programmer it is fascinating to learn about the oddities of different languages and compilers.
I'm more interested in this allowing someone to make a native port of Mario 64 to PC.
Demetrius Lolos unfortunately, I imagine a great deal of the code is hardware dependent
@@andrewrusso3871 couldn't you just remove those bits of code?
@@Kira-zf7te Rewriting code to run natively on a completely different architecture is not as easy as that.
The thing is that all the code is tailored to that hardware, and if you wanted to simulate it it could be the same as using an emulator.
I saw someone on Reddit post that they were working on a PC port of the game. It had quite a bit of emulation layers going on, but I'm pretty sure that's normal procedure when porting software from one platform to another, you start emulating most of the output and you implement changes to use actual hardware in the end. Man, I'd love to see a port of the game made to run on vintage hardware, like a 3Dfx Voodoo on Windows 95, like how it would have been if Nintendo decided to port their game to the PC back in 1996.
5:03 did he just say that he is a c program?
It's that Aussie accent. He's a "C programma"
no he legit said "C program"
It's a liaison between the /a/ sound in "programma" and "and." It's probably not something easily picked up by a non-native speaker.
there's a clear pause between the word "program(mer)" and "and"
maybe he just ran out of breath and just rolled with it?
His voice is quite slurred at times, but it was easy to understand from context
What an amazing explanation and testing you've done.
Incredible! I don't know a single thing about programming nor did I understand a single of the technical terms you used, but you put everything is such good context and laid it out so that people like me (whose knowledge of ''programming'' is limited to WoW macros) can understand everything! Amazing !
Can we all just stop and appreciate MVG for a moment for the high quality content, knowledge, professional approach, all his contributions to all the various projects he has taken part in, and - last but not least - extremely quick response time combined with ability to give credit where credit is due. I'm speechless.
Appreciate the kind words.
I don't think I could have worded that any better than you did if I tried. I don't think anyone on TH-cam can make quailty and interesting content like MVG about these niche subjects.
would be interesting to see what a modern GCC could do optimising that code.
You can try compiling the source code yourself. You will just need to provide an original ROM since the source code does not include the game's assets due to copyright reasons.
Surprisingly not much, since the MIPS-specific parts of code generation have changed little due to lack of interest and focus was mostly on stability for use in routers etc. before they switched to ARM. There's no magic gains to be made from auto-vectorization either since the only powerful vector unit is in the GPU, unlike the Playstation you have to go through microcode to make use of it.
Due to this video, you just got yourself a new sub. Are you taking requests for games to compare via debug and optimized versions? Should be interesting to see how effective the -02 optimization is.
Great vid! What's version of Mario's underground theme do you use in this? Cheers
TH-cam has suggested this to me at least 10 times.
.... This was the time I caved.
Well played TH-cam. Well played.