Topic: Keys, characters and font processing in AGS

[Monsieur OUXX]

Hi,

I have found complete answers for what I'm looking for in most of the the threads I've read, or some partial clues, but I'd like to have an overview of it by some people who know what they are talking about :

How are characters processed in AGS, step by step?

Let me explain :
- When a constant string (e.g. : String str = "this is a dialog";) is typed-in in the script editor, is it saved as an ASCII? An extended ASCII?
- When a key is pressed, is the code read in on_key_pressedan extended ASCII code (with unused codes used to flag Ctrl/Alt/Shift)?
- In the translation files, what encoding is it? I don't know how Window's Notepad works : I believe it can't be ASCII, since the purpose of those translation files is precisely to be able to insert any non-latin character!
- a TTF font represents some Unicode pages, I believe

If my questions appear not very self-explainatory, it's because I'm still trying to figure things out.

Thanks

[Pumaman]

AGS uses 256-character ANSI, where the first 128 are the fixed ASCII characters and the second 128 depend on the active codepage on your machine.

The built-in SCI fonts only support the first 128 characters, but if you're using a TTF font then AGS will allow all 256 ANSI characters to be used.

AGS does not currently support Unicode.

In most cases using the local ANSI codepage would be a dangerous thing to do, since the characters will render differently on different people's computers. However, because you include the TTF fonts within your game, this ensures that the extended characters will display the same way on every computer that runs your game.

[Radiant]

To my knowledge, AGS supports characters 32 through 127 from the SCI fonts, and excluding the '[' character which is used as a line break. I tried at one point to use 1-32 for accented letters, but that didn't actually work.

[Gilbert]

Actually you can use characters #1-31 in strings (#0 is terminating character), just not directly, as these characters are control codes like Ctrl-XX, etc., you can't use them by entering them directly (in the script-editor, say for example).
Instead you may do something like:
String blah=String.Format("Haha! %c is a special character!", 16);

As far as I remember, these characters (minus some, like the carriage return and newline characters, etc.) still work in a translation source, as long as you find a way to put these characters into the file (my old defunct japanese translation source maker used them).

[monkey0506]

excluding the '[' character which is used as a line break

You can use the '[' character if you escape it:

Code: [Select]

Display("this\[text\[has\[no\[line\[breaks,\[only[oops ;)");
Would display:

this[text[has[no[line[breaks,[only
oops 

You can also check the ASCII value of the character '[' which is 91 so:

Code: [Select]

String s = String.Format("this text[is split");
Display("s.Chars\[9]: %d", s.Chars[9]);
Would correctly display "s.Chars[9]: 91".

Note if you want to format the '[' character into a String there are other considerations. Simply trying to escape the "%c" value such as this:

Code: [Select]

String s = String.Format("this text\%cis split", '[');
Won't work. The single-slash is immediately followed by the '%' symbol which has no special meaning so the slash is removed. Either of the following do work:

Code: [Select]

String s = String.Format("this text\\%cis split", '[');
// or
String s = String.Format("this text%c%cis split", 92, '[');

[Monsieur OUXX]

1/ In fact, I'd like to be able to swap the inputted key on a non-american keyboard with the one of the original US keyboard.

To be more clear : since the keyboard is automatically using regional settings (via Windows drivers), it often causes problems on AZERTY keyboards when the keys W,A,S and D are used to control a character, because A is replaced by Q, and W is replaced by Z.
The only way to handle this would be to do the exact opposite processing that Windows does : change inputted key codes back to the ones that would be intercepted if using a US keyboard.

(hope you understand what I say, 'cause it's really not easy to explain in my bad English)  :

And DON'T tell me that nobody will ever use such keys to control a character in an AGS game, it's already what is done in the "Monkey Island combat game" (can't remember the exact name)    Anybody who wants to make a 2-player game will also have to enable control using W,A,S,D or any other "letters" keys.

If needed, I'm ready to hard-code the correspondances of non-US keys and US keys in tables within the script, but to do that, I believe I should have a look at the local extended ASCII tables of the countries that I want to implement.

Also, I still don't see clearly the difference between extended ASCII and ANSI. (OK, it's just that characters 128 to 255 are different in some extended ASCII from really ANSI --> leads to question #2)


2/ What "ANSI" is used in AGS? The official one (ISO 8859-1)? Or the MS Windows one (Windows-1252)?

If AGS takes advantage of Windows API, I believe it would be the Windows one (but what about the Linux port of AGS, then )  :'(

Sorry to ask silly questions like this, but I'd rather write right code. 

[Pumaman]

AGS does not use a particular version of ANSI -- it depends which fonts you import. Whatever ANSI codepage the font is, that's what you'll get. However, in the editor it will use your local Windows codepage (1252).

This means that potentially the editor might display different characters to what you get in-game, depending on which TTF font you have imported.

To be more clear : since the keyboard is automatically using regional settings (via Windows drivers), it often causes problems on AZERTY keyboards when the keys W,A,S and D are used to control a character, because A is replaced by Q, and W is replaced by Z.

Hmm, I've heard reports of this happening before, but I haven't really been able to test it, having a UK keyboard. I'll try to look into it at some point.

[Monsieur OUXX]

To be more clear : since the keyboard is automatically using regional settings (via Windows drivers), it often causes problems on AZERTY keyboards when the keys W,A,S and D are used to control a character, because A is replaced by Q, and W is replaced by Z.

Hmm, I've heard reports of this happening before, but I haven't really been able to test it, having a UK keyboard. I'll try to look into it at some point.

It's not really an issue, it's the normal behavior of the keyboard : on_key_press gets the code of the character that has been pressed, independently of it's position on the keyboard - if you pressed Q, you'll get a Q on both Us and non-US keyboard.
But sometimes, you want to refer to a specific location on the keyboard and not to a particular character.

[Pumaman]

Ah ok, so on an AZERTY keyboard, pressing an A or a Z does correctly register them as A and Z in the game?

[Radiant]

Ah ok, so on an AZERTY keyboard, pressing an A or a Z does correctly register them as A and Z in the game?

This might cause confusion for keyboards that e.g. use the WSAD method for moving something around - although I don't think there are too many of those.

Is there some way (within AGS) to detect whether the keyboard is QWERTY or something else?

[SSH]

String french=InputBox("Do you have a weird keyboard?");

[Monsieur OUXX]

This might cause confusion for keyboards that e.g. use the WSAD method for moving something around

Yeah, that's what I was (painfully) trying to say

- although I don't think there are too many of those.

At least French and German keyboards have a different layout  - you must confess that they are not the less significant non-English countries 

[Khris]

Art Of Theft uses Z and X (many freeware platformers do, too) so I take advantage of XP's handy feature, the Language Bar, and change the keyboard layout. Two mouse clicks.

Besides, wouldn't it make more sense to write a module that'll provide an easy and fast key configuration?
The player is shown some text like "you'll need to define four directional and three action buttons", then is asked to press the keys for up, down, ..., action1, ...

The module sets up an array (kp[]), using an enum as index.
The designer can edit the enum fields (eActionCrouch) and descriptive strings (KeyPress.SetName(eActionCrouch, "crouch"); ) to his liking, then uses "if (keycode==kp[eActionCrouch])" in his code.

Everybody wins

[Monsieur OUXX]

Besides, wouldn't it make more sense to write a module that'll provide an easy and fast key configuration?
The player is shown some text like "you'll need to define four directional and three action buttons

that's exactly what I'm trying to achieve, but with the default controls already working on non-US keyboards, even without extra-configuration

[Khris]

That's what I thought, my point being that all the work becomes unnecessary if the player is required to set up the controls once.
I can see that it's comfortable to get right into the game but I'm one of those players who always go through the control options before running a game for the first time.
The default setup is inconvenient often enough, at least for me.