Texture cache of the N64 vs. that of Playstation

[swaaye]

If you can get past the jerky animation Q2 actually looks better on 64 with better lighting and skyboxes and runs better than voodoo 1 Q2.

I have no idea if a voodoo 1 in a console setting would be better than 64 but voodoo 2 is obviously better.

Well I haven't tried Quake 2 at 320x240 on a Voodoo1. But I think it might run ok. Quake 2 will overfill the common Voodoo1's 2MB texture memory however and stutter sometimes with swapping as a result.

I think Voodoo1 probably has a lot more fillrate than N64. It also doesn't have problems z buffering for example. Some other chips do though, like say the Rendition Verite V1000. VQuake doesn't use z-buffering.

I remember asking on Dimension3D about 20 years ago if N64 was as powerful as a Voodoo1 PC and they were not very positive about that lol. Maybe Azbat will say hi.

 

[phoenix_chipset]

Well I haven't tried Quake 2 at 320x240 on a Voodoo1. But I think it might run ok. Quake 2 will overfill the common Voodoo1's 2MB texture memory however and stutter sometimes with swapping as a result.

I think Voodoo1 probably has a lot more fillrate than N64. It also doesn't have problems z buffering for example. Some other chips do though, like say the Rendition Verite V1000. VQuake doesn't use z-buffering.

I remember asking on Dimension3D about 20 years ago if N64 was as powerful as a Voodoo1 PC and they were not very positive about that lol. Maybe Azbat will say hi.

I think Q2 is 640x240 on 64 with the expansion pak enabled? Not too sure but that's a common res on 64.

Looking at voodoo 1 a bit... it has 800 MB/s of bandwidth but is clocked a touch lower than 64. Fillrate is listed as 50 MPs for the voodoo but The highest rating was 62.5 MPs for the 64. So from what I can tell they seem pretty comparable but you have more bandwidth for the voodoo.

A voodoo in a console without PC overhead and faster memory would be interesting, tough to say what kind of memory setup it would have had though.

Edit : got numbers mixed up.

 

[Squeak]

I think Q2 is 640x240 on 64 with the expansion pak enabled? Not too sure but that's a common res on 64.

Looking at voodoo 1 a bit... it has 800 MB/s of bandwidth but is clocked a touch lower than 64. Fillrate is listed as 50 MPs for the voodoo but The highest rating was 62.5 MPs for the 64. So from what I can tell they seem pretty comparable but you have more bandwidth for the voodoo.

A voodoo in a console without PC overhead and faster memory would be interesting, tough to say what kind of memory setup it would have had though.

Edit : got numbers mixed up.

Well Voodoo has to fill a screen that is at least double the size and most often four times. So they have more or less the same bandwidth comparetively.
And the main memory over PCI is somewhat comparable to the cartridge.
In fact N64 is in many ways a Voodoo in a PC, console equivalent.
Compare for example Turok between the two.

Interestingly Voodoo textures, while filtered, actually doesn’t seem that hot either, in many cases worse than Playstation textures.
Is there an analogy/connection?
Did the Voodoo have a texture cache or equivalent?

Also, N64 textures doesn't seem to be at the maximum resolution that will fit within the cache, that is 64x64 where it would be appropriate, like on most landscape and environments (90 to 60 percent of most games graphics rendering).
64x64x4 is actually not half bad for the resolution rendered at, and what most textures are from games in the 90's before detail texturing came.
Most games seem to stick to 32x32 textures or lower. Any reason for that?

 

[swaaye]

Voodoo has a 256x256 pixel size limit to its textures. It also has a RAMDAC dither filter that gives the output a certain look. Their gamma calibration is also a little different... These cause problems for screenshots.

The Rendition Verite V1000 theoretically has ~45 mpix/sec fillrate so it sounds like it could compete with Voodoo right? Well, like N64, it does not achieve anything like that with some features enabled. Like Z buffering. It also can't do per-pixel mip mapping. This was where Voodoo kicked everyone else's ass - they could run with all the features without much hit and they had all the right features, especially for 1996.

I made some VGA captures years ago of Voodoo1.
Turok 2 - this must be 2-3x faster than N64.

Quake 3 with various texture detail levels

UT99 with High and Medium texture settings.

 

[Squeak]

I see precious few examples of textures that looks above 64x64, and certainly none that look even 128x128, in the videos of Voodoo rendered games I can find.
Of course having a maximum limit in a spec sheet does not mean it is attainable in a typical game.

Both Voodoo and RCP share common DNA and development period.
It would be strange if they didn't have things in common.

 

[swaaye]

I see precious few examples of textures that looks above 64x64, and certainly none that look even 128x128, in the videos of Voodoo rendered games I can find.
Of course having a maximum limit in a spec sheet does not mean it is attainable in a typical game.

Both Voodoo and RCP share common DNA and development period.
It would be strange if they didn't have things in common.

Voodoo 1-3 all have the same texture limit. It became a problem in 1999 or so. NV certainly targeted that limit in advertising because even TNT can use bigger textures. Quake 3 might use larger textures than 256x256 in some cases.

N64 seems quite different to me than the Voodoo ASICs. RSP does sound and graphics for example, being a sort of CPU. The graphics featuresets seem familiar certainly, though N64 has very funky limited precision "trilinear" filtering. Both can do edge AA, but 3dfx Glide games rarely did for some reason.

 

[Squeak]

The Unreal example in your edited post definitely seems better looking than just about any Voodoo run game I've ever seen. Is it just the concept of detail textures thats helping so much, or is it really a plain Voodoo?
Turok and Quake compared looks just a bit better than N64, which could come down to a variety of factors in the host machine the card is in.
RSP includes stuff that would later become common on GPU/VPUs, like the 3D DSP and register combiner.

 

[Reznor007]

The first unreal was basically built for voodoo cards. Glide was the primary renderer, with direct3d being the fallback for non voodoo cards. The detail textures really help give things a much higher resolution look than they normally would.

As for N64, in many cases it was cpu or bandwidth limited not gpu limited. If you are technically inclined you can lift/jumper certain pins on the n64 cpu to configure its clock multiplier in order to overclock it. In this state, many of the more demanding games run significantly faster. This can introduce instability in some games as timing mechanisms won't match the expected speed. This also makes the cpu run much hotter and may require active cooling.

 

[phoenix_chipset]

@swaaye I would just note that if that's voodoo 1 as it was back then, it's hardly fair to use a cpu faster than Xbox and 256mbs ram vs the 64

 

[swaaye]

@swaaye I would just note that if that's voodoo 1 as it was back then, it's hardly fair to use a cpu faster than Xbox and 256mbs ram vs the 64

Yeah. The point at the time was to not have a CPU bottleneck. I did videos of about 20 cards. N64 was not in mind at all. Just an old PC card exploration. I hadn't used many of the cards before.

When I bought Voodoo 1 back in the day I put it into a Pentium II 233. With 64MB. I'm not sure what a typical setup might have been. Probably P166 - PII 233.

 

[swaaye]

The Unreal example in your edited post definitely seems better looking than just about any Voodoo run game I've ever seen. Is it just the concept of detail textures thats helping so much, or is it really a plain Voodoo?

One thing about N64 that I always notice is the simplified bilinear texture filtering that takes into account only 3 points. Some people call it "triforce" filtering because of the triangular artifacts. It also seems angle dependent to some degree.
https://filthypants.blogspot.com/2014/12/n64-3-point-texture-filtering-in.html

This looks like a real N64 capture. It's kinda blurry and I think it's with a poor quality svideo cable, but if you look at the runway you can see the filtering behavior. Watch the center stripe for example.

Another interesting quirk is the edge AA sometimes gets pixel colors wrong and you see erroneous specks on edges. See Perfect Dark intro logos.

 

[Megadrive1988]

Imagine if M2 had lived upto its promise (and hype)

MODEdit: Magazine scans are not allowed on B3D, as they are copyright violations. Sorry.

Man, I *so* bought into the hype back in 1995-1996, but by 1997 it was clear M2 couldn't do these things. Still. D2 looked very nice--More interesting that the completely different Dreamcast game that came out years later.

 

[Nesh]

 

[phoenix_chipset]

Thought this would be interesting, bit of an explanation of N64's gpu structure from some programmers of conker : Bit of insight on how quite a few N64 games have nice dynamic lights and maybe how the numbers may not tell the whole story of the hardware. Chip quoted as "very powerful."

Also check out that rippling water!

 

[Squeak]

One thing about N64 that I always notice is the simplified bilinear texture filtering that takes into account only 3 points. Some people call it "triforce" filtering because of the triangular artifacts. It also seems angle dependent to some degree.
https://filthypants.blogspot.com/2014/12/n64-3-point-texture-filtering-in.html

This looks like a real N64 capture. It's kinda blurry and I think it's with a poor quality svideo cable, but if you look at the runway you can see the filtering behavior. Watch the center stripe for example.

Another interesting quirk is the edge AA sometimes gets pixel colors wrong and you see erroneous specks on edges. See Perfect Dark intro logos.

It basically only affects large oblique polygons almost at a ninety degree angle to the screen.
I only remember a few instances of it Oot to be honest.

 

[Squeak]

Just discovered something on the Wikipage for the RCP:
"The RDP contains 4 KB of on-chip TMEM (texture memory) in which the RDP can reference up to eight textures (so-called "tiles") at any given time. The size of the available texture memory may be reduced further if using texture lookup tables (TLUT), since the high 2 KB will be used to store the lookup tables."
What is this?
The CLUT is stored in the texture buffer?
That would explain some things.
Is that always a full 2Kb that is taken? A four bit CLUT will only take 512 bytes and an eight bit 1 Kb.
Is this even true?

 

[swaaye]

Just discovered something on the Wikipage for the RCP:
"The RDP contains 4 KB of on-chip TMEM (texture memory) in which the RDP can reference up to eight textures (so-called "tiles") at any given time. The size of the available texture memory may be reduced further if using texture lookup tables (TLUT), since the high 2 KB will be used to store the lookup tables."
What is this?
The CLUT is stored in the texture buffer?
That would explain some things.
Is that always a full 2Kb that is taken? A four bit CLUT will only take 512 bytes and an eight bit 1 Kb.
Is this even true?

ERP talked a lot about the cache and some other aspects years ago.

You explicitly loaded a texture into the 4K block of memory then used it as a texture source. You could do it as many times a frame as you could get away with.

If you used the approximate trilinear it two banks of 2K, and you put alternate mipmaps in each.
Bilinear was 3 sample trilinear 4(I think), you could see the triangular artifacts if you looked, there was no mandate or requirement to use any rendering feature.

There are a number of issues with this, changing textures is expensive, and probably more importantly art creation tools aren't really designed with the limitation in mind.

The main memory had hideous latency, it was organized in 2 banks the idea being that Z would go in one bank and color in the other, in practice that didn't buy you very much, and with Z on fill was very limited.

The CPU's small direct mapped cache couple with the poor memory latency was an absolute performance killer. Which is probably why Nintendo went the way they did with GC.

FWIW I vaguely remember double buffering textures, but I'll be honest and say my recollection of these things at this point is at best suspect.
I also vaguely remember limitations like 64x64 4 bit textures which supports that.

Manually loaded texture caches were common even after N64, the M2 had one, though I think it was 16K, which is a far more reasonable size. Game cube effectively had one, and you could argue that PS2 had one.

Asset creation was more of an issue with the restriction than the limitation itself. I really hated how we had to make the cars look in Top Gear Rally, because we allowed the users to edit the textures they had to have a very simple mapping which precluded us from making them look much better than they did.

N64 had a 4KB texture cache that had to be explicitly loaded from main RAM in the command stream before it could be used. If Mipmapping was enabled it was effectively 2KB. To put it in perspective a 64x64 4bit/pixel texture is 2K and a 128x64 is 4K.

We didn't use the ZBuffer for World Driver Championship or Stunt Racer 2K, that coupled with faster uCode let us do a lot more visually, there was always a concern during development that Nintendo would bounce the title if they saw playstation like visual artifacts.

That will almost certainly be a fillrate issue.
I personally always felt like the N64's memory subsystem was broken, you're supposed to put Z and Color on different pages, to improve performance, it's clearly stated in the docs. In practice it made very little difference. With Z enabled, you'd be lucky to match fillrate with a PS1 (which of course had no Z)

Neither has what you would term a texture cache today.
PS1 has a page of memory "VRAM" that contains all the textures, and the framebuffers, you can get textures in there larger than the maximum supported UV coords.
N64 has a tiny piece of memory 4K, where a texture must be manually loaded before you can render from it. If mipmapping is enabled, this is reduced to 2K because alternate mipmaps must be in opposite pages.

There were a few High res games on PS1, but it wasn't common. Neither platform really had the fill rate to do it well accross a wide variety of genres.
N64 was probably hit a bit harder, because any extra memory pressure was bad.

Wouldn't be of much use, the theoretical numbers were much higher than what you'd see in practice since it was bandwidth limited for the most part. Plus you have to take into account things like stalls while loading the texture into the cache which the PS1 never had to deal with.
Turning off Z made a considerable difference, World Driver runs without a Z buffer for this reason, but it was a significant risk when we made that decision, because it was unclear if Nintendo would bounce a title for excessive Z fighting.

Disclaimer it's been a LONG time since I wrote an N64 game and even longer since I wrote a PS1 one, I responded from memory, so all facts in this post should be considered appropriatly degraded.

 

[phoenix_chipset]

Seems to me Erp's insight is good from the perspective of a studio with limited budget and time (and also what sounds like not a good relationship with ninty) but maybe not representative of the systems max capabilities. He said gamecube was weaker than ps2 which is clearly the opposite in terms of model and environment geo and textures/effects.

Stunt racer 64 actually looks pretty fun, should pick that up. Edit : wow that game is over $100 o_o

 

[function]

Seems to me Erp's insight is good from the perspective of a studio with limited budget and time (and also what sounds like not a good relationship with ninty) but maybe not representative of the systems max capabilities. He said gamecube was weaker than ps2 which is clearly the opposite in terms of model and environment geo and textures/effects.

Nintendo's relationship with none Dream Team members was not great. The microcode they made available to many developers had performance issues, and developers had to use it to achieve cert. All developers are limited in terms of time and budget.

Throwing shade at ERP's ability to assess the GC - a machine for which he hand wrote code to accelerate culling beyond the limits of the T&L unit - is something you really need to be able to back up. His comments are in tune with those the highly talented Burnout developers and contradicted by no-one with hands on knowledge of the systems. Using your evidence-less criticism of his assessment of the GC as a reason to FUD up his comments on the N64 is not helpful.

 

[phoenix_chipset]

Nintendo's relationship with none Dream Team members was not great. The microcode they made available to many developers had performance issues, and developers had to use it to achieve cert. All developers are limited in terms of time and budget.

Throwing shade at ERP's ability to assess the GC - a machine for which he hand wrote code to accelerate culling beyond the limits of the T&L unit - is something you really need to be able to back up. His comments are in tune with those the highly talented Burnout developers and contradicted by no-one with hands on knowledge of the systems. Using your evidence-less criticism of his assessment of the GC as a reason to FUD up his comments on the N64 is not helpful.

As noted in the video I posted you could rewrite the micro code for better performance. Yes it was dependent on Nintendo's approval, but the fact remains thehardware was capable of more than the majority of studios were able to achieve.

I'm not interested in a biased opponent with regards to the gamecube, it's an undeniable fact it was more capable than ps2 in everything but alphas and dynamic geometry. I'm not calling erp a liar, but it's one man's assessment : from the perspective of someone who didn't ship a game on it, let alone solely focus on it for an exclusive game with a large budget.

You and the rest of you old boys here can cherrypick which data is reliable and agree on it here, but the agreement will be isolated to the forum.

I'm esp. not interested in discussing with you in particular since you already assumed I was ignorant on what hardware was available in 96. Move on if i'm just a ninty fanboy yeh?