By using this site, you agree to our Privacy Policy and our Terms of Use. Close
SvennoJ on 27 May 2023
Edit Thread
Wyrdness said:
haxxiy said:

That's not true. The PS3 OS takes up the same RAM as the X360 OS, around 20-50 MB in the background. However, it has a split architecture where half the total RAM was VRAM and couldn't be directly accessed by the CPU. So the PS3 had to juggle the OS and the rest of the game in 256 MB while the X360 could split graphics, game, and OS between 512 MB as needed.

It wasn't the (modest to present-day standards) savefile size that caused the lag issues, contrary to popular belief, since most of it doesn't even load at once. It's just people playing the game that eventually led to the game fetching enough data when first loading to overflow an already-filled bucket.

The real question one should ask is: why are TOTK savefiles limited to just around 3 MB when, for instance, Minecraft can create a 2 GB save file on Switch?

I'd argue that it *is* indeed because of a technical limitation, to prevent users from building complex machines and overloading the physics engine (which coincidentally is Havok, the very same used in Skyrim and Fallout 4).

If the CPU had been able to handle more complex interactions (whether or not that would've been technically possible for the Switch to have such a CPU is another matter), it's quite likely that build permanence would have been a thing in the game, at least to an extent.

It's not true but then you proceed to say it's an architecture problem which is what I said? Okay...

You don't seem to follow what's being said it's not about save file size it's about the actual saved playthrough itself becoming unplayable because it eats up too many resources because of permanent changes it has to track. So again the is no hardware that will ever deliver this in a seamless huge open world like TOTK because this concept has a dead end flaw that the is no way around the can only ever really be limited or partial permanence. 

Go watch TOTK videos before you claim you can't build complex machines I've linked one recently in the Zelda thread. 

If the ps3 had 2 x 512MB split memory instead of 2 x 256MB it would not have been a problem. Therefore a hardware limitation. Arguing about architecture is irrelevant as that's part of the hardware design.

And Skyrim became unplayable on ps3 because it had to track too many changes, the change log in memory got too big. Plus an ancient engine with lousy garbage cleanup. The game did remain playable, but only after turning off all auto save features and restarting the game every 15 minutes. Either some memory leak or broken garbage cleanup routines, as load the same save file from a fresh start and it worked again (for a while) FS2020 had the same problem initially, the clean-up routines to store cache lagged behind the fetch routines causing the game to use more and more memory. I clocked it at using 51GB ram before it finally crashed, already running horribly maxing out the page file.

You can throw more RAM at it, or optimize the engine. But first you need enough RAM and storage to actually keep track of everything. With enough storage you can track everything in a huge seamless open world. Either in the cloud, in ram or on disk. I've worked on that myself in GPS navigation with maps of entire Europe and US with user changes and updates anywhere, share-able online. Basically a dynamic map stored as a multi level quad tree with bit flags to indicate where changes are, with a hash table to lookup the actual changes in an efficient way. You can build onto it yourself (but mostly used for temporary closures, direction changes, speed traps, traffic jams etc etc) And that ran on piss poor hardware nearly 20 years ago with little ram. Streaming data back and forth to disk, fetching what's relevant. Surely a game can do that as well...

Dynamic machines, sure, they will only be active in a bubble around the player, just like any other moving parts like NPCs. The enemies don't patrol on the other side of the map either. That's the whole point of storage, go out of range, freeze and store until back in range. Minecraft does that as well. I don't expect to make a harvester that keeps running on the other side of the map. That's left to MMO style games that run in the cloud. (Although there are plenty ways to simplify stuff in case of harvesters or machines that appear to keep on going by logging the output. Games are deterministic by nature, everything can be turned back into an equation when the user is absent)