So, I had an issue where my keyboard input wouldn't work, and after much looking back over the videos and debugging, I found that my controller button processing was killing my keyboard updates. Did I miss something where Casey handled this? Basically, When I press the down key, the key state gets set like it should, then my code continues down and does Win32ProcessXInputDigitalButton on the A button of the non-existent game pad. This then clears the state that was set by the keyboard. My two input processing functions:
1 2 3 4 5 6 7 8 9 10 11 | internal void win32ProcessXInputDigitalButton(DWORD buttonState, GameButtonState *oldState, DWORD buttonBit, GameButtonState *newState)
{
newState->endedDown = ((buttonState & buttonBit) == buttonBit);
newState->halfTransitionCount = (oldState->endedDown != newState->endedDown) ? 1 : 0;
}
internal void win32ProcessKeyboardMessage(GameButtonState *newState, bool32 isDown)
{
newState->endedDown = isDown;
newState->halfTransitionCount++;
}
|
Casey decided to treat keyboard as controller 0, and alla gamepades as controllers 1 to 4.
So win32ProcessKeyboardMessage should be called only for Controller with index 0. And win32ProcessXInputDigitalButton will be called for Controllers with index from 1 to 4. They never change same GameButtonState structure.
So win32ProcessKeyboardMessage should be called only for Controller with index 0. And win32ProcessXInputDigitalButton will be called for Controllers with index from 1 to 4. They never change same GameButtonState structure.