A Couple PS1/N64-gen questions

[fearsomepirate]

I've been playing tons of N64 lately on a retro kick. I bought a machine but didn't play it much about 1 or 2 years ago, but I've recently bought piles of games from a local used game shop...sometimes I'm impressed, sometimes I'm disappointed, but a lot of the games were fun. I played the PS1 a lot back in the day, so I've got a couple questions:

1. Turok 2 runs pretty poorly in hi-res mode, but tolerably well in low-res or letterbox. It runs between 40-60fps on an emulator with my integrated video. Would this indicate that fillrate or latency are limiting the game?

2. PS1 is capable of drawing larger textures than N64, right? Does it use some sort of paging or indexing or something, or did it have a larger texture cache?

3. N64 really doesn't like hi-res mode much. Some games run ok with it. PS1 was capable of up to 640x480, but did it draw many 3D games above 320x240?

4. Anyone know the actual fillrate of the N64? I couldn't find it.

5. I have a pretty decent library of N64 games and would appreciate any suggestions. I have both Zeldas on a Cube disc. Here's my collection:
http://club.ign.com/b/list/custom?lid=105262&owner=fearsomepirate&mode=vown
Anything missing?

 

[morlock]

I belive the cartridges where very limiting for the games on N64, in contrast to the PSX. Atleast it could do mipmapping.

 

[Nesh]

Games I remember running above 320x240 right now are

Wipeout3
Rapid Racer
Tobal 1 and 2
Tekken3
Rascal
Tommy Makinen Rally
Ergheiz
Dead or Alive



Games I am not sure about

Soul Reaver
Tomb Raider3
Colony Wars

 

[Squeak]

I belive the cartridges where very limiting for the games on N64, in contrast to the PSX. Atleast it could do mipmapping.

Not really. Of course the devs had to think about the space but it wasn't a severely limiting factor. You couldn't go overboard with FMV or dubbing, but in my mind that's blessing in disguise.

The real limiting factor was the texture cache, which was the same size and speed as the PSone ditto, but wasn't nearly as effective (I don't know the specifics).

Most devs could only map textures that fit exactly within the cache, and that space was cut in half with MIP mapping, which essentially limited the max size to 32x32x4bit (really low even then).

You could do detail textures to not make ground textures seem like mud, like in OoT, but that worked far from well on all surfaces.

During that last games of the system, like Conker and MM it seems that clever devs found out a way to do 64x64 textures or higher by flushing the cache at the right moment, but by then it was 2000 and PS2 and Dolphin was looming in the horizon.

 

[fearsomepirate]

When you get down to it, is Conker really doing anything different than drawing 4 textures to simulate one larger texture? Conker and MM seem like bad examples, too, because both of those games had pretty bad framerates. The Playstation, on the other hand, had a pretty good framerate in games like Quake 2, all the while retaining the fairly high-res (at least compared to N64!) 8-bit textures of the PC version.

Most devs could only map textures that fit exactly within the cache, and that space was cut in half with MIP mapping, which essentially limited the max size to 32x32x4bit

Why would a 32x32x4bit texture be 2 KB? The image itself should take up a mere 512 bytes, so where is the other 1.5 KB going? You could have 32x32x8bit, or 32x64x4bit, etc.

 

[Squeak]

Why would a 32x32x4bit texture be 2 KB? The image itself should take up a mere 512 bytes, so where is the other 1.5 KB going? You could have 32x32x8bit, or 32x64x4bit, etc.

Because the MIP maps also need space. AFAICR the cache wasn't really as much a cache as it was a chunck of memory controlled by software, so you need the MIP maps to be in there while rendering the texture stretch.
You can't really use non square textures for anything other than sprites. If you want MIP mapping and tiling you need the textures to be square.

When you get down to it, is Conker really doing anything different than drawing 4 textures to simulate one larger texture?

Maybe not, again i don't know the specifics of how it was done. But does it really matter if the result is the same?

Conker and MM seem like bad examples, too, because both of those games had pretty bad framerates. The Playstation, on the other hand, had a pretty good framerate in games like Quake 2, all the while retaining the fairly high-res (at least compared to N64!) 8-bit textures of the PC version.

Quake 2 is a pretty simple geometry and lightning wise, compared to Conker and MM which had to render a complex main character all the time, plus global and local lights, Conker even had advanced shadowmapping on a N64 FFS!

 

[fearsomepirate]

Because the MIP maps also need space.

If you have a 32x32x4bit texture, your mip maps will all be smaller, say 16x16x4bit...that's only 128 bytes per mip-map. At 128 bytes apiece, you're not going to have 3.5 KB of mip maps. The way I understand it, when you mip map on the N64, you have 2KB for your texture and 2KB for your mip maps, not 512 bytes for your textures and 3.5KB for your mip maps.

Quake 2 is a pretty simple geometry and lightning wise,

It's "lighting," not "lightning." I'm comparing Quake 2 N64 to Quake 2 PS1. The PS1 version had better textures. Why? Global and local lights shouldn't affect texture resolution.

 

[ERP]

1. Turok 2 runs pretty poorly in hi-res mode, but tolerably well in low-res or letterbox. It runs between 40-60fps on an emulator with my integrated video. Would this indicate that fillrate or latency are limiting the game?

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)

2. PS1 is capable of drawing larger textures than N64, right? Does it use some sort of paging or indexing or something, or did it have a larger texture cache?

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.

3. N64 really doesn't like hi-res mode much. Some games run ok with it. PS1 was capable of up to 640x480, but did it draw many 3D games above 320x240?

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.

4. Anyone know the actual fillrate of the N64? I couldn't find it.

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.

5. I have a pretty decent library of N64 games and would appreciate any suggestions. I have both Zeldas on a Cube disc. Here's my collection:
http://club.ign.com/b/list/custom?lid=105262&owner=fearsomepirate&mode=vown
Anything missing?

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.

 

[fearsomepirate]

If you don't mind explaining something, because I know how tiresome it can be to be the "go-to" guy for everyone's questions, what gave the PS1 a memory advantage over the N64, despite lower bandwidth? Did it have lower latency memory, more efficient/automated management, was it having separate VRAM and audio memory, or what?

 

[Squeak]

It's "lighting," not "lightning." I'm comparing Quake 2 N64 to Quake 2 PS1. The PS1 version had better textures. Why? Global and local lights shouldn't affect texture resolution.

I'm so sorry, I gotta stop using FF spell checking .
Anyhow, you were talking about framerate, and I gave a possible explanation of why those N64 games has unstable framerate (not textures but advanced lighting).
But now that ERP has entered the thread, I think me continuing would be redundant.

 

[ERP]

If you don't mind explaining something, because I know how tiresome it can be to be the "go-to" guy for everyone's questions, what gave the PS1 a memory advantage over the N64, despite lower bandwidth? Did it have lower latency memory, more efficient/automated management, was it having separate VRAM and audio memory, or what?

I think it's unfair to characterise the PS1 as having a memory speed advantage over the N64, while it's true that the memory system was one os N64's biggest weaknesses, it doesn't really say anything about how it compared to PS1.

On the graphics side having seperate VRAM in PS1 means minimal contention and more predictable behavior. But even there is your comparing like to like, i.e. No Z then the N64 has a fillrate advantage IME.

In terms of access to main memory it was expensive on either platform, and neither had a good cache architecture but the N64's processor was clocked almost 3x the speed of the one in the PS1, so any penalty was relatively higher. On top of that you had the contention between the CPU and the other devices on the same bus and the memory latency was probably higher in real terms (actual ns measurements).

Comparing parts of consoles is a somewhat pointless excercise, You don't run a game on the memory subsystem alone. Most of the time how well somethng is put together as a whole is more important than the obvious core pieces.

Comparing N64 to PS1 as a whole is somewhat interesting only because on paper N64 was better in almost every measurable respect (I'd exclude audio from the list) at a hardware level and yet I'd argue that most of the best looking titles from that gen are on the PS1 side of the fence. And frankly IMO CD wasn't a factor for most of them and it has little to do with hardware in general (although I could bitch about the texture cache indefinitely), there were just very few "A" Teams working on N64.

 

[fearsomepirate]

Well, I just figured that since the memory subsystem is where everything fits together, and that's what people complain the most about, that was probably what was breaking everything down. It also is what Nintendo paid the most attention to on the Gamecube. It just seems bizarre to me that as much faster as everything on the N64 was, games generally had fewer polygons and lower-res textures than PS1 titles. You've got to admit, translating more RAM, higher bandwidth, and more powerful processors into worse graphics (minus bilinear filtering) is a pretty astounding feat.

I guess it's interesting to me because I've been playing a lot of 64 games lately, and I'll sometimes see these flashes of brilliant that indicate the hardware was way, way more capable than most of the games would indicate.

Judging by stuff you've said, that Z-buffer made a lot of difference. Now, why would the PS1 be able to get away without using a Z-buffer while the N64 needed one? Why didn't more N64 programmers just do whatever they did on PS1 to manage depth?

 

[swaaye]

Oh I wouldn't go so far as to say N64 was ever really inferior to PS1. Bilinear filtering and perspective correct texture mapping were serious improvements to image quality. Just compare Gran Turismo to World Driver sometime. World Driver blows it totally out of the water, graphically. N64 frequently had some decent full-screen AA going too. Goldeneye is a good example of it in action.

I never saw N64 as inferior in its graphics hardware. The overall game library quality is a totally different story though.

 

[Fafalada]

Now, why would the PS1 be able to get away without using a Z-buffer while the N64 needed one? Why didn't more N64 programmers just do whatever they did on PS1 to manage depth?

PS1 display lists were DMA chains of references, so sorting the packets was a simple as changing sequence of addresses. In other words, it was relatively "easy" to use it for primitive depth sorting.
I'm not sure how N64 graphic subsystem consumed data, but given the presence of ZBuffer, chances are dynamically reordering display lists wasn't as easy.

Relatively on-topic, I managed to try Demo1 for PS1 the other day on PSP. It's quite neat seeing those tech-demos(T-Rex and Co.) on a portable screen, and it seems to work pretty perfect (hats off to Sony emulation teams).
It was also something of a showcase for CD music - some pretty cool tunes in there.

 

[fearsomepirate]

I would agree that when the N64 is really going, it blows the PS1 away. Even in low-res mode, Turok 2 really pops, and I was pretty impressed with WDC, Rogue Squadron, and Shadow Man. Jet Force Gemini looks really good, too. It's just that you'd think that with the higher clockspeeds and more RAM, you'd get some more polygons and better texturing out of the thing.

Also somewhat on topic, I had no idea the N64 could do (faux?) environment mapping like in Blast Corps.

 

[swaaye]

N64's enviro mapping was publicized heavily even before launch. Metal mario in Mario64 was all the rage.

 

[Nesh]

I think PS1 also had games with some enviromental mapping similar to that of Mario's as well

 

[Fafalada]

They both supported alpha blending and UV texture mapping, hence they could both do "environment"mapping.

 

[ERP]

PS1 display lists were DMA chains of references, so sorting the packets was a simple as changing sequence of addresses. In other words, it was relatively "easy" to use it for primitive depth sorting.
I'm not sure how N64 graphic subsystem consumed data, but given the presence of ZBuffer, chances are dynamically reordering display lists wasn't as easy.

Relatively on-topic, I managed to try Demo1 for PS1 the other day on PSP. It's quite neat seeing those tech-demos(T-Rex and Co.) on a portable screen, and it seems to work pretty perfect (hats off to Sony emulation teams).
It was also something of a showcase for CD music - some pretty cool tunes in there.

I'm not sure the N64 needed one, as I've stated before World Driver doesn't use it, but it was clearly something the ArtX thought was important enough to include. And the only Nintendo supplied uCode that made it practical to omit the ZBuffer didn't come until very late and was feature incomplete.

At a hardware level you build command lists in memory and DMA them to the local memory on the RSP, the RSP runs arbitrary code on the command list and eventually you output rendering primitives to the RDP. Most uCode writes this back out to memory into a circular buffer for the RDP to read (increasing the load on main memory), although it was technically possible for the RDP to read directly from RSP memory RAM was so restricted, the RDP tended to starve.

Reordering is certainly not as simple as on PS1, but you could run sets of static display lists in arbitrary orders pretty easilly.

I think most people used the Zbuffer because it was there.

16 bit Z Buffers suck BTW.

 

[Panajev2001a]

I just love reading this thread .