Messages

Right now I have following installed (checked in the SDK manager):

SDK Platforms:
* Android 11 (api level 30)
* Android 10 (api level 29)

SDK Tools:
* Android SDK build tools: 32.0.0, 30.0.3, 29.0.3
* NDK (side by side): 22.0... , 21.3...
* Android command line tools 6.0
* Android emulator 30.3.5
* Android SDK platform tools 30.0.5


May someone else say what do they have?

May the problem be that I set wrong path to ANDROID_HOME? Do I need to set it to the Android Studio root folder, or to one of the subfolders?

Is it possible to post a list of components that I have to check and install in the SDK Manager? Because I tried installing the ones from error message, was not able to find all of them in the list, and even after i installed some of them it kept reporting same missing components again.

[EDIT:]

I'm testing this Android building now. After setting up ANDROID_HOME and JAVA_HOME, I'm getting following error in the command window:

Spoiler

FAILURE: Build failed with an exception.

* Where:
Build file 'D:\Dev\ags-games\ags-camdemo\Compiled\Android\mygame\app\build.gradl
e' line: 31

* What went wrong:
A problem occurred evaluating project ':app'.
> path may not be null or empty string. path=''

[close]

What is this "path" variable refering to, do I need to also set it?
EDIT: Oh, looking at the code, this is keyStoreProperties not set. I wish there was some kind of error message thrown with more details.

UPDATE 1: I hate Android Studio because it looks strange and I cannot find anything it its menus.
So ended up generating keystore from command line following instructions:
https://stackoverflow.com/questions/3997748/how-can-i-create-a-keystore

UPDATE 2: next problem:

Spoiler

* What went wrong:
Could not determine the dependencies of task ':app:compileReleaseJavaWithJavac'.

> Failed to install the following Android SDK packages as some licences have not
been accepted.
     patcher;v4 SDK Patch Applier v4
     emulator Android Emulator
     build-tools;30.0.3 Android SDK Build-Tools 30.0.3
     platform-tools Android SDK Platform-Tools
     platforms;android-29 Android SDK Platform 29
     tools Android SDK Tools
  To build this project, accept the SDK license agreements and install the missi
ng components using the Android Studio SDK Manager.

[close]

So, there are missing components, but I have two questions:
- why is emulator required to build the game?
- is the SDK platform version a variable somewhere, or this is hardcoded, and we must use exactly that version?

"ICBM" by Michael Davis / REPVBLIC, has project source available on gamejolt:
https://gamejolt.com/games/icbm/57197

with original art and soundtrack too.

Sorry, I didn't right understand. Do must I make global variables? And after that how can I fill your conditions?

You fill them with actions corresponding to the event. Just like you fill on_mouse_click now.

For a simple example:

Code: ags

     else if (!mouse_down && was_mouse_down)
     {
         // user just released the button
         // call room interaction (walking, using objects, etc)
         Room.ProcessClick(mouse.x, mouse.y);
     }

If there are more problems with this code, I suggest discussing this in the "Technical help" forum, as this is mostly a scripting question.

[@Mehrdad]

As I said before we need to "release mouse" instead "press down" on mobiles. User wants search hotspots with finger moves on screen. It start to walking with "press down" and mobile users don't want it.

@Mehrdad, indeed AGS currently does not have a ready event for released mouse, but you can change your script to react to the mouse state change (pressed - released) in the repeatedly_execute.

To do this:
1) have a global variable to remember last mouse button state
2) check in repeatedly_execute for the current mouse button state
3) compare to the last saved state. If button's state changed, do the action.
4) save new state in the variable.

Code: ags

bool was_mouse_down;

function repeatedly_execute()
{
     bool mouse_down = Mouse.IsButtonDown(eMouseLeft);
     if (mouse_down && !was_mouse_down)
     {
         // user just pressed the button
     }
     else if (!mouse_down && was_mouse_down)
     {
         // user just released the button
     }
     was_mouse_down = mouse_down; // remember new state
}

Also I may recommend speaking with Wadjet Eye (Dave and Janet Gilberts) and other people who ported their games to mobile, perhaps they will have some advices.

Also, an interesting side effect was that in the compiled Windows version, frame-linked sounds were not playing at all. I don't know what this has to do with the changes introduced for the Android build, but I can confirm that when I compiled and ran my game with the "vanilla" AGS 3.6.0.17 Alpha 18 build, those sounds played correctly.

There's something broken in the master branch after the audio refactor i did few days ago.

From my own tests, ViewFrame sounds sometimes play and sometimes don't, which seem random.

I agree 100% with moving to ags4 right after. Just to clarify, we can really do the tools there and backport if needed, I think it's the better way too.

Sorry, did not mean to discourage you, or anything! I just suddenly got agitated, wondering if more things will be put on 3.6, while we already have a big list of planned but undeveloped features there.

The idea of build configurations where you may select files and compile options sounds pretty interesting. I guess right now this may already be doable to some extent by writing package scripts by hand which call agspak and compiler tools? I wish we had some kind of "feature group lists" that describe these ideas for the future, and all related tasks (e.g. "Automated game building"), so that everyone could know where we are going.

But this is offtopic here, so I will shut up.

I would like to redo how the build process of AGS works, but I am not sure I can do it fast enough and bug free enough to be something that gets in 3.6.0, but ideally I would like to be possible so you can selectively exclude rooms or set macros and things and build different versions of game data, possibly paired with different versions of acsetup.cfg and then can choose what gets build to which system and things like that. But there's already a plan to get after 3.6.0 is done a version of the editor that uses command line tools to build AGS games so I think I would prefer to have that happen at that time. So currently there is no reasonable panel to place things like an adb interface or a gradle interface. :/

I honestly think it's best to switch focus to ags4 soon after 3.6.0, where you can overhaul whatever you like, cutting old features if necessary. ags4 has been in development "limbo" for a long while now, and becomes stale. There's a new script compiler with lots of useful features, an open room format almost ready, and someone may eventually do open sprite format as well. I fear that pretty soon someone asks: why cannot we have these features if they are ready? Then someone will get an idea to start moving them to 3.* branch, and development will go on a new cycle of getting stuck in a 3.* again. This happened before, several times, in the last 5 or so years.

The 3.6.0 was not supposed to be as big as it became, the sole purpose of it initially was to have a SDL2-based engine that has full backward compatibility, as a backup. I'm afraid that pushing changes there further will eventually come in conflict with this concept. When I started 3.6.0 there were two major goals: SDL2 and command-line build tools. SDL2 is practically done, and tool development was unfortunately frozen at some point. But compatible tools may be added to that branch later when time permits, or even backported from ags4 if they are first done there.

[REDACTED] removed unnecessary ramblings

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.

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.

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.

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.

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.