Question

I have a problem that I think is caused by the wm_keyup message not being sent correctly. I believe that the same problem occurs in Minecraft when you move your character and the input will get ‘stuck’. The action of the key continues after you pressed it and doesn’t cease until you tap the key again. I heard that it could be an issue between windows and the keyboard but I’m not completely sure. Also, most other mainstream games don’t have this problem so there must be a correct way to do it. This is what my windows procedure code looks like:

    case WM_KEYDOWN:
        for (list<KeyInput>::iterator t = key_inputs.begin(); t != key_inputs.end(); ++t)
            (*t).PushKeyDown(ConvertKeyCode(wparam));
    return 0;

    case WM_KEYUP:
        for (list<KeyInput>::iterator t = key_inputs.begin(); t != key_inputs.end(); ++t)
            (*t).PushKeyUp(ConvertKeyCode(wparam));
    return 0;

Each KeyInput object has a queue that gets filled with key inputs and is emptied as keyboard input is requested. This code is for a multithreaded game and this technique ensures that no input is missed on any thread. I am using mutual exclusion in the KeyInput objects.

I get this problem more in my game than in Minecraft and I have no idea why. I also got it before when I was doing simpler, non-multithreaded code. I don’t know how to fix this.

I appreciate any help or suggestions anyone has to offer.

Answer 1

After looking at the documentation for the WM_KEYDOWN message I found out that the 31st bit of lparam tells whether or not the last keydown message was the same as the latest. If you use this info to ignore repeat messages, you can get rid of the problem (but you lose repeat input from the key when it is held down). Here is my code:

case WM_KEYDOWN:
{
    union
    {
        uint lparam;
        struct { uint bits:30,_30:1,_31:1; };
    } lparam_data;
    lparam_data.lparam = lparam;

    if (!lparam_data._30)
        // key was pushed
    return 0;
}