Using Unicode (in a buffer) besides keysyms

SDL Development
1

Hello guys

It’s my first entry so please be patient.

I am working on a very old game and I would like to allow Unicode values
for text entries.
First of all I am using keysyms for my game so I can read several keys
together like:

  • SHIFT = FIRE
  • q = do something
    As I want to use Unicode for text input as well I think I have to read
    them seperate from the keysms since SHIFT+q=Q which would break the key
    reading inside the game.
    So my thought is clear: I need to work with keysyms (for game keys) AND
    Unicode (for text input).

Now I wonder how to do that best. The keysyms work over a keybuffer so
all keys are registered, even if the game FPS < “typed chars/sec”.
However this bases on the concept that each key has a RELEASED state,
which the Unicode events do not have for sure.

However when I want to read text inputs I just would like to make sure
all keys (that come in the SDL event poll) are printed out.
So maybe I would need sorta buffer for that and I just cannot figure out
how to do that…
This is my main-concern.

To implement this in this very old game base already gives me a headache
and therefor I would like to ask for ideas how to do that best. Maybe
someone would have a small tutorial I could follow or some pseudo code?

Any help on this would be awesome.

I thank in advance and wish you a nice day
Christian

2

To implement this in this very old game base already gives me a headache and
therefor I would like to ask for ideas how to do that best. Maybe someone
would have a small tutorial I could follow or some pseudo code?

My understanding of the problem is that you’re right, there’s two ways
of processing input, and you pretty much need both, if you want to do
both in-game key-bindings and text input.

One way to do it is to have a mode bit somewhere, so when a text entry
field is activated, your input code starts doing Unicode decoding and
puts the decoded characters in a buffer, to be consumed by the text
entry field. Another way is to do both at the same time, by always
decoding to Unicode and queueing into a buffer, then at the beginning
of your event loop, just empty the buffer, so that if there is no text
entry field consuming the input, it gets discarded (instead of all
appearing suddenly the next time an input field is activated!).

Also, remember the note at the top of
http://www.libsdl.org/cgi/docwiki.cgi/SDLKey. If you want the key
that’s right next to the Tab key, that’s not necessarily always Q!
When you want a specific physical key, what you want is the scancode
(and to make it more interesting, these are not portable from one
platform to the other, and that includes within Linux or X11!). You
most probably want those to be configurable, even if you use the
keysym (in case of an AZERTY keyboard, say).On Mon, Nov 17, 2008 at 8:23 AM, zico wrote:

–
http://pphaneuf.livejournal.com/

3

Pierre Phaneuf wrote:> On Mon, Nov 17, 2008 at 8:23 AM, zico <@zico> wrote:

To implement this in this very old game base already gives me a headache and
therefor I would like to ask for ideas how to do that best. Maybe someone
would have a small tutorial I could follow or some pseudo code?

My understanding of the problem is that you’re right, there’s two ways
of processing input, and you pretty much need both, if you want to do
both in-game key-bindings and text input.

One way to do it is to have a mode bit somewhere, so when a text entry
field is activated, your input code starts doing Unicode decoding and
puts the decoded characters in a buffer, to be consumed by the text
entry field. Another way is to do both at the same time, by always
decoding to Unicode and queueing into a buffer, then at the beginning
of your event loop, just empty the buffer, so that if there is no text
entry field consuming the input, it gets discarded (instead of all
appearing suddenly the next time an input field is activated!).

Ahhh that is exactly the hint I was looking for.
So now I actually have two buffers:

  • for the event loop which adds it’s registered keys to…
  • … the unicode buffer which consumes one key per frame

This actually works perfectly. Thanks you! :slight_smile:

Even tho I needed to make this clearing a bit more clear:

void event_poll()
{
SDL_Event event;
int clean_uniframe=1;

while (SDL_PollEvent(&event)) {
    switch(event.type) {
        case SDL_KEYDOWN:
        case SDL_KEYUP:
            if (clean_uniframe)
                memset(unicode_frame_buffer,'\0',sizeof(unsigned

char)*KEY_BUFFER_SIZE);
clean_uniframe=0;
key_handler((SDL_KeyboardEvent *)&event);
break;
case SDL_MOUSEBUTTONDOWN:
case SDL_MOUSEBUTTONUP:

Reason is: If mouse or other devices are connected, event_loop might be
called several times per frame. So… well small variable here but at
least now I have a WORKING unicode buffer which does not mess up my
normal key readings. :slight_smile:

Also, remember the note at the top of
http://www.libsdl.org/cgi/docwiki.cgi/SDLKey. If you want the key
that’s right next to the Tab key, that’s not necessarily always Q!
When you want a specific physical key, what you want is the scancode
(and to make it more interesting, these are not portable from one
platform to the other, and that includes within Linux or X11!). You
most probably want those to be configurable, even if you use the
keysym (in case of an AZERTY keyboard, say).#

Yeah this is no problem at all. The Q key was just an example. the
actual game control keys can be configured.

Thanks again - I am so happy this now works. :slight_smile:
Finally I can type special characters with my German keyboard as well -
Thanks to Unicode. :smiley:

Best wishes
Christian

4

Ahhh that is exactly the hint I was looking for.
So now I actually have two buffers:

  • for the event loop which adds it’s registered keys to…
  • … the unicode buffer which consumes one key per frame

One per frame? It’s quite possible to get more than one between two
frames, actually.

Don’t make the same mistake that EA did with Battlefield 2142! They
either did that (or something even worse, like SDL_GetKeyState) for
the chat interface, so it works most of the time (occasionally
dropping a letter, because I typed too quickly and they were in the
same frame), until there’s an orbital strike, which happens to lower
my frame rate a lot, and then I have to type very, very slowly, and
pay careful attention to make sure all the letters are there. :slight_smile:

void event_poll()
{
SDL_Event event;
int clean_uniframe=1;

while (SDL_PollEvent(&event)) {
switch(event.type) {
case SDL_KEYDOWN:
case SDL_KEYUP:
if (clean_uniframe)
memset(unicode_frame_buffer,’\0’,sizeof(unsigned
char)*KEY_BUFFER_SIZE);
clean_uniframe=0;
key_handler((SDL_KeyboardEvent *)&event);
break;
case SDL_MOUSEBUTTONDOWN:
case SDL_MOUSEBUTTONUP:

I would actually call the memset() where you declare the
clean_uniframe variable, before you start processing events. This way,
if a mouse click activates a text field, you won’t have the previous
content dumped into it! As I said, you could also just clear it when
you start needing the keys, and not even put information there when
you don’t need them.

Yeah this is no problem at all. The Q key was just an example. the actual
game control keys can be configured.

Xlib has a XKeysymToKeycode function, that allows you to find the
keycode (called a scancode in SDL) for a given keysym, so that you can
define defaults somewhat portably, but I don’t think SDL has something
like that.

Thanks again - I am so happy this now works. :slight_smile:
Finally I can type special characters with my German keyboard as well -
Thanks to Unicode. :smiley:

As a French Canadian, I can sympathize with you. :-)On Mon, Nov 17, 2008 at 3:51 PM, zico wrote:

–
http://pphaneuf.livejournal.com/

5

Pierre Phaneuf wrote:

Ahhh that is exactly the hint I was looking for.
So now I actually have two buffers:

  • for the event loop which adds it’s registered keys to…
  • … the unicode buffer which consumes one key per frame

One per frame? It’s quite possible to get more than one between two
frames, actually.

Don’t make the same mistake that EA did with Battlefield 2142! They
either did that (or something even worse, like SDL_GetKeyState) for
the chat interface, so it works most of the time (occasionally
dropping a letter, because I typed too quickly and they were in the
same frame), until there’s an orbital strike, which happens to lower
my frame rate a lot, and then I have to type very, very slowly, and
pay careful attention to make sure all the letters are there. :slight_smile:

That is why I have another buffer in the actual “print unicode
char”-function as well. It’s filled up with the chars registered in the
event_loop. So each time the “print unicode char” is called, the first
char in the buffer is printed and cleared - until it’s empty. So i get
ALL typed chars… with FPS<10 there’s some delay of course but this way
I can deliver one char per frame - as the old code made it.

void event_poll()
{
SDL_Event event;
int clean_uniframe=1;

while (SDL_PollEvent(&event)) {
switch(event.type) {
case SDL_KEYDOWN:
case SDL_KEYUP:
if (clean_uniframe)
memset(unicode_frame_buffer,’\0’,sizeof(unsigned
char)*KEY_BUFFER_SIZE);
clean_uniframe=0;
key_handler((SDL_KeyboardEvent *)&event);
break;
case SDL_MOUSEBUTTONDOWN:
case SDL_MOUSEBUTTONUP:

I would actually call the memset() where you declare the
clean_uniframe variable, before you start processing events. This way,
if a mouse click activates a text field, you won’t have the previous
content dumped into it!
That would work perfectly, but mouse, joystick and keyboard functions
can call event_loop. This get’s a bit messy in that very old menu GUI
where some mouse functions call event loop after the key functions
(which ALSO call event_poll) which cleans the unicode buffer again…
Still as each function calls event_loop and the actual buffer in the
"print unicode char" reads unicode_frame_buffer, a mouse click would not
dump any content into my input fields.
Yeah I know it might sound a bit messy right now. It’s just the simple
fact that this whole game does not have any read_input() but more
read_key(), read_mouse(), read_joy(), etc (which all call event_poll
while the “print unicode char” function could come up much later). That
is why I need to clean up unicode_frame_buffer I bit more strictly…

As I said, you could also just clear it when
you start needing the keys, and not even put information there when
you don’t need them.

As I tried to explain above (I know I have a hard time to explain) the
different input functions and the memset does clean up exactly then when
a key is required. So… yes it looks messy, but actually does what you mean.

Yeah this is no problem at all. The Q key was just an example. the actual
game control keys can be configured.

Xlib has a XKeysymToKeycode function, that allows you to find the
keycode (called a scancode in SDL) for a given keysym, so that you can
define defaults somewhat portably, but I don’t think SDL has something
like that.

This is a very nice idea. Currently each keysym has a string (SDLK_A =
“A”) assigned inside a table. This way defaults are defined and directly
connected to the keysyms.> On Mon, Nov 17, 2008 at 3:51 PM, zico <@zico> wrote:

Thanks again - I am so happy this now works. :slight_smile:
Finally I can type special characters with my German keyboard as well -
Thanks to Unicode. :smiley:

As a French Canadian, I can sympathize with you. :slight_smile: