Why was the Nintendo 64 so hard to develop games for ? | MVG
ฝัง
- เผยแพร่เมื่อ 26 เม.ย. 2020
- The Nintendo 64 was an impressive console. Silicon Graphics and Nintendo pulled off the unthinkable - the precision of accurate 3D hardware on a $199 consumer home console. Yet developers complained that the system was too complex and overly difficult to develop games on. In this episode we take a closer look at some of the complexities developers faced when making games for the N64.
► Consider supporting me - / modernvintagegamer
Thanks to CrashOveride for his help
Sources :
► RetroReversing N64 - www.retroreversing.com/n64/
► Inside N64 - n64.icequake.net/mirror/www.wh...
► Nintendo 64 Architecture | A Practical Analysis - copetti.org/projects/consoles...
► WTF was Nintendo thinking with the N64 in Japan? - www.resetera.com/threads/wtf-...
► Don't Blame Rare, Blame Rambus - www.therwp.com/forums/showthr...
► Iwata Reflects of N64 dev challenges - www.eurogamer.net/articles/iw...
Social Media Links :
► Facebook : / modernvintagegamer
► Twitter : / modernvintageg
► IG: / modernvintagegamer
► BandCamp : modernvintagegamer.bandcamp.com/
► The Real MVP Podcast : player.fm/series/the-real-mvp
#Nintendo #GameDev #SiliconGraphics - เกม
I would love a "what could N64 games look like if storage wasn't an issue" video 🙂
Yes. What could the RCP and 4300i do if really allowed to stretch their legs? I'd love to see what the real brains of the operation was capable of
There is a guy doing gods work on Portal64 and another lad making modern Mario maps, so you don't have to die wondering.
@@jasonbroadhurstyeah Portal64 is very impressive
N64 graphics with Playstation-like framerate?
@@SamyasaSwiR.I.P. Portal 64 :(
"Reading from cartridge was faster than reading from ram"
That sounds... interesting
catridge os
holy shit.... CArtridges os's
Oh my god if you build an n64 cartridge with Bluetooth and Wi-Fi receivers in them you could basically have a cartridge OS which is totally untraceable
Patent pending
How much is the speed of the average ram speed back then? Now its almost speed of light
I remember working on the N64 back in '99.. was a junior developer working on South Park Rally, well.. originally it was a port of Deth Karz (from Melbourne House) to the N64 which got canned, and then the game ended up quite differently. 4K texture cache was painful but just had to be smart about how you render. R4K assembly was pretty fun though.
What are your thoughts on the final game?
@@crashoveride879 Tech-wise I thought it was great, from a gameplay aspect, not as good as it could have been. I really wish we had gotten to finish Dethkarz. Would have loved to seen it on the N64.
@referral madness These days, compilers are pretty good at generating smart code, however from a learning perspective, I think it's still worth learning. If you plan on writing code for older machines then it is a great skill to have.
Neat
@@shkdzn Any chance the Dethkarz n64 source is floating around??
Nitpick: a five-stage pipeline doesn't mean that the MIPS chip can execute five instructions at the same time, exactly. It means that it can have up to five instructions in progress at any one time, with each at a different stage of the pipeline. Only one instruction starts and/or finishes per clock cycle. That's a pretty important distinction: a chip that can start, run, and complete five totally concurrent instructions at once would have been much more impressive and powerful (and expensive) than just a single-threaded chip with a five-stage pipeline.
That also created a really annoying pipeline problem where you couldn't use a register value until 1 clock cycle after a load instruction, if you tried, you'd get the old value for that one cycle. This was difficult to debug.
Winston/Brian: Happy you guys wrote that up. When I heard that.... I was like 5 at a time. Hell no. That would have been a lot of money in 1996. Thanks guys!
...man.... no wonder emulation for the N64 is STILL subpar compared to consoles like the game cube or wii
Great comment. For some perspective , an original Pentium had a 5 stage pipeline so this was not a particularly novel thing for the time. Later Intel CPUs in the 90s and early 2000s ranged from the 6 stage all the way up to I think 20 on the Pentium 4.
@@cdoublejj There's many reasons the emulations are difficult to get accurate. Timing is the main one. Some games expect timing to be pretty much exact. Some titles generate their display lists, as the GPU is executing them. They are doing this dynamically under the assumption that have X clock cycles in which to do their calculation.
Emulations do not, generally, take this in to account and these are VERY HARD to track down.
Another example is some oddities of the MIPS processor.
For example:
mov r0,0
str r0,[r1]
nop
mov r0,0x80
ldr r0,[r1]
add r2,r0,1
What value will r2 have?
You would expect to see 1. But, no, you'd get 0x81 (I haven't tried this - i'm trying to recall the actual 'bug'). If there was a nop after the ldr, everything would be OK. If you single stepped this in a debugger, you would get what you expect; but when it runs, you wouldn't (EXCEPT if an interrupt happened between the ldr and the add).
"Alright team! Lets learn to develop for the N64! First off, lets read the manual on addressing the RAM..."
Manual: "Dont use the RAM, I beg of you."
To be fair, i think the title is a bit misleading. It's not that the N64 was hard to develop for PER SE. However, it was badly designed in terms of specs, and working around those bottlenecks is what made development hard. You might think that's ultimately the same thing, but it is not: Remember that other console MVG reported on that was hard to develop on? It had the inverse problem: Plenty of power and no bottlenecks, BUT the code to use that power was complex and ugly. So, it's not really the same thing - quite the opposite.
yes do i do have begging of the you
Naota Akatsuki The Sega Saturn and Atari Jaguar were arguably worse in that regard.
@@lyxar777 I wouldn't say "badly" designed, so much as quirkily designed. As illustrated here, the design allowed the system to do some things that other competing consoles couldn't, it wasn't necessarily super intuitive to work with.
The N64's specs are not it's issue per see, it is the most powerful console of its generation by a long shot. The primary issue is limited cart space, developers always had to wrestle with this and the constant need for compression and decompression. Such a waste. CD would have solved all those problems. Also Factor 5 went into detail on how limiting Nintendo's generic SGI code was and the only way to actually push the system was to write custom microcode which alas Nintendo did not authorise but for a few games.
That generation of early 3D consoles was so interesting for the different approaches to the same problems. The N64 took the approach of cutting down professional grade hardware to consumer level prices, leading to some difficult limitations particularly in terms of memory. By comparison the Saturn built much more on the previous generation of bespoke sprite/tile warping technology while the PlayStation implemented a lot of basics of modern 3D hardware from the ground up, but left out all the more taxing features.
To me is not exactly the Hardware what was important of that generation. Out of all those game systems the N64 was the only one that had a clear vision of how interacting in a 3D space should be achieved. The N64 stablished the base of how all game consoles worked after that.
@@Refreshment01 It's a broad statement to say that.
Yeah, it is. I get what he's saying and he's right to a large degree. They got 3D games, environments and movement, even cameras right while most others were really struggling.
I mean compare Tomb Raider to Mario 64. It's a fair comparison yet, TR was so clunky in comparison.
That said, it's unfair to give them ALL of the credit for the way modern 3D games were made thereafter.
I think the Xbox 360 and particularly Gears of War rewritten the rules on large character in 3rd person that usually handle slow and terribly now moving like a cat and building a solid base for gameplay with the first really good cover based shooter system.
So everyone gets to move things on a bit at a time but I get your point
Mario 64 did establish how good 3D camera movement should behave,
Spyro that took that example very seriously became really good and fun, while other playstation games (mentioned in one AVGN episodes) that didn't end up being criticized on how the player have to fight the the game's camera.
@@funky7chunky everyone adds little bits. Max payne gave us slow down to shoot mech that's now a crutch on console shooters, like red dead. But nintendo basically gave the industry a place to start from, which is huge. It's like apple, like it or not, they invtented the modern smart phone. (i was nokia symbian user too, and windows mobile, and bb, put your god damn pitch forks down, fanboys.
That puny texture cache really neutered the system. Even a secondary external cache probably would have been a huge help.
Yeah, 4Kb? Why the hell even bother? No wonder developers told them to shove it!
@@immortalsofar5314
Yep, one of the numerous reasons third parties completely slipped Nintendo for the most part during that generation.
Tell me if I'm wrong here, but wouldn't an external cache have the same problems as the RAM? The cache was so fast, because it was built in the chip that needed it. If you added an external cache, it would lack the needed performance, wouldn't it?
@@g.o.a.t.y.g.u.y Yes and no, I think. The bottleneck tends to be the bus (especially if it's shared), then the RAM access method, then the RAM speed. The length of the wires are way down compared to those although it does affect how quickly the signal becomes stable. I'm no expert but that's how I understand it.
Ummm they did have an external cache. The game cartridge. That’s one of the things talked about in the video. Also a special separate port and bus for a external cache would just add to the system cost. So at that point might as well just add more cache to the chip instead
In case anyone wondered how much $199 in 1996 would equate to today it's around $384.77. So when I think back to my mum saying no it's too much money for one it makes sense to me now. Didn't show her i was gutted, I knew she struggled when we were younger.
I kinda feel bad for asking now.
Same, any console I don’t have that’s $80-100 on offerup I’ll snatch up. I’m 20 and I’ve been collecting consoles and games that I never got to play as a kid. I had a single mother I never had a game console as a kid.
Yeah as kids you just don't realize the costs of things, you just want stuff
I swear i saw an ad for the N64 for around $600 that Xmas and just knew i wouldn't be getting it anytime soon. But after that winter, the price went down to the real MSRP of $199. Demand legit drove the price of that thing up way more than what this video says the price was
@@billybones6463 im guessing he found a random retail price for an outlet at the time. Not sure if the US was big into bundles but most N64s here had a game joypad or rumble pack thrown in for a bit extra. I wonder if he quoted one of those prices.
Even at retail was a big ask for a kid in a family of 4 siblings. I never got my hopes up.
But dont get me wrong i didnt miss out and was grateful for what I did have mind you.
yeah and on steam sales they are extremelly cheap... problem is AAA games themselves are pretty crap nowadays.@@captainkirk4271
I would also like "Why X console was developer friendly?" series
This would be awesome, there gotta be some developers out there with good experiences.
Dreamcast and Xbox in the top tier alongside Sega Genesis.
i think gameboy color was.
@@Viktoria_Selene wasn't that coded on assembly??
Maybe a video on PS1, because it was so easy to develop for when compared to its immediate competition.
I remember the texture filtering in Ocarina of Time really blew my mind back in the day, even though it was low res the textures looked really smooth compared to the PlayStation where you would always see each jagged square pixel in games like FF8.
I actually prefer jagged textures. Maybe it's the Minecraft fan in me. The Project64 plugin for video I use allows me to use jagged edges.
Best game ever
@@linkthehero8431 Same, the blurry textures make my eyes hurt
@@ThreeDaysOfDan It's like enlarging a photo in Microsoft Paint. Sure, a 240p image can _technically_ be resized to 4K, but it ends up looking even worse because of all the guesswork required to do so.
Also it had perspective whereas the PS1 kept thinking the world was in 2D
To their defence nobody knew how to design a viable real time polygonal/3D rendering system at the time, especially not in the consumer space. It was a completely new paradigm. Still mind boggling that Silicon Graphics could design a chip with such a laughable small texture cache even for that time when the system was so dependant on that. It was so much ahead in everything else.
It's not really laughable. 4KB per texture is fine for that era. PS1 had the same. The idea for N64 was tiling and clamping multiple textures across surfaces, making use of texture detailing etc. Unfortunately due to tiny carts and time, in most cases devs simply stretched a single small texture across the surface.
They didn't have CD rom for good rez textures anyway. Less textures, cheaper cartridge to produce. Saturn and Sega32X were promoting games like Virtua Fighter at the time which had like no textures at all.
@@zerazara N64 was designed with a superfloppy in mind. N64 DD was supposed to release much earlier and effectively be _the_ N64, and AFAIK wasn't even meant to be a peripheral, but it was postponed because of quality issues and eventually effectively cancelled. But you're right, textures wasn't much of a consideration at the time, flat surfaces was believed to be what they had to settle for in most cases, that was the paradigm, I had forgot that.
It’s because they basically just copy and pasted their workstation rendering architecture, designed for frame-by-frame rendering of high resolution movie scenes, and sold it to Nintendo as a game architecture.
Why Nintendo even bought it though…
That's not true. Nobody new how to design a capable 3D graphics rendering system with a unified memory bus. The geometry transformation, texture mapping, and framebuffer reads/writes are all memory intensive - and they interfere with one another when they are all on the same bus. Nintendo could have added a small VRAM chip like the Playstation did, but that would drive up the cost. And their custom hardware was already expensive.
1:44 "5-stage pipeline" means only that five instructions are being worked on _at_ _different_ _stages_ at the same time. When people say "execute n instructions at the same time", it refers to being doing multiple instructions simultaneously (being "superscalar"), which this CPU can't do.
Correct. Older non-pipelined CPUs, such as on the NES, took perhaps 4 clocks (on average) to do something meaning your 1MHZ CPU was actually doing 250k operations per second.
And this then introduces the risk of "pipeline stalls", which are pretty expensive in their own right.
Thank you! I was about to write this comment. Now I don't need to :)
It's one of those details that you can't really explain quickly, might as well leave it out.
@halofreak1990: Pipeline-stalls can be worked around in various ways, such as multithreading or barrel-processor design. Yes, that adds floorspace in its own right, so it's not cheap - but it's an addressable problem.
RAM-latency and speed in turn cannot be fixed: If your CPU runs faster than memory tek can keep up with, there's nothing you can do about it.
If you developed Nintendo 64 games back it the day, let me know about your experiences (feel free to email me)
A few points.
- I didn't talk about DMA in this video as i the main focus was on the graphics side. However if you want to understand how DMA worked on the N64, check out Rodrigo Copetti's blog (link in description). tl;dr - the implementation is NOT good
- at 1:54 i meant to say 16 and 8 kilobyte instead of bit
- stay safe!
If developers learned from Developers like Capcom and Rare.. Those 2 developers made the N64 shine..
Unrelated: I love how you have everything so neat in the background, it makes your videos stand out.. I can tell you have the same care when developing these videos..
@@kenrickeason yo I agree. MVG is one of my favorite channels for many reasons, this being one of them.
I like to compare Nintendo's restricted sdk to the story of crash bandicoot where the dev removed Sony's code to put in place faster in house code
N64 was the first console I developed for. I wrote a lot of the game engine (rendering and character control) for Earthworm Jim 3D (I know it was not a particularly good game - I'm so very, VERY sorry). I have fond memories of using the hardware - and don't remember it being particularly bothersome. It was a struggle early on with the documentation, but once I got a basic textured triangle on the screen, in my memory it went smoothly (from a technical point of view). But it was a long time ago, and I wouldn't say we really pushed it. I hadn't programmed any 16-bit consoles, so perhaps it helped not having that baggage. And the display lists felt familiar from having worked with DirectX (DX3? DX5??) albeit the N64 had a more OpenGL like syntax. I definitely remember fill rate and textures sizes being an issue. Pretty sure we kept everything 32x32 or lower.
We started the game quite early on in the lifecycle of the console, but the project lurched in a few different directions, so by the time it was released the engine was older than other titles that were hitting the market at the same time. The chap who worked on the camera and collision had more issues - I remember the collision, in particular, was difficult to optimise - and the camera was hamstrung by the fact development of the levels and the camera happened in parallel - the camera should have been nailed down first - but that was a project management thing, and nothing to do with the hardware. The big positive I remember was the speed of the CPU and the fact it had a built-in FPU. We did a lot of prototyping on PC and converting that code to the N64 was easy. I do remember the Partner64 debugging system being unreliable - both the hardware and software were temperamental. That slowed things down, especially during debugging phases.
All in all, I really enjoyed developing for the N64, and really like the fact it has a great catalogue of games, even if the one I worked on isn't :)
I liked looking at the office dev docs. They treated the developers as if this is the first time they have seen 3D. Which was true for some at the time. Nintendo explained all the super basic stuff, like what is a polygon. I find that funny because today how could you work for a AAA studio and not know what a polygon was, but this was the mid 90s and Nintendo's first system to be fully 3D so that makes sense.
They teach what a polygon is is elementary school.
3D fully polygonal games were new for most at the time. Even for experienced PC developers. The 3DFX Voodoo came out in the same year as the N64.
Employing people straight out of school without first clue about anything and training them from the bottom up is a standard Asian hiring practice.
Tetsuya Iida, Sony programmer responsible for PS2 backward compatibility layer:
"I had no real electrical engineering skills to speak of whatsoever and I didn’t even know how to boot up Windows 3.1, let alone how to write any programs. Even now, I can’t help but wonder what people at Sony saw in me when they decided to hire me. Luckily, I got the chance to learn how to program computers thanks to a training program that the company ran. "
@@rasz Yeah, also my guess it the job pool for people who knew how to do these things was basically vary small so they had no choice but to hire anyone and train them. I have nothing to back that up on my part though
NIntendo doesn't make sense because back in the early 90s with the Namco System 21 and the Segam Model 1 you had 3D polygon games running at 60fps. of course you had lot of dsp and other hardware making that happen but all developers knew what a polygon was by 1995-6!!
I never thought it was easy to code for just based on the struggles people still deal with emulating it.
1:18 : I clean, restore, and RGB mod a lot of these systems, and every time I open one up, I look at, enjoy, and appreciate the layout and design of the motherboard. The few chips are packaged so nicely on the board, connected by unique curved traces. It's such a beautiful layout, direct to the point with almost nothing wasted, especially space! I don't favor the system or its games that much (I've played very few games and since I didn't have one growing up I don't have any nostalgia for it) but I absolutely respect the engineers who created the final board layouts.
It's a shame whoever picked out the plastics for the case chose a mix that got so brittle with age. Advice for anyone taking a console apart: when reassembling a screw that goes into plastic, rotate it counter-clockwise until you feel it "click" and sink down into the threads. Then tighten. This plastic is very brittle and it's super important to NOT cross-thread through it lest you break off posts. The plastic's only saving grace is it responds VERY well to standard cyanoacrylate super glue. As long as the plastic doesn't shatter into pieces but breaks off cleanly, chances are a superglued piece will bond stronger than the now 20+ years old plastic.
maanerud are you the guy i keep getting the glued together rgb mods from on ebay??
yep, it's indeed rare to see a PCB with that smooth design, electronic engineers wanted to make it like that and I approve. it changes from the ever-seen angular motherboard circuits.
It's a cool layout, but why they never supported RGB out of the box is beyond me. A real step back from the SNES. Thankfully they went back to it on the gamecube. It's especially weird for europe because here the scart connector was very widespread and a majority of TVs supported it. I remember playing the Playstation over RGB 20 years ago and I didn't even realise what that meant at the time.
@@thegearknob7161 yeah the SNES was fully SCART compliant. But you can mod the N64 to have th RGB out, since the signal out of the ICs is RGB + synchro to begin with. Wire it directly to a SVGA connector and add a jack or RCA conn for audio output.
@@Diamond_Tiara That only works on certain NTSC versions. On a PAL console at least it requires quite an expensive FPGA based board be soldered on to the DAC. There's no excuse for that. RGB Scart was as standard in PAL countries in the 1990s as HDMI is today. Nintendo knew this. They did a version for France with native RGB support but most of them are composite only, for reasons that make absolutely no sense to me. I can't see any cost reduction in not sending out a signal that's already been generated internally through a connector that already has the pins for it.
Officially the PAL N64 doesn't even support Svideo either, but there is a way to modify a NTSC svideo cable to get it to work. So at least there's that.
MVG Monday's getting me through lockdown
I think that it would've been awesome if Nintendo, instead of putting every single game on a cartridge, would have put the games on a cd and put in a cache inside of the console the size of a N64 cartridge. This would've drove up the price of the console by a bit, but it would've given developers more cache space to work with and allowed developers to also gain the benefits of a CD with its cheaper cost and higher storage capacity.
The cartridge was mostly used for copy protection I think. They rationalized it afterwards I believe.
A CD would also have caused loading times and would be more vulnerable for kids.thry actually planed the DD 64 as extension but it never was successful.
With every new console generation there are people complaining about limitations - dispute having way more Lower at hand then with the previous system.
The microcode updates factor 5 did were very impressive, got so much more out of it than the ones that came with the sdk
A lot of devs these days are embracing that, getting more from the hardware then Nintendo would let studios of the 90s.
I played Perfect Dark recently on an emulator and was blown away from the opening video and the first level. Blade Runner vibes
Ahhh to play it again for the first time! I bought it at launch back in the day 😁
Love perfect dark, I have the ram cart with it, soo good. Way better than golden eye, when compared to multiplayer.
Still one of my favorite games of all time
Perfect Dark is really impressive, not only how it looks but how it plays also, you can targer a hand or a leg and you disarm them that way, yes they all pretty much use the same animations but considering in other shooters when you hit someones arm or leg you just hurt them less, Perfect Dark for sure tried to do something new
Yea and has bots or simulants which have excellent AI . I like the other bond game the world not enough for multiplayer also
So, the Stop N' Swap feature from Banjo-Kazooie was actually the result of Rare trying to take advantage of the Ultra 64's high memory latency, since it allowed you to power off the console and swap game cartridges while still keeping data in RAM for a short time. Which means that Nintendo accidentally removed a feature from an N64 game by upgrading the N64!
EDIT: It has been pointed out to me that memory retention after power off and latency are not the same thing
Stop N' Swop was originally intended to be done with the console turned on, much like how multi disc Playstation games can change discs during gameplay. Rare was quickly dissuaded from implementing it, as Nintendo was not sure how safe it would be to hot swap memory that's being used.
@@BrunodeSouzaLino Rare should have just saved data to a memory card and read that data for S 'n' S instead.
@@somebonehead That may have worked on an empty memory card, but probably there was too much data to be passing along for even compression to work well in a memory card transfer. Mem card size is also something that neutered these consoles. It was only slightly better/more reliable than using the password mechanic.
Wouldn't ya know, they still do things like that today. Just look at the Switch Lite!
They shared exactly one byte of data, you can read that up in the recent rare gamer interview with Paul Machacek, size wasn't an issue. I wondered why they didn't use the memory card aswell. I assume they just really liked the idea of data retention in RAM and went with it...
Noobs = the cartridge format was the N64's weakness
MVG = 4kb texture cache, RDRAM, pixel fill rate were the N64's weaknesses
Hm, this really makes we wonder what N64 games would have been like if at least two of these things were addressed, even if the processors were at lower speeds.
all of the above
@randomguy8196 I understand the risks for publishers, but as an end user cartridges were superior to CD's in every way. Not only could they quickly load new information in quickly but, like you said, FMV was nigh impossible. In game cutscenes on N64 games could flow seamlessly into and out of the action and plenty of spoken dialogue and other sound effects could be quickly swapped in and out during gameplay with little delay. I have never once heard a Playstation game pull off dynamic, in-game dialogue as effectively as Star Fox 64, Rogue Squadron, Battle For Naboo, Conker's Bad Fur Day, or Perfect Dark. CD's may have been great for publishers, but they always sucked for players. Level design always suffered heavily on CD games as well, in an attempt to cut down on frequent map switching. Banjo Kazooie and Banjo Tooie would of had severely simplified level design had they been designed for a CD system.
Cheap, massive amounts of storage space is one of the big reasons games have become so damn boring and repetitive. Why bother spending months and months making real, genuine, game content when you can simply add in copious amounts of stuff. That is part of the reason games revolve around a billion pieces of loot to collect, cosmetics to purchase, etc. It is cheap and easy and gives the illusion of content and countless hours of gameplay. There are NES games that take an hour or so to complete that have more genuine content and game variety than most of the games that come out nowadays. They had to make as much variety and unique gameplay as they could because they didn't have thousands of gigabytes of storage space to fill up with cosmetics and slight varients on the same damn weapons and equipment.
He misspoke. The expansion pack had 4MB not 4 kilo bytes
@randomguy8196 Not as much as you think. Super Mario 64 was $50. Sony dropped the price of Playstation games from $50 to $40 around the time of the N64 launch as I recall. Even when they started getting into the larger cartridge sizes, Nintendo 1st party games were usually still around $50. The 3rd party developers games would cost $60 to $70. This had less to do with the medium the games were stored on and more to do with Nintendo's extreme greed. Here is the basic rundown of costs according to a reddit poster that claimed to have once had a contract for N64 development.
Minimum production run: 15,000 units
Production costs Nintendo profits from because you have to go through them.
Nintendo takes an additional royalty fee of $7 each cart for logos, seal of approval, etc.
Packaging runs about $150,000 for 15,000 carts. Manuals, boxes, shrink wrapping. Delivery fees not included.
On a $55 cart a profit of $6 to $7 dollars was made. Nintendo got the rest.
Profit margins for developer on Playstation could be as high as $27 per disk.
_________________________________________
This is why 3rd party games cost so much more. Even the Blu-Rays of the WiiU are a special proprietary format that only Nintendo makes.
Crash Bandicoot has a very linear structure to its' level design. The designer always knows what is coming next. That is a luxury that an open world game doesn't have.
Ubisoft, EA, 2K, Activision, Rockstar, Capcom, etc. They all do it. If Mega Man was a new franchise released today you would have about 5 levels that you would keep playing through over and over again. You wouldn't gain a new weapon after defeating the boss either, but instead a random part that is needed along with others to make the weapon. How is what I described not exactly like Monster Hunter or any number of endless grind-a-thons? For the record, I do enjoy Monster Hunter, but it is a short game as far as content goes, that is artifically lengthened to be an endless time sink.
I’ve never been as amazed by games like I was on the n64. Mario, Zelda etc were total game changers.
I think that's because of the huge jump forward between going from 2d to 3d and then the graphical shift as well. I suppose it would be like if we went from the n64 straight to like ps3 with nothing in between. But either way I am with you on that. Going from original Nintendo and Super Nintendo to N64 growing up was mindblowing.
David Brunell I agree. Nintendo games in the late 90s and early 00s had really engaging stories, sound effects, music, and gameplay that had never been seen before. There are some others on different platforms that were great too like Spyro on PlayStation. All later platforms have been recycling the same types of games with marginal improvements or forced gimmicks (Wii/3DS). I don’t think we’ll witness a leap like N64 ever again.
@@haseebs.7286 There are still improvements to be had from 1.) cloud rendering/computing + 6G internet, 2.) 5D optical memory, 3.) ReRAM & MRAM, 4.) AI tensor chips + cloud AI models, 5.) VR + fovea rendering, 6.) haptic feedback controllers, 7.) super parallel arcitectures
@@aoeu256 yes but still not as impressive to the eye and ear as n64 and first 3d consoles
I remember reading a quote by the CEO of Sony SCEA in the early 2000s where he said the PSX could push more polygons than the N64, in theory, but because of the lack of z-buffer and the various limitations of the RAM etc, it meant that once you factor in textures and AI, if you wanted your game to be playable or actually look good you needed to compromise on that.
Sad feels when he says we're gonna leave it here for this video :(
its only another week till a new one!
I know, it's like 'Aww man, keep going!'
@MultiTarded +1
Would be interested in a Wii U video as well. I remember hearing all this talk about eDRAM or something being the secret sauce of the Wii U. With the few games actually utilizing it to the max really showing it (Fast Racing NEO with the 4k textures and 8k shadows, Xenoblade X with the gigantic world + entire city without any loading times, Bayonetta 2, Smash Bros. with 8 players at once still at 1080p/60fps etc.).
Claiming it's about as powerful as a Vita is wildly ignorant I think, but a video about the Wii U's strange architecture and what was or wasn't actually possible with it would be interesting for sure. Probably a bit niche though.
Poorly optimized multiplat ports gave the masses the impression that it was barely more powerful than PS360, but the few games that really tried certainly proved the contrary.
Also it's the reason why it took so long before we saw accurate low level emulation just a few years ago with AngryLion
And probably why AngryLion still eats your CPU for breakfast.
@@steel5897 They got it a lot faster on a retroarch plugin, i think parallei.
On a good CPU you can play most games in realtime with it.
What? I tried CEN64 recently, it works but it's extremely slow, and I have a beefy machine.
@@Sauraen Thats another attempt at low level emulation. Get the Angry Lion Plugin, there are versions for Project 64 and MupenPlus.
@@Sauraen The fastest implementation of the angrylion stuff is on the retroarch parallel core.
It can run several games in realtime.
I never knew the N64 packed so much compute power... Like, I knew it was powerful, but damn... Kinda curious of what a "modern" developer could do on it, if they had a good SDK...
You should look up Kaze Emanuar. He makes videos about the various ways in which he's been able to get as much performance as possible from the N64
the N64 was even way more powerful SGI Onyx computer that was used to make those games, it used to cost $80k of those ages money. If you look up what SGI Onyx was you'd be interested
Look up Kaze's SM64 romhacks. Some of them almost look like gamecube or even some early wii games. they are legit impressive.
Still amazes me that we had an experience like Zelda OOT on this hardware. So many good memories with the N64. Thanks for this I enjoyed it!
Would love to see your thoughts on programming for things like Saturn and Dreamcast!
In this matter, the Saturn and the Dreamcast are VERY different beasts. The Saturn was notoriously hard to develop for and Sega did everything in its power to avoid doing the same mistake for the Dreamcast, so that 3rd parties would be more keen on developing for their system. The Dreamcast is notoriously EASY to develop for, with a very straightforward, down-to-earth architecture, powerful and easy-to-use API and even DirectX compatibility.
@@Liam3072 i am SO upset Dreamcast didnt last. Imagine the indie scene that wouldve blossomed...
Also the shoddy ports on Gamecube piss me off. SADX is a MASSIVE downgrade but now everyone thinks thats how it looked on the dreamcast.
@@Liam3072 Saturn wasn't hard to develop for. Lazy Western Programmers didn't want to learn it.
poo poo pee pee
@@KOTEBANAROT There's still people creating games for Dreamcast so you don't really have to imagine too hard lol
I'm a hardware guy but development on older consoles has always caught my interest. Great work!
It's very rare that any gaming youtube channel makes me want to change the notification settings to "all", but you just hit it out of the park so consistently with your videos. Informative and entertaining, with good editing technique that keeps the viewer engaged. Thanks for what you do MVG.
Great video. People like to say that the lack of a CD drive is what prevented the system from being a major success. But I have always said sticking with cartridge was a better move for Nintendo at the time, and the console's overall hardware was a bigger factor. Good to see my theory get some support.
I always appreciated seeing 30 vehicles on screen at once with no slow down at all on F Zero X...the audio was great but in mono only, and I wonder if that reduction in audio quality was due to prioritising graphics/frame rate.
It was in mono to make it fit into the cartridge. The EXpansion Kit (on the 64DD) has all the music in stereo.
The music is mono in F-Zero X? I never noticed it when playing on a Hi-Fi system...
@@ZinhoMegaman Some Hi-Fi systems have features that can force 'simulated' stereo or surround sound from a console that produces mono.
@@FinancialHealth-ku1ry Them I must play It on my receiver, It always play mono sound on the center speaker, like when I play Command & Conquer, the sound fx is stereo but the music is mono so I only hear the music coming from the center channel. Dolby Pro Logic II does this same thing, mono sounds always goes to center speaker.
I remember getting disappointed even back then considering how F-Zero X was so simple in terms of graphics. N64 never truly felt like a generational leap for me.
another high quality video, thank you for making all of these great content
When he doesn't make them!? From this point that's all I expect from him.. Mr. Quality Man..
This makes me incredibly curious how developing for the N64 would work today. I remember reading somewhere that Nintendo had newly hired programmers working with the N64 as late as the Wii era to test how capable they were. I always wondered what kind of neat tricks they'd be able to do on the old but familiar hardware now that we have a better understanding of player's needs and how 3D games can work, and also given how games nowadays are considerably better at optimizing computer power.
RSP is comparable to x86 SIMD unit. There is a dude (giovannibajo) with a project to port Dragons Lair to N64, he claims to have h264 running on RSP at 18 FPS.
Lots of hacks and even music roms are available, some decent homebrew s can’t be that hard
I liked your video :)
Definitely a comprehensive overview of the basics for some of the challenges.
Good to see people are still interested in this topic!
Ah, nothing like getting up too early for work and seeing a new video uploaded 28 seconds ago! Cheers and thank you for continuing to put out content when we need it the most!
Very interesting. I do not remember having read or heard at the time this kind of criticism concerning the N64. About the Saturn, yes, it was even a constant complaint, but not the 64. Thank you for this information.
Wow just found this channel and have to say I really like the technical breakdown of different consoles, their capabilities and shortfalls and all that. Great stuff 👍
7:01 4 kb RAM expansion. Don't you mean 4 Mb RAM expansion ?
Sony be like " So we have this PS3 architecture 8 cores and a whopping 512mb/256 of shared ram and here is the the manual *hands bible* good luck"
Devs: what teh do we do with this shit, HOW DO I FREAKING CODE!
*7 years later*
Devs: finally I get it now
Sony: introducing PS4 with X86 system that would be good for the developers because they suck our ding dongs with the PS3
Devs: *cries in happiness*
Also devs: *cries in sadness* all those wasted years were for NOTHING!
The Xbox 360 was originally planned with 256MBs of RAM, But Epic Games conviced Microsoft to go with 512MBs for Gears of War.
As Gears looked incredible when it came out in 2006 and didn't need 1GB of RAM for that.
Microsoft had to choose between 512MBs of RAM or HDD by default
Funny because the N64 was going to be a CD based system and Nintendo had Sony help designing it. But Nintendo decided to scrap that for cartridges and Sony took the idea and what they developed to make the Playstation.
I absolutely love these videos. No fluff, and all the information delivered in an approachable manner yet never dumb-ed down.
no fluff is seriously understated, more content needs to be straightforward like this
Please create a playlist of videos like this. 10/10 work man.
Love this stuff. Helps make sense of things I went through without knowing why when i was growing up with these systems.
I really enjoyed this. I'd love a follow-up deeper dive into some of the optimisations Rare/Factor5/etc used and perhaps how today's retro-coders are using modern techniques to make the most from the hardware.
>perhaps how today's retro-coders are using modern techniques to make the most from the hardware.
There isn't much n64 brew stuff these days
I'd love to see an interview of Factor5 covering all their work. The N64 would be just one chapter of their history.
@@christuckwell3185 they did a few really interesting interviews for ign
@@christuckwell3185 yeah there's a good interview out there about Factor 5's cancelled Dragon flying game for the PS3. I enjoy reading interviews about failed projects and development hell. You learn more from them :)
Hey mate, loving your content - just seems to get better and better.
Thank you for this technical video MVG, I can't get enough of these!
Great video! And great portrait lighting also!
MVG: N64 was hard to code on
Sony: *Laughs in playstation 3*
Sega: Laughs in Sega Saturn
Atari: Laughs in Atari Jaguar
@randomguy8196 I would really like to see one on ps2 as well. The spectrum of graphical and performance quality was huge on that system too across games.
@randomguy8196G Dam-it, I hate vector processors!
A very interesting and very well documented insight into the hardware. I would say regardless of latency it was still a much more powerful system, 4Kb can be worked around easily but it requires alot of space on the media format, which the N64 cartridges didn't have - alongside unoptimised SGI microcode - and Nintendo's intolerable control over what developers where allowed to do really shot themselves in the foot.
On the downside, it would have meant that the overall hardware would've been more expensive than what Sega was offering for their Saturn at $399. Could you imagine how much it would cost to buy an N64 then with a built in disc drive?
Great and insightful video. It's really interesting to hear all this year's after it was out.
One thing everyone should watch are Chris Seavors playthrough of Conkers Bad Fur Day (lead on the project) with some of the other developers. Some really interesting tidbits in that!
Fantastic video!!! Super interesting stuff, please do more in this stye!! Would love to see some code examples tried as well.
I am not sure if it is possible but I would love to hear you talk with Julian Eggebrecht the former President of Factor 5 on Nintendo development on the N64 and GameCube.
yes that is my dream!
That would be amazing!
nintendo 64= wow, i am so complex
sega saturn = hold my beer
From Wikipedia: "The Saturn has a dual-CPU architecture and eight processors." 😲
You make complicated discussion, very interesting! I also lovr the music and presentation of your videos!
These are my absolute favorite videos you put out. Nobody does a better job on the subject of retro hardware. Great work, keep it up!
Regarding the painful 4k texture cache, non-3D games have a way around it, in theory. You can simply render on the CPU and blit pixels to the framebuffer. I think it's called framebuffer poking on other platforms. This is used in a limited fashion in N64 games to render certain elements. The red dot in Pokemon Snap is a fairly famous example. But the only commercial game rendered entirely on the CPU was Namco Museum. A number of homebrew attempt this technique, including a Flappy Bird clone and some other stuff. But one of the more interesting projects is 64doom. A port of Doom to the N64 that renders on the CPU and blits directly to the framebuffer. github.com/jnmartin84/64doom
Overall, the N64 suffered from severe bottlenecks. There's no point having fast access to the cartridge or a lot of RAM if you're constantly stalling trying to get to it. This is the root cause of rampant framerate issues on the N64. I remember reading that Factor 5 had to get very creative to render Rogue Squadron without the framerate tanking. Devs had to find ways to render while minimizing fetches from RAM, because fetching anything from RAM destroyed performance.
Doom64 makes a lot of sense being rendered on the CPU since it's a port of the Doom engine from over in PC land, which predates hardware accellerated 3D graphics (and indeed PCs of the era did not have the hardware accellerated 2D graphics that consoles did).
Without getting into too much technical detail, Doom did not use triangles for geometry, but was rather built around using a BSP tree to figure out which walls each column of pixels is projected to. This technique has severe limitations (you can only have vertical walls and horizontal ceilings and floors, and only one floor and one ceiling for any given sector - no two floor buildings here.), which is why it was replaced by using triangles once computers were fast enough in the years to come.
It would also be difficult to rewrite it to use the N64 GPU. For one thing, Doom textures are generally 64x128 or 128x128, which would not fit in the N64's texture cache, so you'd have to go and break everything down into smaller chunks or else greatly reduce texture resolution in addition to turning everything into triangles. In the end, it's not even clear that after all this the hardware accellerated path would be faster!
Besides, the original Doom came out in 1993, and targeted the 486s of the time. N64 had plenty of CPU power by those standards - 3 years later was a looong time for tech advancements in those days. Do a direct engine port, find out it's plenty fast, and call it a day. Heck, Doom actually had a port running on the SNES....
N64 does not have enough CPU power to render anything impressive to the framebuffer. Maybe you can get a couple of 2D layers like Genesis games had.
@@Keldor314 actual Doom 64 game had nothing to do with the original PC Doom on the tech side, it is a completely different engine and completely different game as well. It does not render on CPU either. The one that runs on CPU is a direct port of PC Doom made by enthusiasts a few years back. It can't even run full speed.
@@shiru8bit I was going to to ask this exact question. Did it actually have enough power to do anything with the frame buffer that would be of significance. Thanks!
@@shiru8bit That's pretty hilarious that you believe such malarkey. So according to you, 5 MBs of VRAM, a 64-bit Address Register, and a Dual 32-bit Data Bus, with 60 MIPS & a 73 MHZ Clockspeed, is not enough CPU power to implement a Framebuffer.
Kinda funny, that Sony would end up making same mistake with the PS3, 10 years later.
they stated many times they made it intentional hard so you could see graphical jumps during the generation. ps3 was planned as a 10 years console from the beginning. on 360? this thing basically maxed out at gears of war in 2006. after that there werent many jumps. on ps3 though? god of war, killzone, beyond two souls, gran turismo...it was leagues above anything ive seen on 360
@@Axtmoerder I've heard Sony's Ken Kuturagi say this in interviews, "We made our PlayStation intentionally difficult to create games on". As a consumer I just find this incredibly stupid and it makes no sense. The number of shit games with bad frame rates I had to sit through in the consoles' early years... I'm glad that design mentality is a thing of the past
Odd, it sold the most games..................?
@@Axtmoerder The 360 had plenty of great looking games.
Halo 3, Halo Reach, Fable II, Forza motorsport 3, Gears of war 1,2,3.
To name a few.
@@Axtmoerder at the cost of gameplay
I love videos like this that really give us a technical deep dive on these old systems. It's so interesting to find out what went wrong.
Love these technical look-backs mate, keep ‘em coming 👍🏻
I was going to eat right now, and had no idea on what video to see during lunchtime, and all sudden, notification poped up! Thanks!
Û7ïï
Even if it's nice now that games are quite "uniform", so it maters little which platform you get it on.. there was something special about the vastly different hardware, games and ports, how they could be even completely different games on the other systems. The graphics were also nothing alike between the systems, made each console feel more unique.
Just found your channel, this is my third or fourth video. Banger channel dude, I find this stuff really interesting but I only have a passing knowledge of the tech. You do a great job of explaining the hardware and software. Can't wait for video I watch next
Hey, thanks Modern Vintage Gamer... This video, and many of your other videos remind me how crazy the "good old days" of game consoles were. I was mostly a PC gamer in the 90s and 2000s, but I had some experience in some consoles in the 80s, 90s, and 2000s... But it's very interesting to get history and insight on topics I only know a little bit about
This reminds me of the situation with the atari jaguar, and subsequently the ps3, a superior console which was way ahead of it's time, it terms of the technology it was using. The architecture however, was subsequently incredibly difficult to program for, as there wasn't a programming standard, or a benchmark to base it against, as 3D technology was still relatively new at the time, when the N64/ Playstation was released, but the playstation had net yaroze, and a very developer friendly approach to programming its games.
Don't forget about the Sega Saturn too! It was also hard to develop for..
Same with Amiga. Only once the ST started to die off did we get Amiga native games. Look at how bad Xenon 2 looks on the ST vs the Amiga. That was an Amiga native game ported ot the ST.
@@kenrickeason that's a different story, the main problem with the Saturn was a lack of native 3D rendering, so it was hard to code 3D games but probably the best console for 2D
I have mixed feelings about the PS3's hardware. The Cell CPU was good as doing GPU-esque parallel math tasks, but as a general purpose CPU the 360s 3C/6T Xenon was arguably better. The initial design pitch for the PS3 actually had two Cell CPUs and no GPU. It would have been a return to the old paradigm of software rendering without dedicated 3D acceleration. We can't predict the future, but as it stands I'd consider the PS3 more of a failed divergence than a forward-thinking design.
"...ps3, a superior console which was way ahead of it's time, it terms of the technology it was using"? PS3 has almost the same architecture as the XBox360. XBox360 was released a whole year earlier. Both systems have real SDKs. I don't believe that ist was difficult to develop for them. The existence of indie games should suffice as evidence.
Its fascinating looking back at that generation of consoles and how unique each system was, with both Saturn and N64 only seemingly unlocking their potential right at the end and it's a bit of a shame we never quite got to see what they really could do.
While on lockdown I'm replaying many from that generation and I have to say the Saturn has outstanding picture quality for the time with its rgb setup and the few games which support its hi-res mode and of course the 4mb ram. The N64 is somewhat disappointing looking back with its forced AA and complete lack of RGB (something luckily we can fix today to make a huge difference). Overall all 3 have some truly amazing and quite unique games and a variety that we often lack in today's AAA space
It's almost like saturn designers were afraid about the motion sickness of 3d games and stuck with the 3d (or sprite scaling) that was popular in the arcades at the time that favoured racing, fighting and on track flights.
The gaming industry today is nothing but delays, DLC, politics (I'm not joking), censorship, and long download times.
@@FoxUnitNell I think that was more the limitations of the hardware mainly due to using quads. That being said when the Saturn combined its 2d and 3d capabilities we got games like Panzer Dragoon Zwei which would have been impossible on the Playstation due to it having to render everything in polygons, where as Saturn used its Infinite plane engine to draw huge floors and ceilings well beyond what the competition could do.
@@lucasn0tch *yawn* I love retro gaming too but acting like there isn't lots of new amazing games released all the time is such a boring, jaded take.
@@marcelm2 I wasn't implying there aren't exciting games, but I was saying the games always advertised by Sony Interactive Entertainment outside of Asia are just plain unattractive to me. For example, in Taiwan and South Korea, games such as Trails of Cold Steel IV are advertised very heavily, while in Europe and the USA, Western games get heavily promoted. And let's not forget that Sony is the master of forced censorship (cultural Marxism) in games (even M-rated ones!)
thank you - i love when you make videos on the n64! appreciate your hard work and sharing with us
Love of gaming, vast knowledge of console history, great editing, and, most impressive of all: understanding and sharing of underlying coding in such... very happy to subscribe 😃
Interesting how two generations later Sony made a very similar mistake
You mean one generation later. The PS2 had little VRAM, and clever developers had to rapidly swap in from main RAM. Between that and the VPUs, it was arguably even more challenging to wring the most out of than the N64... the only console harder to develop for (at least for 3D) was the Saturn. You needed someone at Jon Burton levels to get good 3D performance out of the Saturn.
Ps2 sacrificed capacity for high bw edram...it was a gamble that did pay off even with sacrifices
@@MrInuhanyou123 That's the point, there were tradeoffs similar to the N64. EDRAM/ESRAM can be good if it's used in addition to a powerful conventional configuration (Xbox 360) but it can be a detriment if it is used to make up for other shortcomings (Xbox One / DDR3). If you were a very talented developer without major time or cash constraints you could make the PS2 sing pretty good but not as good as a more conventional Xbox (original). Even the older Dreamcast with its more conventional layout (and less total RAM) often outshone the more powerful (and more expensive) PS2 when it came to textures and AA. Even early titles like Soul Calibur looked quite good. The PS2's main advantage was that (again in the right hands) it could push a lot of polygons. Not as many as they tried to claim initially, of course... in an actual game with advanced special effects, decent textures, AA, etc the actual triangle count wasn't that epic. Meanwhile Sega actually under rated the DC. Developers were wringing out 5-6 million polys even with all the bells and whistles turned on.
Don't get me wrong, the PS2 was still overall more powerful, and could do very well with the right developer (especially late in its lifespan)... but I think they would have had better results with a more conventional layout, especially for early games and smaller developers. Side note: My favorite example of "help I'm out of VRAM!" was the port of Grandia II to PS2... they had to turn stuff off when you used a video-stream-overlay spell.
@@AlexvrbX xbox one used esram which is not as fast as traditional edram for higher capacity. Not exactly same situation. I think ps3s unique traits is more applicable to the n64 comparison since it truly hobbled multiplatform development( of course not to as drastic as n64 which barred even making games of specific types)
@@MrInuhanyou123 It was still quite fast, and provided a large bandwidth boost. Had they had used it in conjunction with GDDR it would have been purely an asset. As it was, they were using it to help make up for the shortcomings of a DDR3 setup. It was barely good enough, and required a TON of effort on the part of devs to reach the kind of bandwidth you got out of the PS4's GDDR - and even then it still could fall short, depending on the game/engine in question. Of course it didn't have enough raw power either, since they went with the smaller GPU. They fixed their shortcomings with the One X.
PS3 is actually a more conventional setup in terms of graphics and memory bandwidth. The Xbox 360 was actually more radical with the daughter die and EDRAM, plus unified main/vram. The CPU side of things is a different story, and Cell was definitely a handicap. Although the PPC chip in the Xbox 360 was pretty strange too compared to the original Xbox. It was a triple core hyperthreaded PPC with custom VMX vector processors, and it was an in-order CPU. Not as bad as Cell, but still harder to harness fully. Anyway, that's all getting off topic - the video and general conversation was mostly revolving around graphics and associated RAM / bandwidth. In which case, the 360 was the strange setup.
Side note: I wonder if they aren't making a similar mistake with the next gen consoles, not packing in enough RAM and leaning on the SSD to stream in hardware-decompressed assets. I guess since both MS and Sony are taking a similar approach, it won't matter. Devs will just have to deal with it. Either way this might benefit PC games in the long term, finally force devs to require decently-fast SSDs and actually tax the drives a bit.
(From what I can tell by a precursory scan of the documentation) One big issue with the texture cache is that it wasn't acutally a cache, but a dedicated memory space. This means that the program had to manage copying in textures as needed "by hand", and in general, you'd have to copy the entire texture even if only a couple texels are actually used. Also, the texture unit could ONLY access that 4KB texture memory. If you wanted a texture, you had to copy it over there.
What this ultimately meant is that you would have to sort all your triangles by texture when you rendered them, and of course, the more textures you used in a scene, the more time would spent copying textures and not drawing pixels.
Partial transparency/alpha was also made more difficult by this arrangement, since rendering it correctly requires that the (transparent) triangles are rendered starting with the ones furthest away and rendering the nearer transparent triangles blended on top of them. Remember how we also wanted to render the triangles sorted by texture to avoid thrashing texture memory? Uh oh! Thankfully textures with pixels that are either opaque or else completely transparent (such as trees) don't need to be rendered in back to front order - the z-buffer can take care of this case.
aaaauuhhrrgggg mah gawd, the stupidity! I would try to change job if faced with something like that.
imagine if it was a proper cache with weighted ejection rates and everything.. managed by the hardware itself..
The Texture Chache issue was debunked by Homebrewers 2 years ago. The N64 used 4 Dies and had 32KBs on Each. But it required A Dual Thread with the NECVR4300 CPU and SGI RCP Graphics Chip, but MANY developers weren't used to that method. So they just resorted to Storage Capacity on the Cartridges and relied on N64's EXTREMELY primitive software tools including Open GL, and Run Scope. The Open GL Tool for N64 was limited to just 4KBs of Fil Rate without use of the main assets of the SGI RCP.
Love your videos, very informative. Keep on keeping on! Thanks.
wicked video mate, really enjoy these old school analysis of retro consoles
This is massively interesting. Thanks for sharing all this N64 info with us.
Good video! Tons of knowledge. Who knew the N64 was like that. I knew that Saturn was hard to program, or get the most out of, but didnt know the N64 has those issues.
I don't understand everything at once, but I love your vids. Super interesting. Keep it up!
7:30 I immediately thought of Banjo Kazooie's Stop n Swap. It's kinda neat Rare was looking to change a flaw in the system into an added feature instead
Games from Rare and Factor 5 always pushed the N64 to its limits and sometimes beyond them, having said that they were the best games on the system IMO.
I own Diddy Kong Racing and can confirm. Rareware games look AMAZING on the N64. Even to this day it still holds up quite well. I need to find more Rare games
I remember noticing right away that DKR karts showed the wheels actually steering and the characters looked a lot more "real." Aged 10 I didn't know how any of this worked in the slightest, but we all _knew_ DKR looked way better than Mario Kart.
It has a more independent feel to it it’s more advanced than smk for sure and just more fun
Pretty sure the karts in DKR were pre-rendered 2D sprites for each angle, that would be why they looked so good
By what i saw in the N64 development manuals and stuff, it was easy... as long you used the standard nintendo microcodes.
After the PS1, both nintendo and sega rushed to make an "Open GL like" API so developers didn't needed to deal with the hell behind the curtains.
You lost some performance and flexibility in the process, but not every game company have a genious able to deal with the RCP/SCU bullshits.
3D rendering is really hard, so it's the logical conclusion we're gone from microcode hacking to universal APIs right up to the current day where almost everyone except really big studios (even some of those) use one of the two big premade game engines (Epic or Unity). Less money spent on expensive programmers, more on creative staff.
@@theshinken Sony got it right out of the gate, by basically copying the best API of the time and designing the hardware itself to be friendly with it.
But then nintendo and specially sega had to rush something to compete.
The sega saturn techdocs are quite hilarious because they explain EVERYTHING about 3D graphics from the basics of basics, including "how to use lightwave to model a low poly monitor/car".
But this was needed given most devs were coming out of the snes and genesis.
@@dan_loup I felt like there was a lot of competing APIs the time. Everything was so new. Given Nintendo partnered with SGI. I would think their solution is heavily biased from what SGI was doing at the time. It's amusing to say Gamecube was a more traditional 3D system when at the time of the N64 I don't think I'd say anything was deeply ensconced as the 3D machine.
@@Jerhevon On PC space there was quite a shootout brewing between DirectX, Open GL, intel 3DR, apple quicktime VR, proprietary videocard APIs like GLIDE, S3 metal etc..
Consoles on the other end had to deal with much slower CPUs so actual graphical APIs didn't looked like the best of the ideas, until sony basically implemented OpenGL in hardware on the PS1, and everyone had to run after.
so, for the N64 there was no API whatsoever? you had to deal with the HW code to create an engine from scratch?
Excellent video, explains fitrates well. Satisfies a question in my head I've been thinking about for years regarding Hram and expanding the 4mb with Hnd functionality.
Thank-you for making this video. I shared an N64 with my brothers. This video clears up a few questions we had. I could never understand how a machine with 4 times the RAM of the PS1 had lower res textures. Now it makes sense
God I love your channel, so many good memories with N64 in 1998 when i was 16. Banjo-Kazooie was as a true masterpiece
Imagine if somehow it had 64K of cache and 64MB of RAM. Like a N64+ that came out a few years after initial release. That would be mind blowing for the consumer with high potential textures, and larger levels. But a nightmare for developers to make a game that plays on both consoles with 2 texture packs.
It would still have the laughable 4MB cartridge size , and the compressed to hell sound thats also dependent on the CPU .. unlike even the PS1 which had an impressive sound chip and didn't waste CPU cycles for sound
@@aceofspades001 with large enough Ram you can just stream the sound from it at decent quality. so it would be more possible to pre generate the music at like a level transition. this would waste barley any cpu cycles.
(yes i am aware of how absolutely bat shit insane this solution sounds).
Very informative as usual. Love your channel. Thank you 😍
Hey MVG, did you ever create or help develop homebrews for the N64? I'd be curious to know or see you try to have one working from source code in one of your videos.
i don't know anything about ganedevelopement or programming. still i love these videos. very entertaining.
Love your videos man! I'm always craving to write some code after watching your vids. Back to working on my NES emulator :)
Most of what I learned about the basic components of PCs came from a book on building PCs that my aunt got me at Barnes & Noble when I was five (so 2005~2006). I recall there was a chapter on Rambus RAM, and that it was super expensive and probably on its way out. They recommended the then-new DDR2 instead.
Haven't heard of Rambus since, until today.
1:43 - A 5 step Instruction pipeline means EACH instruction takes 5 stops at clock speed in the CPU to complete the machine code instruction. This is NOT parallel processing that you'd get from multiple cores. You complete 1 instruction per clock cycle, with 4 instructions processing in line behind it.
Pipelining is used to increase processor clock speed by splitting more complex instructions into multiple steps.
For comparison, the Pentium 4, released in 2000, had a 20 instruction pipeline to increase nominal processor clock speed (GHz). Long pipelines can be a major weakness. If you choose to go left instead of right (branching), the Pentium 4 might need to throw away the last 19 instructions, and then you'd have to wait 20 clock cycles for the correct instruction to be processed through the whole pipeline.
AMD focused on performance over marketing, and Intel gave up on the P4 giant 20 step pipeline in 2007 (high heat, mixed performance), dropping down to 14+ stages in current processors.
9:32 I never had an N64, but that sure looks familiar...
Midway Games: "Hey man can I copy your homework?"
Polyphony Digital: "Fine, just change it up a little so it doesn't look like you copied."
Boss Game Studios
made the game, Midway, that trash company did not have the technical skill in their internal studios to ever pull a game like that. A lot of Boss Game Studio devs went and joined Turn10 and made the original Forza
Great vid...Wish u would make a vid on skylander tech...how the portal the figs and other stuff works
Your videos are the best MVG, I really appreciate all the research and effort you put into your content.
I didn't really do much on it, but I can tell you my video game development class in college had a Doctor V64.
Explaining pipelining as running multiple instructions at once is quite an unfortunate choice in my opinion.
While technically true, it suggests the false idea of executing multiple instructions per clock. That is not the case. Pipelining splits instructions that would take too much time to process at once (forcing you to use lower clock speed) into smaller chunks (5 in this case) that complete much faster. But all that means is that you don't need to wait for instruction A to finish before starting instruction B, you can start B as soon as block 2 of A is executing (and C as soon as blocks 3 of A and 2 of B start). You can't start A and B at the same time.
And you must also make sure that A and B do not depend on each other, or you'll stall the pipeline
@@halofreak1990 Not even that on these old MIPS CPUs, no interlocks meant it was on the programmer to avoid dependencies in branch delay slots and load delay slots.
N64 is VLIW Latency Language exactly like Saturn. But the difference being, NECVR4300 is a single Wafer CPU Chip, SH-2 is a Double Wafer Chip Pair.
@@segaunited3855 RISC, not VLIW.
@@espfusion VLIW(Very Long Instruction Word) is Latency Language or Assembly Language writing. RISC(Reduced Instruction Set Computing) is an ISA(Instruction Set Architecture) . Saturn's ISA is RISC. N64's is MIPS(Million Instructions Per Second), but both use VLIW Latency Language for Programming.
N64 is capable of up to 60 MIPS Computing Instructions. Saturn is maxed out at 50 MIPS Computing Instructions.
All 5th Gen Consoles used C Language Assembly. It was just easier to do on PS1.
Extremely interesting as always MVG! Thanks!
Great video! waiting for the saturn video!
I was blown away the first time I seen Mario 64
One word: Cartridges. They were expensive and even the largest ones (64MB) had less than 1/10 the storage capacity of CD's (660MB), so no one wanted to deal with them.
ikr? I mean what the hell was N thinking
@@Killaswarm N64 cartridge capacity was often listed in bits, not bytes. There's 8 bits to a byte, so 256 Megabits was only 32 Megabytes.
Someone mentioned Crash, this vid was very interesting: th-cam.com/video/izxXGuVL21o/w-d-xo.html
but the non-existent loading times were AMAZING
It's always a pleasure to see a new video! Thank you
Love the channel. I can see I'm a year late to post but I know it helps with algorithms and your work is great!
I member playing Mario 64 xmas day 1996, what an impression that left on me! Your vids are so insightful, brilliant man!