Register
Handmade Hero»Forums»Code»Looped recording and playback (threads and tasks queues)
1 posts
Looped recording and playback (threads and tasks queues)
5 months, 3 weeks ago Edited by CyberK on Dec. 5, 2019, 2:29 p.m. Reason: Initial post
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?
Simon Anciaux
791 posts
Looped recording and playback (threads and tasks queues)
5 months, 3 weeks ago
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.
1 posts
Looped recording and playback (threads and tasks queues)
5 months, 3 weeks ago Edited by robinbin on Dec. 7, 2019, 8:50 a.m.
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.)

... 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).