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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel