I'm just starting out in the wonderful world of windows api programming. I've cruised the net trying to find an answer but no luck so far. I'm trying to make a basic space invaders game to get myself going here. Using real easy rectangles and such so I can work on the api and program flow. I've come to the part where I need keyboard input to move the player and read gunfire. I've manged to use WM_KEYDOWN to read keyboard input so I can move the character left or right and the spacebar to shoot. The problem I have is that it seems like WM_KEYDOWN only reads 1 key at a time. So I can either more or shoot but not both. If I am moving left and I hit the spacebar to fire I stop moving. I could only find one other person who was asking about this type of question with google and it was on a MSDN forum and he didn't really get the answer to his question. So I guess I'm asking is there a way to get input from both keys at the same time and if so how or do I need to move on to something more like directinput? Thanks for any help.

Maintain an array of keys that you turn on or off depending on if you receive a WM_KEYDOWN or WM_KEYUP message. So you can check if several keys are pressed at once eg. if(Keys[VK_SPACE] && Keys[VK_LEFT])...

You could probably use GetAsyncKeyState(). I moved to DirectInput when I had that problem. Also, one problem I had with trying to use something similar to what Headkaze suggested was that windows only seems to recognize up to 6 key-downs, and then any additional keypresses are kind of screwy (i.e. holding down 6 keys and then pressing a seventh). It probably wouldn't be too much of a problem since I doubt a space invaders game needs to respond to 6 simultaneous key events, but it might cause problem later on I suppose.

Quote:Original post by sotsilent
You could probably use GetAsyncKeyState(). I moved to DirectInput when I had that problem.

Domn't do that [smile].

Quote:Original post by sotsilent
Also, one problem I had with trying to use something similar to what Headkaze suggested was that windows only seems to recognize up to 6 key-downs, and then any additional keypresses are kind of screwy (i.e. holding down 6 keys and then pressing a seventh). It probably wouldn't be too much of a problem since I doubt a space invaders game needs to respond to 6 simultaneous key events, but it might cause problem later on I suppose.

That's a physical hardware limitation of the keyboard, due to the way they work. You're lucky if you can get 6 keys, usually you'll only get 3 or 4.

As for the original problem, it sounds like you're moving each time you get a WM_KEYDOWN message. WM_KEYDOWN messages are sent when Windows' key-repeat kicks in. You'll probably want to do what Headkaze suggests, using an array of bool's indicating what keys are down and which are up.

Thanks for the help everyone. I'll give the array a try and go from there.

I'm having the same issue and even before searching was already using bool values to track key presses. My issues is that for diagonal movement I'm allowing 2 keys to indicate it. The movement begins but then stops after moving for a second (or essentially half a animation cycle (which is about 8 frames)).

Where is the best place to put the bool logic for this? Not right where the WM_KEYDOWN switch is?

Also my keyup logic is only verifying if either the left or right key has gone up and then using that to set diagonal movement in that direction to false. Is this a bad idea?

What it feels like is occurring is that the api is reporting a keyup in the miliseconds that the keydown data iterates and this is setting it to off. Probably not it at all but kind of feels like it. I can't think of why it would cause the animation and movement to freeze.

Anyone have any ideas? I know this has to be an easy fix.

2d

PS: Sorry for rezing this thread. It super relevant though.

Its going to be a problem with your logic, because simply maintaining an array should work fine.

This is the code I use and my stuff works fine with more than one key


case WM_KEYDOWN:
Key[wParam]=true;
break;
case WM_KEYUP:
Key[wParam]=false;
break;

Please disregard, I figured this out.

Basically the blitting and position update logic needed some work, where the diagonal movement was moved before the normal movement. Worked like a champ.

I also was able to improve the key down logic to allow for many more down keys in the future.

Thanks empirical2 for the comments. You are right.

2d