N64's bilinear filter and AA method were mandatory functions of the hardware, right?

I

inlimbo

Newcomer
I ask because for the PSX and Saturn games that do hold up, it's in part because their texture art remains untouched. And, like good pixel art, it holds up both despite and because of each system's limitations.

I generally have a high tolerance for early 3D and think a lot of the N64's texture work also holds up, despite the smear imposed, but I think it's clear that bilinear filtering or whatever approximation used does more harm than good under such limited conditions. Given its z-buffer, I think people would think of N64 3D more fondly had it gone without filters, or at least if they had remained optional.

edit: scratch that last edit
 
Last edited by a moderator:
The biggest problem is it only had something like 4K of texture cache, so all the textures were incredibly low res, and the filtering was used mostly to hide that fact. PSX games could have higher resolution textures, and had tons of storage so they could store tons of large bitmaps (in addition to high quality sound and video files). Filtering could have helped PSX a bit, but more than that it really just needed perspective correction.
 
I thought it was more the way texture rendering worked than the size of the texture cache, since the PSX also has 4k of cache, right? There are enough N64 games that seem to have circumvented some texture size limitations, albeit probably painfully. And I had an edit questioning cart limitations sitting in the OP a few minutes ago, but did that many PSX games really use large bitmaps? I know some did, but it's not like they could load a scene down with them. Is that space as much an advantage for in-game texture variety as it was for FMV and audio?
 
PSX has 4K of instruction cache. Its texturing isn't cache limited the way N64's is. It textured directly from the 1MB of VRAM AFAIK.
 
Okay, that makes sense. Then the question is: do the best looking N64 games on the whole use smaller textures per scene, tiled or otherwise, than the best looking Playstation games?

edit: I mean, largely, that question is irrelevant. I'm not interested in a straight technical comparison, because I'm talking more about texture art and the way cheap filter methods can smear it to hell. But if it's a fundamental limitation of the N64 that it could not do the texture variety and size that a Playstation could, then I guess the discussion goes beyond filtering. If they're roughly comparable, given the right programming, then it doesn't.
 
Last edited by a moderator:
From what I understood of previous threads (from many years ago), the edge AA could be disabled, and the bilinear filtering was not quite conventional bilinear, but a slightly more economical approximation. This approximation (3 samples c.f. 4?) could be adjusted for with pre-processing of the texture, making it close enough to a full bilinear of the era.

It certainly seems that it could be turned off, giving nearest-neighbour on specified textures (the lights on the distant buildings in the first or second level of Perfect Dark appear to be 'nearest' rather than bilinear). I'm not sure if this was available in the API or whether it required microcode adjustment. I have not noticed 'nearest' filtering in other titles, be they from Rare, Factor 5/Lucasarts, or Nintendo.

I always very much liked the N64 as a system, though by the accounts given on this forum, it was very difficult to program. I recently played through Donkey Kong 64 again, and there are some nice environment mapping effects and decent levels of geometry, though the two Banjos and Conker are better looking for the most part (to me). It's very interesting to ponder the N64 design choices, given the Wii, and Wii U. Relatively fast CPU (R4300i), relatively advanced rasterizer (RCP), UMA (single-channel 9-bit RDRAM), on what I think was an advanced process at the time (0.35um?)
 
inlimbo said:
Okay, that makes sense. Then the question is: do the best looking N64 games on the whole use smaller textures per scene, tiled or otherwise, than the best looking Playstation games?
Click to expand...

From my understanding, the N64 literally could not use more than 4K worth of textures in any given frame. PSX did not have such a restrictive limitation. So yes.
 
I had the impression that each surface was limited to 4k (or 2k with mip-mapping). So more than 4k per frame, perhaps very much more, but the limits (latency?) of the RDRAM meant that it was deeply challenging to get good performance.
 
Last edited by a moderator:
Ah, yeah. I'm probably misremembering that. Probably conflating it with some other weird technical limitation from the days of yore.
 
From what I can remember of the previous discussions, there were definitely many constraints and perhaps counterintuitive limits on the system (many involving the memory subsystem, the development environment, and the available RCP microcode options).
 
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.
 
Seems like one of the big problems of having a directly managed 4KB texture buffer (as opposed to a hardware managed cache) is that the straightforward choices of managing it are to either double buffer it so 2KB is used for what the RDP is currently rendering and 2KB is used to stream new textures into, or stop rendering entirely while you're updating textures. Neither are very good solutions. Of course you can't exceed the buffer size for a single primitive and 2KB can already become restrictive there..

Shame that N64 frees you of needing to tessellate to reduce perspective errors (like on PS1), only to force you to tessellate to fit your textures in. And when your texturing capacity sucks it makes all the system's nice features like perspective correct interpolation, bilinear + trilinear filtering, mipmaps, multi-texturing, and so on a lot less useful :/ None of these things are nearly as nice on texture-less polygons that many N64 games used in abundance.
 
I suppose they were breaking new low-cost ground, but it is something that SGI engineered those serious design flaws. Also, considering Sega turned the hardware down years prior, you have to wonder how long it had been stewing. It must have initially been intended for 0.50um.
 
Exophase said:
either double buffer it so 2KB is used for what the RDP is currently rendering and 2KB is used to stream new textures into, or stop rendering entirely while you're updating textures.
Click to expand...
There isn't really a difference between either scenario, because while you're copying from memory into the cache you can't render to memory, regardless of if you "double buffer" (which the N64 did not really support I believe) or not. So provided you're able to "double buffer", you'll just slow your rendering down while uploading data into the cache, meaning there won't be a performance benefit.

In a well-designed memory subsystem you would actually benefit from filling your texture cache in one large burst transfer versus doing scattered accesses reading texture data interleaved with frame and Z-buffer reads and writes, but it's doubtful the N64's RDRAM actually performed very well in either scenario... :p
 
Grall said:
There isn't really a difference between either scenario, because while you're copying from memory into the cache you can't render to memory, regardless of if you "double buffer" (which the N64 did not really support I believe) or not. So provided you're able to "double buffer", you'll just slow your rendering down while uploading data into the cache, meaning there won't be a performance benefit.
Click to expand...

Do you know that for a fact, that the texture buffer is locked during rendering? I don't know why you keep putting double buffer in quotes, because what I described is what double buffering is. It doesn't only apply to framebuffers.

There'd still be a performance benefit even if the texture buffer is single ported and can't simultaneously accept DMAs to and fetch requests from, if the RDP spends anything less than 100% of the time accessing the texture buffer.
 
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.
 
Exophase said:
Do you know that for a fact, that the texture buffer is locked during rendering?
Click to expand...
The texture cache could be multiported, but the DRAM memory isn't, so even with a multiported TC you would still be either fetching texture data from main RAM to put into the TC, or reading/writing frame or Z buffers stored in main RAM; not both at once.

I don't know why you keep putting double buffer in quotes, because what I described is what double buffering is. It doesn't only apply to framebuffers.
Click to expand...
Just guarding against the possibility the N64 doesn't support it; I've never seen it confirmed in any online specs or discussion that you can store more than one texture (+ its corresponding MIP maps) at any one time.
 
Grall said:
The texture cache could be multiported, but the DRAM memory isn't, so even with a multiported TC you would still be either fetching texture data from main RAM to put into the TC, or reading/writing frame or Z buffers stored in main RAM; not both at once.
Click to expand...

Fair enough. In that case I guess substitute what I said about 100% utilization for the RDRAM, if indeed it goes undersaturated much.. compared to the texture buffer it shouldn't be tied up per-pixel regardless of access width, there pretty much has to be some buffering to overcome the latency. The RDRAM provides 500MB/s of peak bandwidth if looking at 8-bit writes (the 9th bit can be used in graphics too but I'll ignore it in future calculations). The RDP is probably not capable of more than one pixel/clock or 62.5MPixel/s. With 16bpp pixels and no Z-buffering or alpha blending that'd be a max of 125MB/s, so in theory there should be extra bandwidth for other stuff in at least some scenarios.

Grall said:
Just guarding against the possibility the N64 doesn't support it; I've never seen it confirmed in any online specs or discussion that you can store more than one texture (+ its corresponding MIP maps) at any one time.
Click to expand...

You mean, that you can have primitives address different parts of the texture memory? You can (http://www.dragonminded.com/n64dev/Reality Coprocessor.pdf check the Set Texture Image command), but even if you couldn't you could usually just atlas it.
 
Exophase said:
Fair enough. In that case I guess substitute what I said about 100% utilization for the RDRAM, if indeed it goes undersaturated much..
Click to expand...
Not really a case most of the time probably, due to the horrifically low efficiency of said RDRAM interface... I believe ERP said they did some measurements of RAM latency on the N64 and concluded it was around 250ns or something ludicrous like that, I can't quite recall the exact numbers stated so I may be off. :)

I wonder where that poor performance comes from, some crazy quirk with the RDRAM standard to reach 500MT data rates in the mid-1990s, bad memory controller implementation in the RCP, or combination of both perhaps... SGI had four RDRAM channels in parallel for the graphics subsystem of one of their smaller graphics workstations, maybe if N64 had used twin channels at least things would have been a bit better. They probably couldn't have squeezed in the required pins on the RCP package though... It was a rather large PQFP as it was, and RAM expansion would have been more complicated as well of course. The case design Nintendo used wouldn't have worked for example (no room to fit a bigger RAM module.)

Bah... Just thinking of that ancient machine makes me feel old.

9th bit can be used in graphics too but I'll ignore it in future calculations
Click to expand...
9th bit was hardware parity used by the RDRAM interface I believe. It would probably lead to some very odd alignment issues if it accessed the DRAM array directly...

The RDP is probably not capable of more than one pixel/clock or 62.5MPixel/s.
Click to expand...
IIRC it's worse than that, bilinear filter ran at half-rate and trilinear at quarter rate I believe.
 
You must log in or register to reply here.
Back
Top