Messages

So apparently it was a problem of permissions. I solved it with

Code: ags

 chmod -R 755 NameofGame.app 

After that, I was able to launch the game, after the usual warning about insecure source.

I think this is the similar problem to the linux distribution that is packed by the Editor.

Okay, I will probably begin pulling minor changes back into 3.5.*/3.6.0. There was a number of small but useful additions.

Actually I am no longer sure if that's was a right thing to do. I keep making so many bad planning decisions and this development became an endless mess.
I worried that will end up working on several versions in parallel again (and it happened anyway). Some changes we had were rather risky (like new font outlines could produce new font errors and require further optimization and I did not have time to work on that), but others were relatively minor. I also did not know how much time will it take to complete 3.5.1, and in the end everything takes much more time than expected. And I wanted to move to ags4 development completely and stop working on ags3, but with ags4 it's not clear when the first version will be ready. We still do not have a proper milestone for it and because of that it's impossible to tell when to not begin coding new functionality there. For example, now I think that it might be a good idea to try having first 4.0 version with Unicode support, as that can be a breaking change.

So now I'll probably will have to begin porting certain changes back to 3.5.1 or next minor 3.5 or 3.6 update. Need to review what was in the dropped branch again to see what may be worth pulling over.

-Weird bugs related to the custom blocking functions (redundant as of upcoming 3.5.x version with Wait() extensions)

I need to clarify, these Wait extensions are no longer in 3.5.x, they were moved to ags4 development, as well as many other recently implemented script functions. I made a decision to only keep perfomance/backend updates in 3.* branch from now on and only add new script API if there's a critical gap in functionality due to recent changes or something (like happened with GUI.Visible and "popup at y" guis).
All the new API is going to ags4 now.

ags4 branch already features a new script compiler written by fernewelten that has many things fixed and new good things like array.Length property. We were also discussing what's required for pointers in pointers, but that was not implemented just yet.

In theory this compiler could be backported to ags3 branch too, as it does not change any data formats and not reliant on anything else in the editor or engine (except for array.Length)... maybe we could see to it when 3.6.0 comes close to completion. Or maybe we should just focus on releasing a preliminary ags4 version sooner.

But does it mean that the Android Launcher has to be launched by the player ? Or I can create with it the game version for Android ?

Android Launcher is a ready Android app, it works like a menu to run compiled games from the file system.

Also, I don't know what is the "External storage device"...?

Storage devices you plug to Android with a cable, like SSD.
But I think this is no longer necessary, I was able to run games uploaded right to Android from PC.

I keep forgetting to update the post with instructions (it's made by another person many years ago) and adding one to the manual.

But in brief it goes like this. There are two ways you can run on Android:

1. "Android Launcher" is a program provided with each recent AGS release. You find it under "For Android" spoiler in the release post. It lets you run any random AGS game on Android, if you upload compiled games by hand.
There are short instruction on using launcher here: https://github.com/adventuregamestudio/ags/blob/master/Android/README.md#using-the-engine. You need only first 3 sections of that readme (the rest is for building the program from source code).
It sais that games must be placed on the external storing device, in the "ags" directory. Each game needs its own subdirectory. The data file is automatically detected within the folder.
But I believe that most recent Launcher also lets you choose the destination path in the app menu.

2. Native libraries for Android (also provided with recent release) let you build individual APK for your game. The process is not yet automated. You will need Android Studio for that.
There was a Editor plugin made by monkey0506 in the past, and the instructions, with links to Android Studio projects, were written by eri0o:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=55681.0

To clarify, this is basically an alternate GUI system made with AGS own drawing on overlays; does not requires any plugins etc?

standing in front of a neon-yellow single-color background so garish that it literally hurts my eyes watching it.

This is what the smog in Los Angeles will look like in 2077.

I'm using 3.5.0.2 beta,so that might be the issue?

I don't know what is this about, but if remember correctly there was about a year of development between 3.5.0.2 (alpha) and the final release, so alot of changes have been done in between.

Sorry for bumping, but someone asked about this on Discord lately, and I decided to post little more.

"AGS Awards" repository: https://bitbucket.org/agsa/ags-awards-source/src/master/

My two games, but have to warn that they are not "conventional".
"Last & Furious" (topdown racing): https://github.com/ivan-mogilko/ags-lastfurious
"Cameras Tech Demo" (technical demo, work in progress): https://github.com/ivan-mogilko/ags-camdemo

Games by eri0o I remember about:
"Dungeon Hands" (card game): https://github.com/ericoporto/DungeonHands
"Hell Puppy" (arcade): https://github.com/VacaRoxa/dogfromhell

Byte of the Draculator II
http://www.vanwijst.com/games/swarm/draculator_source.zip
(if clicking on the link does not work, do right-click and save as)

Ancient demo game which was distributed with AGS in the past:
https://github.com/adventuregamestudio/ags-demo-quest
(not a very suitable game in my opinion)

I found this much earlier this year, probably did not post here. It's hard to tell if I new what "post-rock" genre means before, but I like it.

Few examples, by same (or related) people, Hungarian bands called "Silent Island" and "Black Hill".

https://www.youtube.com/watch?v=_GV5_CpaybU

https://www.youtube.com/watch?v=eTvJUa6Vg78

https://www.youtube.com/watch?v=fOiGc-UPGhE

https://www.youtube.com/watch?v=lsjpPHVYxMQ

https://www.youtube.com/watch?v=TRjRGFeRo6w

Not sure whom to address this, there's a game called "Hit The Freak" which download is not available in the database anymore, but I have a download link attached by user to a bug report a while ago: https://github.com/adventuregamestudio/ags/files/3955030/git.tar.gz
(Don't know how long this link will be available, it's hosted by github now and is automatically named archive containing another archive...)

I could be mistaken, but I thought allegro.log is only written if you compiled engine in Debug configuration or using debug version of allegro library. Could you double check that you are using a release build?

What kind of messages that log contains?

PS. AGS itself does not control that behavior.

Added all the remaining above from this thread: https://github.com/adventuregamestudio/ags-manual/wiki/FAQ

(maybe in the future we may need to split FAQ in some sections too, for faster navigation, if it becomes overfilled)

This is going a bit off-topic, but following some of the github discussions, I've seen claims that the rewritesâ€"both of the compiler and the backend switch from Allegro to SDL, I believeâ€"have led to worse performance. Is that correct, and if so, has it been addressed?

AGS already does not have great performance, so I would be nervous about an upgrade that degraded it further.

Where was the claim that compiler rewrite led to worse perfomance? I haven't seen such comment. There will be a switch in the editor for the first time, that toggles between old and new compiler.
Someone might do a perfomance test on a big complex script.

There was a notion that Software renderer has worse perfomance for non-32bit games, and I have suggestions why, but I haven't seen it myself only heard 1 person talking about it. The new software renderer is working about same way as it worked in mobile ports since the beginning (Android, iOS), but maybe there's some mistake or unnecessary operation that affects the speed. I did not address that yet because just finished the work on the port branch itself and did not have time to investigate.

There were also a problem that sound plays too loud in some games, and in one game I tested sound did not play correctly at all. Other games seem to run alright.

The SDL port is still a WIP, it's located in the wip code branch in the repository, and requires testing most of all.

It may have slightly worse if you are using the Software driver but honestly no one should ever.

At the moment Software renderer is the only way to run properly 8-bit games with palette effects, as other renderers are not made to update their textures when palette change (this is doable but was not a priority).

I saw in the GIT Discussions that you are also rewriting the script compiler in c++. Was this originally part of the editor in C#? What is the benefit of the rewrite? BTW, nice job on that rewrite. I had been following along and it seems like a lot of work went into it with everyone involved.

fernewelten did the rewrite on his own initiative. Script compiler was originally written in C and is now C++. The main reason for rewrite was to have a cleaner code, because old compiler is very difficult to read and understand, let alone improve.

I forgot to mention that we are also completely rewriting audio code to use OpenAL implementation based on SDL2.

Also, what effect will switching from Allegro 4 to SDL2 have?

Do you mean effect on users or effect on development?

The primary reasons for changing libraries were:
* better modern OS support,
* better device support (e.g. Allegro 4 did not have any native touchscreen support, and SDL2 does),
* because Allegro 4 is long discontinued we are stuck with ancient utility libraries based on Allegro 4, or have to write our own.

We still are going to use parts of Allegro 4 embedded into the engine, because SDL2 did not have alternative for everything (Allegro is just a more wholesome library), that's easier approach at the moment.
Raw bitmaps and drawing functions are prime example, as SDL2 has only rudimentary support for that (it's more focused on texture-based gfx).

["ags3"]

That became apparent long time ago that developing AGS further becomes difficult while keeping the "luggage" of old functionality, which was mostly kept for running old games and easier project upgrade.
So this is overdue, and we are planning to introduce a "break" in the versions, where the updates are split into two "branches". We currently call these branches "ags3" and "ags4", but these are informal names, and may be given proper names later.

"ags3" is going to be a fully backward compatible version, based on the latest AGS 3.5.0. From now on it will only receive bug fixes, perfomance and utility updates. There will be no new script functions or game features whatsoever.
There's at least one planned update currently, which number will probably be AGS 3.6.0, and its main feature will be change from "Allegro 4" to SDL2 library. AGS used "Allegro 4" for nearly two decades, but it's discontinued, and often not very well suited for the contemporary OSes. As this change comes with new potential problems, there may be lesser updates in the middle (like 3.5.1 etc) when necessary, until SDL2 update works well enough to be officially released.

"ags4" will be a breaking change version, also based on AGS 3.5.0, but having all the deprecated functions cut off. It may also have other things removed, such as certain plugin functions support which are not convenient to keep. This will be the main branch to develop AGS further. It will also be updated to SDL2 library.
It's not known at the moment how it will be developed, there are several priority tasks, but it mostly depends on how much time contributors can spare, so it's too early to talk about any new features.
We do not yet know what number will this version use, but probably we'll skip couple of them to reserve for "ags3" branch, so somewhere in the range of AGS 3.7.0 - 3.9.0.


Related short-term roadmap ticket on github: https://github.com/adventuregamestudio/ags/issues/1121

There's also something similar, but idk if related or not: https://github.com/adventuregamestudio/ags/issues/935
I will open a separate ticket just in case. https://github.com/adventuregamestudio/ags/issues/1123

[@isatche]

@isatche

This workaround is best that I could come with after experiments. It replaces Move command with manual coordinate change. This should work because you use eAnywhere, so do not need pathfinding here:

Code: ags

       player.LockView(21);
       player.Animate(0, 3, eOnce, eNoBlock);
       while (player.x > 350)
       {
           player.x -= 5; // change 5 to the wanted speed
           Wait(1);
       }

PS. Not relevant to the problem at hand, but each View you create adds a script constant identical to the view's name in caps. E.g. if you create View called vTumble there will be script constant VTUMBLE equal to the View's ID.
Then you can use this constant instead of bare numbers, like:

Code: ags

player.LockView(VTUMBLE);

this may make it easier to understand your code in case you forget something.