Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Keyboard translation in lwjgl  (Read 3897 times)
0 Members and 1 Guest are viewing this topic.
Offline elias

Senior Devvie





« Posted 2003-01-05 12:03:29 »

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

Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-01-05 15:35:50 »

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 Smiley

Offline elias

Senior Devvie





« Reply #2 - Posted 2003-01-05 15:57:09 »

Quote
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!
Legends of Yore - The Casual Retro Roguelike
Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2003-01-06 09:32:31 »

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

Cas Smiley

Offline elias

Senior Devvie





« Reply #4 - Posted 2003-01-06 10:58:58 »

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

Online princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2003-01-06 11:54:56 »

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 Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (35 views)
2014-12-15 09:26:44

Mr.CodeIt (26 views)
2014-12-14 19:50:38

BurntPizza (60 views)
2014-12-09 22:41:13

BurntPizza (95 views)
2014-12-08 04:46:31

JscottyBieshaar (55 views)
2014-12-05 12:39:02

SHC (71 views)
2014-12-03 16:27:13

CopyableCougar4 (73 views)
2014-11-29 21:32:03

toopeicgaming1999 (133 views)
2014-11-26 15:22:04

toopeicgaming1999 (124 views)
2014-11-26 15:20:36

toopeicgaming1999 (34 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!