Handmade Hero » Forums » Code » Debugging Keyboard Issues (Day 028)
6 posts
#13514 Debugging Keyboard Issues (Day 028)
4 months ago Edited by on Nov. 14, 2017, 10:11 p.m.

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.
Simon Anciaux
342 posts
#13515 Debugging Keyboard Issues
4 months ago

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.
6 posts
#13517 Debugging Keyboard Issues (Day 028)
4 months ago Edited by on Nov. 14, 2017, 10:24 p.m.

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.

Mārtiņš Možeiko
1600 posts
1 project
#13518 Debugging Keyboard Issues (Day 028)
4 months ago Edited by Mārtiņš Možeiko on Nov. 14, 2017, 11:41 p.m.

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