how bad a limitation was the 4k texture cache in N64 ?

[Megadrive1988]

one of Nintendo 64 many limitations was the tiny 4k of texture cache. I think this was small even for the time the hardware was developed, 1994-1995.

look at the unreleased 3DO M2, it has 4 times as much texture cache, and it was developed at roughly the same time N64 was.

I notice with realtime screens of M2 in-development M2 games, textures are somewhat better than that of N64 games ( though not far better ).

Also, if you were calling the shots, how would you redesign N64 hardware to be somewhat more powerful, more capable, with fewer bottlenecks? i.e. you can't say "well I'd design what they did with Gamecube which fixed N64's problems", gotta keep it to within 1994-1996 timeframe.

 

[fearsomepirate]

Looking at the actual games, it was a very, very bad limitation. You could get around it by using lots of textures, but then you run into other problems. If you use 4x as many textures to simulate 4x the resolution, then you're doing 4x the memory reads, which could cause you latency trouble. Depending on what you do, you're using more polygons or introducing additional code complexity to put multiple textures on a polygon. So unless a programmer was going to really stretch himself, it was just much easier to use very low-res textures than to try to do something clever...and that's exactly what happened.

What would I do? Well, I would have axed the 64DD instantly, allowing the company to spend the money sunk into that pit on...

1. 16KB texture cache. Look at it this way; original Doom's textures were 128x128x8 = 16KB. A 1996 machine should have been designed to at least use Doom assets without any problem. 128x128x8 textures are perfect for 1996-level graphics.

2. Bite the bullet and spend the extra $20 or so per system for a sound chip. In the standard libraries, sound took away graphics resources.

3. UMA was not a good design choice. 2MB of VRAM and 4MB of main RAM may have been a good option, would have rendered the Expansion Pak superfluous, and would have given the N64 almost twice as much RAM as the PS1. Depending on prices, maybe just integrate all 4 MBs as VRAM.

I'm cool with cartridges.

 

[Squeak]

It was not the size of the cache but rather the implementation. PSone also "only" had 4Kb, and modern GPUs Lv1 cache isn't much bigger, maybe double that figure.

I don't know the specifics, but it had something to do with it not being software transparant (ie self manageing) and/or not enough bandwidth.

Basically you had to fit all the textures for the model/instance into the cache.
With MIP maps, that only leaves enough space for one 64x64 or two 32x32 textures.

Late games in the N64s lifecycle seemed to be able to do a few 128x128 or higher textures per scene, maybe with some clever swapping technique...


For the hindsight improved N64 I would do the following:

- Ship with the 64DD drive as default storage medium. That would mean a somewhat pricier machine but would have a number of huge advantages over cartridge or CDs.
1. Much cheaper medium.
2. Higher capacity (64Mb from day one).
3. Huge savespace for creative apps and games in general.
4. Being able to, later in the life of the N64 make downloadable software an option , and/or vending machines at retailers for writing games to blank discs (like the Famicom discdrive). That would alleviate all problems with distribution bottlenecks of games (just ship printable covers and empty discs to retailers).

- 2Mb VRAM (256Mb/s Rambus) and 2Mb DRAM. Again a bit more expensive but for such a small RAM pool where you can be almost be certain that a fixed amount of RAM is going to be used for screen buffers and textures, you are better off acknowledging that in the design. UMAs only really makes some sense in larger memory configurations.

- Higher clocked hardware, even if that makes the casing look like a sieve (for venting).
The N64 was downclocked because of overheating troubles in the last phases of development. Which resulted in a slightly underpowered CPU and not quite enough fillrate.

- More durable hinge at the base of the analog stick. Would a sealed metal hinge really cost that much more?

- 65c816 for sound, plus SNES cartridge port and slightly upgraded SNES soundchip (32 channels plus software driven ones) for backwards compatibility.
BC would have given the N64 a huge edge over Playstation and the cartridge port could have been used for future enhancements and games in that format, if someone should insist.

- And of course (almost forgot) better texture cache.

 

[swaaye]

I dunno. The hardware may have been flawed, but back then all 3D hardware was. They were just figuring out how to make it cheap enough for consumers. N64 was certainly way ahead of PS1. If only the texture cache hadn't been such a problem. And that RAM latency. And the gimped storage courtesy of carts (I'd still argue for them over a 2X CDROM though!)

Yeah, carts were a bad call. They lost Square because of that, I believe. More storage could've turned the tides in their market success, for sure IMO. People didn't want SNES cart tech; they wanted CDROM or just something new.

And going cheap and chopping out a real sound chip was a bad idea too. But, I believe this system was a full package they bought from SGI. There's an interview with the former President of Sega where he says SGI actually approached them with the tech too. SGI had bought MIPS and the two collaborated to make this console chipset. Sound is part of the RCP's design.

 

[DeadlyNinja]

That reminds me, can someone clear up this issue that's always been troubling me?

I have this issue of Next Generation magazine back from 95 or 94 that talks about the N64, and one one of the question was about using carts. The answer was that by using carts, it allows them to design a system without RAM like the CD based system. What the heck do they mean by that? The N64 clearly has RAM in it despite the cart format. Can someone explain what they meant by that?

The quote's not exact, so I'll go back and dig up that issue for a direct quote later.

 

[swaaye]

There's a RAM buffer for the CDROM in PS1. That wouldn't be needed in a cart-based system. I've also heard it said that carts were fast enough to stream from, whereas 2X CDROM was not really. Factor 5 streamed data off of them (read that in an interview with them).

 

[Mintmaster]

I think it limited graphics a lot more than cartridge vs. CD. Texture filtering was a huge advantage over PS1, but when the hardware also entails a big loss of detail, the texturing advantage goes away.

 

[fearsomepirate]

Carts just were not a huge limitation in graphics. The Doom 2 IWAD, which contained all the level, sound, and graphics data was only ~14 MB. That's a tad large for an early N64 cart, but it does show just how much data mid-90's games took up. Quake 1's pak1.pak file was 32 MB, and although that makes unaltered Quake too big for an N64 cart, that should still illustrate that making a rather extensive 3D game in the mid 90's did not require the hundreds of megabytes CDs provided. High quality music and FMV were the big storage eaters.

 

[phat]

That reminds me, can someone clear up this issue that's always been troubling?

I have this issue of Next Generation magazine back from 95 or 94 that talks about the N64, and one one of the question was about using carts. The answer was that by using carts, it allows them to design a system without RAM like the CD based system. What the heck do they mean by that? The N64 clearly has RAM in it despite the cart format. Can someone explain what they meant by that?

The quote's not exact, so I'll go back and dig up that issue for a direct quote later.

They probably meant that they could run code and access const data directly from the cartridge instead of loading the contents first into RAM like they'd have to do with CDs. The cartridge becomes an extension of the system's physical memory, if only read-only. They would still need some RAM for read-write data, but none of that RAM needs to be used to hold a runtime image of the contents on the transport medium.

 

[Mintmaster]

Carts just were not a huge limitation in graphics. The Doom 2 IWAD, which contained all the level, sound, and graphics data was only ~14 MB. That's a tad large for an early N64 cart, but it does show just how much data mid-90's games took up. Quake 1's pak1.pak file was 32 MB, and although that makes unaltered Quake too big for an N64 cart, that should still illustrate that making a rather extensive 3D game in the mid 90's did not require the hundreds of megabytes CDs provided.

Yup, I'm just pointing it out because a lot of people blame the low detail of N64 graphics in general on the lack of CD.

(And, of course, some think the same will happen with PS3 vs. 360 in a few years.)

High quality music and FMV were the big storage eaters.

Indeed.

 

[ERP]

They probably meant that they could run code and access const data directly from the cartridge instead of loading the contents first into RAM like they'd have to do with CDs. The cartridge becomes an extension of the system's physical memory, if only read-only. They would still need some RAM for read-write data, but none of that RAM needs to be used to hold a runtime image of the contents on the transport medium.

Trust me you wouldn't want to run code off ROM on an N64.

 

[swaaye]

When I mentioned the possibility of streaming data from the cart, I was referring to something Factor 5 said:

http://ign64.ign.com/articles/087/087602p1.html

IGN64: What strengths and weaknesses did the N64 have when porting [Indiana Jones] over from the PC?

Factor 5: The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day.

In terms of weaknesses we fought hard against the fill-rate limitations of the N64. We loved Hi-Res on Rogue because of its crisp look, but the framerate was questionable. So when starting the engines for both Indy and Naboo, the main goal was to get a high framerate in Hi-Res. This meant not using the Z-Buffer, because it alone uses quite a bit of the N64's fillrate.

 

[Droid]

Heh, the thread seems to have derailed into a CD vs Cart debate.

Anyway, CDs appear to have the advantage over carts when it came to distribution. CDs are dirt cheap to manufacture compared to carts, and are quicker to make. This made quite a difference for game publishers if I'm right.

When a game is first release, the demand for it will be the highest (well it's new). So say you manage to sell out your initial stock of copies, when a retailer places orders for more, I heard in the case of CDs they can manufacture them and deliver them within a week, while carts take weeks to arrive. By the time the new carts arrive, a good number of people would have lost interest, either because they got a second hand one for cheaper or a new game has come out.

One solution was to increase initial stock, but with carts being so expensive, there is quite a risk (which publishers don't like). And if the game is a dud, you end up with a bunch of useless expensive carts.

 

[archie4oz]

So say you manage to sell out your initial stock of copies, when a retailer places orders for more, I heard in the case of CDs they can manufacture them and deliver them within a week, while carts take weeks to arrive.

Weeks my ass, more like months for carts. Sony was downright masterful with exploiting CD production this with the Playstation, whereas NEC and Sega were still using the same Shoshinkai wholesaler system for CDs as they were for carts...

 

[Panajev2001a]

When I mentioned the possibility of streaming data from the cart, I was referring to something Factor 5 said:

http://ign64.ign.com/articles/087/087602p1.html

Well, the Factor 5 guy is saying streaming while ERP was saying that you would not want to directly run the code from the cart: Factor 5 probably was talking about moving (while the application was running) data, code, and other important assets in and "out" (well overwriting those locations) of RAM reading chunks of "data" (intended now in the broader sense of just bits) from the ROM cart... all IMHO .

 

[I.S.T.]

and slightly upgraded SNES soundchip (32 channels plus software driven ones)

The two chips responsible for sound in the SNES were designed by Sony. There's no way you could get them onto the N64.

 

[Squeak]

The two chips responsible for sound in the SNES were designed by Sony. There's no way you could get them onto the N64.

SNES and Super Famicom continued to be sold quite a bit after N64 had launched. I recall something about Nintendo having a bought the rights to the chip at some point...

 

[ERP]

Weeks my ass, more like months for carts. Sony was downright masterful with exploiting CD production this with the Playstation, whereas NEC and Sega were still using the same Shoshinkai wholesaler system for CDs as they were for carts...

Yep and this is the real crux of it.
Beause of long lead times an the fact that you paid for the order when the order was placed, plus the relatiely steep cost of goods, and it mad inventory management with carts a big problem. It's largely why 3rd parties were so enamoured with CD, the technical issues were largely secondary for most publishers.

We streamed audio and animation data off the cart during game play, we could have certainly gotten the audio streamed off CD and probbly some of the animation. But we'd have needed bigger internal buffers.

Back to the original question, i was a pretty big limitation, as mentioned it wasn't a cache in the traditional sense it was an explicitly loaded block of memory that was the only place you could render from. It could not be updated mid triangle, so if you wanted a texture that wouldn'y fit, you were stuck with adding more tris and doing more explict loads, which generally led to poor performance.
What was worse was that enabling trilinear split the cache in half, so it was a 2K block of memory for the largest MipMap.

It required thought and some understanding of the technical limitations on the art side to work around.

 

[phat]

Trust me you wouldn't want to run code off ROM on an N64.

I assumed that the cartridge ROM was physically byte-addressable and had latency and bandwidth similar to the other off-chip memory on the system. Are you free to say which of these assumptions don't hold?

 

[ERP]

It's been a long time, but I can tell you we DMA'd data off the cart into RAM buffers, that the bus was 8 bits wide, and extremely slow. I have a vague recollection that the memory was also mapped to the address space, but that we avoided direct access because of the time it took to read.

In the Genesis/SNES days most code/data was on the cart, with the RAM only used for dynamic data/decompression buffers. On N64 the cart was used more like a Read only mass storage device.