I watched Handmade Hero Day 023 - Looped Live Code Editing and had me wondering why you would record the game state every frame? If you were to just record the initial 64MB game state then just record input for the rest of the recording wouldn't you get the same result when you play it back?
Edited by mojobojo
on
That's what I'm doing. I have a snapshot.mem file that contains the initial state, then an input.mem that I append the input struct to every frame.
Err, that's what the codebase already does? Not sure what you guys are saying here... when you start a looped live code edit, it writes the mem block, and then for the rest of the frames, it just writes the input. That's exactly how it currently works.
- Casey
- Casey
Maybe the OP is not calling your Win32RecordInput(&Win32State, NewInput) in the game loop?
@mojobojo
Look here:
@mojobojo
Look here:
1 2 3 4 5 6 7 8 9 | if(Win32State.InputRecordingIndex)
{
Win32RecordInput(&Win32State, NewInput);
}
if(Win32State.InputPlayingIndex)
{
Win32PlayBackInput(&Win32State, NewInput);
}
|
cmuratori
Err, that's what the codebase already does? Not sure what you guys are saying here... when you start a looped live code edit, it writes the mem block, and then for the rest of the frames, it just writes the input. That's exactly how it currently works.
- Casey
I looked back at the video and it was just me misunderstanding what happened in the stream. When I saw that big file I thought it was because it was the entire state recorded every frame. I was unaware recording just the input was going to make a large file that quickly.
Edited by mojobojo
on
The file is large because it is actually saving all the memory that is allocated, not just the 64 megabytes. It has nothing to do with the input, the input is tiny.
- Casey
- Casey
Yeah, my input is 440bytes per frame. I haven't looked to see how big Casey's version is. But even after a few seconds of input recording, the input portion is still well below 100Kb.