ztellman / penumbra

not under active development - idiomatic opengl bindings for clojure
354 stars 43 forks source link

Disabling key repeat #12

Closed elliottslaughter closed 14 years ago

elliottslaughter commented 14 years ago

I've begun using keyboard input in my game, and have been unable to find any way to disable key repeat, or any (platform independent) way to work around it. I'm wondering if you have any ideas on how to accomplish this (or how to structure games so that it doesn't matter).

Thanks.

ztellman commented 14 years ago

This was actually really irritating for the Tetris clone, too. Key repeat is now blocked in key-press and key-release, but still active for key-type. As a bonus, there is now a (key-pressed? ...) function that can be called inside the callbacks or update loops.

elliottslaughter commented 14 years ago

Awesome. Works great on Windows and Mac.

But I suspect the solution might have problems on Linux -- when I last tried to work around this issue, I was getting key-press, key-release, press, release, etc, instead of many key-presses followed by a single key-release. Have you tested this?

Thanks.

ztellman commented 14 years ago

No, I don't have a Linux box to test this on. I should set up some VMs to test out these sorts of issues, though. I'll look into it.

elliottslaughter commented 14 years ago

Well, I just tested it on the machine it was failing on last night, and it looks like it works now, so I guess it's fine....

ztellman commented 14 years ago

Hmm, I was able to reproduce the key repeat issue on a linux VM running karmic koala. Anyways, based on the assumption that the end of one auto-key press and the beginning of the next coincide, I was able to make key-press non-repeating in linux, but key-type and key-release both repeat.

I guess that will have to do.

elliottslaughter commented 14 years ago

Does java have an option to poll for events rather than using callbacks? That might let you control both press and release.

Just a thought.

ztellman commented 14 years ago

I don't think so, as I found a bunch of people complaining about this same issue in Linux without anyone coming forward with a solution. Unless you disagree, I think this is a sufficient solution for the time being. It's certainly a little ugly, but nothing else seems to suggest itself.

elliottslaughter commented 14 years ago

My problem is that I am trying to use arrow keys for controlling motion. So I add velocity when a key is pressed, and subtract it when the key is released. I suppose I could check the key-pressed? state, but that still seems ugly.

I suppose one thing you could do would be collect key events and then provide a way for users to deal with them in their update loops. That way you could automatically delete repeated press/release pairs from the event sequence.

I'll keep looking around and tell you if I come up with a better idea.

ztellman commented 14 years ago

I think setting up an update-loop that queries key-pressed? is probably the way to go. That seems functionally identical to the event queue approach you're describing, except that you might sample key-pressed? in between the auto-release/press interval (which seems to be infinitesimal, as far as I can tell)

elliottslaughter commented 14 years ago

Ironically, my game actually works better without the linux fix. Since I increment velocity on press, and decrement on release, it works fine with linux's rapid press-release cycle (since release-presses don't coincide with the update loop). If I need it to work perfectly, I'll write some sort of key-event or query loop. For the moment, I wouldn't mind reverting the linux fix (at least until we can get rid of the repeated key-releases).

ztellman commented 14 years ago

OK, fair enough. The linux fix was pretty ugly anyways.