Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Internationalization

Credits go to AMCerasoli, Elias, Peter Wang, and SiegeLord for helping out!
This thread is locked; no one can reply to it. rss feed Print
Internationalization
Arthur Kalliokoski
Second in Command
February 2005
avatar

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)

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

SiegeLord
Member #7,827
October 2006
avatar

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.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Elias
Member #358
May 2000

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.

--
"Either help out or stop whining" - Evert

Arthur Kalliokoski
Second in Command
February 2005
avatar

Right now I have:

#SelectExpand
1 case ALLEGRO_EVENT_KEY_CHAR: 2 { 3 char c; 4 c = event.keyboard.unichar; 5 printf("%c 0x%X\n",c,c); 6 fflush(stdout); 7 break; 8 } 9 10 case ALLEGRO_EVENT_KEY_DOWN: 11 if (event.keyboard.keycode == ALLEGRO_KEY_ESCAPE) 12 goto done; 13 key_array[event.keyboard.keycode] = true; 14 break; 15 16 case ALLEGRO_EVENT_KEY_UP: 17 key_array[event.keyboard.keycode] = false; 18 break;

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Elias
Member #358
May 2000

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.

--
"Either help out or stop whining" - Evert

AMCerasoli
Member #11,955
May 2010
avatar

Elias said:

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:

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

Arthur Kalliokoski
Second in Command
February 2005
avatar

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"}606033

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

AMCerasoli
Member #11,955
May 2010
avatar

Is your text editor using UTF-8?

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

AMCerasoli
Member #11,955
May 2010
avatar

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.

Arthur Kalliokoski
Second in Command
February 2005
avatar

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.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

AMCerasoli
Member #11,955
May 2010
avatar

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"}606034

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

Edit:... Uh?

Peter Wang
Member #23
April 2000

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"}606035

Arthur Kalliokoski
Second in Command
February 2005
avatar

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

#SelectExpand
1 u = al_ustr_new(""); 2 . 3 . 4 . 5 (event loop) 6 case ALLEGRO_EVENT_KEY_CHAR: 7 { 8 int c; 9 if(inputtext == 0) 10 break; 11 c = event.keyboard.unichar; 12 al_ustr_append_chr(u, c); 13 printf("%s\n", al_cstr(u)); 14 break; 15 }

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?"

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Peter Wang
Member #23
April 2000

Yes.

Arthur Kalliokoski
Second in Command
February 2005
avatar

Thank you! I guess I can proceed now.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Tobias Dammers
Member #2,604
August 2002
avatar

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).

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Go to: