yeah this can only work if implemented by the devs. The only reason this can be done for some older emulated games is that there is only a megabyte or two needed to capture the state of the entire system. Not several gigabytes.
I was under the assumption the collections that utilize this system do it by just saving the inputs and timestamps and simulate them as such rather than understanding the entire whole state. I’m not sure how it works with non-seeded elements
I do agree with you about the dev focus. It would be way more complex even though if feasible if you can simulate without it graphically but you I can’t imagine it just being a system similar to recording or achievements
that only really works with deterministic systems though. You could do that with a 6502 or simple systems because you could perfectly predict what the state of the system would be in just by replaying inputs. everything up to predicting all cache misses.
consider a badly written game on a modern console (remember that save states should work for any game) in which physics is tied to framerate. Follow the chain… framerate depends on system speed… which, indirectly depends on the ambient temperature (a console running in a hot climate would throttle earlier than one running in an air conditioned cool room). And because modern systems execute more than one process, it also depends on what else is running (were you downloading a game in the background, slowing down the game ever so slightly?) or unpredictable things such as interrupts on certain system timers. And the list goes on and on. Even if the game didn’t have physics depending on framerate, differing deltaTime on each frame means different floating point rounding errors happen, which could accumulate over time.
So in this case, replaying inputs does not get you the exact state. you were in. there are just too many variables.
No game should save gigabytes. Even megabytes can be too much. If the game is very linear a save could mean a single number. Even if it has character cosmetic customization and a convoluted plot with lots of choices it’s still usually in the kilobyte range. The larger saves (overall) would be sports games like rally racing where the game needs to be able to provide a thorough replay of every race.
system state is not the same as a save file. System state is the cpu registers, the process’ entire memory space (because you don’t know what the game might do at any point) gpu context, etc.
edit: example: the save file for older games was measured in bytes. System state is much larger han that. It contains everything not just what the developer decided to allow you to save.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
yeah this can only work if implemented by the devs. The only reason this can be done for some older emulated games is that there is only a megabyte or two needed to capture the state of the entire system. Not several gigabytes.
I was under the assumption the collections that utilize this system do it by just saving the inputs and timestamps and simulate them as such rather than understanding the entire whole state. I’m not sure how it works with non-seeded elements
I do agree with you about the dev focus. It would be way more complex even though if feasible if you can simulate without it graphically but you I can’t imagine it just being a system similar to recording or achievements
that only really works with deterministic systems though. You could do that with a 6502 or simple systems because you could perfectly predict what the state of the system would be in just by replaying inputs. everything up to predicting all cache misses.
consider a badly written game on a modern console (remember that save states should work for any game) in which physics is tied to framerate. Follow the chain… framerate depends on system speed… which, indirectly depends on the ambient temperature (a console running in a hot climate would throttle earlier than one running in an air conditioned cool room). And because modern systems execute more than one process, it also depends on what else is running (were you downloading a game in the background, slowing down the game ever so slightly?) or unpredictable things such as interrupts on certain system timers. And the list goes on and on. Even if the game didn’t have physics depending on framerate, differing deltaTime on each frame means different floating point rounding errors happen, which could accumulate over time.
So in this case, replaying inputs does not get you the exact state. you were in. there are just too many variables.
No game should save gigabytes. Even megabytes can be too much. If the game is very linear a save could mean a single number. Even if it has character cosmetic customization and a convoluted plot with lots of choices it’s still usually in the kilobyte range. The larger saves (overall) would be sports games like rally racing where the game needs to be able to provide a thorough replay of every race.
deleted by creator
system state is not the same as a save file. System state is the cpu registers, the process’ entire memory space (because you don’t know what the game might do at any point) gpu context, etc.
edit: example: the save file for older games was measured in bytes. System state is much larger han that. It contains everything not just what the developer decided to allow you to save.
My BG3 saves are massive. Not at the PC but very much in the Gigabytes