Why was the Nintendo 64 so hard to develop games for ? | MVG

[Music] the Nintendo 64 has a lot of great games super mario 64 The Legend of Zelda Ocarina of Time banjo kazooie perfect dark to name a few games that frequent best top 100 games lists of all-time the system was a giant leap forward in technology from the Super NES all of a sudden we've gone from a 16-bit CPU running at three megahertz to a MIPS our 4300 64-bit chip at almost 100 with some of the best games ever made would lead you to believe that the hardware was great to develop on the reality is it wasn't so simple while it's true that the system is responsible for some of the best games the hardware had its reputation for being very difficult to code on brilliance can only be achieved by going above and beyond Nintendo's a late president Satoru Iwata had his own take in 2010 when asked about the complexity of the hardware he said that was because Nintendo 64 drastically changed how things were made up through the Super NES system we ran up against how to make the best use of 3d graphics and the team had quite a hard time so what made the Nintendo 64 so complex was it just the transition to 3d or was there more to it to understand this better let's first review the hardware the CPU as mentioned is the MIPS R 4300 I essentially this is a cut-down version of the MIPS 4400 that was used for workstations the 4300 I supports both 32 and 64-bit instructions and also contains a 64-bit floating-point unit the chip is clocked at 93 megahertz and was faster than any other console at the time including the Sony Playstation and the Sega Saturn it has a 5 step instruction pipeline or in other words it can execute five instructions at the same time which can be either integer or floating-point instructions and it also has a 16-bit instruction and 8-bit data cache onboard TLDR the 4300 I was a very powerful chip on a home console that retailed for $199 in 1996 but the processor chip is only one part of the architecture the reality coprocessor or RCP is the custom chip that houses the RSP the reality signal this handles all the 3d graphical data such as 3d models and vector operations once the RSP is done manipulating the data it's then sent over to the RDP or reality display processor the Nintendo 64 has quite advanced 3d Hardware compared to the PlayStation and the Sega Saturn it features full hardware texture mapping anti-aliasing z-buffering trilinear filtering perspective correction and a 32-bit frame buffer audio is also handled by the RCP with 16-bit stereo sound at 48 kilohertz and a programmable number of sound channels of up to 64 is achievable Silicon Graphics boasted that the raw compute power was 10 times more powerful than a Pentium computer at the time the Nintendo 64 has 4 megabytes of RAM on board this was utilizing RAM bus technology and was one of the first consoles to use a unified memory architecture or in other words memory that was shared across all processors this meant that the programmer could make decisions about how much memory would be needed for code graphics audio data rather than imposing the hard limits on the amount the RAM bus technology memory known as Rd Ram found on the Nintendo 64 was fast it could transfer up to around 500 megabytes of data per second in theory the console can also be expanded with an additional 4 megabytes of RAM via the expansion port on top of the system to a total of 8 megabytes and then of course is the cartridge format it came with lots of criticism that Nintendo should have adopted the CD format like Sega and Sony however the advantages are faster loading performance and access but some development companies like factor 5 embraced the cartridge format stating that the cartridge system was being treated more like existing memory that was available on the console so the Nintendo 64 on paper boasts some very impressive hardware specs the most impressive out of the fifth generation of home console yet many developers complained about the complexity on developing on the n64 let's go ahead and take a closer look at the hardware and the architecture of the Nintendo 64 and see if we can make sense of this to render graphics on the Nintendo sixty-four and output them to the screen it works something like this display lists are a series of graphical commands that are stored in RAM the RSP will execute this list and apply any geometry operations to it this isn't really anything different to something like the Sony Playstation which uses the GTE or geometry transformation engine to handle these lists on the ps1 but on the Nintendo 64 graphics and audio isn't fixed it's programmable the RSP will be provided a display list until the rdp what it needs to render and the programmable microcode is letting the RSP know how to interpret the display lists on paper this sounds pretty standard for 3d back in 1996 the first and perhaps the most frustrating problem for developers at the time was the texture cache the RDP contains a texture cache that was four kilobytes in size without a texture cache the hardware would need to access main memory each time it needed to access a texture which would result in stalling this is because it takes longer to access main memory over the bus when the cache is sitting right there inside the RDP it's super fast to access but with only four kilobytes programmers were frustrated by the miniscule size to do with this limitation they had a few different choices the first method was to reduce the size of the textures so they would fit inside the cache this was a problem because the texture would end up being low res and blurry and this is why so many n64 games look so low res if the texture was larger in size then it was usually cut into 4k chunks which required processing to do so the second option was to just load uncompressed textures from the cartridge directly and ignore the texture cache most of the time reading from cartridge was faster than reading from RAM but not as optimal as using the texture cache but the problem with this approach is that the size of the cartridge needed to be larger to accommodate for uncompressed textures this ended up being a fairly standard approach later on in the n64 lifecycle but neither of these options were optimal both of them had costs associated with them ideally the intent oh really should have increased the size of the texture cache to 16 or 32 kilobytes which would have really helped the developers take more advantage of the cash and help with performance of the games the main reasons why there wasn't a larger texture cache was for both cost and space while it most certainly would have aided developers it would have also increased significantly the size of the chip and its power requirements it's also important to note that the four kilobyte Ram expansion doesn't help here at all one Nintendo 64 developer was quoted as saying it's like adding a new fuel tank when there isn't enough gas at the pump although the texture caching was a major frustration point for many developers the biggest one probably has to be centered around the RAM that was inside the n64 known as Rd Ram but what about the Nintendo 64 Rd Ram implementation too much typed super fast memory why was it not preferred to store textures in simply because although it had lots of data transfer bandwidth it had horrible latency or in other words the delay in time before a data transfer can occur during development of the ultra 64 prototypes the latency was said to be so bad that it was possible to turn the Machine off for up to 30 seconds before the RAM banks were cleared out this was obviously addressed before final retail to more acceptable levels but the latency was still an issue games had to be developed in such a way that the CPU always needed to be executing instructions and not stalling waiting for another Ram read or write to finish it also meant that it was better to pre-compute textures and store them on the cartridge rather than allow the hardware to calculate MIT maps which would have a cost associated to it while other games such as Super Mario 64 resorted to garage shading techniques over texturing on surfaces to work around any unnecessary Rd Ram access the Nintendo 64 had no trouble pushing many hundreds of thousands of polygons per second but the games never seemed anywhere near as fast as the PlayStation this is because of the fill rate or the amount of pixels that can be rendered in a 3d scene in a given amount of time this was one of the major bottlenecks of the Nintendo 64 while it was optimized over the lifespan thanks to the programmable microcode that we mentioned earlier the problem was this code was property of Nintendo and almost every developer was not authorized to get access to it this meant that if the developer had an idea for a fast algorithm to speed up fill rates they were out of luck fortunately Nintendo did offer micro code updates with additional SDK releases and later on allowed programs to customize existing ones provided but overall micro code was a very strange situation that hamstrung developers especially early on there was also no debugger and very little documentation fortunately companies like factor 5 who were skilled developers ended up customizing existing micro code to great success 1 late game in the Nintendo 64's life cycle will drive a championship ran micro code known as Z sort the game ran at 640 by 480 at 60 frames per second without an expansion pack but had to disable things like mipmapping as a result on the flip side a game like Perfect Dark runs at a poor framerate simply due to the limitations imposed on the developer while the Nintendo 64 ultimately was very successful and many great games were released it was a system that focused too heavily on peak performance and less about performance over time Nintendo themselves admitted that perhaps they made the hardware overly complex with hardware development chief guineo Takeda stating when we made nintendo 64 we thought it was logical if you want to make advanced games it becomes technically more difficult we were wrong we now understand its cruising speed that matters but the momentary flash of peak power so there you have a guys that is the unnecessary complications of developing games on the Nintendo 64 it's a interesting insight to go back and look and read some of the stories about the frustrations that developers had when rewriting games for the n64 but obviously you know challenges like this can be overcome we saw companies like rare and factor 5 really just excel on the system and bring some amazing games and really just kind of overcome those technical challenges that were brought in front of them so there was certainly ways to get things to run and look really well on the n64 but a lot of the times it was just unnecessary thoroughly complicated and even in Tendo themselves admitted as much that perhaps maybe the system was too over architected or over complicated for its own good and they really learnt a lot of lessons going out of the Nintendo 64 into the Gamecube which was more of a traditional 3ds system well guys we're going to leave it here for this video thank you so much for watching if you liked it you know what to do leave me a thumbs up and as always don't forget to Like and subscribe and I'll catch you guys in the next video bye for now [Music]

Channel: Modern Vintage Gamer

Views: 1,170,194

Keywords: nintendo, n64, mvg, modern vintage gamer, gamedev, rambus, texture mem, Nintendo 64, retro, gaming, video games, play nintendo, reality display processor, reality signal processor, rcp, rsp, display lists, 3d, graphics, perfect dark, rare, factor 5, banjo kazooie

Id: gRslfM-MOOw

Length: 11min 55sec (715 seconds)

Published: Mon Apr 27 2020