It is currently Sat Oct 21, 2017 10:53 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 34 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Fri Jun 09, 2017 5:09 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
I've been wondering if it's possible to pull off a recognizable version of The Legend of Zelda: Breath of the Wild on the Nintendo 64. Since I haven't played BotW and have no game development expertise above SNES level (which is probably a bridge too far for this game), the following is mostly handwaving:

Physics is easy as long as you're clever and don't just run everything all the time. The math is really very simple, and if you watch your code size the N64 has a disproportionately powerful CPU. Rocket: Robot on Wheels used real physics.

Distant terrain doesn't have to be rendered every frame if you can scroll and zoom the backdrop. The killer is pan, really, and scroll is a trivial way to accomplish that in between skybox updates. Zoom just drops the required update speed even further. You could even have multiple backdrops with different update speeds, with only the near field updating at the full 20 fps or whatever. Mind you, I haven't tried this; it just seems reasonable... You might get some weird-looking artifacting in edge cases, but perhaps you could mitigate some of it with some reasonably inexpensive image warping... I'm getting out of my depth here...

With heavy use of terrain LOD and billboarding, maybe some procedural geometry/textures to finish up the near field without busting the storage limits... you'd never be able to pull it off on Playstation, but with data streaming from cartridge like in Infernal Machine, plus a custom microcode to push the RCP as far as it will go, I think an open-world game of this size might just be feasible on N64.

Maybe I'm underestimating the difficulty of combining all those interactive systems on such a primitive CPU. But honestly it doesn't seem that hard if you're clever and don't try to use brute force. It might not turn out exactly the same in all cases, but I don't see why something that feels similar enough to the player should be out of reach.

Apparently a lot of open-world games are CPU-bound due to the enormous amount of stuff that has to happen independent of the player; NPC actions and such. Has anyone who's played Zelda got a good idea of whether this element is likely to be a problem?

I get the feeling that world state might be an issue, with only 8 MB of RAM. Perhaps efficiencies could be had and shortcuts taken; one bit per chest/enemy should about do it, with extra storage only when the player is nearby... I'm sure nobody would mind if boulders replaced themselves once you got too far away...


Top
 Profile  
 
PostPosted: Fri Jun 09, 2017 5:37 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5728
Location: Canada
It's obviously "possible" in some form, but that doesn't seem like a very difficult question. What kind of answer are you hoping to hear?

Are you going to work on it for a few years, or...?


Top
 Profile  
 
PostPosted: Fri Jun 09, 2017 6:35 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
No, I don't think one guy working for a few years would accomplish much on a task like that, not as a hobby. I've already spent a few years on a SNES game of a type that's proven to be tractable for one person, and I haven't gotten very far even on that. It's just an idle thought, which is why it's in General and not Other Retro Dev.

I was hoping somebody might have more specific comments about what you'd have to change, how much of a hit it would take in what areas, stuff like that. My lack of experience means I really have no idea why this sort of game is so CPU-intensive on a modern platform. I can see why the graphics would have to be downgraded, but even there I don't have any relevant experience so I'm just creatively extrapolating from what I see in other N64 games.

The draw distance in BotW is an important part of the game, so I tried to come up with a way to get that without bringing the system to a standstill (like that one golf game with textured polygons on SNES). I had half-baked ideas about environmental fogging, lighting/shadows and faking fields of long grass without drowning the system in enough billboards to choke a Gamecube, but I felt the post was long enough already.

Maybe my brain is fried; work has been stressful lately. If nobody's interested, or if there really isn't a way to have an interesting conversation about it without actual hardware testing, the thread will just die I guess...


Top
 Profile  
 
PostPosted: Fri Jun 09, 2017 7:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19114
Location: NE Indiana, USA (NTSC)
To test this hypothesis, we'd first need a open world terrain data set the size of a considerable fraction of Skyrim under a free data license. How fine would the terrain data need to be? And where would one go about finding that?


Top
 Profile  
 
PostPosted: Fri Jun 09, 2017 9:55 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
Breath of the Wild is already ugly enough. :lol:


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 2:06 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 558
I'll have to get back to you once I reach BotW in my backlog, estimated at 2060 or so :D

@tepples
Terrains of any size can be generated at will. Ryzom may also have some readily available, haven't checked as I've only used textures from it.


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 3:50 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 248
For open world N64 see Body Harvest. You could skin it, and that would probably give you a decent idea on the limits. RAM is going to be the killer, you don't just have 8MB to hold game data, you have to hold everything, code,textures, verts, data etc and all in the 8MB.


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 4:15 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19114
Location: NE Indiana, USA (NTSC)
And a substantial fraction of players won't have the Expansion Pak.


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 7:48 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
tepples wrote:
How fine would the terrain data need to be?

Not sure. It depends on how reasonable it might be to augment a coarse mesh procedurally on a 93.75 MHz R4300i with 24 KB of L1 cache and clunky indirect RAM access.

Espozo wrote:
Breath of the Wild is already ugly enough. :lol:

It's one of the least ugly games I've ever seen. What are you, an anisotropic filtering snob?

Oziphantom wrote:
For open world N64 see Body Harvest. You could skin it, and that would probably give you a decent idea on the limits. RAM is going to be the killer, you don't just have 8MB to hold game data, you have to hold everything, code,textures, verts, data etc and all in the 8MB.

Body Harvest uses a ton of fogging to hide pop-in. It's also a (much-delayed) first-generation game that I imagine uses some variant of Fast3D and doesn't seem to use terrain LOD. It also doesn't use the Expansion Pak. I'm suggesting taking a novel approach to maximizing draw distance.

With custom microcodes, the N64 could supposedly exceed 180,000 polygons per second, roughly twice what Fast3D could handle. That's fully textured, filtered, lit etc. Even on the Wii U and Switch, most of the texture detail is lost in haze in the distance, so using Gouraud shading on solid colours might be enough for the majority of terrain elements. And if my dynamic nested skybox idea from the OP could be realized in some form, distant geometry wouldn't need to be rendered very often, which would allow a vastly higher polygon count for the same computational load.

Furthermore, for distant terrain the level of detail can be very low, hopefully allowing the mesh to fit into 8 MB of RAM with room for everything else. Progressively higher-detail meshes can be loaded dynamically from the cartridge as the player moves. Though I wonder if the Sheikah Scope would need special handling, and/or maybe a limit on pan speed, to avoid misinforming the player too badly...

Things like shrines and (especially) towers have to be visible from a long way off, but they can be billboarded easily enough. The Divine Beasts would take special handling because they move, but they don't exactly dominate your field of view until you get close so the load should be light.

Considering the slow render rate of the backdrops and the reasonably quick cartridge bus specification (50 MB/s), I was kinda wondering if it might be reasonable to stream mesh data from the cartridge for the furthest backdrops. But I'm not sure the cartridge speed can be relied on; I've seen numbers not much higher than 5 MB/s, or twice what the SNES DMA unit can do, and that might be pushing it if we're trying to keep the load share low...

tepples wrote:
And a substantial fraction of players won't have the Expansion Pak.

Sucks to be them. They deserve it for not appreciating the masterpiece that is Donkey Kong 64.


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 8:31 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19114
Location: NE Indiana, USA (NTSC)
93143 wrote:
tepples wrote:
And a substantial fraction of players won't have the Expansion Pak.

Sucks to be them.

Would it be practical to manufacture new Expansion Paks? If not, that'd be like MMC5 homebrew on NES or Super FX homebrew on Super NES.


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 8:50 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6289
Location: Seattle
93143 wrote:
I'm not sure the cartridge speed can be relied on; I've seen numbers not much higher than 5 MB/s, or twice what the SNES DMA unit can do, and that might be pushing it if we're trying to keep the load share low...
The default, and, if I understand the rumor correctly, only actually used, values for the cartridge bus yields 5.4MB/sec.

As far as I can tell, it should be trivial to get ≈16MB/sec out of the cartridge interface. Getting all the way up to the 25MHz might start being a tricky engineering problem. But one can certainly get SQI-capable NOR flash now that's capable of 104MHz, so the external engineering challenges should be doable...

The fastest theoretical bandwidth should be transfers of 64KiW at a time, taking 2FSB per word plus a fixed overhead of 52FSB, or 62MB/sec. This should "only" be the same challenges as designing a 'conventional' PCI (i.e. not PCIe) card.


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 8:53 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19114
Location: NE Indiana, USA (NTSC)
Or even just on the order of 2 KiW if you want to write a library that implements a more conventional virtual memory approach.


Top
 Profile  
 
PostPosted: Sun Jun 11, 2017 12:01 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
93143 wrote:
It's one of the least ugly games I've ever seen. What are you, an anisotropic filtering snob?

No; but I'll show you what I'll tell you what I find really ugly in this screenshot:

Image

The leaves on the trees are just large, randomly intersecting planes, and the loss of detail the further away from the camera is some of the most intense I've ever seen; The landscape looks like it's made of Play-Doh. Lighting also seems to break further from the camera; the trees don't appear to cast shadows. I wouldn't complain about this if the game had good performance, but it experienced framerate drops at 30fps, 900p, which is already pretty bad in itself. Fast RMX looks a bazillion times better and runs at 60fps, 1080p, but it's also not an open world game, so it's not a fair comparison (but I still feel Nintendo could have done much better).

93143 wrote:
Sucks to be them. They deserve it for not appreciating the masterpiece that is Donkey Kong 64.

Basically what I was thinking.

tepples wrote:
Would it be practical to manufacture new Expansion Paks? If not, that'd be like MMC5 homebrew on NES or Super FX homebrew on Super NES.

Dude, tepples, it's 4MB of ram with an edge connector vs a custom microchip. Apparently, 3rd party expansion packs have been made:

Image

Nothing would be compatible with this, but it would still be cool to see someone expand the expansion pack ram from 4MB to 12MB, if that's all the N64 can address.


Top
 Profile  
 
PostPosted: Sun Jun 11, 2017 1:07 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10065
Location: Rio de Janeiro - Brazil
That shading on Link(?) is atrocious.


Top
 Profile  
 
PostPosted: Sun Jun 11, 2017 1:58 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 558
Xenoblade looks better than that, and it was an open-world game on the Wii.

And yeah, if you wanted, you could build new expansion paks. The patents are naturally expired for that type of RDRAM anyway, having been manufactured in 1996.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group