adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] SDL 1.3 input differences


From: Kai Sterker
Subject: [Adonthell-devel] SDL 1.3 input differences
Date: Thu, 26 Feb 2009 23:25:26 +0100

Tonight I was doing a little bit of cleanup on the SDL 1.3 backend,
since I had noticed that some key presses did still not yield the
proper result. What I didn't know then is that things would turn out
much worse then expected.

Seems that the input model of  SDL 1.3 is completely different from
1.2. Here's what I found out so far:

Together with KEY_PRESSED and RELEASED events, there is a new
SDL_TEXTINPUT event. The former two are dumbed down to report back the
physical and virtual key that has been pushed/released. So they report
which key has been pressed, but no longer to which character this
translates. So pressing '.' will always return just '.', no matter if
I hold down shift or not. Instead, SDL generates an additional text
event that returns either '.' or '>', depending on whether I hold
shift or not.

Also, text events do not necessarily correspond with key presses.
Shift+'.' are two key presses, but only one text event.

For some reason that escapes my understanding, key presses for letters
do distinguish between upper and lowercase. That means unless we want
to have proper punctuation (or non-ascii characters), we'd still be
fine. But even if we just allow players to input a character name and
save game title, I still think we should try to do stuff right.


Here's an idea how to map things to the old way.

We only propagate key pressed and released events for non-printable
symbols. Conveniently, SDL 1.3 defines the flag SDLK_SCANCODE_MASK
that allows to recognize most of these. The only exceptions are
RETURN, ESCAPE, BACKSPACE, DELETE, TAB and SPACE.

For all the other keys (well, I should better say characters), we
convert the text input event into our internal key press and release
events.


Or we can adopt the new way and change the SDL 1.2 backend to emit a
corresponding text input event whenever a key has been pressed that
results in a printable character. In that case, the changes to our
code would be bigger, but we'd get the benefits from the SDL 1.3
implementation (i.e. proper unicode and possibly future IME support).


Any opinions on that? Anyone interested in implementing it? :-)

Kai




reply via email to

[Prev in Thread] Current Thread [Next in Thread]