What is the CORRECT Way to get ASCII

[jasonf]

I've got a serious problem with my input code. It's only just come to light and frankly, it's embarrasing. But we're all friends here so I'll tell you my dirty little secret.

Using the KeySym and Modifiers, I cannot seem to get the values for things like the @ symbol or the " symbol..

All of the examples I've seen seem to be based in the USA and appear to just hack the [KMOD_LSHIFT]+ [SDLK_2] to give [SDLK_AT] which will only work on a US style keyboard. There appears to be no intelligence in the SDL C code to determine the locale the user is in and their keyboard settings. It just seems to map directly (I might have missed something)

This is most annoying.

Does anyone have a tried and tested, internationally accepted way to get the correct keyboard code from an international keyboard, regardless of locale? I want the Real key the user has pressed.

I need to know when someone's typed john.smith@someaddress.com and at the moment, my assumption that the @ key was on the ['] key (UK Keyboard) was dead wrong!..

I've had to hack my code to retrieve an @ symbol on both [shift]+['] and [shift]+[2] keys.. This is also wrong, but at least it catches more people than the UK version.

Thanks for any help, anyone.

[jasonf]

I had no idea there were so many different types..

If SDL can't support them.. what chance have we got?
http://en.wikipedia.org/wiki/Keyboard_layout

[User137]

I don't know about methods you are using, but this table should be valid in all keyboards:
http://www.asciitable.com/

[jasonf]

The ASCII to Character table isn't my problem really. It's that I can't get access to the KeyCodes for Characters which share a key with a main key.

For instance. In the USA, to get the @ key, you use Shift and 2
The only Keys SDL tells you have been pressed are the Shift Key (via a modifier) and the 2 Key.

From this, one could wrongfully assume that to get the @ key, one just has to check for the Shift+2 keys..

However, on some Keyboards, the @ key is accessed by pressing the AltGr+Q keys

In the UK, the @ key is where the " key is in the USA. In Italy, it's where the Semi Colon should be.

I just want the damned @ key.. It shouldn't matter what country the keyboard is from. The OS knows about it, so SDL should be able to pick that information up. But apparently it's not that simple.

I set my Keyboard to AZERTY mode, pretended I was French, even played som accordian music in the background and drank strong coffee.. but SDL still was convinced that I had a QWERTY keyboard. SDL was technically right, but the settings should have told it to map the Q key to the A key (amongst others).

This is quite an international forum so I'm wondering how others are handling this.. Throughout the development of Crashblock, I've had to deal with all manner of internationalization issues.. but they've all been handled in code, by Delphi or FreePascal. SDL, I have little control over.

Apparently, SDL 1.3 formalizes the concept of the KeySym (which may solve the AZERTY issue), but I don't want to wait for 1.3 to come out.. and apparently, it works all the time on Linux.

So far, my investigations have led me to believe that the developer has to check the machine themselves, thus defeating the object of having a Direct Media Layer. If we can't trust SDL Input to give us the correct codes, what use is it?..

The answers on various forums appear to be "Allow the users to define their own game controls" well, that's fine.. apart from when the user wants to enter their name, or chat to another player.

Any ideas?

[pstudio]

What about reading Unicode in KeySum?
(Don't forget to enable unicode SDL_EnableUnicode )

[technomage]

I just found out that SDL_Enableunicode is the way to resolve this.

the @ character is represented by the unicode value of 64 in both UK and US keyboard layouts.

[jasonf]

Don't you just hate it when a perfectly good spleen vent is dismissed so easily :lol:

I've implemented the unicode stuff and it works really well. I've still yet to test it on a non-standard machine, but it's looking promising... :roll: gonna have to find something else to moan about now I suppose :lol:

Thanks for the prod in the right direction guys.

[jasonf]

One thing to note chaps, there don't appear to be any constants for the unicode letters for UpperCase letters. I've used SDLK_*-32 for my tests, which seems to work.

..or am I not supposed to be using the SDLK constants on the Unicode value?

[User137]

I know that much from my language (finnish), where we use big and small letters for ?•?§?? ?Ö?Ñ?ñ which do not convert same way as a to Z and that is pain... Uppercase versions aren't 32 but 10 characters ahead :?

[jasonf]

I've only done the -32 for A-Z, I'm not supporting other international characters, sorry about that.

The SFont library I'm using doesn't support additional characters. I guess I should move over to using TTF, but I believe that has other issues like distribution of fonts and their copyrights, unless I can convert them into a different format. Some confirmation on this would be nice.

I need to do something soon, because if I'm to translate the game to different languages, I'll need international character support.

I want to do a Korean version at some point soon.. but there's no way in hell that SFont can support Hangul. A Korean version will also test SDL's international input handling to it's very core. But that's a way off yet.