Sega Saturn, its limitations, the fifth generation and the VDP-2 Factor

[roce]

Not only that, N64 runs some ps1 games at lower frame rate like Donald Duck goin' Quackers 15~20fps PS1 30fps most of the time, how I can imagine Crash Bandicoot above 20fps on N64 ?

I was thinking about this wrt the Crash precalculated poly ordering. Most of the Crash Bandicoot cd is taken by that data, which is completely unnecessary on N64. So it'd fit on a cart, and google says Crash 1 had "1800 polygons per frame, and Crash 2 cracked 3,100 polys per frame" - that would run 30fps or maybe even 60fps on N64. Crash main games run 30fps on PS1 according to reddit. The models aren't even textured for the most part, just vertex colored.

Would be rather fun to see Crash N64 running faster and looking better, ha.

[SegaAMD]

that would run 30fps or maybe even 60fps on N64. Crash main games run 30fps on PS1 according to reddit. The models aren't even textured for the most part, just vertex colored.

Would be rather fun to see Crash N64 running faster and looking better, ha.

Sweet illusion, the N64 doesn't run complex games at 60fps and in many games it doesn't reach 30fps, this is a fact, a practical limitation of the system.

Donald Duck Goin Quackers (a Crash like game) was released on the N64 in the year 2000 with the best tools available and using the Rayman 2 engine optimized for the N64. however it failed to reach 30fps. It runs in the 15-20fps range. the N64's strengths are in other areas, in other types of games.

there are other multiplatform games made simultaneously for both consoles but running at a lower frame rate on the N64, games in which we see that there was no sabotage or ill will from the producers.

on previous pages I put some numbers fps for n64 games, few games maybe 7 run at 60fps It's also hard to find any advanced game that runs at least at 30fps the best graphics on the platform are around 20fps. It's an amazing console but unfortunately full of bottlenecks.

[TrekkiesUnite118]

Sweet illusion, the N64 doesn't run complex games at 60fps and in many games it doesn't reach 30fps, this is a fact, a practical limitation of the system.

It's not really a practical limitation of the system. It's just that the system at the time was very difficult to work with and trying to keep the CPU, RCP, and RDP from fighting with each other for RAM access was a challenge. If you can figure that all out, you should be able to hit a decent framerate on N64 while drawing a complex scene. See what was posted earlier.

[SegaAMD]

It's not really a practical limitation of the system. It's just that the system at the time was very difficult to work with and trying to keep the CPU, RCP, and RDP from fighting with each other for RAM access was a challenge. If you can figure that all out, you should be able to hit a decent framerate on N64 while drawing a complex scene. See what was posted earlier.

I can't agree on this, nothing explains the console having 10 (or less) games at 60fps or Donald Duck (2000 third generation of SDK) using Rayman 2 engine to 15-20fps. I'm not an engineer but based on what the console has shown throughout the generation it's easy to see that there is a practical limitation in this aspect. and it's not just about 60fps games, 30fps games are also hard to find on the system. later I will compile a complete list of games that run at 30fps and we will see that they are not great exponents in technologies.

[TrekkiesUnite118]

I can't agree on this, nothing explains the console having 10 (or less) games at 60fps or Donald Duck (2000 third generation of SDK) using Rayman 2 engine to 15-20fps. I'm not an engineer but based on what the console has shown throughout the generation it's easy to see that there is a practical limitation in this aspect. and it's not just about 60fps games, 30fps games are also hard to find on the system. later I will compile a complete list of games that run at 30fps and we will see that they are not great exponents in technologies.

I'll explain it for you right now. The System has 4MB of RAM on a shared bus. Everything uses the same RAM. The CPU, GPU, etc. The more each tries to access the RAM, the more they'll lock out the other parts of the system causing stalls and slowing things down. Throw in that it was RDRAM which didn't really have the best performance and you start to have a serious challenge on your hands.

So to boil it down as simple as possible for you, if the GPU is currently doing operations that require it to use RAM, the CPU is locked out and can't get access to do what it needs to do. So it has to sit and wait. If the CPU is doing something with RAM, the GPU is locked out and can't access RAM to do what it needs to do. So again, it has to sit and wait. So to get good performance, you need to work around this and make sure that neither the CPU or GPU is stalling the other parts of the system, or that they do it as little as possible. A lot of developers of the time didn't fully understand this or didn't have the time or resources to truly optimize things around this. Nintendo themselves struggled with this in their flagship titles like Mario 64.

[axel]

A lot of developers of the time didn't fully understand this or didn't have the time or resources to truly optimize things around this. Nintendo themselves struggled with this in their flagship titles like Mario 64.

After seeing the optimizations in the Kaze videos I think Nintendo probably did much of the development of Mario 64 before they even had a prototype ready. Their code is perfectly adequate if you are running on an SGI workstation but isn't optimized for the N64's unique architecture. This is how Kaze is able to get such big improvements by rewriting those functions.