N64, fillrate monster of the previous generation?

[Roly]

I was recently reading over the N64's specs again, and as I understand it the RCP (or the RDP block portion) could theoretically draw 62.5 mpix/s with bilinear filtering, and half that with mip-mapping. Even with the poor memory performance, wouldn't 30-40 mpix/s (~1/2 theoretical, and presuming the RDP section was basically 'hard' ASIC so no microcode improvements) have made the N64 the real standout in terms of fillrate in the previous generation? I can't help but think it was perhaps one of the more underutilized consoles, though I never saw Indiana Jones, which was apparently quite impressive.

Also, does anyone have any detail on the bilinear filtering hack that someone mentioned in a previous thread? I thought I vaguely remember an SGI guy on IGN mentioning something about this. Seems like it would have been a useful feature to have a few years back if it saved performance or real estate, though I thought the N64's filtering looked basically identical to that of the Verite, so maybe it was true bilinear just with an economical implementation.

Any thoughts on the N64's hardware, particularly in terms of fillrate, texturing etc. I would be really interested in, though obviously it's not terribly practical information anymore.

Cheers,

roly

 

[duffer]

Although I never programmed the N64, and I haven't read any of the open source N64 emulators that are floating around the net, here's what I've gathered from reading various articles:

Good features:

A much faster CPU than the competition
More RAM
A programmable vector unit somewhat similar to the VUs on the PS2.
A nice clean OpenGL-like API
A high quality rasterizer, with a Z buffer, bi-linear filtering, alpha, mip-mapping, and accurate sub-pixel-positioning of triangle endpoints

But it had several big flaws:

- Relatively slow T & L, so few polygons per second

- A pathetically small texture memory. 1 KB if I recall correctly. And this wasn't a cache, the programmer had to manage it themselves.

- The lack of a CD drive meant games were data starved and cross platform ports were difficult.

- Sound was done in software, on the same DSP that did graphics.

As a result, the N64 games tended to have very few, but very high quality, polygons with lots of Gouroud shading and low-rez textures.

 

[Tagrineth]

You forgot the somewhat fickle but high-quality nonetheless multisampling

N64 was also the first console to support a full 640x480 output IIRC.

 

[KOF]

How about anti-aliasing performance? Obviously, it's one of N64's feature yet I've never seen any game using that. Some programmers are saying it was impossible to implement it in the first place.

 

[Ozymandis]

I thought a lot of n64 games used the edge AA?

 

[ERP]

A lot of N64 games used antialiasing, it supported two modes the faster of which incurred about a 10-20% penalty.
Both methods were very dependant on draw order, and used a single coverage value to weight the final color.

The bilinear filtering used 3 samples instead of four, you can see this if you look at a bilinear filtered circle texture it there it appears as if there are small tris making up the image and protruding beyond the edge.

Unfortunately Nintendo never widely released documentation on the vector unit.

The unit as a whole was crippled by the small texture "cache", and it's memory system.

About the only thing that didn't starve for memory access was the RSP and that's only because it would DMA data in large enough chunks that it could actually offset the hideous latency.

I've never tested actual fillrate, but with Z enabled it was probably <30 mega pixels, it was certainly nowhere near the peak.

 

[Tagrineth]

How about anti-aliasing performance? Obviously, it's one of N64's feature yet I've never seen any game using that. Some programmers are saying it was impossible to implement it in the first place.

Impossible to get it to work reliably on everything, maybe, but definitely there.

Go play MARIO 64 for crying out loud, and look at some of the edges...

The AA is just VERY VERY fickle about whether or not it'll work, which makes for some really odd contrasts - a beautifully AA'ed edge right next to a hard, 320x240 edge x_x

 

[Roly]

Texture mem. was 4kb, which meant 64x64 with 4bpp, or more commonly higher color with lower res.

ERP, thanks for the detail on the bilinear shortcut, and your estimation of the real world fillrate, which still seems pretty good for c. 1996.

 

[n64]

Couldn't they use some of the n64's ram for texture memory? As Banjo-Kazooie proved you can get some beatiful textures out of the system

 

[duffer]

Texture mem. was 4kb, which meant 64x64 with 4bpp, or more commonly higher color with lower res.

Wouldn't 64 x 64 x 4bpp be 2 KB? Maybe it was 64 x 64 x 8 bpp?

Couldn't they use some of the n64's ram for texture memory?

Sure, but each texture was limited in size to just 4 KB, so you ended up with scenes with pretty bland, repetative textures.

I liked "Conker's Bad Fur Day", where they combined Gouraud shading with various repteating texture maps to produce a world that looked quite nice, without taking much texture ram.

 

[Mr. Angry Pants]

All at a blazing 12 frames per second, no less!

 

[Megadrive1988]

a few points -

-texture cache was only 4kb, I think. and only 4.5 MB memory (unified) - both much less than what was needed.

-lack of CD-ROM pretty much crippled it.

-although the triangle/polygon count was never officially listed, it was quite low with all or most features enabled. conciderably less than PSX's simple textured and gouraud shaded count.

-fillrate was decent. more or less in the same ballpark as 3dfx Voodoo1, but don't know what it was exactly. Voodoo1 was like 45M pixels/sec I believe.

-N64 had good image quality, the best actually, compared to Saturn or PSX, which were not true 3D machines (the Saturn even less so than the PSX)

-N64/RCP was ment to be based on SGI's Reality Engine or RE2 - though the $200 N64 (was originally going to be $250) was VASTLY watered down/cut down compared to an SGI Reality Engine visualization supercomputer.

I personally wanted to see the 3D0/Matsushita M2 released. IMHO, it would have been much better than the N64 if it had been supported. (the original D2 and Power Crystal looked amazing) M2 had twin PPC 602s each at 66 Mhz, (72-80 MIPs, 133 MFLOPS each) a more powerful triangle/T&L engine (one of the PPCs did that) 4x the N64's texture cache (16k) - 8 MB SDRAM - and a 4x CD-ROM. Overall, M2 was about 1/3rd or 1/4th of Dreamcast's processing power, or about 2-3 times that of N64.

 

[mech]

Isn't it weird how SNES and N64 both had excellent image quality but a lack of "grunt" underneath to drive the graphics? Such a shame really.

If someone can find that quote about the bilinear hack, I'd love to see it again. I was the one who brought it up in that other thread - I read it in an interview somewhere, and I'd love to read that interview again.

 

[Tagrineth]

Isn't it weird how SNES and N64 both had excellent image quality but a lack of "grunt" underneath to drive the graphics? Such a shame really.

If someone can find that quote about the bilinear hack, I'd love to see it again. I was the one who brought it up in that other thread - I read it in an interview somewhere, and I'd love to read that interview again.

It's probably due to a higher resolution (SNES - 256x224 standard, max 512x448; N64 - 320x240/AA standard, max 640x480/AA)... makes for a cleaner image, and on SNES makes for more space to fit fun stuff

Also both ended up having a lot of FPS slowdown.

In the end it's probably due to both consoles needing a lot of optimisation to run well, therefore devs really went the extra mile to get it running great...

 

[Blade]

SNES had some amazing looking games (Yoshi's Island, Chrono Trigger, Secret of Mana 2, and a lot of other Japan-only games took full advantage) but required the Super-FX chip for some of the more intensive ones. (Star Fox, Yoshi's Island)

 

[Tagrineth]

SNES had some amazing looking games (Yoshi's Island, Chrono Trigger, Secret of Mana 2, and a lot of other Japan-only games took full advantage) but required the Super-FX chip for some of the more intensive ones. (Star Fox, Yoshi's Island)

...which is mostly because SNES has a severely underpowered CPU. 3.2MHz 16-bit which can only address 64kb chunks of data... that also restricted the poor SPC700 (WAY ahead of its time) which would have been even MORE impressive without the 65816 only being able to feed it 64kb at a time (all ripped SNES sound files are EXACTLY 65536 bytes).

 

[Megadrive1988]

IIRC, the Super Famicom/SNES was ment to get a 10 Mhz 68000 CPU - that was the original intention of NoJ - however costs became a huge factor and the CPU was cut down, while an extra math co-processor was designed into the graphics architecture - meanwhile magazines didn't get it, they thought that SFC/SNES CPU was getting FASTER. One of them even had the balls to say that Nintendo's CPU would be slightly faster than the NeoGeo's at 14 Mhz! (NeoGeo's CPU was 12.5 Mhz) - So it came as quite a shock for many when they learned the SFC/SNES CPU was only in the 3+ something Mhz range - that was lSega Master System-like speeds--Although the SNES CPU was 16-bit and could naturally do much more work per cycle than SMS's Z80. still, SNES's CPU was SLOW, that could be seen and felt in early games like Gradius III and Super R-Type.

Amazingly, the SNES had some extremely fast & smooth shooters later on like Axeley and Space Mega Force aka Super Aleste.

EGM even reported on an upgrade CPU device that was in the works, a 33 Mhz accelerator that would boost SNES speed to great heights. that never happened of course. Even the final SNES CD-ROM (there were 3 different CD-ROMs in dev) called the ND or Nintendo Disc, featureed a very fast 21 Mhz CPU to speed SNES up, but this too was canned in favor of the N64.

 

[KOF]

SNES's archilles hill was it's CPU. It wasn't even true 16bit because the register was still 8bit. It would have been great if they had at least retained the backward compatibility feature also intended as well.

 

[ERP]

I personally wanted to see the 3D0/Matsushita M2 released. IMHO, it would have been much better than the N64

M2 was really imoressive for the time even the single processor version was much faster than anything else at the time. It was a great example of unified memory done right, vs the N64 which was a great example of unified memory done wrong.
To be fair even if they had shipped it, it would have been at least 12 months later to market than the N64 and I can't see the box being particularly cheap.

 

[Megadrive1988]

M2 was really imoressive for the time even the single processor version was much faster than anything else at the time. It was a great example of unified memory done right, vs the N64 which was a great example of unified memory done wrong.
To be fair even if they had shipped it, it would have been at least 12 months later to market than the N64 and I can't see the box being particularly cheap.

Agreed. the single CPU version of M2 blew PSX away, even beating N64. I think most of the games were coded using the single CPU ver, but maybe that's not the case, I can't remember. Matsushita wanted to hype the M2 as being as powerful as the then new Sega Model-3 arcade board, but that was a bit too much to beleive. On the other end, some critics said the M2 was no better, in practice, than the N64. The truth is probably more like M2 being 2-3x the performance of N64 overall. I really wanted the M2 version of Warp's D2, rather than the totally different version that was released on Dreamcast. There were also rumblings of Namco converting some of its System22/SuperSys22 arcade games to M2, but that too, never happened since M2 was canned.

The CG car demo was probably beyond what M2 could actually do in real-time. maybe even beyond Dreamcast, which was 3-4 times M2's performance. The car demo, and other prerendered M2 demos shown, couldn't have been done until GeForce256 or GF2 GTS on the PC side, or Gamecube & XBox on the console side.