Messages

The Editor combining Android + Unicode may be downloaded from here:
https://cirrus-ci.com/task/5505374429118464

I think adapting mouse to touch is bad, the developer should handle touch input differently.
<...>
I would rather have proper 1 and let people implement this in-game.

The problem is that we were using Android port not only to make games, but also to run existing games whose authors were not preparing for Android (this is what "universal" game launcher was meant for, as 99% of AGS games do not have proper mobile ports). This is why we need some basic controls/keyboard as a default solution for such cases.

2. Keyboard is not there, the problem is this was done through a menu, but SDL2 is done in a way that it grabs the surface and draw and it's over painting any control I throw on top.

Was it done by drawing a keyboard control right on top of the game's surface in the old port? I wish i knew more about this.

About 2, I could make that version, yes, but I can advance that the Unicode version doesn't support font ligatures yet. Font ligatures requires the Harfbuzz library and we haven't gone there yet.

We were discussing this on Discord just recently, and turns out Mehrdad has found a way to make it work, using some software called "ParsiNegar" which generates Persian text, which is then copied into the AGS Editor. I'm not exactly sure how it manages to do this, but visually it seems working.

If no font ligatures is fine for now I can create that build, but probably only Friday. Please test the Unicode version separately though, we are probably going to be integrating both later but knowing what works and what doesn't helps polishing the features.

If you're too busy, maybe I could make a Draft PR for a test with these merged? Assuming it's enough to use your existing android branch. I'd prefer to rely on build server instead of making these by hand.

After adding Unicode support to the engine in 3.6.0, and allowing UTF-8 translation files, I honestly thought to stop there, as it covered some use-cases and we had a lot of other problems to work on.
But now when 3.6.0 is progressing well towards completion, I suddenly decided to look into this again, and found that maybe it's quite doable to support Unicode right in the Editor.
There were number of doubts, but eventually it appeared less scary than anticipated.

Following is an experimental build, made on top of latest 3.6.0. This is only for testing, please don't use for real games yet, because if it contains mistakes it may ruin your game texts.
Download zip: https://www.dropbox.com/s/36iscyq3ydfb70t/AGS-3.6.0.17-Alpha18-unicode.zip?dl=0
Opened issue (if necessary): https://github.com/adventuregamestudio/ags/pull/1542

Find "Game text format" in General Settings (in the topmost section), and switch to UTF-8..
Make sure to import proper unicode fonts and set them anywhere you want them be used (Game.SpeechFont, gui labels, and so on).
Here's a free universal one if you need: https://unifoundry.com/unifont/ but in theory any correct TTF font will work.



What is supposed to work (if it does not - that's a bug):
* Human texts in game options: object descriptions, etc
* Custom properties' text values;
* Texts in scripts (in double quotes)
* Speech lines in dialog scripts
* Mixing multiple languages, even in the same string.

What will not work (and not supposed to):
* Script names of characters and objects, etc;
* Custom properties' names;
* Anything else in scripts: variables, function names etc.

3.6.0-alpha18 is an intel binary. I got errors compiling sdl2 when trying to do a universal build.

Could you mention which errors did you get? Maybe we should look into this.

[Editor:]

Updated to Alpha 18
(use download links in the first post)

I had to post another update early, because there was a critical bug found in the Alpha 17, related to audio playback.

New changes:

Editor:
- The new Editor's Preferences dialog now features several tabs, including "Advanced" with a property grid. There's nothing special there yet (it just repeats all the same options in the table format), but this will be used later to add certain settings for Android build, etc.
- Added Room.BackgroundAnimationEnabled property to let have disabled animation on room load.
- Renamed font's "Point Size" property to just "Font Size", because AGS historically used wrong term in regards to this value.
- An attempt to enhance new "Import TTF dialog", making it easier for users to understand the import method selection.

Engine:
- Fixed potential crash occuring randomly when the audio playback starts (regression in 3.6.0.16).

I don't know if it's a problem, but it's a bit annoying for me : in my struct to manage the maps in my game, I have plenty of functions to set up the map. I have a huge function that creates the chosen map (with if/else conditions). The problem is that when my function becomes to big, and if I write something like that :
<...>
Normally, when I hit the "(", AGS shows me the order of the parameters below the editor's text. But it doesn't if the function is too big (I think after a hundred or so lines long).

This sounds like a autocomplete bug; we may open a bug report for that. Autocomplete is known to have number of problems in AGS...

as Ego walks up/down the screen and the scaling changes, the shadow sort of drifts away/drifts back again. Example below

I think this happens because character scales, and shadow scales, but distance between them remains the same absolute number. So you also need to scale the distance (offset).
Something like

Code: ags

function late_repeatedly_execute_always()
{
    cShadow.Scaling = cEgo.Scaling;
    cShadow.x = cEgo.x + (cShadow.Scaling * shadow_offsetx) / 100;
    cShadow.y = cEgo.y + (cShadow.Scaling * shadow_offsety) / 100;
}

Though I've noticed that the shadow doesn't scale on walkable areas which have variable scaling levels. UseRoomAreaScaling is set to True for the shadow character. Am I missing something straight forward here do you think?

Well, if you modify it's position, it may get outside the walkable area. In this case you might turn UseRoomAreaScaling off and additionally set its scaling to match the character:

Code: ags

cShadow.Scaling = cEgo.Scaling;

If it's only the vertical offset, you may use Character.z property to assign a visual offset by Y axis. This way you may still use FollowCharacter function.


If above does not work for any reason, or the offset is more complicated, the solution is to instead assign shadow's position yourself in "late_repeatedly_execute_always", as this function is called right after the game update (but before the game redraw).

Code: ags

function late_repeatedly_execute_always()
{
    cShadow.x = cEgo.x + shadow_offsetx;
    cShadow.y = cEgo.y + shadow_offsety;
}

Shouldn't you divide those widths and heights by 2, CW?

Right.

I already scripted all the tokens with their top-left corner coordinate (which is the way AGS works for buttons, and tokens are represented by buttons), and it should be very long to change it now...

I made a mistake. You do not have to use center positions. You may keep existing top-left positions (non rotated), and then adjust tile's position after it is rotated like this:

Code: ags

new_x = old_x + (old_width - new_width) / 2;
new_y = old_y + (old_height - new_height) / 2;

EDIT: fixed by /2

This will work generally if the tile is resized for any reason.

To clarify: what you normally do is save target coordinates in variables, and then move Camera bit by bit until it reaches the saved destination.

For blocking movement you do that in a loop; for non-blocking you have to save coordinates in global variables and move camera in repeatedly_execute (or repeatedly_execute_always).



This is what Tween modules does (and it does many other things too).

I presume that if I only talk about 45° multipliers (45, 135, 225 and 315), these dynamicsprites should have the same width/heights ?

That should be correct, all mirror angles should result in the same size.

[centers]

That said, but I still wonder if this is necessary.

Could you save positions of the token centers instead of top-left corners? Then you won't have to calculate these coordinate changes, and realign the sprites only after they change.
This depends on what kind of map you have though.

Hey, I would like to suggest two modifications on the top post

Should be done now.

But if I rotate the tile, I have to rotate the tokens too. So they change their rotation (up becomes right for a 90° rotation, or becomes down for a 180° rotation, etc), and their coordinates. To change their coordinates, I need to know their width and height. I have to script it during a time when DynamicSprites are NOT created yet. So I can't use DynamicSprite.Width etc

Is the formula too complex ?

Oh, sorry. I was wondering if you are doing some unnecessary work for sprite rotation.

Formula is this (math):

Code: ags

new_width = (cos(angle) * old_width + sin(angle) * old_height);
new_height = (sin(angle) * old_width + cos(angle) * old_height);

In AGS script that would be:

Code: ags

new_width = FloatToInt(Math.Cos(angle) * IntToFloat(old_width) + Math.Sin(angle) * IntToFloat(old_height));
new_height = FloatToInt(Math.Sin(angle) * IntToFloat(old_width) + Math.Cos(angle) * IntToFloat(old_height));

The angle above is in radians. If you have angle in degrees, you need to first convert it using Maths.DegreesToRadians.

I just wanted to know the formula to calculate the new height/width of the dynamic sprite.

But why do you need this formula? Are you resizing sprites yourself before rotating?
The manual sais that for DynamicSprite.Rotate "AGS will automatically calculate the new size required to hold the rotated image" if you pass no width and height.
That is, if you write just "f.Rotate(45);" it will be resized itself as necessary.

The width and height will be minimal necessary rectangle to accomodate the rotated image.

But why do you need to know how AGS does this? Do you want to know about the algorithm, or do you simply want to know resulting width and height? In the last case you may read DynamicSprite's Width and Height properties after rotation.

Hmm... I can't vizualize your solution. How could it "increase" the number of parameters in a function by passing a struct ?

You can put multiple variables in a managed struct and pass the instance of that struct as 1 parameter. There may be other solutions, depending on the situation: what the function is for, how do you use it, maybe it can be replaced with just a struct and setting struct members instead? But this is a general scripting topic.

EDIT : also new suggestion : would it be possible and technically possible to have a text in a label that uses different fonts ? Also for ListBox Items in different colors ? It could be useful But I don't know if it's technically possible in AGS ?

It's currently possible to script your own label or list box that uses several fonts and colors, with DrawingSurface and DynamicSprite functions.
In theory it's possible to implement some kind of a "rich text" control in the engine too, for example one that draws text using html-like tags, but that's a serious work that requires some good design decision first. We have already planned to wrap 3.6.0 version up, and now working towards finishing priority major features. The other features added were ones that cover problems that are too inconvenient for scripting and simple enough to do quickly in the engine at the same time.
If there's an actual interest in such engine feature, you may post it in the engine suggestions forum section, or our issue tracker on github.

[not do the first action]

I tried

Code: ags

if (keycode == eKeyEscape)
  {
   close_gui(gPanel);
  }

Your approach is wrong. You want to prevent certain action from happening, and trying to solve that by making a second action countering the first.
Instead you should find a way to not do the first action at all. You need to find where the panel is opened with Escape key, and add a condition there.



To elaborate a little more, suppose you have something like this in GlobalScript somewhere:

Code: ags

function on_key_press(eKeyCode keycode)
{
    if (keycode == eKeyEscape)
    {
         open_gui(gPanel);
    }
}

Then you may change this to:

Code: ags

function on_key_press(eKeyCode keycode)
{
    if (keycode == eKeyEscape)
    {
         if (player.Room != 1) // don't do if the room is 1
         {
              open_gui(gPanel);
         }
    }
}

Alternatively, if you do not want to use room numbers, you may set up Custom Properties for your rooms, and make a property that tells if gPanel is allowed or not, and check that instead.