I wonder if some kind soul could spend some time and tell me where I went wrong with the live code editing. My looping works, but the state is never initialized to the captured game state when the L key is pressed. The game just repeats the input over and over. So if I press forward and move 30 pixels, instead of resetting the "player" to the default position, it keeps adding 30 to the previous value. I've been staring at my code and trying to compare to Caseys, but I just can't see what I'm doing wrong.
It appears that my game memory that I'm writing to the disk is full of 0s, however, the gameMemory struct passed to the game engine seems to have valid data in it. I'm sure it's something simple and I'll loudly bang my head on my desk once it's pointed out.
Handmade.cpp:
http://pastebin.com/ViRdE9U3
Handmade.h:
http://pastebin.com/rJXv2gYF
win32_handmade.cpp:
http://pastebin.com/DXGpA4e6
It appears that my game memory that I'm writing to the disk is full of 0s, however, the gameMemory struct passed to the game engine seems to have valid data in it. I'm sure it's something simple and I'll loudly bang my head on my desk once it's pointed out.
Handmade.cpp:
http://pastebin.com/ViRdE9U3
Handmade.h:
http://pastebin.com/rJXv2gYF
win32_handmade.cpp:
http://pastebin.com/DXGpA4e6
Edited by Jason
on
you forgot to paste the win32_handmade.h file, so I can't check but.. You should try this:
change
to
You got wrong the third argument of the WriteFile Call :)
I hope is just this one!
Let me know
Cheers
change
1 2 3 4 5 6 7 8 | static void Win32BeginRecordingInput(win32_state *win32State, int inputRecordingIndex)
{
win32State->inputRecordingIndex = inputRecordingIndex;
....
WriteFile(win32State->recordingHandle, win32State->gameMemoryBlock, (DWORD)win32State->totalSize, &bytesWritten, 0);
game_state *testState = (game_state*)win32State->gameMemoryBlock;
}
|
to
1 2 3 4 5 6 7 8 | static void Win32BeginRecordingInput(win32_state *win32State, int inputRecordingIndex)
{
win32State->inputRecordingIndex = inputRecordingIndex;
....
WriteFile(win32State->recordingHandle, win32State->gameMemoryBlock, bytesToWrite, &bytesWritten, 0);
game_state *testState = (game_state*)win32State->gameMemoryBlock;
}
|
You got wrong the third argument of the WriteFile Call :)
I hope is just this one!
Let me know
Cheers
Edited by rizoma
on
bytesToWrite is initialized like this
so it should not matter.
- you can check bytesWritten to make sure you wrote the right amount of bytes to the disk.
- You may check the written file to make sure it doesn't contains only zeros (by writing a small program to do so or using an hex editor). The game state is huge (2GB I think) and is mostly filled with zeroes at that point in the project.
- You may check that bytesRead == bytesToRead in the BeginInputPlayback and that it restored the data in win32State->gameMemoryBlock
Since it seems that you're not modifying the state, it looks like you aren't reading the file from the disk (if you were reading zeros, the game would crash or do something unexpected).
1 | DWORD bytesTowrite = (DWORD)win32State->totalSize; |
so it should not matter.
- you can check bytesWritten to make sure you wrote the right amount of bytes to the disk.
- You may check the written file to make sure it doesn't contains only zeros (by writing a small program to do so or using an hex editor). The game state is huge (2GB I think) and is mostly filled with zeroes at that point in the project.
- You may check that bytesRead == bytesToRead in the BeginInputPlayback and that it restored the data in win32State->gameMemoryBlock
Since it seems that you're not modifying the state, it looks like you aren't reading the file from the disk (if you were reading zeros, the game would crash or do something unexpected).
Debugging is half of the fun :)
I found the problem. It was really a confusing issue because my bytes written/read were right, the memory locations being read/written were right, and I didn't see any problems with that code.
I took some time away and finally came back fresh to debug. I noticed stepping through the debugger that after the win32_handmade.cpp called gameUpdateAndRender(), that the address in the permanentStorage pointer changed. That shouldn't happen.
If you look at lines 84-91 in handmade.cpp, you'll see some initialization code for much of the data in the permanent storage memory. This is where the gameMemory->permanentStorage pointer address was changed. A look at line 71 reveals the problem. I cast the entire game memory to a game_state struct instead of the gameMemory->permanentStorage location.
This wouldn't have been a problem if the permenantStorage pointer was the first item in my game_memory struct, but it wasn't. Because of this, the offsets to write the data was completely wrong when I tried to read/write any game_state values, it was actually writing those values in 64 bit space meant to hold the address to the permanentStorage, and thus corrupting the memory of the game state. I can't believe this didn't crash or manifest itself in a more obvious way, but at least I was able to think it out and find reasons why things were happening.
I feel much better now that I've found it. Now back to Caseys videos to see what else I break :p.
Thanks for the replies, suggestions and encouragement.
I took some time away and finally came back fresh to debug. I noticed stepping through the debugger that after the win32_handmade.cpp called gameUpdateAndRender(), that the address in the permanentStorage pointer changed. That shouldn't happen.
If you look at lines 84-91 in handmade.cpp, you'll see some initialization code for much of the data in the permanent storage memory. This is where the gameMemory->permanentStorage pointer address was changed. A look at line 71 reveals the problem. I cast the entire game memory to a game_state struct instead of the gameMemory->permanentStorage location.
This wouldn't have been a problem if the permenantStorage pointer was the first item in my game_memory struct, but it wasn't. Because of this, the offsets to write the data was completely wrong when I tried to read/write any game_state values, it was actually writing those values in 64 bit space meant to hold the address to the permanentStorage, and thus corrupting the memory of the game state. I can't believe this didn't crash or manifest itself in a more obvious way, but at least I was able to think it out and find reasons why things were happening.
I feel much better now that I've found it. Now back to Caseys videos to see what else I break :p.
Thanks for the replies, suggestions and encouragement.
Edited by Jason
on