The Nintendo 64 was an amazing video game console, and alongside consoles like the Sony PlayStation, helped herald in the era of 3D games. That said, it was new hardware, with new development tools, and thus creating those early N64 games was a daunting task. In an in-depth review of Super Mario 64’s code, [Kaze Emanuar] goes over the curious and wasteful memory usage, mostly due to unused memory map sections, unoptimized math look-up tables, and greedy asset loading.
The game as delivered in the Japanese and North-American markets also seems to have been a debug build, with unneeded code everywhere. That said, within the context of the three-year development cycle, it’s not bad at all — with twenty months spent by seven programmers on actual development for a system whose hardware and tooling were still being finalized, with few examples available of how to do aspects like level management, a virtual camera, etc. Over the years [Kaze] has probably spent more time combing over SM64‘s code than the original developers, as evidenced by his other videos.
As noted in the video, later N64 games like Legend of Zelda: Ocarina of Time are massively more optimized and streamlined, as lessons were learned and tooling improved. For the SM64 developers, however, they had a gargantuan 4 MB of fast RDRAM to work with, so optimization and memory management likely got kicked down to the bottom on the priority list. Considering the absolute smash hit that SM64 became, it seems that these priorities were indeed correct.
So, when is [Kaze] going to release his 60fps Mario 64 patch? Dude’s been teasing it for the past couple of years at this point. His initial video that went viral used a bunch of emulator footage because of ROM hacks that had no hope of fitting in the geometry budget on real hardware.
All of his content comes across as “hurr durr gamedevs stupid”, I would be legitimately shocked if he’s ever shipped an actual game in his life. It’s real easy to be smug and arrogant when one has the benefit of 35 years of people picking apart hardware down to its lowest level, and has never had to deal with the time pressures, trade-offs, and sacrifices needed to get a game out the door, particularly on hardware that’s still in its infancy.
Overall, his content may not be wrong in a technical sense, but it has always come off to me as disingenuously smug, and omits boatloads of context just to pump up his own ego with self-soothing along the lines of “I’m so much smarter than the original Super Mario 64 team”.
Wow, you clearly did not listen all the way to the end of this video because he explains that the decisions made were rational.
Yeah, at no point did I get the sense that he was criticizing their work. It’s very much “this is what could be done with modern dev tooling and infinite time”.
And better knowledge of the architecture. The N64 is a very awkward architecture due to the RAM bottleneck. Half of what Kaze tries to explain is that most of the common opinions on N64 games comes from developers not realizing how much they had to adapt to this architecture.
It’s worth noting that over time we’ve trended towards easier and easier to program consoles.
Have you?
It’s very easy to sit back doing nothing and complain.
It’s one thing to show carefully selected footage showing what has been achieved so far and what is possible, it’s another to implement it for the entire game and get it polished up to the point where people can play it without constantly hitting bugs.
Thanks for asking. I was originally going to go with “ten since 2005 including two GOTY candidates over the years”, but after writing out my entire history of shipped titles, that would have been inaccurate. It’s thirteen since 2005 including two GOTY candidates.
And at no point did you wish that you had more time for optimizations before the games had to ship?
If you actually work in the industry you know very well that as a developer sometimes you don’t have the choice to finish code to the best of your ability because you have a manager breathing down your neck which leads to shipping code that is functional but not “perfectly” optimized. This is true for almost all software unless we are talking about passion projects that a developer will tinker with for years until they are happy.
don’t worry about these keyboard warriors you are correct in your assessment about him
ooohhhh… using the same memory size of a smartphone picture. What kind of comparison is that, first of all, smartphones make way to detailed images for what they are actually used for, wasting precious storage/energy/infrastructure in cloud servers for images (of which 90%) that contain no serious info.
okay… you’ve got a fixed set of hardware, with 4MB of RAM… why are you not “allowed” to use it all? Wouldn’t it be more wasteful NOT to use it? Other data is stored on cartridge, amazingly fast, so no need to cache that in RAM, you can load it on the fly wen needed.
These are fixed systems, you’ll never encounter one with less memory, so why optimize to run on less memory, put in some time/effort that isn’t used/required? I don’t get it.
Having memory and not using it, that’s the true definition of “wasting memory”.
I think he agrees, and Mario’s art style is heavily influenced by the ram constraints. If you view the entire video, you’ll see dead spaced unused between the different sections the game uses, which could have been used for a couple more textures, which would maybe enrich the stained glass sections some more. I don’t think he’s advocating leaving memory empty and in the table (which is actually what the game is doing), but freeing up ineffectively used space to use to improve performance and/or graphics. All with the benefit of hindsight and modern tools, and no time constraints because no deadlines or commercial goals, but he acknowledges this constantly. I think some people (WTF Detector included) confuse his enthusiasm for smugness or arrogance, I’ve never experienced it that way and I’m a long time follower.
Okay, makes sense, thanks for clarifying this. I indeed did trigger on certain aspects of the video and clickbait title(s) and the perceived smugness caused by the all so common modern arrogance of hindsight. Skipping parts (by pressing L on the keyboard during playback) in order to get through a 24 minute video doesn’t always help. Perhaps the video could be optimized in order to prevent people from skipping and missing the point (just kidding).
Did the video kick your dog or something? I’m having hard time understanding your anger.
i never agreed with the “unused ram is wasted ram” sentiment. that’s like saying all the tools in the shed are wasted because i only need a screw driver right now. i dont need a leaf blower to tighten a loose screw. ram not used in the present application/game may be useful on the next, and its better to keep it un-allocated when you aren’t using it, because its instantly available later.
this frustrates me even more on computers where the os gloms over everything in the vain hope that you might use a part of the operating system you never need or care about and have it start in one second instead of two. then when you want to run something, the os has to deallocate all those resources which takes time. thats like letting people borrow your tools and you have to knock on doors and fetch them all again before a big project.
On a console running a single game with no additional background stuff (like console OS features) then unused memory is just value left on the table. For the N64, it means they could’ve added more music, more textures, more models, or anything else to give some extra polish and fidelity to the game.
On PC, you are absolutely right though because wasting RAM ruins it for other running applications.
Most products are not made to be great. They are made to make money. Being great is juste one of the way to make money.
Cheap, good, or fast pick 2
Games on PC didn’t always need a massively over complex OS to run, they used to achieve really good results on limited systems because they could unload DOS and make use of every byte of memory and CPU cycle so nothing else was wasting hardware resource, just like a console.
I wish game devs could/would go back to those days and really utilise some of the incredible hardware we have now but everything seems to need gigabytes of OS to even start.
But then with support for VBE/AF, please? And 640×400 res minimum? 🩶🙂
The plain mode 13h in 320×200 pixel @256c was such an eye-sore IMHO.
Even by mid-90s already, when good old blurry 14″ VGA CRTs (0.41mm dot pitch) started to get being replaced by hi-res 15 to 17″ CRT monitors (0.21mm dot pitch).
Who says the game they released isn’t exactly what they wanted and there was nothing they had to cut that they regretted? The OP’s video clearly shows plenty of scope for squeezing more memory out of the game, and the biggest reason for not doing it is if they didn’t need it.
Thank you, you managed to hit the major gripe I have with this stuff, everything else I wrote is just a follow-on from it.
I stand by my statement that I doubt Kaze has ever been in the industry. The best games are the ones that make the team money so that they can continue to make more games, which are enjoyed by others who in turn make the team that money, and that the team is satisfied with what they shipped.
Once you’ve seen how the sausage is made, videos like these from super-fans of a given game get a bit stomach-churning. Dude might be really enthusiastic about Mario 64, but kids are really enthusiastic about cake. That does not make them good judges of cake.
Kaze made this point himself. Clearly you’ve decided that you want to be personally offended on behalf of the Mario 64 developers, and you’re ignoring everything he says and does that shows off his deep love for the title and it’s engineering.
Now that all those comments have been removed, it’s like we’re having a one-sided argument with a ghost :D
That’s a thing multitasking/multiuser systems do.
Many DOS users of late 80s and early 90s didn’t grasp the concept.
They were still thinking “C64 style”: an application either fits memory or not.
However, operating systems from the big iron do “buffer” and virtualize everything.
HDD caches, printer spoolers, queues, virtual memory etc.
That’s why OS/2 was so being critized all the time.
Because it needed an “huge” 4MB of RAM and up (just like NT and Win95 did btw).
Because it had to reserve 0-640KB for DOS space (DOS memory); 640KB to 1MB were shadow memory (adapters segment).
Then you had a few hundred KBs for HDD cache (to be efficient), some reserved kernel memory..
Device drivers and libraries (DLLs) needed some RAM, too.
Then there was the graphical environment (PM) on top of all that.
And finally, the user applications.
That being said, *nix indeed is a memory hog, I won’t argue.
It doesn’t reserve a bit of memory for quick access by applications.
It rather defends RAM fiercelly, like an angry big cat.
Modern Windows NT has an option to let the user determine if applications or the OS have priority over RAM.
There’s a general tradeoff between CPU and memory. If you’re not using all of the memory, that likely means that you are processing things which could have been cached or precalculated. You want as much CPU headroom as you can get in a game, for when some YouTuber decides to bring every enemy into the same room or some such silliness.
As others have pointed out, this is a console with a single running program.
I don’t know why everyone here got issues with the game and the memory, I play on my phone all the time with others great titles of the console and run perfectly with no issues. Maybe it won’t be that their phones doesn’t have enough memory or something like that?
Actually, the N64 had 8MB total if the memory expansion pak was installed.
4MB was never truely enough to begin with, that’s why the memory slot was there in first place after all.
The reason the N64 didn’t have it on-board from the get go was RAM price, likely.
The 4MB stock configuration wasn’t meant be really usable, though, I think,
but enough to sell the console for an acceptable price tag.
https://en.wikipedia.org/wiki/Nintendo_64_accessories#Expansion_Pak
4MB was entirely usable for most of N64 games. Only 3 games required the expansion pack and 3 more games that enabled bonus levels. The majority of games didn’t support the expansion pak or used it as extra screen buffer.
There are only.. three? four? N64 games that actually required the expansion pak, and maybe a dozen others that benefit from it.
Yes, the 4mb was undoubtedly a cost-cutting measure, especially given that the RDRAM the N64 used was pretty pricey, and it was only marginally more than the playstation, which had 2mb main memory and 1mb dedicated to the gpu.
But in 1996, I don’t think anyone felt that 4mb was unreasonable for a console.
(Heck, it was technically enough for a PC running the latest and greatest OS, windows 95, though 8mb was much better and all the professionals and cool kids wanted at least 16)
Um, that’s another controversial topic..
Many users had 1 or 2MB of RAM when running Windows 3.x.
But Windows just started to fly with 4MB of RAM.
If Windows for Workgroups was used, more memory was being recommended (say 6 to 8MB).
Up to 16 or 24MB (!) of RAM for a powerful, 486/Pentium-based WfW mail server in an office.
Also because of the big HDD software cache and the buffering required.
16 MB of RAM is a common RAM configuration that AutoCAD R11 (Win) users had used on their 486 workstations..
Windows NT 3.1 was a memory hog and needed 16MB, initially.
OS/2 2.11 and Warp ran (booted) with as little as 4 or 6MB,
but 8MB was the bare minimum to not wear down the HDD through excessive swapping.
12 or 16MB were real world minimum to make it bearable, I believe.
Windows 95.. It too ran (crawled) on 4MB of RAM.
Many 486 laptops had 4MB soldered and couldn’t be upgraded without proprietary memory modules.
But the experience was horrible, Win95 was swapping all time.
With 16MB of RAM, Windows 95 began to be as usable as Windows 3.1 on a 286 with 4MB of RAM.
It was okay for running small, Windows 3.x era software (the majority at release of Win95 RTM).
However, for larger applications, such as shrink-wrapped Windows 95 applications, even 16MB wasn’t ideal yet.
It needed 32MB (!) of RAM to stop excessive swapping to HDD.
By contrast, Windows 98SE greatly improved memory managment.
It had higher requirements, but could run 4KB aligned Win32 applications directly from swapfile (VCACHE) without moving it into RAM first.
With 24MB of RAM, Windows 98SE ran a bit better than Windows 95 ran with 16MB, I guess.
Speaking under correction.
Far as I recall nearly everything on the N64 just worked perfectly without the expansion pak, and many titles didn’t even benefit from having it at all. There are titles that can make use of it if you have it, and something like 5 that actually really needed it, which from my recollection were often sold with it – Think that is how I ended up with one. But the N64 was a long time ago, and I was pretty young at the time (it also wasn’t originally mine – bought it off a friend just as it went obsolete).
If I didn’t make a mistake at counting,
then there are about 63 games on Wikipedia that are being listed as using the expansion pak in some way.
64 games if we include Dinosaur Planet. ;)
How would you explain what 4MB is to the average person?
Give it as a fraction of whatever the current du jour is in phone-a-bytes, to wit “This is less than ONE ONE-THOUSANDTH of what your phone has.”
They will then say “Oh, yes” and nod sagely. Still won’t grok it, of course, like Arthur Dent being told about eddies in the space-time continuum. “Is he now, is he.”
In football (soccer) fields? ;)
“Wouldn’t it be more wasteful NOT to use it?”
The entire point of most of the video is that with more aggressive memory management, it would’ve left more space for textures. That’s why he counted in texture numbers.
Again though as others have posted, he’s not really critical of the developers, because they were obviously under time constraints. The main people he’s critical of are the people criticizing the N64 hardware as the reason why certain games look the way they do. The main reason for the graphical limitations are just that the developers didn’t have time and the architecture was odd.
To be fair, N64 and Playstation games didn’t age well in general.
The whole 3D gaming was very primitive at the time. Even on PC (W3D, Doom, Duke3D).
Many hand-crated 2D games stood the test of time, by contrast.
They’re still pretty. Unless being drawn in mode 13h, shown on a flat screen display.
If your device runs only a single application, then optimization doesn’t matter as long as it fits in the space and runs at the desired frame rate. Imagine if the devs, after finishing the game said “we would like another month to make the memory usage more efficient”. The answer would obviously be no, unless there was some advantage for the company or consumers.
An advantage like more detailed levels, models, and textures to better show off the capabilities of the hardware you’re developing one of the flagship games for?
i don’t see any reason to be angry at all…software archaeology is just an interesting rabbit hole. it’s just this weird fact that a lot of software, they spent 3 years building it, and then we spent 30 years using it. it’s such a trip to look back at the extremely limited computers of, e.g., the 1980s and realize that we didn’t even use them to nearly their potential. they didn’t exist for long enough for people to learn how to develop for them! the 286-targetted software that i grew up playing with was, with hindsight, just garbage prototype experiments that no one knew how they’d turn out until they were done. by the time anyone learned the important lessons, the 286 was ancient history!
but we can sit today and look back on any part of this history with a detail they never could have afforded as it was happening. just plain neat.
Hold on! One moment, please. 🙂
Please let’s don’t measure humanity’s technological level on punny home user hardware (ZX81, C64, PC/XT).
And game developers had standards, too.
There had been professional systems in the 80s that equaled home user hardware from ten or fifteen years later.
By ~1984, there had been graphics workstation running Unix in resolutions of 1280×1024 (non-intelaced) in 256c and more (depending on graphics terminal).
Here’s an SGI Irix 2400 from that time period, for example:
https://www.youtube.com/watch?v=9EEY87HAHzk
https://en.wikipedia.org/wiki/SGI_IRIS
About ten years later in 1993/1994, Rare developed Donkey Kong Country on a different SGI hardware:
https://www.youtube.com/watch?v=vTBnzCb6jMM
The 80286 ran Microsoft Xenix and OS/2 1.x in the 1980s.
There had been important commercial software to both platforms.
By early 90s, before NT was ready, OS/2 1.3 was still used as big development platform at Microsoft itself.
Many 16-Bit Microsoft development tools support “Family API”,
meaning that they create 80286 code and bundle with an OS/2 runtime.
On DOS, they would run the limited OS/2 runtime while on OS/2,
the applications can handle hundreds of megabytes of memory and run in preemptive multitasking and memory protection.
Without needing XMS or EMS.
Likewise, many Windows 3.x development tools do default to generating 80286 code.
The majority of Windows 3.1x software uses 16-Bit instructions found on 80186/80286.
Only a relatively few stick to basic 8086 instructions or use newer 386 instructions (in-line assembly, WIN386 extender etc).
Sure, the 80286 wasn’t as popular as the 80386 was.
But Windows 3.x “Standard-Mode” kernel required an 80286.
Thus. I wouldn’t call that processor non-standard or irrelevant whatsoever.
The 80286 was a reliable workhose that people just used, but never appreciated.
Unlike the 80486 or the Motorola 68000. Or 6502.
Reading Byte Magazine provided some insight back then.
And I’m not from the US, even. International newspapers and magazines were (are) available at airports and train stations.
Just a few years ago, I visited by local library and had a look at Byte Magazine issues from 1994.
Lots of articles about Windows 3.11, OS/2 and so on.
Very interesting. And without needing the internet, at all!
Dude spends the entire video dropping knowledge while ad nauseam making the points that it’s “not a waste of memory” if you don’t need to optimize and that the developers were under crazy time constraints while also working with poor and new tools. Dude goes out of his way to only point out optimizations that could be made without huge CPU trade-offs, and again reiterates that it’s just a fun mental exercise to do in modern time and not a reflection on the developers, but this whole comment section is filled with people who couldn’t be bothered to actually watch the video and want to rage about all the points he made. By the way Kaze is a brilliant N64 hacker who has done incredible work on his own Mario rom. The dude knows his stuff. He’s not just speaking in theoreticals.
I love seeing us really dig into systems like this still years later, it really helps to preserve critical core knowledge and skills at risk of being lost. At the same time there’s going to be an unbridgeable gap of understanding between people that have lived through a real game release in that era and everyone else, it’s unavoidable. It’s not ‘gatekeeping’, it just is. It’s obvious the video author didn’t experience that time. And that’s fine (and is an advantage w/fresh perspective), but it probably leads to them and the subject matter being misunderstood. The video title and the game chosen are obvious clickbait after all, and they show the author’s lack of access to adequate insight into the reality of the time. And if I had to bet, the irritation you might sense from someone like WTF Detector probably comes from having actual experience during or close to that time period. There are going to be emotions involved because succeeding at that time was anything but a simple feat.
The N64 existed in a climate that’s significant. To just say it was new hardware glosses over a lot. Of course early titles for a console face a universe of new architecture, and dev success hinges on understanding it. That’s a mountain of info to absorb in a short period. A lot has to be done from scratch. Release titles add even more pressure, they sell the system. You often don’t know much if anything concrete until dev kits come out, and being 1st party can’t even alleviate a lot of the uncertainty either. It takes time to hammer out details and get early usable dev tech. But there was more w/the N64 on top of that.
At the time, real time 3D content on consoles was exploding. There was a bandwagon to deal with. And finally there was actual hardware available to pull it off (PSX/Saturn). And along came a new console not only built from the ground up for 3D but designed by people with considerable direct experience–the premier graphics hardware company of the time. Imagine bringing Mario of all things, a 2D star for so long, into 3D. Imagine having Miyamoto on your back. The N64 was also RISC-based (SGI) and a 64-bit chipset (compare to SNES’s chip setup which was more familiar to PC users). Early dev was rumored to have been on an insanely expensive and unwieldy Onyx of all things. Understandably, none of that was mentioned in the video; the closest thing was a statement at the end to clarify intent and/or possibly address perceived criticism.
The core of the video focused on the technical side of decisions without being able to fully understand or appreciate all of the advantages. The hardcoded RAM segments for example were a result of space budgeting from day 1 and are a sign of a smart dev team. It puts your constraints front and center in your face. If you do this early in dev then there’s no guessing whether you’re going to make it, and you can add debug logic to police the sizes/bounds. To contrast, there are cases of groups getting to a demo stage w/a game and it being up to 3x larger than target hardware supports b/c they didn’t budget. That’s a game that’s never going to be. The video also mentions the idea of using multiple code segments (having code not loaded into RAM when not in use), but the second you start splitting up code/data into loaded/not loaded you take on the burden of being aware of what’s loaded and what’s not. Developing that way and under a deadline is the only real way to understand the impact. Releasing the game debug–my guess is it was a time constraint mistake, either an accident from rushing for deadline under pressure or to mask bug impact. The other major point in the video is general optimization, and ya optimization is a way of life, but there’s a cost: in finding optimization opportunities, successfully implementing them, dealing with inevitably stickier bugs, and then dealing with the increased complexity during development, all under a deadline. He does understand the idea of ‘making it’ and not needing further optimization though, and that’s big.
None of that’s intended as criticism of the video content (IMO it’s awesome), it’s just a reality that collides with that of the content and making a video noticeable. All of these things you can convey to someone and they can understand it, but living it is something else entirely. And that difference is going to bring emotions to the table, it’s unavoidable. For anyone that might be, I wouldn’t take it personally, that can get in the way of some really cool possibilities.