I'm following day 017 successfully up until Casey puts the assert check for endedDown around 24:43. The assert check seems to fail and crash the program once any arrow key is pressed since Win32ProcessKeyboardMessages() appears to be called twice for a single keystroke. That resets the endedDown and isDown comparison to a equal and incorrect state, as evidenced by the debug statements. The assertion fails because the states are meant to be unequal in order to preserve, from what I understand, the previous state of the keyboard input.

Please see the attached image (click to enlarge) for what I mean.



I'm sure it's a stupid typo I've made, but I'm just in a rut here. Any help getting to the bottom of this would be much appreciated. I've spent about 2 hours trying to fix this and am stumped since the code is as he types in.

With the assert disabled but all the code before it added, the screen only shifts by 1 pixel even when the down arrow is held down, which I find strange. It's as if the new code isn't being seen.

Update: The good news is that 017-source compiles perfectly, so it's definitely something wonky in my local code. I'd like to know what's wonky though, but it could just be something underlying fixed in the later part of the video.

Check carefully where Win32ProcessKeyboardMessages is called. And it what situations. What is message, what is wparam, what is lparam? Answering these questions will make it clear why it is called in wrong time.

It was an insane effort, but I got back to feature parity by literally merging my code into the clean 017 source with personal formatting, comments, and all! I never found out why the method was called twice...

I learned that cl stops building after 100+ errors. lol

If you're trying to learn, you should try to figure out the problem instead of trying to move on. Solving bugs is a huge part of programming and a skill that is important and will benefit you more than moving on faster (in my opinion).

A few advice:
- If you can't find the solution after 2 hours, take a break. Often when you come back you'll find the solution quickly.
- Don't try to solve the issue by comparing the code to Casey's. Try to figure out why your code behaves differently and than verify it with the handmade hero code.
- Use the debugger, place a breakpoint in the Win32ProcessKeyboardMessages function and look in the call stack from where it was called. Inspect variables don't assume their values are correct.
- Keyboard and mouse input debugging is sometimes harder because pausing the program with the debugger will make you release the key and so no more message for that key will be received if you step. Logging messages with OutputDebugString helps a lot in those case. But be sure to also output messages for marking the frame start, the start and end of processing windows messages and other important step in you main loop. This should make it obvious in the log if something happens at an unexpected time.
- If you ask for help, provide your code (if possible with a simple way to compile it), not a screenshot, otherwise we won't be able to help you.