The main problem is that there’s no way to (as far as I know) lock memory into a state where modifications won’t affect it. This is necessary because reading through 16 GB of RAM and writing it to disk, or even to SSD, or even to a separate block of memory, takes a non-trivial amount of time and during that time stuff within that 16GB is changing. Without the ability to prevent updates temporarily, you need every process and thread in the game to stop instantaneously in a consistent state and keep them paused while the snapshot is happening. Otherwise you end up with an inconsistent snapshot, which you may be tempted to handwave away, but realistically this means your save games won’t load properly or will load with bizarre bugs like you passed a certain threshold that was supposed to give you an item but the inventory was in a lower part of RAM and got saved with no item yet, and the threshold was in a higher part of RAM that was saved later, so now your game is loaded back up and you don’t have the item but you’re already passed the threshold so you can’t get it again. That’s just an obvious example to help understand the issue, but realistically the bugs even in a single snapshot will probably be very numerous and extremely subtle, quickly turning into massive corruption and making the game unplayable and the save unloadable.
I don’t think this is realistically possible without running it in a virtual machine, which adds so much performance impact that your game won’t run well, which means nobody’s ever going to do it.
You can suspend a program so it doesn’t change state until resumed. I’ve even seen at least 1 tool that allows you to pause games not normally able to be paused.
And if doing it exactly like an emulator isn’t feasible, perhaps it can be truncated the way the game itself saves and just lock specific values down like what your stats are, what triggers have been triggered, your position and inventory, etc. This would require different profiles for every single game, tho, to find the address values that need to be stored to restore later.
They obviously know more than I do then. I would recommend asking them if they can implement a save/load state function to their tool. It’s not within the realm of any functionality that I know about.
I don’t think this is realistically possible without running it in a virtual machine
Seems like a Linux kernel specially developed to have this feature could potentially pull it off. You wouldn’t need to stop all processes or store the entire contents of RAM, just pause the processes involved in the game and store the contents of the memory currently assigned to those processes. Since the kernel is already in charge of process management and memory management, this seems theoretically possible. Just don’t allow the game to use any more CPU cycles at all until all game-related RAM is copied onto a save file on disk. The game will appear to freeze for an appreciable amount of time while this happens, but after that it should resume … basically the same as if you were running a CPU-intensive game on a CPU that was woefully inadequate for it and the game froze/stuttered due to waiting on the CPU. Then, the save state could be loaded by the kernel just creating a new process with the same parameters as the original one, loading that information from disk into memory, then un-pausing that process.
It would have to be done at a very deep level and be baked right into the kernel, though.
(If you have sufficient RAM, the same basic process could maybe be done more quickly and efficiently by copying all game-assigned RAM into a new allocation in unused RAM, rather than saving it to disk. There will probably still be a noticeable stutter, but the game should spend much less time ‘frozen’ that way. I guess, come to think of it, this technique could also be used as a write cache for writing to disk, so you could save states to disk without needing to pause the game for as long. Would only work if your system has enough RAM to hold everything the game is using twice, plus overhead for the OS. But in systems with 32GB or more, that’s unlikely to be a problem. Even 16GB systems could do it, depending on how RAM-intensive the game is.)
The main problem is that there’s no way to (as far as I know) lock memory into a state where modifications won’t affect it. This is necessary because reading through 16 GB of RAM and writing it to disk, or even to SSD, or even to a separate block of memory, takes a non-trivial amount of time and during that time stuff within that 16GB is changing. Without the ability to prevent updates temporarily, you need every process and thread in the game to stop instantaneously in a consistent state and keep them paused while the snapshot is happening. Otherwise you end up with an inconsistent snapshot, which you may be tempted to handwave away, but realistically this means your save games won’t load properly or will load with bizarre bugs like you passed a certain threshold that was supposed to give you an item but the inventory was in a lower part of RAM and got saved with no item yet, and the threshold was in a higher part of RAM that was saved later, so now your game is loaded back up and you don’t have the item but you’re already passed the threshold so you can’t get it again. That’s just an obvious example to help understand the issue, but realistically the bugs even in a single snapshot will probably be very numerous and extremely subtle, quickly turning into massive corruption and making the game unplayable and the save unloadable.
I don’t think this is realistically possible without running it in a virtual machine, which adds so much performance impact that your game won’t run well, which means nobody’s ever going to do it.
You can suspend a program so it doesn’t change state until resumed. I’ve even seen at least 1 tool that allows you to pause games not normally able to be paused.
And if doing it exactly like an emulator isn’t feasible, perhaps it can be truncated the way the game itself saves and just lock specific values down like what your stats are, what triggers have been triggered, your position and inventory, etc. This would require different profiles for every single game, tho, to find the address values that need to be stored to restore later.
They obviously know more than I do then. I would recommend asking them if they can implement a save/load state function to their tool. It’s not within the realm of any functionality that I know about.
Seems like a Linux kernel specially developed to have this feature could potentially pull it off. You wouldn’t need to stop all processes or store the entire contents of RAM, just pause the processes involved in the game and store the contents of the memory currently assigned to those processes. Since the kernel is already in charge of process management and memory management, this seems theoretically possible. Just don’t allow the game to use any more CPU cycles at all until all game-related RAM is copied onto a save file on disk. The game will appear to freeze for an appreciable amount of time while this happens, but after that it should resume … basically the same as if you were running a CPU-intensive game on a CPU that was woefully inadequate for it and the game froze/stuttered due to waiting on the CPU. Then, the save state could be loaded by the kernel just creating a new process with the same parameters as the original one, loading that information from disk into memory, then un-pausing that process.
It would have to be done at a very deep level and be baked right into the kernel, though.
(If you have sufficient RAM, the same basic process could maybe be done more quickly and efficiently by copying all game-assigned RAM into a new allocation in unused RAM, rather than saving it to disk. There will probably still be a noticeable stutter, but the game should spend much less time ‘frozen’ that way. I guess, come to think of it, this technique could also be used as a write cache for writing to disk, so you could save states to disk without needing to pause the game for as long. Would only work if your system has enough RAM to hold everything the game is using twice, plus overhead for the OS. But in systems with 32GB or more, that’s unlikely to be a problem. Even 16GB systems could do it, depending on how RAM-intensive the game is.)