That's not going to happen. That would be too much work for devs. And we all know how they are.
Baseless Next Generation Rumors with no Technical Merits [post E3 2019, pre GDC 2020] [XBSX, PS5]
- Thread starter BRiT
- Start date
- Status
That's quite a big ask IMO. Realistically, I think a memory dump is the best solution as it'll work with everything, from the biggest first-party title to the next GTA to the smallest Indie. At best, perhaps an optional optimised solution? But in the time it takes a dev to design and implement a data-structure that identifies key-states and world-reconstruction around those, price for NAND will have halved again.
Just ride out the first couple of years of constrained storage until capacious storage is cheap, same as the original PS360 consoles and their paltry 20 GB HDDs.
D
Deleted member 11852
Guest
You say that a million+ apps work like this on iOS - including games like Civ VI. I assume Android does something similar. If Apple can make this that easy, Sony have too.
It was required from the get go on android and ios or at least at one of the major milestone releases. A bit harder to do once the programs have already been written and released. Sure they could add an api and tie it to terms, but that's only going forward.
D
Deleted member 11852
Guest
Good point, although for backwards compatibility, you're talking smaller RAM sizes to begin with.
Going forward we're likely looking at 12-16Gb of useable RAM per game. It guess it depends how much solid state storage they include but assuming 16Gb a game, six games will eat almost 100Gb of space. Yikes.
It doesn't have to be complicated. The OS can automatically save any RAM flagged as 'state' on allocation and the OS will save that the user switches games. It would be wasteful if gigabytes of textures (which already exist on the SSD) are saved again - especially as Mark Cerny made a concerted point about elimiating dupe data to get the most out of the SSD space.
Games would require an API for boot and load the state (skipping any menu) but is this really that much different to existing loading code?
Really? Every game has to be able to save and restore its game state, so all physics objects need their motions, collisions, etc. saved, all animations saved at their frame count, all audio saved in its part-played state, and recovered? I've never heard of such a thing in Unity and AFAIK games are either suspended in memory or more normally closed. Have you a link to any of this?
Save games, saving all the necessary data to reconstruct your play, happen by and large at given points. I'd expect a suspend/resume to be different. Presently, that's done by keeping the memory state exactly as is through a low-power mode. Suspend/resume for multiple games working the same way would need a memory dump. The alternative is a fast load/save but that's not quite the same.
D
Deleted member 11852
Guest
This is certainly how it works on iOS but it could be realtime except, I assume Apple's motivations for not doing this is for experience immediacy e.g. if the user wants to open a new app, any old app could be flushed from RAM immediately. That said, UIKIt does this for he UI if the system terminates your app. The inconsistency is Apple's.
What I was really referring too was the concept of clearly defined save state and API to allow near seemless suspemd/resume. This does require a little effort as not all iOS apps support this. But on a device primarily designed for playing and switching games, I'd expect Sony to not make the same compromises as Apple.
Tkumpathenurple
Veteran
That would be desirable. I expect they'll brute force it to begin with - since it's essentially suspend/resume with copying to/from the SSD - and gradually work towards it. As said, textures and audio don't need to be included in the savestate, so I suppose that'd be quite an easy first step.
What you are asking is already there in almost all games: it's the standard save feature. Remember, HDDs will be gone on nextgen so a loading from a save should be sufficiently quick for most people.
I think on PS5 they plan to load only one specific part of the game to make the loadings even shorter.
D
Deleted member 11852
Guest
Save is a different problem because only the game needs to know where in RAM the save state data is, but for suspend and resume the OS needs to know. You don't want every game needing to have its own save-state implementation on top of whatever save/quick-save mechanics it already has - if any. Some games want to you live with the consequences of your actions.
I think it was around gdc 2019 that he 9.216 rumor started. That would've been 2-3 months before github became public. The talks picked up again when 5700 and xt were announced and specs were leaked.
That same GDC leak by Josh also mentioned 12Gig of GDDR6 + 4Gig DDR4 which I think is total bogus. No way in hell PS5 has this little amount of usable ram for games, pretty sure the 4 Gig DDR4 is for OS.
anexanhume
Veteran
That account is an MS fanboy conspiracy theorist.
all out non-technical baseless drivel.
Reveal is few weeks/months away.
Weeks I can wait but not months! So you got the internal specs for XSX but not PS5 then?
Betanumerical
Veteran
Im pretty sure his reply is a hint that is only from the GitHub leak.
Do you want a riot? Because this is how you get a riot.
- Status
Similar threads
- Locked
