Holding down keys

[wookoouk]

I have an issue with the way I am having the player shoot.

I am aiming for when W,A,S,D are pressed the player shoots ONCE in that direction but with the way I have written it, there are multipul bullets fireing and the user is able to hold down the keys for rapid fire (unwanted), Im sure it could be done via bools but I dont know if there is a better way of wording the below text to get what I am after.


if (Keyboard.isKeyDown(Keyboard.KEY_W)){
         shootUp();
}

any ideas?

[RylandAlmanza]

I think this will work better:

1   2   3   4   5   6   7

while (Keyboard.next()) {    if (Keyboard.getEventKeyState()) {       if (Keyboard.getEventKey() == Keyboard.KEY_W) {          shootUp();       }    } }

[wookoouk]

sweet, will give it a try now, feed my son and update.

Games published by our own members! Check 'em out!

[wookoouk]

my son can wait  ,

Works perfectly thanks chap.

[RylandAlmanza]

No problem. I think I just found an optimization for it, too. You might want to change it to this:

1   2   3   4   5   6   7

while (Keyboard.next()) {    if (Keyboard.getEventKey() == Keyboard.KEY_W) {       if (Keyboard.getEventKeyState()) {          shootUp();       }    } }

Let me know if you need me to explain what it does.

[Nyhm]

Does LWJGL provide a more reliable/consistent keypress API than AWT/Swing?

I ask because I've experienced different keyboard responses on different platforms, requiring hokey timing tricks. Particularly, Linux implements key-repeat by firing a sequence of key up/down signals, which Java/AWT/Swing happily reports to the application. In Windows, key repeat is handled at the app level, so only one key-down *time passes* key-up sequence is reported to Java. Sadly, the Windows signals are much better to program against. (For the record, my response to these issues using raw AWT/Swing API was to throw out keyboard control).

[RylandAlmanza]

Particularly, Linux implements key-repeat by firing a sequence of key up/down signals, which Java/AWT/Swing happily reports to the application. In Windows, key repeat is handled at the app level, so only one key-down *time passes* key-up sequence is reported to Java.

Ah, so my solution may only work correctly on windows, then?

[Nyhm]

Particularly, Linux implements key-repeat by firing a sequence of key up/down signals, which Java/AWT/Swing happily reports to the application. In Windows, key repeat is handled at the app level, so only one key-down *time passes* key-up sequence is reported to Java.

Ah, so my solution may only work correctly on windows, then?

Not sure - I assume you're referencing LWJGL API, as Java/Swing doesn't have a Keyboard class (unless that's Java 7). I do not have experience with LWJGL. My account was referring to Java 6 AWT keyboard events. Am I confused/confusing?

Basically, I'm wondering how to best handle key-down events in Java, as I haven't found a (good) way with AWT/Swing.

[UprightPath]

Ah, yes and no. It's probably best if you write your own key managed so that you can really manage how it works. Especially with the key repeat stuff some computers have.

I use something like this:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29

public enum KeyCommand {     SHOOT(10);     private final int repeat;     private int countDown;     private boolean armed;     KeyCommand(int repeat) {         this.repeat = repeat;     }     public void updatePressed(boolean pressed) {         countDown--;         if (pressed) {             if (countDown < 0) {                 armed = true;                 countDown = repeat;             }         }     }     public boolean isArmed() {         return armed;     }     public void resetArmed() {         armed = false;     } }

1   2   3   4   5   6   7   8   9

KeyCommand.SHOOT.Input.isKeyDown(SHOOT_KEY)); if(KeyCommand.SHOOT.isArmed()) { //shoot code KeyCommand.SHOOT.resetArmed(); } [code] The int value to the enum constructor sets how many frames can pass before another keypress/instance of the key being down, causes it to be 'armed' again. So that if you're mashing the key or you're holding it down or you're pressing when you're ready, it shouldn't allow you to have a beam-spam.

[/code]

[wookoouk]

I only just noticed these posts, sorry. Thanks for the info guys, I will implement this tonight. You are a great community.