[OLD-1] AGS engine Linux port

[Crimson Wizard]

I just installed alex4 from the official repos. It uses allegro 4 and also has broken sound. Can you confirm that?

Yes, I guess. It randomly either works or not, every time I run the game.
Sometimes it takes about 30 seconds for jitter to dissapear.
Sometimes it fixed itself after playing different sound, and sometimes breaks again when music restarts.

It also crashed in liballeg for me .

[Alberth]

This is the most stupid thing I've ever seen to encode these Ids like that...

They are for ALSA: 1095521089
and OSSD: 1330860868

The only stupid thing is to encode it as a decimal number. As a sequence of ASCII character bytes, it makes perfect sense:

Code: python

>>> hex(1330860868)
'0x4f535344'
>>> chr(0x4f) + chr(0x53) + chr(0x53) + chr(44)
'OSS,'
>>> hex( 1095521089)
'0x414c5341'
>>> chr(0x41) + chr(0x4c) + chr(0x53) + chr(0x41)
'ALSA'

[Crimson Wizard]

BigMC, there was an old discussion about Humble-Bundle pull request, and it mentions some changes to Allegro audio:
https://github.com/adventuregamestudio/ags/pull/109#issuecomment-31289275

May that have something to do with the issue we were experiencing here?

[BigMc]

It doesn't really convince me. In general ALSA over pulseaudio works so this must be fixable in Allegro or AGS. He added an SDL2 audio driver to Allegro, which will probably never go upstream. If someone would add a PulseAudio driver to Allegro, that could probably go upstream eventually.

[monkey0506]

Okay, it's just come to my attention that apparently the Linux engine isn't running standalone game data files any more. I know it was at one point, but now it simply refuses to find them. I have tested this with the game data files produced by the amended develop-3.4.0 branch, as well as the stripped EXE (hex edited everything leading up to "CLIB\x1A", which marks the start of game data) from both the new and legacy game compilers. The Windows engine reads all of these data files without issue. I also attempted to pad the raw game data file with "\x00\x00\x00\x00CLIB\x01\x02\x03\x04SIGE" (zero, as a four-byte integer, followed by the CLIB signature), but to no avail.

This fundamentally breaks the Linux build option because it produces files that don't run. I am testing to see if I can figure out at what version this stopped working, but I also confirmed the same behavior from the master branch.

[Crimson Wizard]

Okay, it's just come to my attention that apparently the Linux engine isn't running standalone game data files any more. I know it was at one point, but now it simply refuses to find them. I have tested this with the game data files produced by the amended develop-3.4.0 branch, as well as the stripped EXE (hex edited everything leading up to "CLIB\x1A", which marks the start of game data) from both the new and legacy game compilers. The Windows engine reads all of these data files without issue. I also attempted to pad the raw game data file with "\x00\x00\x00\x00CLIB\x01\x02\x03\x04SIGE" (zero, as a four-byte integer, followed by the CLIB signature), but to no avail.

To elaborate: they cannot run game created with latest develop-3.4.0 branch, or just any game?

What is the error message, exactly? Can you make a log file?

E: Just tried out both master and develop-3.4.0 branch on Linux, it runs existing games just fine.

[monkey0506]

Are you running the Windows executable or the game data file? Because it's telling me it can't find the game data file.

Edit: Using the "startgame" script produced by "debian/make_ags+libraries.sh", I can only load the game using the full Windows executable. In fact, it seems that the script is ignoring its arguments altogether. Here are my results:

startgame script with extracted game data file
> ./startgame
> ./startgame ./
> ./startgame ./data
> ./startgame ./ac2game.dta
> ./startgame ./data/ac2game.dta
> ./startgame ./NotARealPath/ac2game.dta

AGS: Game data file could not be found


startgame script with Windows executable
> ./startgame
> ./startgame ./
> ./startgame ./data
> ./startgame ./Game.exe
> ./startgame ./data/Game.exe
> ./startgame ./NotARealPath/Game.exe

(game runs normally)


ags engine with extracted game data file
> ./data/ags64
> ./data/ags64 ./
> ./data/ags64 ./data
> ./data/ags64 ./ac2game.dta
> ./data/ags64 ./data/ac2game.dta
> ./data/ags64 ./NotARealPath/ac2game.dta
/data> ./ags64
/data> ./ags64 ./
/data> ./ags64 ./NotARealPath
/data> ./ags64 ./NotARealPath/ac2game.dta

AGS: Game data file could not be found

/data> ./ags64 ./ac2game.dta

(game runs normally)


ags engine with Windows executable
> ./data/ags64
> ./data/ags64 ./
> ./data/ags64 ./data
> ./data/ags64 ./Game.exe
> ./data/ags64 ./data/Game.exe
> ./data/ags64 ./NotARealPath/Game.exe
/data> ./ags64 ./NotARealPath
/data> ./ags64 ./NotARealPath/Game.exe

AGS: Game data file could not be found

/data> ./ags64
/data> ./ags64 ./
/data> ./ags64 ./Game.exe

(game runs normally)

Were some changes made to the generated "startgame" script? Because this script is also being used to set up the path for the Allegro modules based on system architecture (pointing it to lib32 or lib64 directory), as well as any plugins that the game may use. So simply running the engine directly is not a viable solution for developers or their end-users.

Particularly bothersome is that the script is apparently not passing its arguments to the engine at all.

For reference, this is the contents of the script file produced by the current develop-3.4.0 branch:

Code: text

#!/bin/sh
SCRIPTPATH="$(dirname "$(readlink -f $0)")"

if test "x$@" = "x-h" -o "x$@" = "x--help"
  then
    echo "Usage:" "$(basename "$(readlink -f $0)")" "[<ags options>]"
    echo ""
fi

if test $(uname -m) = x86_64
  then
    ALLEGRO_MODULES="$SCRIPTPATH/data/lib64" "$SCRIPTPATH/data/ags64" "$@" "$SCRIPTPATH/data/"
  else
    ALLEGRO_MODULES="$SCRIPTPATH/data/lib32" "$SCRIPTPATH/data/ags32" "$@" "$SCRIPTPATH/data/"
fi

[Crimson Wizard]

Sorry, I don't know what the script does or how it is supposed to work.

I am building engine manually from the heads of master or develop-3.4.0 branch, then install the *.deb package and call "ags" either from game directory or passing game dir as parameter; and games are loaded just fine.

I'll try to investigate the start script when I can.

[BigMc]

The script expects the game to be in the data directory, as is well documented:
https://github.com/adventuregamestudio/ags/blob/master/debian/ags%2Blibraries/README

Next time rtfm before throwing around angry smileys.

[monkey0506]

Whom are you telling to stop throwing around angry smileys? I don't see anyone doing that. If you meant me, let me clarify that I have previously used the startgame script with ac2game.dta files without modification to the script. This method no longer works, although it should, as the engine should be receiving the data directory as the working directory. Based on the above, however, it also appears that the engine is not detecting the data file unless it is given as a parameter explicitly to the engine, not the script. The engine should be able to find the data file in the working directory, which actually appears to be the underlying problem, though it should also be pointed out that the script does not appear to be passing the command line arguments to the engine properly.


In case you weren't aware (from not rtfm), the ac2game.dta file is the game. Nothing in the linked documentation says that the Windows executable must be provided (nor is this the case for the engine to run the game).

[monkey0506]

And, I managed to track the problem down (with only a small amount of egg on my face ). I've been referring to "ac2game.dta" (because that's what the editor calls it!) but the engine refers to "ac2game.dat".

Relevant commits:

de3ac29, "Initial import" (Editor)

a45f1a5, "Initial release of AGS Engine source code!"

This bug has been around since before the git repositories were ever created. The only prior references (in editor code, referenced by a constant) were both in Editor/AGS.Editor/GUI/GUIController.cs, used at line 909 as a fall-back when loading a game file and line 976 as a fall-back when creating a new game (from a template file). With the one-way upgrade that the editor has done since AGS 3.0, it's highly unlikely that either of these ever would have arisen to cause problems. I will submit a quick commit to fix this in the editor code (fef66bf), mainly because it's only referenced in one place (defining the constant) whereas the editor references the string "ac2game.dat" in several locations.

Sorry about the confusion! This should amend the issue with the 3.4.0.2 Linux builds not running, they just need the data file renamed.

[Crimson Wizard]

And, I managed to track the problem down (with only a small amount of egg on my face ). I've been referring to "ac2game.dta" (because that's what the editor calls it!) but the engine refers to "ac2game.dat".

Monkey_05_06.... you are too fast jumping into conclusions and making fixes. Please don't do such fixes (changing standard file names) without at least some discussion first.

"ac2game.dta" is the standard file name used since AGS 2.*. I am not sure where did you see ac2game.dat in the Editor code, because I see only ac2game.dta everywhere.
Now with your fix loading 2.72 templates is broken, at least (I can't tell when loading old file from recent project can occur, yet it follows same logic).


EDIT: I scrapped this part of my previous post, because this situation was somewhat misleading.

From the analysis of the code it appears to me, that ac2game.dta and ac2game.dat are two different files.
ac2game.dta is an asset, found inside game package. It is the main asset, for it contains general game data.

The constant you changed is the name of the internal asset, not the game package; you should not be using this constant for the Linux builder at all.

ac2game.dat is a supposed name of game package for the engine to look for, if it did not find data in *.exe or *.ags.

UPD: Here, I found where it comes from:

VERSION 2.4, July 2002

Changed name of AC2GAME.DAT to AC2GAME.AGS to work with explorer better.

I think JJS did not realize that it's just a very old game name, and used it for some of his ports. I would suggest using newer name instead (*.ags).

[monkey0506]

Was there ever any solution to the audio problem? I'm trying to submit a bug fix for The Cat Lady on Steam, and I don't recall this issue being present before... I might have to revert back to an older build if I can't find a better solution.

[Crimson Wizard]

Was there ever any solution to the audio problem? I'm trying to submit a bug fix for The Cat Lady on Steam, and I don't recall this issue being present before... I might have to revert back to an older build if I can't find a better solution.

You mean the one with "jittering" sounds?
Do you know the last build that did not have the problem?
Earlier we found that same problem exists with other (non-AGS) games.

[monkey0506]

The previous build of TCL was done with a beta of 3.3.0, IIRC.



Edit: I don't seem to be able to find compatible shared libraries to build 3.3.0-beta, but I confirmed that the issue exists in 3.3.0-hotfix3. Honestly, I haven't tested the older build of TCL on this system/set-up, which is a new computer and I am running Linux Mint in VirtualBox. Previously I was booting directly into Linux. I will now go ahead and download the older build from Steam and see if the results are the same.

Edit v2.0: Okay, I have confirmed that the old build of TCL did NOT have the audio issue and was built with AGS 3.3.0.1156. By 3.3.0.1164 (hotfix 3) the issue was introduced. As I said, I can't seem to get a fresh build of 3.3.0-beta because it is complaining about incompatible shared libraries (i386 versions of Allegro libraries on 64-bit Linux Mint 17). In any case, it looks like 1156 was 3.3.0-final (initial "final" release, prior to the hotfixes). I will test later and see if I can narrow it down further (there were a total of 44 commits between 3.3.0-final and 3.3.0-hotfix3).

[monkey0506]

Further testing proved that 3.3.0-final did actually have the audio issue, it was just far less prevalent when the game was launched from the Steam for Linux client. When launching the game directly from the OS (using the exact same SH script), the issue occurred almost every time.

[Crimson Wizard]

Had anyone tried to discuss this on Allegro tech forums? Latest Allegro 4 update was released in 2012, which is not so long ago. And Linux is one of their main supported platforms. I find this unlikely that they could miss such a bug if it affected everyone. Maybe it affects only particular Linux builds?

Secondly, what may be tested is whether this effect affects all types of sound (Wav, Mp3, Ogg).

[Problem]

Any idea what can be done about the sound issue?
I tested two sound cards, and depending on which I use I get either perfect sound or complete garbage. The one that doesn't work causes a lot of noise and jitter, and the music plays too fast although the pitch is correct, as if the playback keeps skipping small parts during the playback. If anyone has a solution to this (even if it requires doing custom builds of the engine), I'd be very grateful. We'd like to release a Linux version of Rogue State on Steam, but of course we can only do this if the sound works.

[Crimson Wizard]

I think Wadjet Eye has their own Linux build which is fixed, but better ask them for details, because I could be mistaken.

[Problem]

I just asked, and they say they outsourced the Linux build a couple of years ago, and that it doesn't work the same way anymore. So they are also trying to figure it out.
I'll take a look at the AGS sources, but I fear this is beyond my abilities. But it can't hurt to try.