So, what *were* the causes of the delay of the N64?

People cite old Resident Evil and Silent Hill as games that were not actually good when released and claim that fans saying they were good have "nostalgia glasses." I feel like this holds up to old GTA way more. OId GTA games, to me, are almost unplayable. I couldn't even imagine what GTA would have looked like on an N64.

 

I'm not a fan of GTA. I like the 1 and 2 2D games more than any 3D GTA, but Body Harvest is just too cool and wasn't Body Harvest exactly that?

 

I actually like Blue Stinger

 

A long time ago, I was talking to one of the engineers who worked on the N64 hardware development. It was a long time ago, but this is what I remember from the conversation.

The original test platform (before there was any hardware available) was built by taking one of the existing SGI machines and gimping it in firmware and microcode to try and match the projected capabilities of the N64 chipset. I think it was a R4000 SGI Crimson with the (original) Reality Engine graphics - except running with the caches disabled on the CPU and special degraded ucode running on the RE that slowed everything down (and disabled some features completely).

In gross terms, it was a pretty good performance match for the silicon that was finally delivered - but since it had a completely different architecture it handled very differently in edge cases - and game developers love to drive the hardware to a point where it's operating in an edge case. In this case, the biggest difference was in the memory subsystem - the SGI workstations had a very wide memory data bus - so even running with just the on-chip cache you could refill a cache line in just a few memory cycles. The N64 used the old (9 bit) RamBus memory - this had extremely impressive peak bandwidth (especially for the time), but also suffered a very significant first-word penalty. This was compounded by a number of other factors - firstly, the N64 used unified memory, so every single memory access had to hit the same memory array and secondly because that old RamBus memory could only have a single memory page open at once. These two combined to make the N64 very sensitive to memory access patterns - a characteristic that was completely absent on the initial test platform.

This quickly became obvious once they got the chip taped out and made the first iteration of the real devboard - this was basically the same hardware as a retail N64 but without the PIF and with a bunch of DRAM in place of the ROM cartridge. The initial release also had a charming little hardware bug that very occasionally corrupted memory reads (including instruction fetches) and would result in random crashes even if your code was perfectly good. This was rapidly fixed once it was pointed out, though (and the test suite modified so that it replicated the conditions that induced it.

There was also a running battle between the people developing the ucode and the game developers - the ucode people wanted to make it feature-filled and highly accurate - the games developers just wanted it to be fast and good enough. The initial compromise was the "fast3d" ucode that was shipped in the first developer kit, but with time even more stuff got cut from it - most of the shipped games used the version that had no culling, no near clipping plane, no texture correction and which "clipped" polys to the viewpoint by simply discarding anything that had any of it's vertices outside it. This could give markedly ugly results if you weren't careful, but it was a lot faster.

The other sad thing was that SGI had a stock of the GIO bus boards that installed in the Indy, because they were the ones doing service support on it - but due to the terms of the agreement with Nintendo they couldn't sell them to anyone without Nintendo's approval. After the KMC system became available, the demand for the original dev board dropped pretty much to zero, so they never got used. Since they couldn't be sold - or even given away - they all got crushed.

 

I was never a fan of GTA 1 or 2, but I love the 3D ones; GTA 3, Vice City, San Andreas (still my favourite!), and GTA V. I never liked GTA IV, as to me it was no fun, it felt like a technology demo with no effort put into making it enjoyable.

And for me, seeing GTA 3 on a mate's PS2 for the first time was one of those very rare, stop-and-stare-in-amazement moments, like seeing Knightlore (ZX Spectrum), or Doom (PC) for the first time.

But no, I didn't much care for GTA 1 on the Playstation. But you have to remember that back then, city based driving games were much simpler (and almost never in 3D), plus GTA was different in that it allowed you to cause chaos (steal cars, run over predestrians, kill coppers, etc), and at the time my only console was an N64, so I was feeling the gaming drought caused by the long gaps between good game releases. So GTA was a bit of fun to pass a few minutes for me, but I'd never have bought it if it had come out on the N64, but no doubt millions of others would.

Body Harvest was and is fantastic! And yet neither Rockstar nor anyone else has tried to make a similar game. And neither has any modder (or if thereare such mods, then please let me know, as I've never heard of them). I mean, any GTA 3 onwards game could be modded to have invading aliens, various armed and unarmed vehicles, and if the modders were dedicated enough, then they could change the buildings, and more so the buildings' textures, so that the same map (with changes) can represent different time zones. How about if Liberty City were shown in five time zones, say 1928 (Prohibition era), 1963 (hippies and the beatles era), 1988, 1999, and 2099? The middle three dates wouldn't need much alteration to the city, mainly just textures for shops and factories, with vehicles and NPCs' clothing being specific to the era. It would still be a *huge* job, making all these changes, but the end result could be maybe the best game mod of all time.

That's very interesting, thanks! Apparently the N64 was very difficult to program, with the two options basically being either use the official Ucode set, which wasn't optimized at all, or spend lots of time and effort learning (very) difficult low level coding (which presumably means you can't use much of the official development kit either). Evidently most companies, except Rare, did the former, judging by the way most N64 games didn't look much better than the Playstation's games.

To add to the N64's other flaws, such as the tiny texture cache, the limited storage space of the cartridge format, and the lack of a dedicated sound chip, there's also the fact that the N64 is apparently extremely slow at executing code directly from the cartridge - from what I've read you're much better off [when programming an N64 game] if you treat the cartridge as a hard drive, and instead of running code directly from a cartridge, you first copy the code to the RAM and run it from there. This limitation probably didn't hinder too much, as most well written games were probably compressed anyway to fit on a cartridge, so any code block would have to be unarchived and executed from RAM anyway, but it was another limitation for the developers to have to work with.

Mind you, you have to wonder how badly did the games developers really suffer due to the limitations of the cartridge format. I mean, they still managed incredible feats in what they put into cartridges, and the huuuuuge amount of extra storage space on the Playstation's discs were (I think) usually filled with CD audio or FMV (I could live without the FMV personally, I much prefer cut-scenes to be done in the game's engine in real time, as it doesn't take you out of the game, I think).

 

Re: Resident Evil, and Silent Hill, I never saw the appeal in the Resident Evil games (well, I loved RE4, not played RE5 or RE6), they were just (to me) boring games with the odd, in-effective jump-scare, with an infuriating save system, too limited ammunition, and uninteresting puzzles. But even though Silent Hill was very similar gameplay-wise, I found it to be fascniating. Yes, gameplay-wise it was hugely flawed, but the atmosphere was incredible, and I followed the story through and completed the game. I also played (and completed) Silent Hill 2, which was even more atmospheric. I've not played Silent Hill 3 or later yet. The people behind the SH games (well, Silent Hill 1 and 2, at least) really understood fear a lot better than the RE people, I think. In SH you rarely see anything bad, it's mostly hinted at - and whatever you imagine in your mind is more scary than what you can see. I wasn't scared with Resident Evil, not because I'm so brave (I'd be terrified if RE were real, and I was in that situation) but because I could see the dangers and that somehow lessened the fear, but with Silent Hill the scares were mostly just out of sight, which made me imagine all sorts of things.

It's like the Japanese movie about the video tape that when you watch it you die a week later - the American remake is rubbish because you see everything, so you're accustomed to all of the horror and nothing throws you. But the Japanese one is *much* better paced, as you see almost nothing frightening, it all takes place off-screen, and then at the end of the movie, that one short scene is *hugely* effective at shocking and unnerving you.

 

That's basically always true of ROMs once the CPU clock speed gets over about 10MHz, though - it's hardly a specific architectural failure of the N64. The basic problem is that running flat out the cartridge bus could run at about 25MHz (that's for sequential reads) and is 16 bits wide. The CPU was clocked at about 93MHz and uses an instruction stream that's 32 bits wide (yes, MIPS III is a 64 bit architecture, but it uses 32 bit instructions) - so basically you could theoretically consume the data about 8 times faster than the cartridge can deliver it.

In practice there are some other bottlenecks (like the system bus - also 32 bits wide, and clocked at 66% of the CPU clockspeed), and the CPU has caches that reduce the required bandwidth, but if you try and directly run out of ROM you are going to end up stalling the CPU a lot of the time. You also have to consider that the other machines on the market at this point used 2x CD-ROM drives that could deliver about 300KB/sec - so even if a cartridge interface that can deliver a peak rate of about 50MB/sec is slow compared to the CPU, it was still several orders of magnitude faster than a CD.

Overall, the fact that you could execute code in place on the cartridge has to be seen as a nice feature, but not something you wanted to make any extensive use of because the performance was so much poorer than running out of RAM.