Hi everybody,
If I understand correctly, the recording and playback mechanism is restoring game state, to some specific point of time,
it does it by passing the entire game state into game dll every frame. But what happens with the running threads?
For example, asset loading queues, what happen to them?
If I understand correctly, the recording and playback mechanism is restoring game state, to some specific point of time,
it does it by passing the entire game state into game dll every frame. But what happens with the running threads?
For example, asset loading queues, what happen to them?
Edited by CyberK
on
Reason: Initial post
Are you speaking about a particular day ? It would help knowing which one so we are on the same page.
If I remember correctly (big if), the loop recording/playback doesn't restore the memory each frame. It load the first frame memory and then playback the keyboard inputs for following frames. For threads, I think that the game waits for current threads to finished their work before starting to record or starting to playback. I'm not sure. But you could probably find out by stepping in the code to see what happens when the record/play keys are pressed.
If I remember correctly (big if), the loop recording/playback doesn't restore the memory each frame. It load the first frame memory and then playback the keyboard inputs for following frames. For threads, I think that the game waits for current threads to finished their work before starting to record or starting to playback. I'm not sure. But you could probably find out by stepping in the code to see what happens when the record/play keys are pressed.
Go through Day 023, it should be clear how the looped live code editting works.
IIRC, when you start recording, the whole game memory block is saved into a local file "loop_edit_x_state.hmi", and there is a "loop_edit_1_input.hmi" file created, which is for saving the game input data of every frame. The "loop_edit_1_input.hmi" file stop recording the game input when you hit the recording button again.
During playback, it just overwrites the game memory block with content of "state.hmi" file, and overwrites the game input of every frame with content of "input.hmi" file.
The loop process is trivial, you can find out the detail in the code base (if you've pre-ordered the game.)
Remember that, a) the game is always running during the looped live code editting process, and 2) the game memory always starts at the same base address. Don't complicate the situation, it's just a copying-and-pasting trick that Casey uses, based on the underlying structure of the program (separate platform from game).
IIRC, when you start recording, the whole game memory block is saved into a local file "loop_edit_x_state.hmi", and there is a "loop_edit_1_input.hmi" file created, which is for saving the game input data of every frame. The "loop_edit_1_input.hmi" file stop recording the game input when you hit the recording button again.
During playback, it just overwrites the game memory block with content of "state.hmi" file, and overwrites the game input of every frame with content of "input.hmi" file.
The loop process is trivial, you can find out the detail in the code base (if you've pre-ordered the game.)
... to some specific point of time, it does it by passing the entire game state into game dll every frame.
Remember that, a) the game is always running during the looped live code editting process, and 2) the game memory always starts at the same base address. Don't complicate the situation, it's just a copying-and-pasting trick that Casey uses, based on the underlying structure of the program (separate platform from game).
Edited by robinbin
on