How do you guys (especially non-USA residents) handle the wide variety of standards for Unicode type stuff?

Imagine a little scenario where you have a FPS game and you want to have a screen that maps the controls to the next keypress? I get the idea that accented European chars need two keypresses, so they'd never register (?), but what if the player was from Asia? How would the confirmation character be displayed? As a hex character if it wasn't in the font being used?

Cookies for sensible, easy to understand answers (if such answers don't exist, then everybody who doesn't troll gets a cookie)

For text input, Allegro5 handles that relatively nicely via the ALLEGRO_EVENT_KEY_CHAR event. It doesn't handle the custom Unicode entry (Ctrl+Shift+U), but it does work with the compose key.

For everything else, I'd map the keycodes (which stay the same regardless of what they are mapped to, I think) to actions. For display purposes you'd need some way to map keycode to what's written on the keyboard, but that is a secondary issue.

What SiegeLord said. For example to have left/right movement, ask the player to press the key for moving left, then listen for the next ALLEGRO_EVENT_KEY_DOWN. Whatever keycode it was should be used for the "move left" action.

If it is ALLEGRO_KEY_Z then that does not mean the key has a "z" painted on it. It will have a "y" on a German keyboard and a "w" on a French keyboard and possibly something else entirely on other keyboards. But it doesn't matter - it will just work.

The only time internationalization is a problem is if you hard-code ALLEGRO_KEY_Z into your game. That will break.

Right now I have:

and I was imagining using the key_array[] for movement, etc. The ALLEGRO_EVENT_KEY_CHAR is just an experiment based on what SiegeLord said.

OTOH, I have a word wrap function using char buffers (for largish text files to be displayed in a box with a scroll bar) that looks for '\n' to start a new line, else it casts it to an unsigned char and ignores everything below ' '. I tried it with a couple of weird accented strings from Google Translate to see if it'd do anything unexpected, but it hasn't done anything but ignore chars with the high bit set yet.

Yes, that key_array will work fine on any international keyboards (as long as you let the user press the keys to obtain the keycodes and don't hardcode anything).

The event.keyboard.unichar gives you the unicode number, so you need to store it in an int and not a char. And to print use:

int c = event.keyboard.unichar;
ALLEGRO_USTR *u = al_ustr_new("");
al_ustr_append_chr(u, c);
printf("%s\n", al_cstr(u));
al_ustr_free(u);

This makes sure it's encoded into an UTF8 string which printf (at least under Linux) should understand. Otherwise use Allegro's text functions which have UTF8 as input.

Yhea, an unicode number may consist in one, two, up to four bytes.

So I'm clicking on the links to the manual, and looking at ex_utf8.c in my text editor...

{"name":"606033","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/f\/5fde498aba429ad8a340509ef64f9d31.png","w":710,"h":229,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/f\/5fde498aba429ad8a340509ef64f9d31"}

This sort of thing doesn't make it any easier.

I'll try to make a little example program for people to test in another thread eventually.

Is your text editor using UTF-8?

I'm using KWrite, under Settings | Configure Editor | File Opening and Saving | General there's a dropdown list set for "Encoding Detection: Universal" and a "Fallback Encoding" which I set to "Unicode (UTF-8)" but ex_utf8.c still looks the same. IIRC, there's some sort of configuration file somewhere to set colors for comments etc. (maybe an earlier version of Kwrite or some other editor entirely) but I can't find it now.

Well if it's not an encoding problem then maybe the fonts that it's using the editor doesn't know those symbols... Generally it should just place a rectangle (█) or some weird symbol, but since it's putting those weird (Asiatic?) letters I still thinking is trying to encode the text with the wrong encoding format.

I tried with quite a few others just now, and it looks like either one of the red circled areas except for Kword which showed some weird XML looking stuff. I would assume the "1/8th note" thing is supposed to be followed by what looks like an actual music note (blob at the bottom of a vertical line with a flag on top) but I haven't seen that yet.

[EDIT]

I tried the code snippet Elias provided, and it seemed to work OK until I exited the program and the bit at the end that prints FPS ranged from 0.0 to 9.9 when the timer is set to 60FPS. Weird.

I don't know man... I think it's just a problem with the fonts, this how it looks on C::B:

{"name":"606034","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/b\/db946abacf67e34573a16cd16b9b1ceb.png","w":989,"h":283,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/b\/db946abacf67e34573a16cd16b9b1ceb"}

If you'll be showing those kind of symbols then you need to find a super font with all those symbols.

Edit:... Uh?

Here is the ⅛ note. I guess it's pretty rare. I don't see it either.

http://www.fileformat.info/info/unicode/char/1d160/index.htm

I tried KWrite here as well. While it looks better than in Arthur's screenshot, it's broken in another way (notice the two dominos, and editing on that line is broken). The rest of the file seems to be okay, so it's probably a problem with surrogate code points. (Don't worry about it.)

{"name":"606035","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/5\/3535b780368629ca419305502c393f89.png","w":701,"h":418,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/5\/3535b780368629ca419305502c393f89"}

Does al_ustr_new() reallocate space as needed? I see a vector.c which seems to be for this purpose alongside bstrlib.c. Since I don't want to make a career out of deciphering all this stuff I thought I'd ask this here. The documentation doesn't seem to say this. FWIW, I did a

and got it up to over 5000 chars before each instance of the string filled the console and it didn't crash.

[EDIT]

I should have asked "Does al_ustr_append_chr() reallocate space as needed?"

Yes.

Thank you! I guess I can proceed now.

You just need a font that has the missing Unicode glyphs. The one where you see the 1/8 glyph is probably correct; the reason you don't see the other glyphs is, most likely, that none of the fonts you X11 knows contains them. You can try looking the glyph up in some character map program to see if it's there (gnome-charmap is OK, but if you're more of a KDE guy, I'm sure they have something similar).