trilinear is actually just a short term for bilinear filtering of texels and linear filtering of mip levels, hence TRIlinear the N64 just uses a janky version of bilinear that uses less samples to save on cost and offsets the UVs by half a texel to compensate for the texture shift effect that causes
Part of the reason I believe the fill rate was capped and the ram latency wasn't fast enough was because the tech was developed in the late 80's with Project Reality. The Reality Engine MIPs processor was basically an embedded version of the Reality Engine from the previous decade. It blows my mind how in 7 years Silicon Graphics managed to get a $250,000 PC reduced to it's core to be a $200 N64. That's why in my opinion the Shark Tech Demo that you show here both ran on the original Reality Engine in 1988 and was used as a tech demo for the embedded console in 1995.
Yeah exactly! fill rate issues primarily lie due to the high bandwidth high latency RAMBUS design and a small texture cache. Both cost cutting measures. But yes, it's amazing right? It's a shame SG didn't find a way to adapt to the new emerging PC market in the late 90s. They were one hell of a company. Remarkable technological feat.
@@ZygalStudios right! If only it was Nvidia head to head with SGI like AMD and Intel are to each other. That would have been amazing. My point that I didn't explain properly is that the original SGI machines were expandable so if you needed more cache you just dropped in another ASIIC. Something you definitely couldn't do on the N64. I wish the trilinear filtering was an option in games. And more 2D games like SNES ports. (I'm not the most hardware savvy but I am a fan of SGI and Maya and The Spirits Within) I want to know why the Devkit had 6 controller ports?
@@chikato7106 Yeah that makes total sense! Expandable hardware was SGIs game at scale and throw to the wind for cost. But that dev board question is something I might be able to answer! :) thanks for the video idea!!
Ok, I have a few issues with this comment. First of all, what do you mean by "Reality Engine MIPS processor"? Do you mean the Reality Co-processor? Secondly, Reality Engine was introduced in 1992 as a graphics hardware upgrade option for the Silicon Graphics IRIS Crimson and is way above the hardware they used in '88 and '89. Thirdly, and most importantly, they didn't somehow squeeze a quarter-million dollars of hardware into a $200 console, they are worlds apart in terms of performance and features. That $250000 worth of hardware accounted for dozens , if not hundreds, of megabytes of memory not just for main memory but for framebuffer and texture memory to account for huge screen resolutions with true anti-aliasing etc. This isn't even mentioning all of the powerful floating-point CPUs (including twelve Intel i860XP 50Mhz processors) that make up the Geometry Engine hardware on Reality Engine. As a side-note, the shark demo didn't run on an actual console. It was a demo made to run in IRIS Performer (on the IRIX operating system used on Silicon Graphics computers) named Performer Atlantis. You can find footage of the demo on RUclips. It requires at least 4MB for textures alone which the N64 couldn't cache.
The SGI O2 workstations could attach a L2 cache of up to 1MB to their systems. Had NINTENDO ponied up the money and used even 128KB of L2 backside cache, they wouldn't have had anywhere near as many performance problems with their architecture.
To compensate for the lack of rich and varied textures the N64 would need to generate way more polygons than the competition, but it also failed to do that. Nowadays I think Saturn and PlayStation graphics aged better, showing lots of granular details, even if they are pixelated and wobbly. With few exceptions, N64 games look blurry and lifeless.
We still use Mipmapping today. Its faster to sample from a mipmap than average the pixel color that contains hundreds of pixels. The mipmap chain is essentially a prefiltered texture table that gives the correct pixel color for any distance. Say you had a quad with a 128x128 texture, but its very far away, so it only appears to be 8x8 in screen pixels. Without mipmapping, Each screen pixel would need to average 256 colors together at run time. With mipmapping, it just samples from the correct mipmap. mipmap 0 128x128 mipmap 1 64x64 mipmap 2 32x32 mipmap 3 16x16 mipmap 4 8x8 etc... So you only need to sample mipmap 3. Which is the equivalent of the average you would have got if you average 256 colors together. The gpu uses the mipmap that has a texel resolution as close to the screen pixel resolution for the current triangle. When Its in between resolutions, thats when trilinear comes in, to blend between mipmaps. Modern games look better because our base mipmap 0 textures are very large, 2048x2048 and up.
Mipmapping is actually very important factor to reduce granular look on textures that are further away. PS2 - games are sad example what happens to textures when mipmapping is not used.
@@halionextra It varies depending on game, while some have mipmapping (Ratchet and Clank/Jak and Daxter games for example) a lot of them don’t, it wasn’t a universal feature like it was with some other consoles for whatever reason.
Yes and no. Ps2 usually eschewed mip mapping but if you play its games at a modern day resolution they hold up a lot better imo. Yes, there is a sharper, jagged look but I'd prefer that over a blurry, low detail mess
@@halionextra You mean, the console is capable to do mip mapping. I have lots of PS2 games, but only game of those where mip mapping is used is Motostorm Artic Edge. Many people do not recognise when game lacks mip mapping. -They think it lacks Anti-Aliasing instead. Those who don't know the difference should perhaps say, compare XG3 PS2 version to NGC-version. Mip Mapping keeps the distant textures stable, not gritty while camera is moving or player moves.
The N64 hardware was such a bag fumble. They packed so much power in there, but gimped it so bad that it ended up being just an expensive-to-produce sidegrade to the PSX, which was a far cheaper-to-produce and light-years weaker console.
People like to hate the N64 textures and prefer the PS1 textures for some reason but to me I prefer N64 textures. My reasoning? As someone who likes to play PC games from around the same era N64 games look like 3D hardware accelerated games running on a 3DFX Voodoo card. PS1 games look like the type of games you'd see running in software rendering mode.
Even software rendered texture-mapped 3D games on DOS/Windows 95 from 1994 and on mostly tended to use some sort of perspective-correction to avoid "wobbling" texture maps.
@@rac1equalsbestgame853 You can prefer the art style of the PS1 textures subjectively but from an objective technological standpoint the N64 texture filtering features are more advanced. There are a few late PS1 games that look like they have some pseudo texture filtering that looks great too.
I’ve become fascinated recently with how the PS1 and the N64 both went all in on using the imperfections of the technically inferior composite and RF signals most people were using to get the games on their TV to their advantage… yet the two consoles went about doing that in ways that were quite different.
A better way to explain interpolation is: Prediction based in previous and future happenings. In video engineering, optical flow for increasing or deducting frame rate to a specific number, demands prediction from previous and future frames to calculate which interframes artifacts should be shown or hided. The optimal frame rate for any video is 1000 per second (so each millisecond has its own frame in time) but with the evolution of computation, video software for compression and optical adaption handling like Hybrid video encoder, use math to interleave non decimal frame rates allowing us to reduce usual 60 fps to be perfectly (with no hiccups) videos to be optically resampled to inferior fps, such as 25/24.
This explains why some games have certain lighting and shading in the App Store 64 which rick can’t be remade in emulators says they would look off I’m kind of a piggy person, so I like my games being 100% like how they’re supposed to look and not like how it has been ripped and emulator, but I also want every game that plays fast, but not too fast
The whole point is you are dissecting it some decades later. Back in the Days i played on a black and white monitor not much larger then my current tablet. It was apropriet for this time and looked so much better then the competition.
back in day the consoles have small form factor, prob to reduce cost, not much later ,consoles are as big or bigger than a pc, and the tv set are bigger than the old arcades ,lol
Nintendo didn't care that the games look blurry and repetitive. They could just make smaller, more contained games, but if they could do this larger areas, that the other systems could not do as easily, they would, even if it looked like crap on the wrong hands. People talk about Mario, Zelda, Conker, Banjo, and yeah, these look fine, but non AAA 3d open world games on 64 look terrible. There was a catch with texture choices and tecniques and most developers couldn'g get it right, and the results were terrible.
Imagine its a problem, and you are the developer in Nintendo, then what will you do to increase the quality? Or what they can do. I am new in this field , i found that your videos are interesting ❤
Could a 32kx8 high speed SRAM chip on the motherboard have sped up texturing and also increased the amount of textures as well? That is, the latency of the RAMBUS RAM is mitigated by having a separate source and destination for textures when buffering, but not having to worry about adding more transistors to the N64's already tightly packed GPU. Obviously this would break the unified memory architecture Nintendo has sought and added increased cost slightly. I only ask because someone on 4chan's /v/ mentioned this as being something Nintendo considered from the "Gigaleak," but they didn't source it so I'm not sure.
You know, there's a good chance it could have, but it would have been costly. That's essentially the equivalent of what they did with Flipper in the GameCube GPU with scratch pad RAM. Can't speak to whether or not Nintendo considered it, but definitely would have helped.
The Nintendo 64 also had a very primitive style of anti-aliasing that coated the entire screen in vaseline lol -- usually implemented in software. This was in addition to some hardware blurring that was used in most games. Definitely did not help with the problem.
That is fullsceen bilineal filtering; used to hide the dithering patterns but as bilineal filtering also diminished the colors brightness they used gamma correction to counter the fullscreen bilineal filtering, making the dithering patterns visible in some high contrast areas of the screen.
In any case, "thanks" to those limitations, we had the aesthetics of N64 that has already become a classic with its blurriness, fog and smoothing. I personally love those graphics and wouldn't trade them for modern HD textures. They have just the right mix of warmth and nostalgia.
In blender make your model then when texturing use a texture that is very low Res and also give it some blur by softening in in texturepaint, den when unwrapping use cube project and also scale the uvs low and stretch them and bam, also you can buy old texture CDs with textures on them that N64 games used, extra points if you get them from japan
@@mastertigranI have seen a recent tech demo showing some extremely detailed textures in an N64 demo. At least ps2 level texture quality (maybe even above). Well above what I’ve seen possible on PS1 hardware and obviously no texture warping. I’ve tested it on actual n64 hardware. Of course just a tech demo and not a full game but incredible all the same.
So I was very lucky to try some of the first PlayStation ever made, it was shockingly good, I noticed how crisp textures bring life to the all new 3D graphics. Then the N64 was released and it looked really wrong, poor geometry and low quality textures, I was very upset, so I went with PS and never looked back.
You are wrong on all counts. For starters most puzzling/odd/abhorrent stuff has one main reason only. It’s surprisingly seldom that it’s multiple things conspiring into one outcome, when you get to the bottom of things. Storage medium was not a limitation at all for textures. On the contrary the speed and small latency of the cartridge meant new textures could be loaded super fast. And should have resulted in better textures if anything. PlayStation games if you rip off all the FMV and Redbook music, often takes up less actual space than the N64 games, even if they can be much more careless with storage space. RAM size, bandwidth or latency was not a limitation. Latency is a very small issue with a relatively predictable process such a texturing. The RAM was much faster than the PlayStations RAM and larger too. The SRAM texture cache was the only reason. The N64 cache is actually larger but has to be loaded explicitly, which makes it not a real cache and impossible to reload when drawing a polygon. The PlayStation cache on the other hand could be reloaded multiple times during texturing because it behaves like a simple but real cache. The two pieces of hardware was developed concurrently and Nintendo/SGI had no chance of adjusting the design before it was too late. The issue can be circumnavigated by texturing and modeling in a clever way, where you piece together a higher resolution texture from many separate polygons (like the Chinese puzzle in the volcano level in Mario 64). It takes extra planning and takes a toll on the geometry. Conker does it. Multitexturing is also possible like Zelda does. Nintendo should have put out a premium version of the console with a large cache halfway through the gen. And possibly a CD drive or the disc drive. It would have fared very well against the Dreamcast and the possible M2 3DO and been completely backwards compatible. Post in thread 'Texture cache of the N64 vs. that of Playstation' forum.beyond3d.com/threads/texture-cache-of-the-n64-vs-that-of-playstation.60851/post-2039251
@@bootmii98 Yep, this is true, but this isn't something I mentioned. I wouldn't say that's an inaccuracy. That's an observation here. 3D techniques for both of these consoles is very different, each requires different hardware requirements. The 64 would have certainly benefited from a larger texture cache.
you just explained a simple thing in 8 minutes, took literally so long to explain that i dont remember anything. the only thing stretched here is your explanation time.
back in day the consoles have small form factor, prob to reduce cost, not much later ,consoles are as big or bigger than a pc, and the tv set are bigger than the old arcades ,lol
trilinear is actually just a short term for bilinear filtering of texels and linear filtering of mip levels, hence TRIlinear
the N64 just uses a janky version of bilinear that uses less samples to save on cost and offsets the UVs by half a texel to compensate for the texture shift effect that causes
Part of the reason I believe the fill rate was capped and the ram latency wasn't fast enough was because the tech was developed in the late 80's with Project Reality. The Reality Engine MIPs processor was basically an embedded version of the Reality Engine from the previous decade. It blows my mind how in 7 years Silicon Graphics managed to get a $250,000 PC reduced to it's core to be a $200 N64. That's why in my opinion the Shark Tech Demo that you show here both ran on the original Reality Engine in 1988 and was used as a tech demo for the embedded console in 1995.
Yeah exactly! fill rate issues primarily lie due to the high bandwidth high latency RAMBUS design and a small texture cache. Both cost cutting measures. But yes, it's amazing right? It's a shame SG didn't find a way to adapt to the new emerging PC market in the late 90s. They were one hell of a company. Remarkable technological feat.
@@ZygalStudios right! If only it was Nvidia head to head with SGI like AMD and Intel are to each other. That would have been amazing.
My point that I didn't explain properly is that the original SGI machines were expandable so if you needed more cache you just dropped in another ASIIC. Something you definitely couldn't do on the N64. I wish the trilinear filtering was an option in games. And more 2D games like SNES ports.
(I'm not the most hardware savvy but I am a fan of SGI and Maya and The Spirits Within)
I want to know why the Devkit had 6 controller ports?
@@chikato7106 Yeah that makes total sense! Expandable hardware was SGIs game at scale and throw to the wind for cost.
But that dev board question is something I might be able to answer! :) thanks for the video idea!!
Ok, I have a few issues with this comment. First of all, what do you mean by "Reality Engine MIPS processor"? Do you mean the Reality Co-processor? Secondly, Reality Engine was introduced in 1992 as a graphics hardware upgrade option for the Silicon Graphics IRIS Crimson and is way above the hardware they used in '88 and '89. Thirdly, and most importantly, they didn't somehow squeeze a quarter-million dollars of hardware into a $200 console, they are worlds apart in terms of performance and features. That $250000 worth of hardware accounted for dozens , if not hundreds, of megabytes of memory not just for main memory but for framebuffer and texture memory to account for huge screen resolutions with true anti-aliasing etc. This isn't even mentioning all of the powerful floating-point CPUs (including twelve Intel i860XP 50Mhz processors) that make up the Geometry Engine hardware on Reality Engine. As a side-note, the shark demo didn't run on an actual console. It was a demo made to run in IRIS Performer (on the IRIX operating system used on Silicon Graphics computers) named Performer Atlantis. You can find footage of the demo on RUclips. It requires at least 4MB for textures alone which the N64 couldn't cache.
The SGI O2 workstations could attach a L2 cache of up to 1MB to their systems. Had NINTENDO ponied up the money and used even 128KB of L2 backside cache, they wouldn't have had anywhere near as many performance problems with their architecture.
This is a really good channel! I will see if I can share it around, it deserves more views.
Thank you so much!!
I would really appreciate it! Thanks for coming by!
To compensate for the lack of rich and varied textures the N64 would need to generate way more polygons than the competition, but it also failed to do that.
Nowadays I think Saturn and PlayStation graphics aged better, showing lots of granular details, even if they are pixelated and wobbly.
With few exceptions, N64 games look blurry and lifeless.
Good explanation for the N64 BlurroVision(tm)
We still use Mipmapping today. Its faster to sample from a mipmap than average the pixel color that contains hundreds of pixels. The mipmap chain is essentially a prefiltered texture table that gives the correct pixel color for any distance.
Say you had a quad with a 128x128 texture, but its very far away, so it only appears to be 8x8 in screen pixels.
Without mipmapping, Each screen pixel would need to average 256 colors together at run time.
With mipmapping, it just samples from the correct mipmap.
mipmap 0 128x128
mipmap 1 64x64
mipmap 2 32x32
mipmap 3 16x16
mipmap 4 8x8
etc...
So you only need to sample mipmap 3. Which is the equivalent of the average you would have got if you average 256 colors together. The gpu uses the mipmap that has a texel resolution as close to the screen pixel resolution for the current triangle. When Its in between resolutions, thats when trilinear comes in, to blend between mipmaps.
Modern games look better because our base mipmap 0 textures are very large, 2048x2048 and up.
Mipmapping is actually very important factor to reduce granular look on textures that are further away.
PS2 - games are sad example what happens to textures when mipmapping is not used.
ps2 uses mipmapping
i think you meant ps1
@@halionextra It varies depending on game, while some have mipmapping (Ratchet and Clank/Jak and Daxter games for example) a lot of them don’t, it wasn’t a universal feature like it was with some other consoles for whatever reason.
Yes and no. Ps2 usually eschewed mip mapping but if you play its games at a modern day resolution they hold up a lot better imo. Yes, there is a sharper, jagged look but I'd prefer that over a blurry, low detail mess
@@halionextra You mean, the console is capable to do mip mapping.
I have lots of PS2 games, but only game of those where mip mapping is used is Motostorm Artic Edge.
Many people do not recognise when game lacks mip mapping. -They think it lacks Anti-Aliasing instead.
Those who don't know the difference should perhaps say, compare XG3 PS2 version to NGC-version.
Mip Mapping keeps the distant textures stable, not gritty while camera is moving or player moves.
Nice video! I've got an N64 game planned and this will help me make it look legit.
The N64 hardware was such a bag fumble. They packed so much power in there, but gimped it so bad that it ended up being just an expensive-to-produce sidegrade to the PSX, which was a far cheaper-to-produce and light-years weaker console.
I really wish this video was longer.
People like to hate the N64 textures and prefer the PS1 textures for some reason but to me I prefer N64 textures. My reasoning? As someone who likes to play PC games from around the same era N64 games look like 3D hardware accelerated games running on a 3DFX Voodoo card. PS1 games look like the type of games you'd see running in software rendering mode.
Even software rendered texture-mapped 3D games on DOS/Windows 95 from 1994 and on mostly tended to use some sort of perspective-correction to avoid "wobbling" texture maps.
@@Banzeken Yeah like Descent for example.
@@ironinquisitor3656 That's one good example!
I prefer PS1 because it looks more "raw" if I had to describe it
@@rac1equalsbestgame853 You can prefer the art style of the PS1 textures subjectively but from an objective technological standpoint the N64 texture filtering features are more advanced. There are a few late PS1 games that look like they have some pseudo texture filtering that looks great too.
I’ve become fascinated recently with how the PS1 and the N64 both went all in on using the imperfections of the technically inferior composite and RF signals most people were using to get the games on their TV to their advantage… yet the two consoles went about doing that in ways that were quite different.
A better way to explain interpolation is:
Prediction based in previous and future happenings.
In video engineering, optical flow for increasing or deducting frame rate to a specific number, demands prediction from previous and future frames to calculate which interframes artifacts should be shown or hided.
The optimal frame rate for any video is 1000 per second (so each millisecond has its own frame in time) but with the evolution of computation, video software for compression and optical adaption handling like Hybrid video encoder, use math to interleave non decimal frame rates allowing us to reduce usual 60 fps to be perfectly (with no hiccups) videos to be optically resampled to inferior fps, such as 25/24.
This explains why some games have certain lighting and shading in the App Store 64 which rick can’t be remade in emulators says they would look off I’m kind of a piggy person, so I like my games being 100% like how they’re supposed to look and not like how it has been ripped and emulator, but I also want every game that plays fast, but not too fast
Man, all our favorite games are just a bunch of complex math formulas. 😐
Your entire experience of reality is just signals firing in between neurons.
The whole point is you are dissecting it some decades later. Back in the Days i played on a black and white monitor not much larger then my current tablet. It was apropriet for this time and looked so much better then the competition.
The reason it's stretched seems to be it being 64x64 pixels and then stretched all over a huge cliff.
Fantastic explanation. Thank you!
back in day the consoles have small form factor, prob to reduce cost, not much later ,consoles are as big or bigger than a pc, and the tv set are bigger than the old arcades ,lol
consoles run on medium graphics with very short draw distance
Nintendo didn't care that the games look blurry and repetitive. They could just make smaller, more contained games, but if they could do this larger areas, that the other systems could not do as easily, they would, even if it looked like crap on the wrong hands.
People talk about Mario, Zelda, Conker, Banjo, and yeah, these look fine, but non AAA 3d open world games on 64 look terrible. There was a catch with texture choices and tecniques and most developers couldn'g get it right, and the results were terrible.
So... Textures were so large for a cartridge that it wouldn't mattered implementing a larger texture cache on the console?
They should have gone with 16kb cache and with a different SDRAM instead of RDRAM
Very informative!
Btw you sound like Robin from Teen Titans 😆
Imagine its a problem, and you are the developer in Nintendo, then what will you do to increase the quality? Or what they can do. I am new in this field , i found that your videos are interesting ❤
Simple. The textures were very small.
But Banjoo Tooie is not the best example. I think Jet Force Gemini is more representative of really small textures stretched in big poligon areas.
Could a 32kx8 high speed SRAM chip on the motherboard have sped up texturing and also increased the amount of textures as well? That is, the latency of the RAMBUS RAM is mitigated by having a separate source and destination for textures when buffering, but not having to worry about adding more transistors to the N64's already tightly packed GPU. Obviously this would break the unified memory architecture Nintendo has sought and added increased cost slightly. I only ask because someone on 4chan's /v/ mentioned this as being something Nintendo considered from the "Gigaleak," but they didn't source it so I'm not sure.
You know, there's a good chance it could have, but it would have been costly. That's essentially the equivalent of what they did with Flipper in the GameCube GPU with scratch pad RAM.
Can't speak to whether or not Nintendo considered it, but definitely would have helped.
Fascinating❤
The Nintendo 64 also had a very primitive style of anti-aliasing that coated the entire screen in vaseline lol -- usually implemented in software. This was in addition to some hardware blurring that was used in most games. Definitely did not help with the problem.
That is fullsceen bilineal filtering; used to hide the dithering patterns but as bilineal filtering also diminished the colors brightness they used gamma correction to counter the fullscreen bilineal filtering, making the dithering patterns visible in some high contrast areas of the screen.
In any case, "thanks" to those limitations, we had the aesthetics of N64 that has already become a classic with its blurriness, fog and smoothing. I personally love those graphics and wouldn't trade them for modern HD textures. They have just the right mix of warmth and nostalgia.
Any method to replicate this kind of visual effect in blender or an Unreal Engine Project?
stretch the uv map
In blender make your model then when texturing use a texture that is very low Res and also give it some blur by softening in in texturepaint, den when unwrapping use cube project and also scale the uvs low and stretch them and bam, also you can buy old texture CDs with textures on them that N64 games used, extra points if you get them from japan
@@xXUnhingedDevXx don't blur the texture, use a shader with the n64 semi-bilinear algorithm and have the texture itself point sampled (by tex2d)
@@TorutheRedFox well I meant as In to soften it, to actual blur I'd first use smart interpolation and then shader code
n64 games not only look blurry,they also look dark/grainy and for some reason a bit cartoony
N64 cartridges had limited storage space. Cartoony textures would take a lot less space then high detailed one.
@@I.C.Weiner i know it has limited space, but n64 just couldn't handle higher res textures
the grainy look is courtesy of dithering and then blurred with fullscreen bilineal filtering.
@@mastertigranI have seen a recent tech demo showing some extremely detailed textures in an N64 demo. At least ps2 level texture quality (maybe even above). Well above what I’ve seen possible on PS1 hardware and obviously no texture warping. I’ve tested it on actual n64 hardware. Of course just a tech demo and not a full game but incredible all the same.
@@mastertigran ruclips.net/video/plh9OGel-lM/видео.htmlsi=5k257H83J68ZZpwm
I much rather the look of a blurry texture rather than a warped pixelated texture
The CHAD lack of perspective correction 650mb CD enjoyer vs the VIRGIN blurry low res texture 16mb cartridge Yoshi's World fan
64mb (max) actually lol
reminds me of mode 7 a little...faux scrolling and zooming
N64 definitely my least favourite 5th gen console. Blurry textures & awful frame rates were the norm
So I was very lucky to try some of the first PlayStation ever made, it was shockingly good, I noticed how crisp textures bring life to the all new 3D graphics. Then the N64 was released and it looked really wrong, poor geometry and low quality textures, I was very upset, so I went with PS and never looked back.
You are wrong on all counts.
For starters most puzzling/odd/abhorrent stuff has one main reason only.
It’s surprisingly seldom that it’s multiple things conspiring into one outcome, when you get to the bottom of things.
Storage medium was not a limitation at all for textures.
On the contrary the speed and small latency of the cartridge meant new textures could be loaded super fast. And should have resulted in better textures if anything.
PlayStation games if you rip off all the FMV and Redbook music, often takes up less actual space than the N64 games, even if they can be much more careless with storage space.
RAM size, bandwidth or latency was not a limitation. Latency is a very small issue with a relatively predictable process such a texturing.
The RAM was much faster than the PlayStations RAM and larger too.
The SRAM texture cache was the only reason.
The N64 cache is actually larger but has to be loaded explicitly, which makes it not a real cache and impossible to reload when drawing a polygon.
The PlayStation cache on the other hand could be reloaded multiple times during texturing because it behaves like a simple but real cache.
The two pieces of hardware was developed concurrently and Nintendo/SGI had no chance of adjusting the design before it was too late.
The issue can be circumnavigated by texturing and modeling in a clever way, where you piece together a higher resolution texture from many separate polygons (like the Chinese puzzle in the volcano level in Mario 64).
It takes extra planning and takes a toll on the geometry.
Conker does it.
Multitexturing is also possible like Zelda does.
Nintendo should have put out a premium version of the console with a large cache halfway through the gen. And possibly a CD drive or the disc drive.
It would have fared very well against the Dreamcast and the possible M2 3DO and been completely backwards compatible.
Post in thread 'Texture cache of the N64 vs. that of Playstation' forum.beyond3d.com/threads/texture-cache-of-the-n64-vs-that-of-playstation.60851/post-2039251
yep, i always wondered how the Ps1 with 2 kbytes of texture cache could have better textures than the N64 with 4 Kbytes.
There is a bunch of inaccuracies
Can you elaborate? Would be nice to hear some constructive feedback on this!
It also allows me to provide corrections as well.
@@ZygalStudios For one, the PS1's texture cache was actually smaller at 2KB.
@@bootmii98 Yep, this is true, but this isn't something I mentioned. I wouldn't say that's an inaccuracy. That's an observation here. 3D techniques for both of these consoles is very different, each requires different hardware requirements. The 64 would have certainly benefited from a larger texture cache.
you just explained a simple thing in 8 minutes, took literally so long to explain that i dont remember anything. the only thing stretched here is your explanation time.
You are another big example that channels with low views and low subs often contain some of the most information.
back in day the consoles have small form factor, prob to reduce cost, not much later ,consoles are as big or bigger than a pc, and the tv set are bigger than the old arcades ,lol