Keyboard translation in lwjgl

[elias]

Hi,

Currently, the lwjgl Keyboard class regards the keyboard as one big gamepad. That is, you can query the up/down state of a key or ask the class to stream keyboard events to a buffer that can be emptied every frame or when keyboard input is needed. So when in buffered mode, a raw user key press/release event is recorded to a buffer and stored for the game to read when ready.

The nice thing about regarding the keyboard as a gamepad is that arcade/action games are easily implemented and with minimal overhead. Games like Quake, Tetris and the like, where only key states matters. The bad is that chat-based games are not easily implemented. Games like Warcraft, Sims etc. where text input is required from the user and not just key presses/releases.

The current approach is just to use the Keyboard.map method that supplies a crude form of static key->ascii char mapping. This way, the keyboard is always mapped according to a US keymap, so international letters (like the danish æøå), accented letters (é, ñ) and to a certain degree even modified letters (shift+a->'A') are not possible under the current scheme.

To keep the arcade style keyboard for those who prefer that, I propose we add another buffer to Keyboard class that is enabled through a Keyboard.enableTranslation() call. Enabling the translation buffer will require that the event buffer is enabled. When the translation buffer is enabled, every key press/release event is still recorded to the event buffer as normal, but additionally the events are translated to character whenever possible and placed on the translation buffer to be read from the game and used when clear text is required.

So a key event buffer that looks like

[shift down][a down][a up][shift up][; down][; up][' down][' up][e down][e up][esc down][esc up][shift down]

Will result in the translation buffer on a Danish keymapping being filled with:

"Aæé"

The last shift event cannot be translated in itself, so it has to stay in the buffer when the next read() is performed. That is, every event that cannot be fully translated will be copied to the beginning of the event buffer. Of course the index that marks the next key pressed/released event to be read by the game will have to be adjusted so no raw events are read more than once.

The esc key cannot be translated so it is ignored by the translation and can only be detected if the game reads the raw event buffer.

- elias

[princec]

It goes without saying that clients should not read from both the translation buffer and the raw buffer during a frame or you will probably get nonsensical output from both. It would be best to disable the raw buffer read function whilst translation is enabled.

I'm all for it. I think enableTranslation() should automatically set up a raw buffer as well. But that's getting down into implementation details.

Cas

[elias]

It goes without saying that clients should not read from both the translation buffer and the raw buffer during a frame or you will probably get nonsensical output from both. It would be best to disable the raw buffer read function whilst translation is enabled.

Why is that? I don't see a reason why not read both buffers at the same time. In fact, that is what I'm going to do in my project when this is implemented. That way I can emulate the java way of doing keyboard handlings. AWT sends _both_ raw key events as KeyPressed/KeyReleased events for every key and at the same time sends the translated character as KeyTyped events.

- elias

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

[princec]

Aha, you'll have to keep a separate private copy of the raw buffer for processing into translated keys then. That'll work.

Cas

[elias]

It occured to me that it might not be such a good idea to have a separate buffer for the translated characters. How about putting the translated characters in the ordinary raw event buffer, so the when translating is enabled, the game has a chance to know which characters belong to what key presses.

Of course characters created that cannot be assigned to a single key press will simply generate extra events with a keycode of, say, -1; likewise, key presses with no translation like pressing the shift key will have a character of '\0'.

When translation is disabled, only normal state and keycodes are generated.

- elias

[princec]

The problem is when you simultaneously read keypresses and translated keys. If there's some untranslated keypresses left at the end of the buffer and you read them out, then they've vanished forever and will never form part of the next key translation.

As many translations will be the result of multiple keypresses anyway I'm not so sure that there's any use in knowing what keypresses caused what translated key to appear. Either you're interested in translated keys, or you're interested in raw scancode events, but not both simultaneously. (And if you do need raw keycodes simultaneously a poll() won't hurt). But it solves the problem if you just copy the raw keys into another buffer just for the use of the translator.


Cas