Hi, im having problems with my keylisteners. Theyre threaded, and the problem is that when i switch the key, it takes a while fo the computer to realize it. The effect is that, for animations, i get one picture moving across the screen until it changes, or when i switch keys quickly the image freezes for a bit. Any help is appreciated. ??? ??? ???
You use Threads for listening!?
That’s not how you do it. Check the swing tutorial.
you can use that to check if multiple keys are pressed at once so it is ok
with the normal keylisterne you cant see if key UP and RIGHT are preseed together
because it only registers one event
if you keep an array of key states, you can check if two keys are pressed at the same time without using threads. I wrote an example of this recently on the Sun forums, check it out: http://www.woogley.net/misc/MultiKey/
now that you have this info, stop threading keylisteners 
It works even worse if i dont use threads! When i hold down a key, it registers it once, then pause, THEN goes on quicker. How do i remove that inital pause?
that pause is from the OS itself (in windows it’s “repeat delay”). if you use the example I gave you and check key states OUTSIDE of the event loop, you won’t have to worry about pauses.
When a key is pressed, set a corresponding boolean to true. When it is released, set that boolean to false. Poll your booleans once every frame. Don’t ever mess with Threads until you understand stuff like public synchronized void doSomething() or blocks like synchronized(lock){ doSomething(); }. I will be so bold as to assume you’re not entirely familiar with those expressions. Please correct me if this assumption is wrong. There’s a reason why games normally execute most or all code from a single Thread, and it’s called synchronization.
Woogley:
Thanks for posting your MultiKey example. Is there an advantage to listening that way instead of creating and adding KeyListeners?
well, if you’re programming for the 4K contest, it’ll save you some bytes
the only other advantage is you don’t have to worry about defining each method for the listener even when you dont use them (e.g. you only want keyTyped but you have to define keyPressed and keyReleased to compile).
I always thought it was because developers don’t know better and fear threads as the plage. ;D
'course you could sidestep ALL this event crap if you use JInput.
</project plug>
find it rather uneasy to use jinput 
I haven’t looked at JInput for a while, but I can understand why you say that. At the time I was trying to help out with the Mac port and I never did get my head wrapped around how the heck it was supposed to work 
… of course at the time there is a good chance that was because it didn’t
Is there good documentation of JInput yet?
I’m hoping that soon some general purpose USB bindings make it into the core JRE and then things like JInput can be done in pure Java. (Kind of like Java COMM should have been. Hello, Sun? Remember that concept of client-side Java? It doesn’t work so well when you can’t interface with the client :).)