Hyrule Field in OOT for the N64.

[DeadlyNinja]

I've always been wondering, is the reason for the barrenness of Hyrule Field for OOT purely a limitation of the N64's power? Do they make enemies appear at night because of the greatly reduced view distance? When you're adult Link, there aren't any enemies unless you count the ghosts. Is it because as adult Link, you had Epona and that added further stress to the system preventing it from rendering more than 1 ghost? Just how much did the scale of Hyrule Field stretch the N64 hardware?

 

[Rangers]

I dont know but that was pretty much the first free ranging open world RPG landscape I ever saw, very astonishing at the time.

It was like "wow see all that stuff off in the distances? Those are actual places you can go!".

 

[mikiex]

Its possible you are correct Id have to play it again to give a full opinion. I think they used some lod methods and were quite clever in the way they put it all together. It was impressive for it's time. Also consider scale is an illusion, in terms of people think bigger means more data.

The level designed eg. where hills are was important

 

[almighty]

That same filed looks the same on the 3DS version but has much improved textures and effects

 

[V3]

I thought Mario 64 levels were more impressive than OOT field even though it is smaller. I think the Kokiri forest stressed the N64 more than the main field, the frame rate was quite bad in that area. I remember getting motion sick in there.

 

[DeadlyNinja]

That same filed looks the same on the 3DS version but has much improved textures and effects

Yeah, one of the things that pissed me off about the remake was them not adding enemies to Hyrule Field. The 3DS would easily handle more than just an empty barren field.

While we're on the subject, why was the RAM Pak needed to create larger rooms in Majora's Mask? I thought the extra RAM only meant more textures or higher resolution textures, not the ability to pump more polygons.

The level designed eg. where hills are was important

What do you mean by that? Can you elaborate on this?

 

[Ninjaprime]

I would guess a poly limitation. IIRC, poly count was the main weakness of the N64 hardware, unless you made custom microcode, which was really difficult. Link on screen is already using a bunch, and long view distances(relative to other N64 games) only strained that further. RAM was probably a consideration as well, being a big area, adding more AI/code/models probably was a bad idea. They really shouldn't have cheaped out and shipped it with the 8 megs it was supposed to have.

 

[function]

The cart on the N64 was really slow to access too, so in addition to other considerations they could have been giving themselves time to stream in new data with large transitional areas.

 

[mikiex]

I would guess a poly limitation. IIRC, poly count was the main weakness of the N64 hardware, unless you made custom microcode, which was really difficult. Link on screen is already using a bunch, and long view distances(relative to other N64 games) only strained that further. RAM was probably a consideration as well, being a big area, adding more AI/code/models probably was a bad idea. They really shouldn't have cheaped out and shipped it with the 8 megs it was supposed to have.

Poly count was a problem and working cross platform with ps1 often meant two sets of level data. This was because the ps1 could shift more polys, but you had to use more anyway to reduce warping of textures (no perspective correction)

The n64 had positives such as perspective correction, filtering and even zbuffering (although it was of limited use - lack of memory) speaking of which it only had 4kb texture cache and no colour add blending (what idiot left that out!) - it was a pretty hideous bit of kit as was the ps1.

 

[DeadlyNinja]

They really shouldn't have cheaped out and shipped it with the 8 megs it was supposed to have.

Really? I never heard of the system being originall designed with 8 megs of RAM. I mean, I know about the RAM pak, but wasn't that also designed because it worked with the 64DD?

What is the N64's peak polygonal performance? Wikipedia says 150,000, but Nintendo Power and Next Generation Mag says 100,000.

 

[swaaye]

It has been said on here that the 100k poly figure is with all rendering features in use with one of the SGI microcodes. The homebrew microcodes from developers greatly improved its efficiency, and developers learned how to deal with its nasty quirks. Look at World Driver Championship or Conker, or the smooth full screen 640x480 of Indiana Jones. And there were also big audio improvements like Dolby Prologic with realtime 3D positioning.

Do some searches for threads where ERP stopped in. There are also old IGN64 interviews to look up.

 

[Ninjaprime]

Really? I never heard of the system being originall designed with 8 megs of RAM. I mean, I know about the RAM pak, but wasn't that also designed because it worked with the 64DD?

What is the N64's peak polygonal performance? Wikipedia says 150,000, but Nintendo Power and Next Generation Mag says 100,000.

IIRC, the RAM pak only existed because nintendo wanted to get the 64 out the door faster and cheaper, and at $249 with no game it was already higher than they wanted to launch it at, which was $199. So they dropped the RAM with the plan that some addon, the 64DD, could add it in later and it would be like a whole new console once more RAM was added. Of course the 64DD, like most addons, failed horribly and was barely even released at all, so they cooked up the plan to sell the RAM pak.

 

[swaaye]

I wonder what that RAMBUS RAM cost in '96. This was when most video cards under $300 were packing 1-4MB of EDO or FPM RAM.

 

[mikiex]

Yeah, one of the things that pissed me off about the remake was them not adding enemies to Hyrule Field. The 3DS would easily handle more than just an empty barren field.

While we're on the subject, why was the RAM Pak needed to create larger rooms in Majora's Mask? I thought the extra RAM only meant more textures or higher resolution textures, not the ability to pump more polygons.



What do you mean by that? Can you elaborate on this?

http://www.spriters-resource.com/community/showthread.php?tid=15960&page=13
Just found someone here has ripped the main model used, you can see it pretty low poly
approx (1500 polys).

If you look there is a central hill that blocks the view of other parts of the map if you stand at the edge, its probably there for interest as well, but it does mean you cannot see data that would LOD all in one view. If you stand on the hill you only see half the map (well depending on the FOV).

Interesting hexagon layout

 

[DeadlyNinja]

http://www.spriters-resource.com/community/showthread.php?tid=15960&page=13
Just found someone here has ripped the main model used, you can see it pretty low poly
approx (1500 polys).

If you look there is a central hill that blocks the view of other parts of the map if you stand at the edge, its probably there for interest as well, but it does mean you cannot see data that would LOD all in one view. If you stand on the hill you only see half the map (well depending on the FOV).

Interesting hexagon layout

Pretty low poly by today's standard, or pretty low poly even by N64 standards?

 

[mikiex]

Pretty low poly by today's standard, or pretty low poly even by N64 standards?

Its extremely low by todays standards.

To be honest its been so many years since I worked on N64 I cannot remember how many polys we were pushing on it, but it looks like a fairly normal amount. On PSX you could not draw such big polys because of the lack of texture correction. Also it looks from the youtube videos that they used multilayer texturing to make the ground look less repetitive.

 

[Iron Tiger]

Its extremely low by todays standards.

To be honest its been so many years since I worked on N64 I cannot remember how many polys we were pushing on it, but it looks like a fairly normal amount. On PSX you could not draw such big polys because of the lack of texture correction. Also it looks from the youtube videos that they used multilayer texturing to make the ground look less repetitive.

Today, and even a little later in the N64's life, polys get used more efficiently. Instead of linking primitives with a lot of occluded geometry, we make models out of contiguous skins. I think Turok 2 was the first to tout the feature. That game may have used fewer polys to make better-looking models.

 

[Squeak]

The biggest mistake with the N64 bar none, was the texture cache. My theory is that they were so sure of themselves, that they had the absolute best tech, that they didn't bother to check with the competition.

If they had seen Playstations performance with texture resolution (even though it was non perspective corrected and point sampled), they would no doubt had done something to make it better.

It was not that the texture cache/scratchpad was too small. It was actually double the size of the Playstations (4Kb vs. 2Kb). It was the implementation that lacked. It required programmer management and it seems they didn't take into account the requirements of using MIPmaps.
Now, software managed scratchpads are fine and can in many cases be preferable to real caches. But it appears that Nintendo either didn't supply the right tools to manage it, or that the programmers simply didn't want to or had the expertise to do it.

There were improvements over the course of the N64s life (compare Conker to the first gen games), but it was incremental improvements and never a complete alleviation of the texture disadvantage.

Pitty really, because the N64 was otherwise way ahead of the Playstation and Saturn in it's architecture, sometimes only in theory and in concept, but when used right mostly also in realworld abilities.

In no particular order:
It had something akin to a pixelshader in the register combiner
it had programmable transformation
It had the texture filtering
It had very fast unified memory
It had a z-buffer
it had software driven sound (just like all consoles today).

With regards to geometry complexity, if they had cut back on some of the filtering, the N64 would have easily bested the Playstation in polycount. It was only Nintendo's reluctance to let developers do that, that kept it from happening.

The N64 should have had the texture cache fixed, either by software, if possible, or from the start. And it should have launched with the N64DD, either as standard or as an option or from the getgo.
It would have done wonders for the N64's other big failing, cartridge price.

 

[Roly]

Squeak, I definitely agree that the texture cache issue was a drawback - though the texturing still seemed (to me) to be relatively strong for its generation - and superior to the PS1 and Saturn. The approximated bilinear filtering was (again) for me, a huge advantage. Better tools, and earlier access to the RCP microcode would have been ideal (though presumably some of the Rare games were using custom microcode). Still, the stronger games seemed well-ahead of the competition from Sony and Sega (though I appreciate there is a diversity of opinion here).

As a side observation, I did note that Perfect Dark appeared to use point sampling on some surfaces (the distant buildings), but otherwise, I cannot remember ever encountering it.

I suppose if there was a hypothetical 'super N64', I'd be inclined to abandon the expansion pak, include 6MB in the launch console, and improve the memory controllers, and maybe the memory bus.

 

[Squeak]

No, I actually think the machine was for the most part limited in the way it was for good sound reasons. The RDRAM must've been pretty dang expensive for the time. 4Mb was the limit if you actually wanted to sell the console.
Nintendo saved a lot by not having a drive in the machine, and was therefore able to put a little extra silicon in it.

But I think the 64DD was a really great idea and it should have been available from the very start, to let people know they had the option if they wanted to. It's not as if it was groundbreaking tech back then. The ZIP drive launched in 94 with similar tech in a 100Mb format.
It would have been pretty trivial to release all games on disc too. Later when price fell they would have combined the two into one standard console. If the modem had been included, as it was in the initial release, they could have been the first to offer downloadable games too.

The only thing that really needed fixing was the texture buffer.

That and the analog stick should probably also have been of a sturdier design, with a better joint.
Just about the best analog I ever tried when it was new, but it deteriorated over time and got more and more play to the point where it was just flopping around on some demopods.
I fixed it on mine though by lubing it with silicone and using two fingers on the side of the disc, instead a single tumb on the top, so the joint wasn't subjected to downward pressure.