Any chance you could be more specific on NV2A's texture cache?
Also can you clarify wether or not NV2A can hold compressed textures in its texture cache? There was a rumour a while back saying it couldn't and it never got cleared up.
I'm not comfortable getting into specifics on the NV2A cache, I know cache size is one of those pieces of info that IHV's like to keep quiet.
As for compressed textures, the texture is expanded as it's read from memory and stored in one of a number of formats in the cache. NV2A has a massive amount of read bandwidth from the cache so it's not really an issue. Compressed textures basically just increase the number of texels that can be read into the cache/cycle.
So were the Banjo games and BFD doing multi-texturing or did I misread the posts ?
Banjo does, Ive never bothered playing BFD so I can't comment there.
In real terms N64's fillrate was comparable to that of PS it didn't really have a big advantage. Most N64 titles woluld either have been fill bound or more likely CPU bound. Cache size and RAM latency were such that unless data and code were extremly carefully organised CPU performance would be very poor.
Did you effectively lose 2k of tmem even with just bilinear filtering? Could point sampling improve fillrate performance much?
No basically, Trilinear requires you to read from two different MIP levels simultaneously. In order to accomplish this you have to split the texture cache in half, and have one MIP level in each half, so you end up with the largest MIP level limited to 4K/2 = 2K.
Also, did the N64 have decent profiling tools like the performance analyzer that Sony bandied about all the time? (I understood it to be a special, sort of system level profiler but I'm not really up on this stuff.)
Not really, but the performance analyzer wasn't available to the majority of PS developers until the end of the PS life span either.
Any decent developer puts there own profiler in place as they build the application. The difficult part is to understand what the results tell you, IMO most developers spend a lot of time optimising the wrong thing because they labour under misconceptions of how the hardware is interacting.
How did Factor 5 get access to microcode?
The same way we did. Towards the end of the N64 lifespan Nintendo released uCode tools and documentation to a few developers. Factor five were one of them.