This works fine, except that when I press the UP key and the LEFT key at the same time, I want the game to react to both keypresses. Right now only one of them happens. I tried like if ((code & KeyEvent.VK_UP) == 1), but this did not work, so obviously code does not hold a flag of pressed keys.

this happens only for up+left? ... This looks fine, problem is probably way you handle it in game. For simple test, add System.out.println(....) to both conditions and see if you get text printed out for both keys when you press them at the same time, you should get 2 lines in one pass through keyPressed().

if (Keyboard.isKeyDown(Keyboard.KEY_LEFT))Globals.offsetX--;if (Keyboard.isKeyDown(Keyboard.KEY_UP))Globals.offsetY--;

And if I press both left and up buttons, I will go in a diagonal direction. With a KeyListener, when I press both buttons I get something like this:

upleftleftleftleft....

So when one key starts to prevail it will not allow the other one to take control. The KeyEventListener has special support for the shift, alt and ctrl keys, but I don't see how it will support something like I want.

My guess is I need somehow to discard the last keypress, so that Java would evaluate it again. But in any case I'm not sure what's going on.

LooL !!! You can post your code and I'll tell you what is wrong. The main thing is that the variable code (int code = key.getKeyCode() can remeber only one value. So when you press a new button code it will change into the code of the last button pressed and it won't remember that you are still holding down the previous keys. When you use the boolean variables you don't change the up value into false because you just pressed left.I hope you understood ! I'm not sure I would understand what I wrote:)

I dunno, if you think about it you're right, but it works this way...It's true the code remained from back when it was drawn in OpenGL, but now I'm drawing in Java and it still works the same... I probably placed a + somewhere where a - should have been placed

LooL !!! You can post your code and I'll tell you what is wrong. The main thing is that the variable code (int code = key.getKeyCode() can remeber only one value. So when you press a new button code it will change into the code of the last button pressed and it won't remember that you are still holding down the previous keys. When you use the boolean variables you don't change the up value into false because you just pressed left.I hope you understood ! I'm not sure I would understand what I wrote:)

That is not the reason at all.

The line "int code = key.getKeyCode();" in the first code example is storing the key code in a local variable. Even if pressing a second key caused a 2nd thread to simultaneously deliver another KeyEvent (which for the record - NO common VM does), it would still function fine.

To the original question.

Are you using Linux or Windows?KeyEvent delivery is bugged in Linux - and have been for the best part of 10 years.In Windows, you recieve the following sequence of events :-

<key is pressed down>keyPressed...keyPressed...keyPressed...keyReleased.<key is released>

In Linux, you recieve :-

<key is pressed down>keyPressed...keyReleased.keyPressed...keyReleased.keyPressed...keyReleased.<key is released>

If that isn't the cause of your problem, then I can only guess it is something else wrong in your code.p.s.may I suggest you use a switch statement instead of dozens of if/else's. It will improve the readability of your code.

Btw. I don't know if anyone's interested, but I looked into how LWJGL handles this problem. They actually relly on platform-specific implementation, so for example on Windows it uses a WindowsKeyboard class, which calls a DirectInput's pollKeyboard() method. I'm guessing they also implemented the mouse and other inputs the same way

You should never handle movement or position changes directly in the KeyListener methods.Never do something like

if keycode = key_leftx_position -= 10;

Especially while a key is pressed, the result can differ depending on the computer, because the frequence of keypress events differs with different hardware. I made this error too in a Pong Clone. I inserted code moving the paddle directly in the listener and the paddle was too slow in my notebook because the keypressed event was not sent often enough.

So what you do is use flags that go true / false. For ordinary "while pressed" actions like moving, you just set a boolean true when the key gets pressed and set it false when the key is released. In the game logic loop, you check this flags and do movement (position change) if true. For other actions you can need a "has been pressed" funcionality. Functions like Pause, Menu, Quicksave, etc should work when the key has been pressed once, even if it has already been released. You dont want the game to go pause while p is pressed but if the user presses and releases p you gou pause.

You can use easy logic, this would be, set the flag true when the key is released and set it false when the game logic reads it. A more difficult logic sets the pause true already on keypress not on release, but if the logic reads it and sets it to false, it must remain false even if the key is still pressed. It may only be set true again if the key has been released. You need two booleans for this.

Some games only react on key release with this buttons, other games react on keypress but do not go like autofire when you keep it pressed. Otherwise you would go pause on/off all the time while you keep it pressed. You want pause or menu to switch on for the first press, and only disappear after a second distinct press, not just on a repeated pressed event beacause the key is still pressed.

Using this, you can also handly multiple key presses. Just read the flags for left right up down and react. Usually, left/right and up/down should be different forces in your game that are independent. For topdown, left and right would change x-velocity and up and down would change y-velocity, without each caring about the other. For a simulation of a plane or car its the same. The game logic doesnt notice if up AND left is pressed. They modify different forces.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org