Keyboard state (instead of keyboard events)
Philipp Gressly
I am programming a "moon-lander" and want to check every 100 ms if a
certain key is pressed.
The keyboard events (key-pressed, key-released and key-typed) are
not helpful, because the operating System (linux im my case)
generates key-releases and key-presses at its own (depending on the
"key repeat speed").
Is there a command to satisfy the following interface easily?
public interface KeyState {
boolean isKeyDown(char keyCode);
}
John B. Matthews
Philipp Gressly <p...@gressly.ch> wrote:
I don't see a way to ignore spurious keyReleased() events except to
instruct the user to disable key repeat using the host's control panel.
It may be possible to do so programmatically using the Java Desktop
System's assistive technology:
<http://docs.sun.com/app/docs/doc/817-7307>
It sounds like you already understand the obvious implementation:
Enumerate the keys of interest and map the state of each. In an
implementation of the KeyListener interface (or an extension of the
KeyAdapter class), handle keyPressed() keyReleased() events accordingly:
Mark a key as down on keyPressed(); mark a key as up on keyReleased().
Return the corresponding state in isKeyDown().
--
John B. Matthews
trashgod at gmail dot com
http://home.roadrunner.com/~jbmatthews/
Knute Johnson
You can see a coded example of what John describes in my Asteroids game.
http://rabbitbrush.frazmtn.com/asteroids.html
There is a link to the source code at the bottom.
--
Knute Johnson
email s/nospam/knute2008/
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
John B. Matthews
Knute Johnson <nos...@rabbitbrush.frazmtn.com> wrote:
Excellent! It looks like control is smooth because the display frame
rate (~67 Hz) is much greater than the typical key repeat rate (~10 Hz).
Given a moderately high frame rate, the OP may be able to do without any
special effort.
For more than a few keys, I found an enumeration helpful:
<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/src/org/gc
s/robot/Key.java>
A lookup Map makes the keyPressed() handler particularly straightforward:
<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/src/org/gc
s/robot/RobotChase.java>
Knute Johnson
>
> The asteroids-Code, is nearly my workaround. But still flickers (see
> Break.java).
> Probably, I should play around with the refresh rates...
>
> Thank you all
>
> phi
To get smooth animation you need to have around 30 frames per second or
faster. Yours appears to be around 10.
Philipp Gressly
Thanks
I have found another method to ignore "key repeats";
unfortunately it does not work properly using gnome:
http://forums.sun.com/thread.jspa?threadID=698156
still searching ...
Philipp Gressly
With all your help, I have implemented the code below.
It works in 99%, because the gnome "keyPressed.getWhen()" has mostly
the same value
as a previous "keyReleased.getWhen()" in case of the
"key-repeat-sequence".
Very rarely the below mentioned code reports "down: false", but it
should be "down: true".
It would be interesting to have some feedback about other operating
systems.
Thanks
import javax.swing.JFrame;
import java.awt.event.*;
/**
* @author Philipp Gressly (p...@gressly.ch)
* after a code from Luther :
http://forums.sun.com/thread.jspa?threadID=698156
*/
public class IgnoreRepeats extends JFrame implements KeyListener,
Runnable {
private long oldWhen = 0L;
public boolean down;
/* starter */
public static void main(String[] _) {
new IgnoreRepeats("Test Frame").top(); }
public IgnoreRepeats(String name){
super(name); }
private void top() {
super.addKeyListener (this) ;
super.setDefaultCloseOperation (EXIT_ON_CLOSE);
setSize (300, 300) ;
setVisible (true) ;
new Thread(this). start(); }
public void run() {
while (true) {
System.out.println("down: " + down);
try {
Thread.currentThread().sleep(40);
} catch (InterruptedException e) { }
}
}
public void keyReleased(final KeyEvent e) {
if (oldWhen == e.getWhen()) return;
down = false; }
public void keyPressed(final KeyEvent e) {
long now = e.getWhen();
if (oldWhen == now) return;
oldWhen = now;
down = true; }
/* ignore */
public void keyTyped(KeyEvent e) {}
} // end "IgnoreRepeats"
Knute Johnson
There are no repeats of keyPressed() and keyReleased(). They are called
only when the key is moved. keyTyped() on the other hand repeats as
long as the key is held down.
> http://forums.sun.com/thread.jspa?threadID=698156
>
> still searching ...
Knute Johnson
Throw out the getWhen() part, you don't need it. Just set the flag when
the key is pressed, and clear it when it's released.
John B. Matthews
Knute Johnson <nos...@rabbitbrush.frazmtn.com> wrote:
Thread.sleep(40); // Class reference OK here
> > } catch (InterruptedException e) { }
> > }
> > }
> >
> > public void keyReleased(final KeyEvent e) {
> > if (oldWhen == e.getWhen()) return;
> > down = false; }
> >
> > public void keyPressed(final KeyEvent e) {
> > long now = e.getWhen();
> > if (oldWhen == now) return;
> > oldWhen = now;
> > down = true; }
> >
> > /* ignore */
> > public void keyTyped(KeyEvent e) {}
> >
> > } // end "IgnoreRepeats"
Philipp : Works well on MacOS 10.5.6, Java 1.5, PPC. I get no false
negatives with limited testing at various rates. I'm wary of relying on
this sort of undocumented behavior, but I think I see why you're doing
it. In effect, auto-generated released-pressed pairs appear to share the
same time stamp. Would testing "delta < 1" be better than testing for
equality?
> Throw out the getWhen() part, you don't need it. Just set the flag when
> the key is pressed, and clear it when it's released.
Knute: On MacOS (Darwin/BSD) and (IIUC) on Linux, automatic key repeat
generates continual triplets: pressed, typed, released, [pressed, typed,
released]. This appears not to be the case on Windows.
Knute Johnson
>
> Philipp : Works well on MacOS 10.5.6, Java 1.5, PPC. I get no false
> negatives with limited testing at various rates. I'm wary of relying on
> this sort of undocumented behavior, but I think I see why you're doing
> it. In effect, auto-generated released-pressed pairs appear to share the
> same time stamp. Would testing "delta < 1" be better than testing for
> equality?
>
>> Throw out the getWhen() part, you don't need it. Just set the flag when
>> the key is pressed, and clear it when it's released.
>
> Knute: On MacOS (Darwin/BSD) and (IIUC) on Linux, automatic key repeat
> generates continual triplets: pressed, typed, released, [pressed, typed,
> released]. This appears not to be the case on Windows.
>
John:
I don't have a MacOS system to try it on and only xubuntu for linux but
it does not do that on xubuntu 8.10 with Sun 1.6. I would think that
this is a serious bug and not expected behavior. Is the automatic key
repeat a user settable feature on MacOS?
John B. Matthews
Knute Johnson <nos...@rabbitbrush.frazmtn.com> wrote:
> John B. Matthews wrote:
> >
> > Philipp : Works well on MacOS 10.5.6, Java 1.5, PPC. I get no false
> > negatives with limited testing at various rates. I'm wary of relying on
> > this sort of undocumented behavior, but I think I see why you're doing
> > it. In effect, auto-generated released-pressed pairs appear to share the
> > same time stamp. Would testing "delta < 1" be better than testing for
> > equality?
> >
> >> Throw out the getWhen() part, you don't need it. Just set the flag when
> >> the key is pressed, and clear it when it's released.
> >
> > Knute: On MacOS (Darwin/BSD) and (IIUC) on Linux, automatic key repeat
> > generates continual triplets: pressed, typed, released, [pressed, typed,
> > released]. This appears not to be the case on Windows.
>
> John:
>
> I don't have a MacOS system to try it on and only xubuntu for linux but
> it does not do that on xubuntu 8.10 with Sun 1.6. I would think that
> this is a serious bug and not expected behavior.
You are correct. Sadly, I am insane. I tried to verify my claimed
repeating pattern using a tutorial example. Auto-repeat produces a
series of pressed and typed events; a released event only occurs when
the key is, um, released:
<http://java.sun.com/docs/books/tutorial/uiswing/examples/events/KeyEvent
DemoProject/src/events/KeyEventDemo.java>
I back-ported your asteroids game to 1.5 enough to rotate and shoot.
It's smooth. When I comment out the getWhen() logic in Phillip's
example, I get correct results. On reflection, I must wonder what
problem Phillip's code seems to fix.
> Is the automatic key repeat a user settable feature on MacOS?
Good question: I'm using Mac OS 10.5.6, Java 1.5.0_16. A control panel
allows setting the the repeat rate to any of a handful of ticks between
"slow" and "fast", but it can't be turned off. The delay until repeat
can be "off" or somewhere between "long" and "short".
Knute Johnson
> In article <495c0598$0$25404$b9f6...@news.newsdemon.com>,
> Knute Johnson <nos...@rabbitbrush.frazmtn.com> wrote:
>
>> John B. Matthews wrote:
>>> Philipp : Works well on MacOS 10.5.6, Java 1.5, PPC. I get no false
>>> negatives with limited testing at various rates. I'm wary of relying on
>>> this sort of undocumented behavior, but I think I see why you're doing
>>> it. In effect, auto-generated released-pressed pairs appear to share the
>>> same time stamp. Would testing "delta < 1" be better than testing for
>>> equality?
>>>
>>>> Throw out the getWhen() part, you don't need it. Just set the flag when
>>>> the key is pressed, and clear it when it's released.
>>> Knute: On MacOS (Darwin/BSD) and (IIUC) on Linux, automatic key repeat
>>> generates continual triplets: pressed, typed, released, [pressed, typed,
>>> released]. This appears not to be the case on Windows.
>> John:
>>
>> I don't have a MacOS system to try it on and only xubuntu for linux but
>> it does not do that on xubuntu 8.10 with Sun 1.6. I would think that
>> this is a serious bug and not expected behavior.
>
> You are correct. Sadly, I am insane. I tried to verify my claimed
> repeating pattern using a tutorial example. Auto-repeat produces a
> series of pressed and typed events; a released event only occurs when
> the key is, um, released:
We're all insane, it's the CRS that's really starting to bother me :-).
> <http://java.sun.com/docs/books/tutorial/uiswing/examples/events/KeyEvent
> DemoProject/src/events/KeyEventDemo.java>
>
> I back-ported your asteroids game to 1.5 enough to rotate and shoot.
> It's smooth. When I comment out the getWhen() logic in Phillip's
> example, I get correct results. On reflection, I must wonder what
> problem Phillip's code seems to fix.
I have no clue.
Is there not a 1.6 for Mac yet?
John W Kennedy
Yes, but only for Intel 64-bit mode (which means that the chip must be a
Core Duo 2 or better, and means that it doesn't support applets unless
and until Safari gets an update to support 64-bit mode. This has been
the situation for some time now; it is generally understood that PowerPC
and Intel 32-bit are not coming.
Philipp Gressly
> In article <495c0598$0$25404$b9f6...@news.newsdemon.com>,
> Knute Johnson <nos...@rabbitbrush.frazmtn.com> wrote:
>
>> John B. Matthews wrote:
>>> Philipp : Works well on MacOS 10.5.6, Java 1.5, PPC. I get no false
>>> negatives with limited testing at various rates. I'm wary of relying on
>>> this sort of undocumented behavior, but I think I see why you're doing
>>> it. In effect, auto-generated released-pressed pairs appear to share the
>>> same time stamp. Would testing "delta < 1" be better than testing for
>>> equality?
I have tried "delta < 9" and "delta < 10". "delta < 9" fails in very
rare cases, where "delta < 10" succeeded.
using HW: Lenovo X61, OS: Ubuntu 8.04, Gnome 2.22.3, java 1.6.0
(update 10).
phi