Check if NO key is pressed?

[Michael]

I'm writing a nifty littly multiplayer Pong-clone applet, and stumbled
upon this problem:

I want to check if NO KEY AT ALL is pressed in my run-loop.

Writing something into keyPressed, keyTyped or keyReleased doesn't
work, because they still require a key to be pressed, typed or
released, so my run-loop halts. I need something like "if
(keypressed=false) ..."

Couldn't found a solution for this one, neither on usenet nor the Java
API/Docs. :-(

Ideas anyone?

mfg Michael

 

[Brian Palmer]

I'm writing a nifty littly multiplayer Pong-clone applet, and stumbled
upon this problem:

I want to check if NO KEY AT ALL is pressed in my run-loop.

Writing something into keyPressed, keyTyped or keyReleased doesn't
work, because they still require a key to be pressed, typed or
released, so my run-loop halts. I need something like "if
(keypressed=false) ..."

One approach would be to keep a private boolean variable which your
key listener updates as appropriate (i.e., set true in the keyTyped()
body). Then your run loop just checks that variable when it needs to
make a decision, and reset the variable to false.

 

[Andrew Thompson]

I'm writing a nifty littly multiplayer Pong-clone applet, and stumbled
upon this problem:

I want to check if NO KEY AT ALL is pressed in my run-loop.

It sounds like you have an horrendous design
and it would be better to sort that out before
you worry about code constructs.

Trim your code to a small, self contained,
compileable example of why you think
you need to detect an action that will not
happen, and perhaps we can give you
some pointers.

 

[Matt Humphrey]

I'm writing a nifty littly multiplayer Pong-clone applet, and stumbled
upon this problem:

I want to check if NO KEY AT ALL is pressed in my run-loop.

Writing something into keyPressed, keyTyped or keyReleased doesn't
work, because they still require a key to be pressed, typed or
released, so my run-loop halts. I need something like "if
(keypressed=false) ..."

Couldn't found a solution for this one, neither on usenet nor the Java
API/Docs. :-(

A typical event-driven Java UI uses threads to create activity not dependent
on the user. It seems that you're between modes because an event-driven app
does not need a run-loop, but you have one and can't resolve how to mix in
events. If you truly have a run-loop, then essentially there is no key
pressed on each pass through the loop unless you have specifically received
an event denoting that a key has been pressed. My question is how are you
receiving that event? Use it (as a previous poster suggested) to set a flag
in your run loop. Turn it on when pressed and off when released. If you
don't really have a run loop, or are badly using the Java UI event thread, I
would suggest more typical Java event-driven UI and starting a timing thread
that updates your game state at specific points in time.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Michael]

A typical event-driven Java UI uses threads to create activity not dependent

on the user. It seems that you're between modes because an event-driven app
does not need a run-loop, but you have one and can't resolve how to mix in
events. If you truly have a run-loop, then essentially there is no key
pressed on each pass through the loop unless you have specifically received
an event denoting that a key has been pressed. My question is how are you
receiving that event? Use it (as a previous poster suggested) to set a flag
in your run loop. Turn it on when pressed and off when released. If you
don't really have a run loop, or are badly using the Java UI event thread, I
would suggest more typical Java event-driven UI and starting a timing thread
that updates your game state at specific points in time.

Yeah, I know my design sucks, as the guy above mentioned. As I said, I
made a client/server model. It works fine for moving the pong-padels
and chatting, my problem is that my run-loop(yes, an event-driven
system would be of course better, but I don't want to rewrite my whole
code now ) waits for input, which is pretty bad for an action game
like pong

That's because I use readline() to check any new messages, and as long
as there is no key pressed, the stupid readline() waits for input. I
tryed to setup a boolean-check at keyPressed and an if-statement in my
run-loop to sent a bogus-message to the server if not true, which
worked, but then of course I couldn't used the paddels any more, which
is not good.

So, what I would really need is a command like "nokeypressed==true".
But I fear my design is simply to messed up :-/

Oh well, thanks for the help anyway, to you all.

mfg and a happy christmas, Michael!

 

[Harald Hein]

So, what I would really need is a command like "nokeypressed==true".

No, you need not. You need a new design.

 

[Matt Humphrey]

Yeah, I know my design sucks, as the guy above mentioned. As I said, I
made a client/server model. It works fine for moving the pong-padels
and chatting, my problem is that my run-loop(yes, an event-driven
system would be of course better, but I don't want to rewrite my whole
code now ) waits for input, which is pretty bad for an action game
like pong

That's because I use readline() to check any new messages, and as long
as there is no key pressed, the stupid readline() waits for input. I
tryed to setup a boolean-check at keyPressed and an if-statement in my
run-loop to sent a bogus-message to the server if not true, which
worked, but then of course I couldn't used the paddels any more, which
is not good.

So, what I would really need is a command like "nokeypressed==true".
But I fear my design is simply to messed up :-/

Well, you're design does need help. At the risk of encouraging you to stay
with an awkward design, I'll give you three suggestions.

1) You can add a new thread to the client so that it sends a "no-activity"
message to the server. This keeps your server using a simple
request-response paradigm to receive no-key-pressed. It requires some
synchronization on the client because the no-activity message must not
conflict with any other outgoing message and the thread timer must be
restarted on every legitimate user action (not too hard.)

2) Your server (the thing that's waiting on readline) can use setSOTimeout
so the readline throws an exception if the timeout expires, assuming that
your server is a true TCP/IP socket server. This does not close the socket
and does not affect data that arrives and is waiting to be read.. Your
client may or may not be able to handle the concept of the server generating
a message without a corresponding request. (You can also use Java 1.4+
non-blocking IO, but that's more complicated.)

3) Your server can have a thread that performs the no-key-pressed activity,
but only while the readline is waiting. You will need special
synchronization to ensure this thread does not conflict with any currently
executing activity. Also, the thread must restart its wait when a real
message arrives.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/