Topic: AGS 3.6.0 WIP (Alpha 21) - SDL2-based engine + Unicode support

[Grundislav]

I use Oggs, so it’s not the issue with MP3s. Also I was assuming it was because of the SDL_sound update, but I’m probably wrong on that. If it helps, the version of the alpha I tested where the issue was not present was alpha 10. Is there an archive of previous versions where I can download alpha 10 again to make the test games for comparison?

[Crimson Wizard]

I use Oggs, so it’s not the issue with MP3s. Also I was assuming it was because of the SDL_sound update, but I’m probably wrong on that. If it helps, the version of the alpha I tested where the issue was not present was alpha 10. Is there an archive of previous versions where I can download alpha 10 again to make the test games for comparison?

Certainly, we have all the releases on github:
https://github.com/adventuregamestudio/ags/releases

specifically 3.6.0 alpha 10:
https://github.com/adventuregamestudio/ags/releases/tag/v.3.6.0.9

The downloads are attached at the end of the post, under "Assets".

[Grundislav]

Great, thank you!

Here is an archive with several tests for 2 tracks. All notes provided in the readme.txt.

https://www.dropbox.com/s/vayozljgedx3rx0/AudioTests.zip?dl=0

[Baguettator]

Sorry to post it here, but maybe it needs to be fixed in the new 3.6 coming...

I encounter this problem : when I press "enter", it generates something that would be done by pressiong CtrlK or something like that (a combination of 2 keys, but NOT the "enter" key).

I have no "if (keycode==eKeyenter)" in my "on_keypress" function... And I don't ever know if "enter" key can be used like that.

Any idea about it ? Which value has the enter key ?

[Crimson Wizard]

I encounter this problem : when I press "enter", it generates something that would be done by pressiong CtrlK or something like that (a combination of 2 keys, but NOT the "enter" key).

It's a known issue that eKeyCtrlM has the same code as Enter/Return.
This may be noticed by comparing their values in the key codes table in the manual: https://adventuregamestudio.github.io/ags-manual/ASCIIcodes.html

The workaround is to additionally test if ctrl is pressed as

Code: Adventure Game Studio

1. if ( IsKeyPressed(eKeyCtrlLeft) ||  IsKeyPressed(eKeyCtrlRight) )
2.  

[Baguettator]

Oh, I see ! But is there a way to fix it ?

EDIT : eKeyCtrlLeft and eKeyCtrlRight don't exist... Have they got another name in AGS ?

EDIT 2 : so I just used their ASCII code (405 and 406) instead, but there are no "enum value" for them in my version (3.5.1)

EDIT 3 : in the same "theme", is "eMouseWheelNorth" and "eMouseWheelSouth" should work with a tactile pad of a PC ? (I don't know the english name for that, but you know, the tactile zone where your fingers can simulate the mouse, like for a smartphone. Scrolling can be done by using two fingers).

[Crimson Wizard]

Oh, I see ! But is there a way to fix it ?

Probably won't do this for 3.5.1, as it's a rare problem and there's a workaround (posted above). We may look if it's possible to improve in 3.6.0 version.

EDIT 3 : in the same "theme", is "eMouseWheelNorth" and "eMouseWheelSouth" should work with a tactile pad of a PC ? (I don't know the english name for that, but you know, the tactile zone where your fingers can simulate the mouse, like for a smartphone. Scrolling can be done by using two fingers).

I don't know. But we recently received a bug report that touch pad does not register some command for the right click on Linux in 3.5.1, and later this was confirmed to work in 3.6.0. Perhaps you could test in 3.6.0 to see if it works there.

[Baguettator]

OK, will see in 3.6 !

And what about the ekeyCtrlLeft and ekeyCtrlRight ? Have they been deleted ?

[Crimson Wizard]

And what about the ekeyCtrlLeft and ekeyCtrlRight ? Have they been deleted ?

They have been added in 3.6.0, were not declared earlier. The values themselves should be valid in earlier versions.

[Laura Hunt]

I'm not sure if this is an issue with 3.6.0 or with all versions of the engine, so I'll mention it here.

When importing ttf fonts, it seems that the engine is mixing up px (pixels) and pt (points).

I have a font that is 11x11 pixels (this one), however, when I import it, AGS says it has a point size of 11 and thus a pixel height of 14:



However, this is incorrect because as mentioned above, the pixel size is 11, which corresponds to a point size of 8. This happens with other fonts too, e.g., if I have a font with a nominal size of 9px, AGS will say it's 9pt, etc.

[Crimson Wizard]

I have a font that is 11x11 pixels (this one), however, when I import it, AGS says it has a point size of 11 and thus a pixel height of 14:



However, this is incorrect because as mentioned above, the pixel size is 11, which corresponds to a point size of 8.

Please check the value of "TTF font adjustment" property?

[Laura Hunt]

Please check the value of "TTF font adjustment" property?

In my example above, it's set to "Resize ascender to the nominal font height". If I switch it to "Do nothing", the Font Height field changes to 13.

That's the only thing that changes; the point size field still displays "11 pt".

[Crimson Wizard]

However, this is incorrect because as mentioned above, the pixel size is 11

I'm not certain if I understand this. AFAIK the TTF is not supposed to have a fixed pixel size itself, its pixel size depends on the point size it's used at, as well as some characteristics.
In the description it sais "font is designed to be displayed at 11px and multiples thereof", but afaik that does not mean that "the font is 11px".
Where may I see the information about point size 8 corresponding to 11px?

AGS asks for the size you want to import the font at, and it's the "Point size" property it displays.

UPDATE: I've read a bit about this, and apparently AGS editor uses "Point" term incorrectly there. I think it's meaning is rather "Import size", as in something that user requested.
TBH this specific may be due to how the importing process works with the library that we're using.

It also might be that the new "import ttf" dialog is also wrong, and should be designed differently. As an option it may be reversed to its old looks if it was more correct.

On a side note, testing this font in 3.2.1 produces same results as 3.6.0, judging by the font looks (when importing with same size parameter).

UPDATE 2: Running under debugger, i can see that when the font is imported with the size "11", its data sais "size 11x11". However the font rendering library calculates final size by summing "ascender + descender", which results in a higher height (13). AGS uses this reported number to show as "Font Height".
What puzzles me further is that under the same circumstances the actual size of letters on screen (tested by screenshot) could be 14px (capital letters).
Perhaps, 11x11 is some kind of a control size, not directly related to particular letter(s).
I wish I knew more about TTF fonts.

[Laura Hunt]

I'm not certain if I understand this. AFAIK the TTF is not supposed to have a fixed pixel size itself, its pixel size depends on the point size it's used at, as well as some characteristics.
In the description it sais "font is designed to be displayed at 11px and multiples thereof", but afaik that does not mean that "the font is 11px".

Right, but pixel fonts like this one are not "real" true type fonts; rather they are more like bitmap fonts saved as ttf for convenience and for wider compatibilty than a strict bitmap font format. But they are only meant to be rendered at very specific sizes (i.e., the "native" size the characters/glyphs were designed at, and integer multipliers of that, just like any pixel art in general).

Where may I see the information about point size 8 corresponding to 11px?

Here, for example: https://simplecss.eu/pxtoems.html

It also might be that the new "import ttf" dialog is also wrong, and should be designed differently. As an option it may be reversed to its old looks if it was more correct.

It could be an option, yes. So far, the "Import at font's point size" option hasn't done anything for me in most cases. How does AGS calculate the font's point size anyway, given that, as you said above, a true vector font doesn't really have a specific/default point size?

UPDATE 2: Running under debugger, i can see that when the font is imported with the size "11", its data sais "size 11x11". However the font rendering library calculates final size by summing "ascender + descender", which results in a higher height (13). AGS uses this reported number to show as "Font Height".
What puzzles me further is that under the same circumstances the actual size of letters on screen (tested by screenshot) could be 14px (capital letters).
Perhaps, 11x11 is some kind of a control size, not directly related to particular letter(s).

Yes, I found that confusing too. I'm assuming that 11x11 is simply saying that every character by itself fits in a 11x11 cell, but of course, this is not the same as the total font height when we take the tallest characters + descenders into account. But at least this confirms that AGS is calculating the total font height correctly as 14 (when the "resize ascender" option is active). This is making me think that maybe AGS is indeed doing things correctly, and it's the font designers who are failing to account for the real total height of their fonts by reporting only the "cell size".

[Crimson Wizard]

It also might be that the new "import ttf" dialog is also wrong, and should be designed differently. As an option it may be reversed to its old looks if it was more correct.

It could be an option, yes. So far, the "Import at font's point size" option hasn't done anything for me in most cases. How does AGS calculate the font's point size anyway, given that, as you said above, a true vector font doesn't really have a specific/default point size?

I think there may be a misunderstanding too. "Import at font's point size" also uses the number field, it tries to import the font at the typed size. But it uses "point" term incorrectly, as it seems. So the correct title would be "Import at this font's size".
The difference between two these options is that the first option imports at the size given by user, and the second searches for the font size that results in particular full font height (ascender + descender).
I may either remove the second option if it's not useful, or reorganize fields to make it more clear that both options use the number field.

But at least this confirms that AGS is calculating the total font height correctly as 14 (when the "resize ascender" option is active).

Erm, this particular option is a backward compatibility feature, and is meant mostly for fonts which made specifically for AGS in the past. Because ascender is resized to match the demanded font size, this option may result in font glyphs being drawn lower, adding vertical space above the letters.

The problem with 3.6.0 is that it still uses unmodified templates from 3.5.*, and therefore when you create your games all the properties are adjusted for importing these older projects.
We need to update the templates to have the recommended settings for 3.6.0, with "resize ascender" off, and other changes.

[Laura Hunt]

It also might be that the new "import ttf" dialog is also wrong, and should be designed differently. As an option it may be reversed to its old looks if it was more correct.

It could be an option, yes. So far, the "Import at font's point size" option hasn't done anything for me in most cases. How does AGS calculate the font's point size anyway, given that, as you said above, a true vector font doesn't really have a specific/default point size?

I think there may be a misunderstanding too. "Import at font's point size" also uses the number field, it tries to import the font at the typed size. But it uses "point" term incorrectly, as it seems. So the correct title would be "Import at this font's size".
The difference between two these options is that the first option imports at the size given by user, and the second searches for the font size that results in particular full font height (ascender + descender).
I may either remove the second option if it's not useful, or reorganize fields to make it more clear that both options use the number field.

Oh. Oh! Yeah, that wasn't clear to me at all, I thought only the second option used the number field.

But at least this confirms that AGS is calculating the total font height correctly as 14 (when the "resize ascender" option is active).

Erm, this particular option is a backward compatibility feature, and is meant mostly for fonts which made specifically for AGS in the past. Because ascender is resized to match the demanded font size, this option may result in font glyphs being drawn lower, adding vertical space above the letters.

The problem with 3.6.0 is that it still uses unmodified templates from 3.5.*, and therefore when you create your games all the properties are adjusted for importing these older projects.
We need to update the templates to have the recommended settings for 3.6.0, with "resize ascender" off, and other changes.

Yes, I had the impression that "resize ascender" was the new option and "do nothing" was the backwards-compatible one. All clear now.

[Baguettator]

PROBLEM !!

I installed the 3.6 last version, and I encountered a problem using the ReadRawLine function.

I use this function to read some attributes for characters and custom things players can create to play with in the game. So I read these informations in a .txt file, and store that in a struct.

I have to read this line :

0;NomVéhicCréé0;null;null;null;0;25;25;25;25;55;35;10;10;90;10;null;0;null;0;null;0;0;

and it crashes !

I debugged the situation and found that, using this function, it meant that :

String s=File.ReadRawLineBack();
Display(s);
// Displayed : "0;NomV"

It seems that "é" was causing an error in the ReadRawLineBack function. I changed into the .txt file and replaced all the "é" with "e", and it worked perfectly.

Any idea what's happenning ? It was NOT happenning with the 3.5.1 version I used before

EDIT : was the limit of 199 removed for the ReadRawLineBack function ? I thought that yes, but I'm not sure...

EDIT 2 : just managed to launch the game with the 3.6, and I found that scrolling with the finger pad works perfectly ! (it was one of my previous questions).

[Crimson Wizard]

It seems that "é" was causing an error in the ReadRawLineBack function. I changed into the .txt file and replaced all the "é" with "e", and it worked perfectly.

Any idea what's happenning ? It was NOT happenning with the 3.5.1 version I used before

Yes, this is a bug in 3.6.0, any letter with code above 127 will be mistakenly treated as an end of file. We have this recorded, and it will be trivial to fix.

I should note just in case, that if the letter is a "unicode" one (code above 255), and text is saved as UTF-8, this expected to be read normally (after this bug is fixed), as it reads byte by byte, but the string will only be correctly displayed if the engine works in the Unicode mode. Currently it may only be switched to this mode by the use of translation options; if you use translations and it has a utf-8 encoding option set, as explained in the thread: https://www.adventuregamestudio.co.uk/forums/index.php?topic=59240.0

EDIT : was the limit of 199 removed for the ReadRawLineBack function ? I thought that yes, but I'm not sure...

Yes, it should be mentioned in the Changes log: https://github.com/adventuregamestudio/ags/blob/master/Changes.txt

EDIT 2 : just managed to launch the game with the 3.6, and I found that scrolling with the finger pad works perfectly ! (it was one of my previous questions).

Nice, this is very good to know that SDL2 works better in this regard.

[Baguettator]

Does that mean that I need to put this :

// Text encoding hint
//#Encoding=UTF-8
// Source text encoding hint
//#GameEncoding=UTF-8

At the top of my translation file, then save the file where I have to read something using the ReadRawLineBack function in UTF-8, and then it will work as expected ?

[Crimson Wizard]

Does that mean that I need to put this :

At the top of my translation file, then save the file where I have to read something using the ReadRawLineBack function in UTF-8, and then it will work as expected ?

You need to have that translation active, for the engine to display the UTF-8 text.
Create and compile translation normally, you don't have to save the file somewhere else.


On a separate note, we're currently conducting experiments to see how easy that would be to make the Editor itself work and save data in unicode mode. If it worked, then users won't have to rely on translations.
There are preliminary tests that give a hope it's possible, but this may take a while to integrate, so no promises for now.