Hi all,

I'm on episode 28, where, after drawing a tilemap, we're moving the player just using the keyboard, but the player doesn't move. I'm going to try to debug this myself, but there's a fundamental problem:

Obviously, I need to press a keyboard key so I can see follow that keyboard press through the code. But I can't work out how to do that in debug mode in VS, 'cause I need to be pressing keys in order to step through the code. Like, when I was debugging my controller, I could simply hold the analog stick with one hand and step through simultaneously using the keyboard to see what was happening, but I can't work out how to do something equivalent in order to check how it's processing my keyboard presses.

I did a check with OutputDebugStringA, so I know they're being recognized and going through ProcessPendingMessages and ProcessKeyboardMessages, I just wanna be able to either retain or enter keyboard-input while debugging so I can see how exactly they're (not) being passed through the player movement code.

Any help would be appreciated, thanks.

One simple thing is to put a breakpoint in the window message loop for the WM_KEYDOWN and WM_KEYUP messages and step from there. After the message is received, you don't need to keep the key pressed. But be careful with WM_KEYDOWN because the debugger will take the focus and your window will not get the WM_KEYUP message, so the key will stay pressed.

Another way is to log messages with OutputDebugString in the Visual Studio output panel.

Thanks, I did try something like that before with no luck, so after reading your message I tried a couple more times, and I think I see what was happening when trying to debug it:

The key was recognized only if I pressed and held the key after the window is created. I guess that's because if the key is pressed down throughout, there's no change from WasDown to IsDown, but if I press it after I see the window created, there's a split-second of !WasDown and then it becomes IsDown, and the key is recognized.

As for what the actual issue was:

Casey set up player X and player Y (which are stored in a struct), compiled and ran the .exe (so the player is on the screen), and then he removed those declarations. Then he wrote some code to handle how X and Y change with the keyboard input, then compiled (and thus dynamically reloaded) the new code. So player X and Y were still in memory (because game_state is in PermanentStorage) so they could be changed by keyboard input.
But I shut down the .exe between those changes to the code, so when I ran it, there was no player X or Y in memory, so there was nothing to manipulate.

Kinda annoying, but hey, at least I learned that structs aren't automatically initalized to zero. The more you know...

Hopefully anybody else who gets caught out by this will spare themselves some time by finding this thread.

> at least I learned that structs aren't automatically initalized to zero. The more you know...

The type of variable does not matter. struct/class/bool/int/float/pointer - they are initialized only on where they are declared, not what type they are.

Local variables - not initialized.
static and/or global variables - initialized to 0. Including structs.