Adventure Game Studio | Forums

AGS Development => Engine Development => Topic started by: BigMc on 03 Jun 2012, 19:04

Title: AGS engine Linux port
Post by: BigMc on 03 Jun 2012, 19:04
AGS works nicely on Linux (32 and 64 bit) now. It supports games created with AGS 2.50 and higher.

There are instructions how to build AGS at

https://github.com/adventuregamestudio/ags/blob/master/debian/README.md

Please report bugs in the AGS issue tracker (http://www.adventuregamestudio.co.uk/yabb/index.php?action=projects).

EDIT: Removed most of the old text about multiarch etc., because AGS got native 64 bit support. :)
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 04 Jun 2012, 21:40
Thanks!

I will make it so that you can just give the game exe as parameter instead of renaming it to ac2game.dat. Also I thought about incorporating the PE reading code from the PSP launcher so that the game data is automatically found if you pass the game directory as parameter to the engine.

Furthermore plugin support for all platforms and also builtin plugins for all should be just around the corner.

Then the next thing is making the OpenGL driver more general (at the moment it is tuned to the needs of the mobile platforms) so that it works on Linux/Mac too.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 04 Jun 2012, 21:57
Nice. I will see if I can make the midi playback of allegro work out of the box by using some patches that are already in Debian.

EDIT: I just realized that the 64 bit stuff doesn't work like this on Debian unstable until libaldmb was rebuilt against liballegro4.4. That will take another couple of days I think.
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 05 Jun 2012, 19:14
I will make it so that you can just give the game exe as parameter instead of renaming it to ac2game.dat. Also I thought about incorporating the PE reading code from the PSP launcher so that the game data is automatically found if you pass the game directory as parameter to the engine.

Furthermore plugin support for all platforms and also builtin plugins for all should be just around the corner.
These two things are now implemented.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 05 Jun 2012, 23:28
Splendid! I updated the Wiki. I gave up on the midi patches front for now. The only patchset in Debian that has similar quality to the one you're suggesting is in the wrong format and converting it results in brokenness. And outputting raw ALSA midi and using that with Timidity doesn't seem to work. Maybe that's broken in Allegro. At least I found out that the patches.dat is found by Allegro when residing in the home folder and doesn't need to be in /usr/bin.
Title: Re: AGS engine (JJS) Linux port
Post by: kati on 07 Jun 2012, 09:25
i followed all the instructions but it crashes trying to load audio:

Quote
ags game.exe
Adventure Creator v3.21 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 3.21.1115
ci_find_file: cannot change to directory: Compiled
Audio vox found and initialized.
Checking sound inits.
jack_client_new: deprecated
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
Aborted (core dumped)

i'm guessing it has something to do with the GUS patch not working?  i did download and copy it to ~/patches.dat

i'm running ubuntu 12.04 (32-bit)

FWIW SQ VSB (http://www.sqvsb.com/) linux port works great on here...it would be nice to be able to play other AGS titles without running XP on VirtualBox...
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 07 Jun 2012, 10:28
It's not certain that the crash is audio related because the engine doesn't print to console after initializing audio.

What game are you trying to run?
Title: Re: AGS engine (JJS) Linux port
Post by: kati on 07 Jun 2012, 10:58
Was trying to run the windows version of Pledge Quest (http://www.spacequest.net/index.php/page/index.html/_/news/fans-release-pledge-quest-to-support-r41) since it seems like a simple game to test with...
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 07 Jun 2012, 11:06
That crashes here too, but the Linux version works. (With the installed engine of course.)
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 07 Jun 2012, 11:28
I guess it is because the Windows version includes a configuration file that selects the D3D graphic driver. If you delete it or change it to use the non-accelerated Direct Draw driver it works.

Stuff like that is the reason why I don't evaluate the standard config file on the mobile platform ports and instead rolled platform specific configurations. In the long run it would of course be better to unify it again.
Title: Re: AGS engine (JJS) Linux port
Post by: kati on 07 Jun 2012, 11:36
i'm not too worried about the pledgequest given that they took the initiative to release a Linux version, but i'd like to be able to play AGDI's KQI and the Space Quest Incinerations on Linux ... will see if i can get either of them working tomorrow :)

it seems fairly trival to port AGS games to Linux ... i really wish more people were releasing Linux versions of their games.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 07 Jun 2012, 12:24
It would be good if on Linux also only a file in ~/.config/ags would be evaluated. And maybe allow overwriting of some of the options by the config files that come with the games at some point? Alternativly introduce a new config file for game directories with a different name to allow for game specific settings.

EDIT: Or even better, first evaluate a file in /etc and then the one in ~/.config/ags
Title: Re: AGS engine (JJS) Linux port
Post by: scottchiefbaker on 12 Jun 2012, 02:50
This is awesome... I'm super stoked about a Linux version. Is there anyway to build a version for Fedora? I'm totally willing to help build it and get it packaged for Fedora.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 12 Jun 2012, 08:38
It can be built on any 32 bit Linux by just installing the dependencies and running make. See the same instructions that describe the Debian package building.

It should also be possible to install 32 bit libraries and the program on a 64 bit Fedora, but googling for Fedora multilib I don't find much. If you figure it out, let us know!
Title: Re: AGS engine (JJS) Linux port
Post by: kati on 19 Jun 2012, 07:22
i was able to get the libdumb package on x64, when i got to this step then it errored out:

$ sudo dpkg --add-architecture i386

saying --add-architecture isn't an option

i'm curious to try this out on x64 (running xubuntu precise 12.04)
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 19 Jun 2012, 09:08
It doesn't even work on Ubuntu 12.10 yet. It will work on Ubuntu 12.10 when it ships, but never on Ubuntu 12.04. That error message means your dpkg version is too old for that.
Title: Re: AGS engine (JJS) Linux port
Post by: scottchiefbaker on 21 Jun 2012, 05:48
I got through a good chunk of the compile and hit a snag:

THIS_IS_THE_ENGINE -DLINUX_VERSION -DDISABLE_MPEG_AUDIO -DBUILTIN_PLUGINS -DRTLD_NEXT -I/usr/include/freetype2   -fno-rtti -Wno-write-strings   -c -o acchars.o acchars.cpp
acchars.cpp: In function ‘void Character_Animate(CharacterInfo*, int, int, int, int, int)’:
acchars.cpp:565:33: error: cast from ‘short int*’ to ‘int’ loses precision [-fpermissive]
compilation terminated due to -Wfatal-errors.
make: *** [acchars.o] Error 1
make: Leaving directory `/home/bakers/ags/Engine'

Any ideas?
Title: Re: AGS engine (JJS) Linux port
Post by: Crimson Wizard on 21 Jun 2012, 06:53
I don't have much experience with linux, but it looks like "treat warnings as errors" compilation option is on ("-Wfatal-errors" flag)?
Unfortunately AGS engine produces some type conversion warnings during compilation.
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 21 Jun 2012, 07:01
No, that option just causes the compilation to abort on the first error. You are confusing it with "-Werror" which causes all warnings to be treated as errors.

To me the error looks like you are trying to compile the engine for 64 bit (because only there an int is smaller than a pointer). You absolutely have to compile the engine into a 32 bit executable, it will not work otherwise.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 21 Jun 2012, 08:47
The -m32 flag in the makefile was at the wrong position. I moved it and now it builds on 64 bit for me, but of course it blows up when linking if you don't have the 32 bit versions of the required libraries available.
Title: Re: AGS engine (JJS) Linux port
Post by: Calin Leafshade on 21 Jun 2012, 08:59
I'm pretty sure the engine is not currently capable of running under 64bit even if it compiles. There are too many int to pointer conversions and stuff.

Getting a 64bit compliant version of the source should be of high priority in my opinion. (mainly for linux)
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 21 Jun 2012, 09:05
I remember that you said that the script interpreter is the source of the 64 bit problems. Specifically that it uses ints for storing pointers. I wonder if the problem could be solved by introducing a translation table that maps these 32 bit values to their real 64 bit addresses. It would cost a bit of performance but the script engine is already slow and 64 bit CPUs are usually fast so speed would not be the problem there. Maybe it could be implemented as a macro around all such accesses. The macro then resolves to nothing on 32 bit and a respective function call on 64 bit.

There is of course still a possibility that some compiled-in library has 64 bit issues.

Edit: Is the problem mostly with these "inst->registers" accesses in csrun?
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 21 Jun 2012, 09:36
I'm pretty sure the engine is not currently capable of running under 64bit even if it compiles. There are too many int to pointer conversions and stuff.

Getting a 64bit compliant version of the source should be of high priority in my opinion. (mainly for linux)

I'm not talking about compiling AGS as 64 bit application. With -m32 it is compiled as 32 bit application and that works on 64 bit Linux if 32 bit copies of all required libraries are there.

I also had a brief look into making AGS 64 bit compatible, but gave up quickly. My interpretation is the following. There's some guessing involved, but that's how it makes sense to me. The AGS scripting language has something like pointers (or needs pointer features for addressing stuff or whatever). They are based on 32 bit numbers and implemented by casting the numbers to pointers, and doing pointer-like stuff in C. The numbers are no real pointers pointing to memory, but only make sense in the AGS context.

If you would want to cast the 32 bit numbers to 64 bit pointers and back, that means you have to know exactly which pointers are AGS pointers and which are real C pointers. That's where it got too hard for me, because I don't know the code well. However, I would highly recommend not to make this even uglier by continue using pointers, but to implement the AGS pointer features properly without abusing C pointers.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 21 Jun 2012, 21:56
The instructions for building a Debian/Ubuntu package on amd64 should now work for Debian unstable and hopefully on Ubuntu Quantal Quetzal. We need someone to test it on Ubuntu. There the distribution parameter for "pbuilder create" is "quantal". I will update the instructions when it also works on Debian testing.
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 26 Jun 2012, 21:47
There is now a native 64 bit version of the engine in the "64bit" branch of the repository: https://github.com/adventuregamestudio/ags/tree/64bit

At the moment it runs only games made with AGS 3.x.

There seems to be an issue with liballegro-4.2 on 64 bit that causes WAV files to fail to load. Games that use this file format and don't check for successful file opening will crash with a script error ("null pointer dereferenced"). The problem appears to be fixed in Allegro 4.4.
Title: Re: AGS engine (JJS) Linux port
Post by: Crimson Wizard on 26 Jun 2012, 22:14
Are you going to merge 32 and 64 bit code one day?
I checked your commit, it looks like most changes are related to default int size (you changed a lot of ints to long). Since that does not make a difference for 32-bit platform, same could be used in the main branch, am I correct?
There are other cases though, I wonder if they could be merged in one source with limited use of macros.
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 26 Jun 2012, 22:41
The 64 bit branch will also compile for 32 bit. I only created a branch instead of pushing to main because I am not yet sure if the engine is 100% stable and always behaves the same as the 32 bit version under all circumstances. Also, as I wrote, it lacks backward compatibility.

I will eventually merge the branch to main.

Tobihan also suggested changing the variables from generic int and long to the "right" ones, which are int32_t and intptr_t. This is a good idea and should ensure compatibility with different platforms (like Windows 64 which defines long long int as 64 bit, and long int as 32 bit).
Title: Re: AGS engine (JJS) Linux port
Post by: Tea23 on 29 Jun 2012, 22:02
Hullo, been watching this thread for a while waiting for someone to say that it now builds on 64bit. Sure, you Debianites might have got it to build in your funky chroots but on Arch we couldn't get anywhere (well, I guess we could chroot but we're lazy).

Had a little play of Blackwell Legacy with the Linux build, all works fine until I need to get to the park and then I had a black screen. Had to go to tty to kill the process.

And to help my fellow Archers, I've created an AUR PKGBUILD (https://aur.archlinux.org/packages.php?ID=60425) which I think has all the right dependencies listed... Anyway, seems to work on this end.

Also, thanks so much for this port. Been looking at the forums since the source code was released waiting for a proper port (I'm no programmer to any degree, unfortunately) and it's great to finally see it!
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 29 Jun 2012, 22:56
You don't need alfont, but libfreetype. The dependencies are listed in debian/README.md.

You can run games in windowed mode by writing into acsetup.cfg

[misc]
windowed=1

Then you can see the error and report the bug.

I'm getting random segfaults all the time with the 64bit branch, while JJS can't reproduce that. We're still a bit clueless why global variables are at random adresses on my system, although I think I have turned off all randomization.
Title: Re: AGS engine (JJS) Linux port
Post by: Tea23 on 29 Jun 2012, 23:47
Well I could get console output anyway, without running in a window. The thing is that there was no error, the room was still loading. I don't think it actually crashed, it just kept trying to load the room and couldn't make it.
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 29 Jun 2012, 23:48
I caved in and got the Blackwell games. The error was caused by the aastr library which used long* to access an int* value. Valgrind to the rescue again (nod). I pushed a fix to the repository.

About the error, that BigMc mentioned: It would be great if some more people would test the 64 bit branch on their system. Right now we don't have a lead on what is causing the engine to be loaded to different addresses on his system. This is something that should not happen for several reasons (1) The engine binary is not PIE enabled. (2) PIE is deactived in the system settings. Still, it is loaded to a different address every time. This is a problem because the script interpreter relies on global variables being accessible with 32 bit long pointers. As BigMc said, I cannot reproduce the error. It only occurs for me when I explicitly compile the engine with PIE support.
Title: Re: AGS engine (JJS) Linux port
Post by: Tea23 on 29 Jun 2012, 23:55
I caved in and got the Blackwell games. The error was caused by the aastr library which used long* to access an int* value. Valgrind to the rescue again (nod). I pushed a fix to the repository.

About the error, that BigMc mentioned: It would be great if some more people would test the 64 bit branch on their system. Right now we don't have a lead on what is causing the engine to be loaded to different addresses on his system. This is something that should not happen for several reasons (1) The engine binary is not PIE enabled. (2) PIE is deactived in the system settings. Still, it is loaded to a different address every time. This is a problem because the script interpreter relies on global variables being accessible with 32 bit long pointers. As BigMc said, I cannot reproduce the error. It only occurs for me when I explicitly compile the engine with PIE support.

Ah yes, I just noticed that commit, recompiled and a gave it a try; the level loaded. Thanks.

I do need an excuse to play through Blackwell again so I'll get on that with this build. I needed an excuse to replay the Blackwell series so I'll keep an eye out for bugs. Just registered to Mantis so hopefully (or not) my reports should be flooding in.
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 30 Jun 2012, 12:50
I made another update to the source, again in aastr, because I noticed that scaled anti-aliased sprites were drawn incorrectly.
Title: Re: AGS engine (JJS) Linux port
Post by: Tea23 on 01 Jul 2012, 20:29
Spent all day yesterday battling with ALSA so I didn't get to play anything until today. I'm spotting very few issues in Blackwell Legacy although when Rosa moves away from the camera (like going into the doctor's office) her sprite gets pretty blurry. I don't know if you've ever played Broken Sword 2 but it looks a bit like George does when you set the graphics to low.

I haven't finished playing yet but I really can't see any issues. I don't think I'm getting the errors related to memory addresses, either.
Title: Re: AGS engine (JJS) Linux port
Post by: xenogia on 05 Jul 2012, 02:22
I get crackly sound in Ubuntu 12.04.  Is this due to Pulseaudio by any chance?
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 05 Jul 2012, 09:28
I have no problems with PulseAudio. Is this a slow computer? Are you using the 64bit branch?
Title: Re: AGS engine (JJS) Linux port
Post by: xenogia on 05 Jul 2012, 12:32
It is actually my work machine which is an AMD AM2 6000+.  It does use an integrated nvidia solution (also the 32bit build).  I'll try it on my home machine.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 05 Jul 2012, 12:43
You can try suspending PulseAudio, but I have no idea what causes this.

$ pasuspender -- ags game.exe

EDIT: Which games are affected?
Title: Re: AGS engine (JJS) Linux port
Post by: xenogia on 05 Jul 2012, 12:45
I also segmentation faults with Resonance and the latest Blackwell game, but this stopped once I removed the acsetup.cfg.  But how can I get it so it is full screen?
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 05 Jul 2012, 12:46
Use the acsetup.cfg, but remove the lines with D3D. We should do something about these lines crashing the engine.
Title: Re: AGS engine (JJS) Linux port
Post by: xenogia on 05 Jul 2012, 12:58
Thanks for that.  The games worked under that.  I did notice a few oddities though.  When I quit the game it didn't recover back to my default resolution of 1920x1080.  It just stayed 1280x800.  I'm currently using the latest Nvidia Blob (302.17).  I get this error msg in terminal.

Code: Adventure Game Studio
  1. X Error of failed request:  BadValue (integer parameter out of range for operation)
  2.   Major opcode of failed request:  129 (XFree86-VidModeExtension)
  3.   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  4.   Value in failed request:  0x360000d
  5.   Serial number of failed request:  6412619
  6.   Current serial number in output stream:  6412625
  7.  
  8. Error: the program has exited without requesting it.
  9. Program pointer: +9908  (write this number down), ACI version 3.21.1115
  10. If you see a list of numbers above, please write them down and contact
  11. Chris Jones. Otherwise, note down any other information displayed.
  12.  
Title: Re: AGS engine (JJS) Linux port
Post by: xenogia on 05 Jul 2012, 13:12
Also I noticed some wierd rendering issues in Blackwell Deception.  All I had the x2 filter in Windowed mode and this is what it looked like.

(http://i49.tinypic.com/2v337le.jpg)
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 05 Jul 2012, 13:15
I pushed a change so that the D3D graphic driver setting is ignored on Linux and Mac (the mobile platforms don't evaluate the configuration file).

E: ^^^ I don't see what is wrong with that screenshot. ^^^
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 05 Jul 2012, 13:16
Thanks JJS!

@xenogia: How is it supposed to look like instead?
Title: Re: AGS engine (JJS) Linux port
Post by: xenogia on 05 Jul 2012, 13:30
My apologies I forgot to click smooth sprites, stupid me.  The crackling audio occasionally happens on load up, but it easily fixed by reloading Pulseaudio by doing the standard killall pulseaudio and it reloads itself and the issue disappears.

Title: Re: AGS engine (JJS) Linux port
Post by: xenogia on 05 Jul 2012, 13:55
BTW you have done an amazing job on this port.
Title: Re: AGS engine (JJS) Linux port
Post by: JJS on 05 Jul 2012, 14:07
I haven't done too much for the Linux port, most of it was already finished by the maintainer of the closed source version. The Debian packaging was also done by BigMc.
Title: Re: AGS engine (JJS) Linux port
Post by: Tea23 on 05 Aug 2012, 23:26
I've noticed a lack of updates to the 64bit branch while main is still going along nicely. Does main compile for 64bit yet (thus rendering the branch more or less obsolete) or is it just lagging behind in taking changes from main?
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 05 Aug 2012, 23:52
It's just lagging behind, but no changes that are important for Linux were added to main since the last merge.
Title: Re: AGS engine (JJS) Linux port
Post by: Tea23 on 01 Sep 2012, 14:57
Just spotted this commit (https://github.com/adventuregamestudio/ags/commit/c514f42244ed7f95488d2644cd453823ec5c2677). Is that now the 64bit branch obsoleted? Should I expect native 64bit if I just compile main now?

If that's the case I need to remove the $CARCH check from the Arch package.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 01 Sep 2012, 15:07
Yes.
Title: Re: AGS engine (JJS) Linux port
Post by: scottchiefbaker on 08 Sep 2012, 07:05
I just wanted to you know I was able to compile a 64 bit version of AGS on Fedora 16 without a hitch! I had to install a couple of libraries, but otherwise everything worked flawlessly. I now have an AGS binary that will run Resonance, Gemini Rue, Time Gentlemen, and three other random games from the AGS site.

In fact, the binary has run everything I've thrown at it. Super stoked!!! Good work everyone who had a part in this!
Title: Error loading save games?
Post by: scottchiefbaker on 14 Sep 2012, 01:52
Maybe I spoke too soon. I loaded up the AGD remake of King's Quest I, walked to the second screen and saved the game. Then I tried to load the save and ags crashed and I got this error:

Code: Adventure Game Studio
  1. An internal error has occurred. Please note down the following information.
  2. If the problem persists, post the details on the AGS Technical Forum.
  3. (ACI version 3.21.1115)
  4.  
  5. Error: read_gui: file is corrupt
  6. AGS: ***** ENGINE HAS SHUTDOWN
Title: Re: AGS engine (JJS) Linux port
Post by: scottchiefbaker on 14 Sep 2012, 01:54
I have the same problem with King's Quest II, but I get a different error.

Code: Adventure Game Studio
  1. An error has occurred. Please contact the game author for support, as this is likely to be a scripting error and not a bug in AGS.
  2. (ACI version 3.21.1115)
  3.  
  4.  
  5. Error: Restore_Game: Game has changed (dlg), unable to restore
  6. AGS: ***** ENGINE HAS SHUTDOWN
Title: Re: AGS engine (JJS) Linux port
Post by: Crimson Wizard on 14 Sep 2012, 02:17
This looks very much like mistake in game saving/restoring code.
What branch you were building from?
I ask because I had this problem just recently in the 'refactory' branch (that was already fixed though, I think).
Title: Re: AGS engine (JJS) Linux port
Post by: scottchiefbaker on 14 Sep 2012, 17:01
I'm compiling "main" according to git status. Should I try a different branch? I loaded KQ1 in Wine did a save/load just fine. It's the exact same game data so I think the problem lies in the engine.
Title: Re: AGS engine (JJS) Linux port
Post by: Crimson Wizard on 14 Sep 2012, 17:12
Should I try a different branch?
No, no, I was asking, just in case. Refactory is still pretty unstable on 64-bit platforms. It's just that the bug sounds familiar.

I think the problem lies in the engine.
Well, that's definitely in the engine, that's what I meant ;).
Title: Re: AGS engine (JJS) Linux port
Post by: scottchiefbaker on 14 Sep 2012, 17:21
King's Quest 3, and Resonance save/load just fine. Seems like something is amiss with KQ1 and KQ2.
Title: Re: AGS engine (JJS) Linux port
Post by: Crimson Wizard on 14 Sep 2012, 17:45
I wish I could build 64-bit windows version, but AFAIK allegro does not support compiling in 64-bit mode under Win (well, that's MSVS problem, not allegro's; probably there's way around this like using different compiler, but I haven't looked much into that yet).
And I am not an experienced Linux user, unfortunately.
I think I may check those games with engine built as 32-bit to see if this is a general fault or only specific to 64-bit engine version.

If I won't have any result, it's JJS's or BigMC's turn then.

EDIT: Nah, KQ1 seem to work fine with win32 build (main branch).
Title: Re: AGS engine (JJS) Linux port
Post by: slapin on 14 Sep 2012, 18:55
hi, all!

This is what happens with latest main branch hash 15039fef3d25004c6ea65501b6da736c59681ee 0,
with Quest For Glory II remake during load of game, after saving,
I run it under gdb:

slapin@slapin:~/qfg2$ gdb --args /usr/bin/ags Qfg2vga.exe
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/ags...Reading symbols from /usr/lib/debug/usr/bin/ags...done.
done.
(gdb) run
Starting program: /usr/bin/ags Qfg2vga.exe
[Thread debugging using libthread_db enabled]
Adventure Creator v3.21 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 3.21.1115
AGS: ***** ENGINE STARTUP
AGS: Reading config file
AGS: Initializing allegro
[New Thread 0xb764eb70 (LWP 8498)]
AGS: Setting up window
AGS: Initializing game data
AGS: Initializing TTF renderer
AGS: Initializing mouse
AGS: Checking memory
ci_find_file: cannot change to directory: Compiled
AGS: Initializing audio vox
Audio vox found and initialized.
AGS: Initializing keyboard
AGS: Install timer
Checking sound inits.
[New Thread 0xb6e4db70 (LWP 8499)]
AGS: Initialize sound drivers
[New Thread 0xb664cb70 (LWP 8500)]
[Thread 0xb664cb70 (LWP 8500) exited]
AGS: Install exit handler
AGS: Initialize path finder library
AGS: Initialize gfx
AGS: Load game data
AGS: Quest for Glory II
AGS: Checking for disk space
AGS: Initializing MOD/XM player
AGS: Initializing screen settings
AGS: Init gfx filters
AGS: Init gfx driver
AGS: Switching to graphics mode
AGS: Widescreen side borders: disabled (windowed mode)
AGS: Attempt to switch gfx mode to 320 x 200 (32-bit)
AGS: Succeeded. Using gfx mode 320 x 200 (32-bit)
AGS: Preparing graphics mode screen
AGS: Initializing colour conversion
AGS: Check for preload image
AGS: Initialize sprites
AGS: Set up screen
AGS: Initialize game settings
AGS: Prepare to start game
[New Thread 0xb664cb70 (LWP 8501)]
AGS: Checking replay status
AGS: Engine initialization complete
AGS: Starting game
AGS: Loading room 0
AGS: Room change requested to room 87
AGS: Unloading room 0
AGS: Loading room 87
AGS: Room change requested to room 1
AGS: Unloading room 87
AGS: Loading room 1
AGS: Unloading room 1
An error has occurred. Please contact the game author for support, as this is likely to be a scripting error and not a bug in AGS.
(ACI version 3.21.1115)


Error: Restore_Game: Game has changed (dlg), unable to restore
[Thread 0xb664cb70 (LWP 8501) exited]
[Thread 0xb6e4db70 (LWP 8499) exited]
[Thread 0xb764eb70 (LWP 8498) exited]

Program received signal SIGSEGV, Segmentation fault.
reset () at ../Common/acroom.h:680
680           response->reset();
(gdb) bt
#0  reset () at ../Common/acroom.h:680
#1  ~NewInteraction () at ../Common/acroom.h:688
#2  ~RoomStatus () at ../Common/acruntim.h:94
#3  resetRoomStatuses () at ac.cpp:440
#4  0x080f656a in quit (quitmsg=0x814961c "!Restore_Game: Game has changed (dlg), unable to restore") at ac.cpp:9675
#5  0x081212ea in restore_game_data (ooo=0x8441c08, nametouse=0xbfffcedc "./agssave.001.Qfg2Sav") at ac.cpp:24157
#6  0x08115fb6 in do_game_load (nametouse=0xbfffcedc "./agssave.001.Qfg2Sav", slotNumber=1, descrp=0x0, wantShot=0x0) at ac.cpp:24697
#7  0x081160bd in load_game (slotn=1, descrp=0x0, wantShot=0x0) at ac.cpp:24725
#8  0x081166f0 in load_game_and_print_error (toload=1) at ac.cpp:3229
#9  0x081169e5 in post_script_cleanup () at ac.cpp:3373
#10 0x08116c47 in run_script_function_if_exist (sci=0x8677090, tsname=0x8225704 "interface_click", numParam=2, iparam=32, iparam2=0, iparam3=0) at ac.cpp:3537
#11 0x08116ed3 in run_text_script_2iparam (sci=0x8677090, tsname=<value optimized out>, iparam=32, param2=0) at ac.cpp:3634
#12 0x081172e3 in process_interface_click (ifce=32, btn=0, mbut=1) at ac.cpp:5661
#13 0x08119409 in process_event (evp=0xbfffd910) at ac.cpp:5205
#14 0x08119d3d in processallevents (numev=4, evlist=0x8232260) at ac.cpp:5238
#15 0x08119d78 in update_events () at ac.cpp:5248
#16 0x0811b862 in mainloop (checkControls=true, extraBitmap=0x0, extraX=0, extraY=0) at ac.cpp:26641
#17 0x0811bd49 in main_game_loop () at ac.cpp:26775
#18 0x08123fe8 in initialize_start_and_play_game (override_start_room=0, loadSaveGameOnStartup=0x0) at ac.cpp:27938
#19 0x08125b92 in initialize_engine (argc=2, argv=0xbffff484) at ac.cpp:29308
#20 0x080815b3 in main (argc=2, argv=0xbffff484) at ac.cpp:28363

When run game under wine, no problem occurs.
Hope that helps,

S.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 21 Sep 2012, 12:14
That was a bug in the saving code that I fixed now in the main branch (commit 205c56d693d903516b7b21beb454251e9489aab f). I don't know why it never caused problems on 32 bit.
Title: Re: AGS engine (JJS) Linux port
Post by: Crimson Wizard on 21 Sep 2012, 12:52
That was a bug in the saving code that I fixed now in the main branch (commit 205c56d693d903516b7b21beb454251e9489aab f). I don't know why it never caused problems on 32 bit.
I've already fixed that in refactory branch some time ago. I wanted to ask JJS about this (since it was in his new code), but forgot :/.
Title: Re: AGS engine (JJS) Linux port
Post by: BigMc on 21 Sep 2012, 13:29
When do you think is a good time to recommend people to use refactory? If there are no known bugs, why not now?
Title: Re: AGS engine (JJS) Linux port
Post by: Crimson Wizard on 21 Sep 2012, 13:34
When do you think is a good time to recommend people to use refactory? If there are no known bugs, why not now?
I know only one bug related to freeing managed script objects that takes place when application window is closed by OS means (e.g. alt+f4 in windows), but it happens only when game is closing so maybe it isn't that critical.
Don't know if there are any platform-specific bugs. JJS said there were some problems on 64-bit and bigend OSes, but he made a commit with fixes recently, so maybe they are solved?
Personally I am totally supporting change to refactored, 'cause it is becoming more tedious to copy changes from main. Plus it will be tested more :)
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 22 Sep 2012, 05:49
Just rebuilt and played through 75% of the Kings Quest I remake and everything worked flawlessly. Good work!
Title: Re: AGS engine Linux port
Post by: JJS on 22 Sep 2012, 07:28
You can start using the refactory branch. But savegames on 64 bit are not compatible between main and refactory. Bigendian code is still broken in the script interpreter.

Still the whole savegame issue is a bit of a mess. What I mean is that savegames have a different size on all platforms, which is something that I do not at all understand.

E: What I am saying is that savegame related stuff is hard to debug because even if the game loads what guarantee do I have that the WHOLE game state was restored? Everything might blow up in specific situations where a value matters that usually doesn't :/
Title: Re: AGS engine Linux port
Post by: BigMc on 22 Sep 2012, 10:30
You can start using the refactory branch. But savegames on 64 bit are not compatible between main and refactory. Bigendian code is still broken in the script interpreter.

Would you make refactory the default branch that is active after git clone?

Quote
Still the whole savegame issue is a bit of a mess. What I mean is that savegames have a different size on all platforms, which is something that I do not at all understand.

I know at least one reason why it's different between 32 and 64 bit. Look at save_game_data in the main branch and search for sizeof. There are structs stored that contain pointers:
RoomStatus, GameState, GameSetupStructBase, maybe more
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 22 Sep 2012, 16:58
I know at least one reason why it's different between 32 and 64 bit. Look at save_game_data in the main branch and search for sizeof. There are structs stored that contain pointers:
RoomStatus, GameState, GameSetupStructBase, maybe more
Was he speaking of main or refactory branch?
I will recheck save/restore functions just in case. Who knows, I could miss some of "sizeof" instances there, or maybe added more mistakes...
Also I think we may finally remove alignment padding from there, since new engine is not supposed to be compatible with older version savegames.
Title: Re: AGS engine Linux port
Post by: BigMc on 22 Sep 2012, 18:24
Anyway, I think you meant they have a different size on all platforms, not only 32 bit vs 64 bit right JJS? Are C++ objects stored in the savegames in refactory? I would not be surprized if their size depends on the implementation.
Title: Re: AGS engine Linux port
Post by: JJS on 22 Sep 2012, 19:56
They are vastly different (several kilo byte) on all platforms, yes. You would assume that all 32 bit platforms at least Windows have the same size but they don't. For all I can tell saving/loading does work on all platforms and also cross-platform regardless of that. It is a mystery to me.

e: I am speaking of the refactory branch.
Title: Re: AGS engine Linux port
Post by: BigMc on 22 Sep 2012, 20:17
Spots where differences occur should be easy to find by stepping through the saving code while keeping an eye on the file pointer.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 22 Sep 2012, 20:40
Another way to debug this would be to write signature strings after every save routine step and then compare two savegames from different OSes in the hex editor.

E: You know what.... I just found a bug in refactory branch... the global vars are READ during save routine :D. That's probably not related to the discussed problem though, but i's nice I made that recheck.
Title: Re: AGS engine Linux port
Post by: kati on 22 Oct 2012, 17:37
i'm upgrading to Xubuntu 12.10 x64 today so i'm hoping that ags will now run on it, i'm going to test it out once the install is finished.
Title: Re: AGS engine Linux port
Post by: BigMc on 22 Oct 2012, 18:07
It should now also work on Ubuntu 12.04 amd64, because it works natively on 64bit know. The multiarch way is now only required for systems where the native 64bit build crashes all the time (seen on Debian).
Title: Re: AGS engine Linux port
Post by: kati on 22 Oct 2012, 20:24
The amd64 version seemed to compile and install just fine, i haven't noticed any crashing issues.  Thanks BigMc for all your hard work, it is much appreciated! 

i'm not sure why i can't restore games saved under windows, although making new saves under Linux seems to work fine.  Also would be nice to have a Linux equivalent of winsetup.exe to easily spit out acsetup.cfg files.

Anyway i just discovered Adventure - All In The Game and it looks intriguing so i'm off to play that on Linux :)
Title: Re: AGS engine Linux port
Post by: Tartalo on 27 Dec 2012, 14:43
I Just compiled and tried AGS engine Linux port in Ubuntu 12.10 amd64.

First it didn't compile, but it was because the g++ package was missing in my system (Perhaps it should be added to the list of packages to install?), once g++ was installed the deb package was created flawlessly.

I tried it with a couple of games and there was no sound, probably because I had removed Pulseaudio. I remembered having read somewhere that AGS used Allegro so I installed liballegro4.4-plugin-alsa and voilá! The games had sound.

So I downloaded a couple of games more, new and old, and everything seems to work fine.

Thank you very much :)
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Dec 2012, 15:15
It is recommended to install the meta-package build-essential (depends on compilers etc) to compile things on Ubuntu. Allegro should use OSS if liballegro4.4-plugin-alsa is not installed. Maybe your soundcard was blocked by another ALSA application. That's what you get for removing Pulseaudio. ;)
Title: Re: AGS engine Linux port
Post by: Tartalo on 28 Dec 2012, 22:10
Allegro should use OSS if liballegro4.4-plugin-alsa is not installed.
Apparently OSS support was removed from Ubuntu's Kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579300
That's what you get for removing Pulseaudio.
A friend of mine removed the brakes from his bike as a kid to make it lighter. That's the spirit!
Title: Re: AGS engine Linux port
Post by: BigMc on 29 Dec 2012, 01:20
Allegro should use OSS if liballegro4.4-plugin-alsa is not installed.
Apparently OSS support was removed from Ubuntu's Kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579300

Ok, that means that PulseAudio is now required for OSS support.

Quote
That's what you get for removing Pulseaudio.
A friend of mine removed the brakes from his bike as a kid to make it lighter. That's the spirit!

Yeah, that's quite to the point.
Title: Re: AGS engine Linux port
Post by: Milanium on 12 Jan 2013, 14:10
I am trying to create an RPM for openSUSE. It fails to build

Quote
gcc -I../Engine -I../Common -I../Common/libinclude -O2 -g -fsigned-char -Wfatal-errors -DALLEGRO_STATICLINK -DTHIS_IS_THE_ENGINE -DLINUX_VERSION -DDISABLE_MPEG_AUDIO -DBUILTIN_PLUGINS -DRTLD_NEXT -I/usr/include/freetype2     -c -o libsrc/libcda-0.5/linux.o libsrc/libcda-0.5/linux.c

libsrc/libcda-0.5/linux.c:11:25: fatal error: linux/cdrom.h: No such file or directory

compilation terminated.

I checked out the main branch from git and used "make --directory=Engine --file=Makefile.linux". Defined the following packages as dependencies:

Guess there is still something missing or wrong with the libraries you bundled.
Title: Re: AGS engine Linux port
Post by: Milanium on 12 Jan 2013, 14:48
The package linux-glibc-devel was missing. Building and uploading now. Check http://software.opensuse.org/package/ags once the mirrors are synced.
Title: Re: AGS engine Linux port
Post by: Milanium on 12 Jan 2013, 15:11
Tested works, except fullscreen mode on openSUSE 12.2 KDE 4.9.5, Mesa 9.0.1:

Quote
Adventure Creator v3.21 Interpreter                                                                                                                                                           
Copyright (c) 1999-2001 Chris Jones                                                                                                                                                           
ACI version 3.21.1115                                                                                                                                                                         
AGS: ***** ENGINE STARTUP                                                                                                                                                                     
AGS: Reading config file                                                                                                                                                                       
AGS: Initializing allegro                                                                                                                                                                     
AGS: Setting up window                                                                                                                                                                         
AGS: Initializing game data
AGS: Initializing TTF renderer
AGS: Initializing mouse
AGS: Checking memory
ci_find_file: cannot change to directory: Compiled
ci_find_file: cannot change to directory: Compiled
AGS: Initializing keyboard
AGS: Install timer
Checking sound inits.
AGS: Initialize sound drivers
AGS: Install exit handler
AGS: Initialize path finder library
AGS: Initialize gfx
AGS: Load game data
AGS: Over the Edge
AGS: Checking for disk space
AGS: Initializing MOD/XM player
AGS: Initializing screen settings
AGS: Init gfx filters
AGS: Init gfx driver
AGS: Switching to graphics mode
AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1367 x 770
AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 426 x 240 anyway
AGS: Attempt to switch gfx mode to 426 x 240 (32-bit)
AGS: Succeeded. Using gfx mode 426 x 240 (32-bit)
AGS: Preparing graphics mode screen
AGS: Screen resolution: 426 x 240; game resolution 320 x 200
AGS: Initializing colour conversion
AGS: Check for preload image
AGS: Initialize sprites
AGS: Set up screen
AGS: Initialize game settings
AGS: Prepare to start game
AGS: Checking replay status
AGS: Engine initialization complete
AGS: Starting game
AGS: Loading room 26
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  151 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0x5c0000d
  Serial number of failed request:  4921
  Current serial number in output stream:  4927

Error: the program has exited without requesting it.
Program pointer: +72  (write this number down), ACI version 3.21.1115
If you see a list of numbers above, please write them down and contact
Chris Jones. Otherwise, note down any other information displayed.
Title: Re: AGS engine Linux port
Post by: BigMc on 12 Jan 2013, 16:55
Use the master branch, not main. Don't know if that fixes it, but just saying.
Title: Re: AGS engine Linux port
Post by: JJS on 12 Jan 2013, 17:52
I guess it fails because the fullscreen video mode is set to 426 x 240. I doubt this resolution is supported by the graphics card. That Allegro does not error out earlier is strange though. If this is the cause, setting a 2x magnifying filter in the configuration file could solve the issue. This is a common problem on Windows too.

E: Actually, this line indicates that the video mode will fail later:
Code: Text
  1. AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 426 x 240 anyway
Title: Re: AGS engine Linux port
Post by: Milanium on 12 Jan 2013, 18:35
Indeed the screen resolution simply was too low when trying http://www.adventuregamestudio.co.uk/site/games/game/1344/ Also tried http://www.adventuregamestudio.co.uk/site/games/game/1576/ which worked nicely although I did not play it further because the texts where Spanish. I also was able to complete http://www.holarse-linuxgaming.de/wiki/gemini_rue demo in full-screen and windowed mode. Nice work! However I had to use pasuspender ags to avoid crackling sound. Now I can't hear sound in any other application, too. http://www.holarse-linuxgaming.de/wiki/resonance demo only shows a white screen when I click "New Game". :/
Title: Re: AGS engine Linux port
Post by: Sslaxx on 13 Jan 2013, 20:22
Got the libcda (CD Audio) devel files installed?
Title: Re: AGS engine Linux port
Post by: BigMc on 13 Jan 2013, 20:30
libcda is included with the AGS source. And even if they were removed that would not cause sound problems, because this is never used.
Title: Re: AGS engine Linux port
Post by: s_d on 14 Jan 2013, 05:47
Hey, JJS & BigMc, is the refactory branch merged upstream?  Is it, or main, a better branch for Linux builds?  How about Android builds?  Thanks!!
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2013, 07:12
Hey, JJS & BigMc, is the refactory branch merged upstream?
Yes it is, as well as "main". Use "master" now. People say it is more stable on 64-bit linux too.
I think refactory will be deleted in a while, because it served its purpose already.
Title: Re: AGS engine Linux port
Post by: s_d on 14 Jan 2013, 07:52
Hey, Crimson Wizard, thanks!!

I've built an interpreter off of the main tree, but before the Revision Of Doom on November 29th of last year.  I've successfully played through the Resonance and Quest for Infamy demos (along with a couple of other games), and I'm going to work my way through all the Wadjet Eye demos.

Hopefully, if I provide nicely packaged installers for all the demos in their catalogue, I can convince Dave Gilbert to just sell native Linux versions of the games on Desura, Steam, and their website ;)
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2013, 08:21
I've built an interpreter off of the main tree, but before the Revision Of Doom on November 29th of last year.
Err... Revision of Doom?
Title: Re: AGS engine Linux port
Post by: s_d on 14 Jan 2013, 08:39
Well, I read on a different thread that a significant scripting engine change went in that day, and that the tree should be considered a tad unstable after that.  So I checked out the revision before that work, and built from there.  Perhaps that was only in reference to a particular port?

I've been trying to play through a couple of games with a version built off of the head of master (cloned a little over a week ago), and encountered crashes.  They looked (to me) to be related to the cross-fade fix (like a regression), but I don't know the engine code well enough to be certain.  One factor which caused me no end of trouble was discovering that saved-game files seem to not always be portable (I assume there are data word size/alignment issues which can need fixing).  Anyway, once I stopped trying to use the Wine-generated saved-game files, it seemed OK (modulo the audio-related crash).

I could (and was planning to) discuss the backtraces with you guys, but wanted to be sure that it wasn't my build setup, OS installation, etc.  So, I wanted to build a known-good version and play through a few test cases to be sure that I had a sane build environment set up (hence scouring the forums here for information on what should be considered stable, etc).

I probably need to play through another full game or two to be convinced, but I think I've got a good solid version (at least, I'm testing on 64-bit OS/kernel combination;  I build 32-bit builds, but can't test them yet).

If I've totally misjudged the state of the tree, then I apologize!
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2013, 09:05
Well, I read on a different thread that a significant scripting engine change went in that day, and that the tree should be considered a tad unstable after that.  So I checked out the revision before that work, and built from there.  Perhaps that was only in reference to a particular port?
Ah, right. It was when new script interpreter was merged into what is now known as "master".
The stability of that branch was improved since. Plus, tests shows that it is much more stable on 64-bit systems now (this was one of the reasons to do those changes). My intention was mostly to "protect" Janet Gilbert's iOS development, because she is doing commercial ports, AFAIK. It would not look good if our changes screw her work before the official release of their games.
If your builds are not related to anything similar, I'd rather suggest you use the latest "master" branch.
More people testing it the better :).

One factor which caused me no end of trouble was discovering that saved-game files seem to not always be portable (I assume there are data word size/alignment issues which can need fixing). Anyway, once I stopped trying to use the Wine-generated saved-game files, it seemed OK
The only possible reason for such incompatibility that I am aware of, is plugins which save their own data differently on different platforms. If the games you test do not use plugins, then this should be considered as a bug.
As for plugins, we are hoping to find solution for that in the future.
Title: Re: AGS engine Linux port
Post by: AGD2 on 14 Jan 2013, 11:40
Forgive my ignorance here, but is it actually possible to currently compile and release a fully functioning Linux version of an AGS game with this port?

I know that Bero ported our King's Quest and Quest for Glory remakes a few years back and had them working flawlessly, but he doesn't seem to be active here anymore and I'm not sure if he used an 'official' AGS port or handled it entirely himself.

Any info on the subject would be appreciated. Thanks!
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2013, 12:06
Forgive my ignorance here, but is it actually possible to currently compile and release a fully functioning Linux version of an AGS game with this port?
You can take ANY AGS game*, take a port and run that game with that port on corresponding platform (linux, psp, android, ios).
For example, I personally was testing Windows version of your Quest For Glory 2 game under Linux, using JJS's linux port.

AGS game = Engine executable + Game data.
AGS game made by Editor = Windows executable + Game data.

Engine (Windows version and ports) can read game data either attached to its own executable, or from separate file. Simply speaking, one may take modern engine and tell it to run already existing game. The older executable won't run at all, the engine will just read the game data from compiled exe.
This is how games are run on all ports.

There was a discussion about adding an option to editor to create game data without windows executable attached. I think it's possible (and not difficult) to do.
Also, there is an utility, made by one guy, which allows to "cut" Windows binaries from game exe, producing a clean game data package (this also saves 0.5-1.5 megs depending on game version): https://github.com/rofl0r/agsutils. That may be used meanwhile.

* not all AGS versions are supported yet, older games may not run properly (or at all) this way.
Title: Re: AGS engine Linux port
Post by: AGD2 on 14 Jan 2013, 12:36
Ah, sorry about the confusion. Yes, I understand that's how it currently works (and thanks for the confirmation!) I was more or less asking whether this specific Linux port is stable enough *right now* to release a commercial quality game? Not being a Linux user, I'm unsure what process is involved in packaging an AGS Linux game for distribution.

The point you raised about the AGS editor being able to compile and create game data without the windows executable attached is a very valid request, I think. From a commercial developer's standpoint, it feels cleaner somehow to not have remnants of the windows version floating around in the ported game folders. Additionally, by selling games on the Google Play store, the current Android port's launcher (which displays a library of AGS games and allows you to run any one of them) is unsuitable. In the case of AGS titles on the Google Play store, Android AGS games would really need to be compiled by the editor as a standalone .apk file which installs the game in question to the device, and then launches into it directly whenever you tap the icon, bypassing the menu completely. (Or at least offer it as an option in the compile settings).
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2013, 12:47
Ah, sorry about the confusion. Yes, I understand that's how it currently works (and thanks for the confirmation!) I was more or less asking whether this specific Linux port is stable enough *right now* to release a commercial quality game?

I misunderstood what you mean.
I think that it is pretty stable, but the problem lies rather in the way new changes were introduced for the last few months (well, mainly big refactoring changes i did ;)). I believe that current development branch should be finalized at some point and tested on number of long modern games without making any more breaking changes (only fixes).
Title: Re: AGS engine Linux port
Post by: BigMc on 14 Jan 2013, 14:33
The only branch that may be stable enough right now on 32 and 64 bit is the master branch. If you want to do a release, test and report bugs and it should be fine. Or wait a bit, it will surely be more stable in a few months.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2013, 14:44
Or wait a bit, it will surely be more stable in a few months years.
:=
Title: Re: AGS engine Linux port
Post by: BigMc on 14 Jan 2013, 15:05
Definition of more stable: At least one more bug is fixed.
Title: Re: AGS engine Linux port
Post by: JanetC on 16 Jan 2013, 18:31
Hopefully, if I provide nicely packaged installers for all the demos in their catalogue, I can convince Dave Gilbert to just sell native Linux versions of the games on Desura, Steam, and their website ;)

We really want to release all our games on Linux before too long. We are concentrating on iOS for now but Linux is definitely on the list! We are mainly limited by manpower - there is only one of me, and I'm doing the ports. Linux should hopefully be easier as we won't have to change all the controls like we did on iOS.

- Janet from Wadjet Eye.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 26 Jan 2013, 00:05
I just updated and recompiled ags from the master branch and it plays and runs VERY smooth. I played through most of the Primordia demo and didn't run in to any issues. I think the tree is ready to see some real releases. I'd be happy to help get them packaged up and tested.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 26 Jan 2013, 22:48
I'd like to request an addition to the ags Linux launcher. Can we add a "--windowed" and a "--fullscreen" option at the command line that would override whatever is in the config file?
Title: Re: AGS engine Linux port
Post by: BigMc on 26 Jan 2013, 22:58
They are already there, but called "-windowed" and a "-fullscreen". I also added "--help" and "-gfxfilter" earlier today. The latter can be used to scale games up more to use more of the screen.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 26 Jan 2013, 23:01
They are already there, but called "-windowed" and a "-fullscreen".
Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 26 Jan 2013, 23:09
That's awesome! I'll work on packaging up some Linux releases. What are the default places for game data?

(Unable to find game data file in any of the known locations.)

Here is what I have founds works:

#1) ./ags something.exe
#2) ./ags /path/to/dir
#3) ./ags

#3 works if you're in the dir with a .exe in it? If we were to do Linux release we probably don't want to include a .exe file. Could we use something like ./ags agsdata.bin to launch? Where agsdata.bin is just the .exe file renamed?

Ideally I'd just rename ags to "resonance" or whatever is appropriate, and let the binary "find" where the data files are.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 26 Jan 2013, 23:10
They are already there, but called "-windowed" and a "-fullscreen".
Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.

I totally agree with this. Not sure how you're doing it, but if you're using getopt you get that functionality for free.
Title: Re: AGS engine Linux port
Post by: BigMc on 26 Jan 2013, 23:14
Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.

I could do this using getopt.h, but that's not available on Windows. Should we keep the current code with only long options for Windows and use getopt for everything else? Or can we live without commandline options on Windows? Everything should also be accessible via the config file right?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 26 Jan 2013, 23:33
What are the default places for game data?
I think we should put this in a readme. Anyway, here how it should work.
The engine accepts ANY file, provided that it is a valid game data format, of course.
The search for the game data is done in a following order of priority:

1. From command line argument. If the path was supplied as cmdline parameter, engine will use it. Currently it cannot distinguish directory from file in a correct way, and treats path as dir if it has a trailing '/'. Otherwise it will think it's a file.
If a directory is supplied this way, engine will search for the first valid game file in that directory, matching following pattern: "*.exe", "*.ags" or "ac2game.dat".
2. From config file. The game file could be set in group "misc" as "datafile" option.
3. If path is not supplied either in cmdline or config, the engine will search:
3.1. For data attached to the engine executable (like AGS always did on Windows).
3.2. For game file in current working directory (same patterns as mentioned above).
3.3. For game file in the same directory as where engine executable is located (if it is different from current dir).

KNOWN ISSUES:
1. Engine does not understand relative paths, only absolute ones. http://www.adventuregamestudio.co.uk/forums/index.php?issue=370.0
2. Engine has problems with paths, containing spaces. At least on Windows (don't remember about Linux).


I could do this using getopt.h, but that's not available on Windows. Should we keep the current code with only long options for Windows and use getopt for everything else? Or can we live without commandline options on Windows? Everything should also be accessible via the config file right?
I was thinking about writing a class for storing cmd args. That could also come handy to fullfil this user request: http://www.adventuregamestudio.co.uk/forums/index.php?issue=322.0
Title: Re: AGS engine Linux port
Post by: BigMc on 26 Jan 2013, 23:47
If we were to do Linux release we probably don't want to include a .exe file. Could we use something like ./ags agsdata.bin to launch? Where agsdata.bin is just the .exe file renamed?

You can also strip off the Windows engine.

I think we should put this in a readme.

Ok, do it. :)

Quote
I was thinking about writing a class for storing cmd args. That could also come handy to fullfil this user request: http://www.adventuregamestudio.co.uk/forums/index.php?issue=322.0

Ok go ahead. One common way to separate different sets of command line options is to use "--", e.g.

ags --engine --options -- --script --options

That doesn't mean that getopt wouldn't help with the actual parsing though.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 26 Jan 2013, 23:52
getopt is freaking phenomenal. At least look at it before you implement your own. No sense in re-inventing the wheel when getopt is already done, and very powerful. Are you sure getopt isn't available on Windows? It should come with glibc, which you can get from cygwin if nothing else.

If we can't get getopt on Windows, I don't think that's a big deal. You already have the short version strings.
Title: Re: AGS engine Linux port
Post by: BigMc on 26 Jan 2013, 23:55
I think Crimsons class will be for storing, he didn't imply reinventing the wheel for parsing.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Jan 2013, 00:12
Is there a way to make a static build of ags? I'm seeing that the executable I made links against allegro 4.4, which my target machine doesn't have.
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Jan 2013, 00:22
Why don't you link dynamically against Allegro 4.2 then?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Jan 2013, 00:24
I was trying to make a "universal" binary that would be portable on different machines/distros. At least get the low hanging fruit: Ubuntu, Fedora, Mint in one binary.
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Jan 2013, 00:59
There are multiple possibilities. Ship two binaries with a script which checks which Allegro is present and chooses the binary accordingly, include the dynamic Allegro library as a fallback in case the system does not have it, or do a static build.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 27 Jan 2013, 01:13
There are multiple possibilities. Ship two binaries with a script which checks which Allegro is present and chooses the binary accordingly, include the dynamic Allegro library as a fallback in case the system does not have it, or do a static build.
My understanding is he wants to do a static build against Allegro 4.4?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Jan 2013, 01:57
My understanding is he wants to do a static build against Allegro 4.4?

I'm not very good at C or Makefiles, what do I need to do to build a static binary? Ultimately we should add an option to Makefile to allow a static build.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 27 Jan 2013, 12:49
Errr, is this all about linking Allegro as static lib?
In Windows this is done by the use of ALLEGRO_STATICLINK flag (preprocessor definition). Probably Linux can use this too?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Jan 2013, 16:15
I see -DALLEGRO_STATICLINK in the Makefiles-defs.linux file. Looks like it's already set?

Also, if I add -static the CFLAGS I get:

Linking engine...
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbeginT.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [ags] Error 1

Unless -static is positional somehow?
Title: Re: AGS engine Linux port
Post by: JJS on 27 Jan 2013, 17:43
Try removing "-pie -fpie" from the CFLAGS for that last error.

Afaik (not) setting -DALLEGRO_STATICLINK does not make any difference for the non-Windows builds. All mobile versions get static linked with all support libraries so it is possible to static link. Exception is libc for Android and I don't really know how iOS does this as it gets handled behind the scenes by xcode.

A thing with static linking Allegro is that the library has to be patched. It boils down to renaming pack_fopen() (see here: https://github.com/adventuregamestudio/ags/blob/master/Android/patches/liballegro-4.4.2.patch#L2526 ).
When dynamically linking the library is patched at run time. This patching also has to be disabled by removing -DAGS_RUNTIME_PATCH_ALLEGRO from the CFLAGS.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Jan 2013, 18:05
If I change the makefile to remove -pie, -fpie and add -static:

CFLAGS = -O2 -g -static -fsigned-char -Wfatal-errors -DNDEBUG -DAGS_HAS_CD_AUDIO -DAGS_CASE_SENSITIVE_FILESYSTEM -DALLEGRO_STATICLINK -DTHIS_IS_THE_ENGINE -DLINUX_VERSION -DDISABLE_MPEG_AUDIO -DBUILTIN_PLUGINS -DRTLD_NEXT $(shell pkg-config --cflags freetype2)

Everything compiles, but I get an error on linking:

Linking common library...
Linking engine...
/usr/bin/ld: cannot find -lalleg
/usr/bin/ld: cannot find -laldmb
/usr/bin/ld: cannot find -ldumb
collect2: error: ld returned 1 exit status
make: *** [ags] Error 1
Title: Re: AGS engine Linux port
Post by: JJS on 27 Jan 2013, 18:14
I guess this would indicate that there are no static libraries for Allegro and DUMB present on the system?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Jan 2013, 18:37
Good question. Is that something that needs to be built ahead of time? I just assumed they would be built on the fly when we compile ags statically.
Title: Re: AGS engine Linux port
Post by: JJS on 27 Jan 2013, 18:46
Is that something that needs to be built ahead of time? I just assumed they would be built on the fly when we compile ags statically.
Yes, definitely. You have to get the sources for Allegro 4.4.x and DUMB (0.9.3 I think, the newest one), patch Allegro (as described above) and then build them. Allegro goes first, then DUMB because it depends on it (aldumb). You also have to ensure that DUMB uses the newly built static libraries instead of the system Allegro libraries. You can take a look at how the libraries are cross-compiled for Android: https://github.com/adventuregamestudio/ags/tree/master/Android/buildlibs/x86 This might help with where to get the libraries, the flags used and how to build them without installing them over the system libraries.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Jan 2013, 23:04
Wow I think that's a little beyond my ability. If Wadjet wants a simple way they can offer ags to Linux clients, are they going to have to build ags for each major distro? Is there another way to make a "universal binary?"
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Jan 2013, 23:39
When using the distributions Allegro, two binaries should be enough: one using Allegro 4.2 and one 4.4.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 01:12
Here is the binary/package that I came up with as a demo for Wadjet. It was compiled and works great on 64bit Fedora 17, using Allegro 4.4. Anyone have Ubuntu, Mint, Suse handy they could test this against?

http://www.perturb.org/tmp/shivah.tar.gz
Title: Re: AGS engine Linux port
Post by: Sslaxx on 28 Jan 2013, 01:29
[Never mind me, just being unusually dense for some reason!]
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 16:03
I do think we should try and strive for a cross-distro compatible binary. Once we have that, it will really open up the sale of adventure games on Linux/Steam/Humble Bundle. Maybe someone with more experience with the build system could build static binaries? I'd be happy to host them, if someone can build them.

FFMPEG offers static builds by community members:

http://ffmpeg.gusari.org/static/
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 18:44
When using the distributions Allegro, two binaries should be enough: one using Allegro 4.2 and one 4.4.

Wouldn't we need a 32bit and a 64bit one of each also?
Title: Re: AGS engine Linux port
Post by: BigMc on 28 Jan 2013, 20:08
Wouldn't we need a 32bit and a 64bit one of each also?

That is needed in any case.

The build from Fedora does not work on Debian, because libaldmb has a different soname here: libaldmb.so.1 instead of libaldmb-0.9.3.so

Another idea would be to use the openSUSE Build Service (https://build.opensuse.org/) to provide AGS packages for all major distributions.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 21:10
Ubuntu does the same thing with libaldmb.so.1. I think perhaps it's a bug? No other distros do that, and it seems to be only for aldmb, as allegro is properly versioned and symlinked. Since the distros symlink properly:

lrwxrwxrwx 1 root root     15 Sep 14 09:09 liballeg.so -> liballeg.so.4.4
lrwxrwxrwx 1 root root     17 Sep 14 09:09 liballeg.so.4.4 -> liballeg.so.4.4.2
-rwxr-xr-x 1 root root 915840 Jan 12  2012 liballeg.so.4.4.2

Can we just link against liballeg.so and let the distro handle passing it off the specific version of the library. Or are we back to trying to figure out a static build?

Also, does AGS use any specific stuff from allegro 4.4, or would it work with 4.2 also?
Title: Re: AGS engine Linux port
Post by: BigMc on 28 Jan 2013, 21:20
It's no bug. Upstream did not give libaldmb a soname, so the distributions had to make up their own ones. AGS also works with Allegro 4.2.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 21:23
It's no bug. Upstream did not give libaldmb a soname, so the distributions had to make up their own ones. AGS also works with Allegro 4.2.

Ah ok... well that causes problems because we can't just link against /lib64/libaldmb.so.

If you're Wadjet and you want to release a Linux version of your game you want to sell on Steam and have it be cross distro (not have a diff executable for each distro combination) what's their best bet? Statically linked?
Title: Re: AGS engine Linux port
Post by: BigMc on 28 Jan 2013, 22:16
Build AGS with

Code: Adventure Game Studio
  1. make LDFLAGS="'-Wl,-rpath,\$\$ORIGIN/libs'"

and put the required shared libraries in the folder libs relative to the binary.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 22:25
That seems possible. We'll need someone whose capable of building the the libraries, and the binary. That's a little beyond my basic compiling skills.
Title: Re: AGS engine Linux port
Post by: BigMc on 28 Jan 2013, 22:48
You can take the libraries from a distribution.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 22:51
You can take the libraries from a distribution.

Oh! I was thinking they'd have to be the statically linked libraries. You're talking about just copying liballeg.so.4.2, etc to lib/ in the same dir?
Title: Re: AGS engine Linux port
Post by: BigMc on 28 Jan 2013, 23:09
yes, copy liballeg.so.4.4.2 and the symlink liballeg.so.4.4, etc to libs/ in the same dir.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 23:13
While we're on the topics of builds. Is there a way to include the version number in the --help? Specifically like build date/time? Or some unique number? Right now ALL my builds say 3.21.1115.

make VERSION_STRING=foo

Something like that?
Title: Re: AGS engine Linux port
Post by: BigMc on 28 Jan 2013, 23:20
Right now you'd have to change ACI_VERSION_TEXT in Engine/main/main.h.

EDIT: But you should better not change that, because it's used to check if a game is compatible with the engine.
You can always change the help text in Engine/main/main.cpp.

EDIT2: We could include build date and time there.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 23:36
EDIT2: We could include build date and time there.

Better than a build date, would be a build string. Then I could do

make BUILD_STR="3.1-TestFixes" or something to give textual information as well as a version number?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 28 Jan 2013, 23:50
Holy crap I think that just might work! I made up an updated standalone (distro agnostic) package of the Shivah demo:

http://www.perturb.org/tmp/shivah-demo-2013-01-28.tar.gz

This was compiled on 32 bit Fedora 18. I've tested the following distros so far:

Fedora 18 32bit
Fedora 17 64bit
Ubuntu 12.10 32bit
Linux Mint 13 32bit

And it run just fine. Anyone else want to help test, please let me know.

I renamed the ags executable shivah, so it looks more legit (better than ./ags shivah.ags) and ran in to two minor issues:

#1) It seems to ignore the acsetup.cfg, the gfxfilter isn't applied.
#2) If you run ./shivah --help the usage still says Usage: ags [<options>] [<gamefile or directory>]

Is it possible to make the usage output $0 (executable name) instead of the hardcoded string "ags"? Not a huge deal, purely cosmetic.
Title: Re: AGS engine Linux port
Post by: BigMc on 29 Jan 2013, 00:15
It does not work on Debian Wheezy, because it requires glibc 2.15 and Debian has 2.13. If it was compiled with glibc 2.13 it might work everywhere.

EDIT: Seems like it's just Fedoras Allegro that needs glibc 2.15. After deleting that (and using Debians) it works.

EDIT2: If you want to use Debians Allegro, it's here:
http://packages.debian.org/sid/liballegro4.4

But in this case, the ALSA plugin is separate,
http://packages.debian.org/sid/liballegro4.4-plugin-alsa

so the files modules.lst and alleg-alsadigi.so from there are also needed. And the environment variable ALLEGRO_MODULES must be set to specify the path. I can help with that tomorrow.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 29 Jan 2013, 01:33
I have a Fedora 14 box that had glibc 2.13 and Allegro 4.2 on it. I can try that. Can you post "ldd shivah" from Debian Wheezy so I have an idea what we're talking about. Is that a 32 or 64bit install?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 29 Jan 2013, 04:08
I don't know much C, but I can edit a Makefile. Consider this formal patch my contribution to the code:

http://www.perturb.org/tmp/ags-strip.patch

The resulting binary was ~10MB, and ~2MB after being stripped. I've been using:

Code: Adventure Game Studio
  1. make clean && make all && make strip

to get my binaries. I will feel very accomplished if I can get some actual code committed, even insignificant code such as this :)
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 29 Jan 2013, 04:12
Another idea would be to use the openSUSE Build Service (https://build.opensuse.org/) to provide AGS packages for all major distributions.

I like the idea of getting ags into a lot of the major Linux distros. I have some experience getting a package into the Fedora repositories.

For me this would be a secondary goal, primary being getting a generic (cross distro) ags binary I can package up for Wadjet's Linux releases. Once I get something to Wadjet I'd love to work on getting this packaged. AGS compiles quite simply, so it should be easy to package up.
Title: Re: AGS engine Linux port
Post by: BigMc on 29 Jan 2013, 09:46
I have a Fedora 14 box that had glibc 2.13 and Allegro 4.2 on it. I can try that. Can you post "ldd shivah" from Debian Wheezy so I have an idea what we're talking about. Is that a 32 or 64bit install?

Don't you think it would be nicer to use Allegro 4.4? I could cook something up later if you want. 64 bit.

I like the idea of getting ags into a lot of the major Linux distros. ... AGS compiles quite simply, so it should be easy to package up.

With my Debian hat on, the main obstruction is that AGS contains a lot of external code in Engine/libsrc. I would not want to maintain these libraries separately (they mostly have no upstream anymore), but I think I would not upload AGS like that either. (And I would also wait for a stable AGS release I guess.)

EDIT: About your suggestions: Maybe create a github account and create pull requests, that way you are properly shown as the author of the changes.

EDIT2: I think I'll push a shell script that prepares everything (on Debian) to the repo in the evening. Build ags with rpath and copy libraries and their licenses to the right place etc.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 29 Jan 2013, 16:11
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).
Title: Re: AGS engine Linux port
Post by: BigMc on 29 Jan 2013, 16:29
Better report that in the bug tracker (here or on github).
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 29 Jan 2013, 16:33
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).
Can you provide a saved game close to that location?
Also, if you tried, did that happen to previous builds?
Title: Re: AGS engine Linux port
Post by: Sslaxx on 29 Jan 2013, 16:43
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).
Can you provide a saved game close to that location?
Also, if you tried, did that happen to previous builds?
Of course. I hadn't tried with previous builds of the code (or of the Linux runtime).

http://sslaxx.twu.net/tmp/PrimordiaGeneratorViewBugs.zip - there are two saves - one before, one after.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 29 Jan 2013, 17:09
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).

I had that same problem with the demo. I didn't try the windows version, I just assumed it was a bug in the demo.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 29 Jan 2013, 19:00
Can you guys test my latest creation:

http://www.perturb.org/tmp/shivah-demo-2013-01-28.tar.gz

This should include a 32bit AND 64bit executable. I haven't built it against glibc 2.13, so currently Wheezy won't work, but everything else (modern) should.

Once we get a stable binary and libs/ directory, that works on multiple distros, we shouldn't need to change much. If we compile ags, and get the libs/ from it once, it's not like we'll need to do it every night. I consider the linux binary to be pretty solid, so I feel comfortable releasing with it. What do you guys think?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 29 Jan 2013, 19:16
There's one long-present bug with saved games, which affect only games which have odd number of animated buttons (yeah, lol). The bug itself makes saved games be incompatible with 3.21.
I finally managed to properly fix it (the previous two attempts were mistakes), but this change is still in separate branch ('develop'). Not that its critical, but if that change will eventually get to 'master', new builds will require some kind of savegame converter for the games saved in meanwhile (yes, only for those that have odd number of animated buttons).

Sort of a warning, FYC.
Title: Re: AGS engine Linux port
Post by: BigMc on 29 Jan 2013, 19:36
This should include a 32bit AND 64bit executable.

It contains just one binary and one set of libraries. That should work on most systems, because most 64 bit systems have a 32 bit libc installed. But what do you mean with 32bit AND 64bit executable?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 29 Jan 2013, 19:39
My bad... I posed the wrong link (to yesterday's build). Try this guy, that's from TODAY.

http://www.perturb.org/tmp/shivah-demo-2013-01-29.tar.gz
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 29 Jan 2013, 22:55
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).

Fixed!
Title: Re: AGS engine Linux port
Post by: Sslaxx on 29 Jan 2013, 23:32
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).

Fixed!
What was the issue?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 29 Jan 2013, 23:43
What was the issue?
A silly typo rather than actual mistake. Wrong function was called by script command.
There was a huge rewrite of script functions in december/january related to making 64-bit builds work safer, which was mainly a tedious routine, and I made few mistakes in the process.
Title: Re: AGS engine Linux port
Post by: BigMc on 30 Jan 2013, 00:24
Ok, I created a script to create a bundle of ags, libraries and all the licenses. The script can be found in the repository at debian/ags+libraries.sh. The resulting bundle is this:

http://people.debian.org/~thansen/ags+libraries_20130130.tar.xz

As Crimson Wizard said, you should probably wait for that one bug to be fixed before releasing a game with this. But please test it! I only tested on Debian.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 30 Jan 2013, 01:36
That is exactly what I want! Both 32 and 64bit versions, and a launcher that picks for you! I did run in to some issues on my Fedora 17 machine:

#1) The binary doesn't seem to find my GeminiRue.ags file, and neither does the launcher. If I run data/ags64 GeminiRue.ags it launches just fine. Did the game detection code change?
#2) I get no sound. Not sure why. The ags I compiled on this machine works fine. I'm assuming it has something to do with the libraries?
#3) Does this include the save game fix Crimson Wizard mentioned?
Title: Re: AGS engine Linux port
Post by: BigMc on 30 Jan 2013, 01:44
1) and 2): For sound the launcher must be used, because otherwise ALLEGRO_MODULES is not set. I didn't have time yet to make sure that path names are handled correctly in odd cases. Did you maybe put this into a path containing spaces or other unusual characters?

3) No, it's the master branch.

EDIT: Oh, I see, you didn't read the README. You must put the game into "data".
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 30 Jan 2013, 02:05
Aha! Well if I RTFM then everything works fine!

It works great with my Shivah demo. Let me throw something else at it. Thanks for putting this all together.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 30 Jan 2013, 17:18
I just setup a github account and sent a "pull request" (I think). To add the strip option to the Makefile. Can someone tell me if I did it correctly?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 30 Jan 2013, 21:36
EDIT: Oh, I see, you didn't read the README. You must put the game into "data".

After RTFM I packaged up my Shivah demo using your engine and posted it here. Looks like it works pretty well. Want to take it out for a spin on your various distros?

http://www.perturb.org/tmp/shivah-demo-2013-01-30.tar.gz
Title: Re: AGS engine Linux port
Post by: Problem on 30 Jan 2013, 21:47
The demo works fine for me on Debian Wheezy 64 bit.  :)
Now the only thing that's missing is a linux equivalent to winsetup.exe, so you don't have to find and edit acsetup.cfg to switch between fullscreen and windowed mode. A basic setup tool would be a good idea if you want to distribute a commercial game this way.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 30 Jan 2013, 21:56
Now the only thing that's missing is a linux equivalent to winsetup.exe, so you don't have to find and edit acsetup.cfg to switch between fullscreen and windowed mode. A basic setup tool would be a good idea if you want to distribute a commercial game this way.

That's on my list of things to do. I'll probably whip up a quick perl script that writes our your acsetup.cfg for you. I want to use dialog, but most boxes probably don't have that installed. It'd only be 2 questions:

1) Window/Fullscreen
2) GFX Filter

We probably don't NEED one, if we ship sane defaults.
Title: Re: AGS engine Linux port
Post by: BigMc on 30 Jan 2013, 22:25
There already is one included with the old Linux ports:

http://www.adventuregamestudio.co.uk/forums/index.php?topic=37968.0

(I just checked and the download links work again.)

But it seems the source code is missing. Maybe ask Electroshokker.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 31 Jan 2013, 01:37
The demo works fine for me on Debian Wheezy 64 bit.  :)
Now the only thing that's missing is a linux equivalent to winsetup.exe, so you don't have to find and edit acsetup.cfg to switch between fullscreen and windowed mode. A basic setup tool would be a good idea if you want to distribute a commercial game this way.

If you run ./shivah --help it will give you the help output of ags, which includes the -windowed and -fullscreen options. Even if you don't know how to edit the config, the binary gives you the options now. Did we decide to switch to --windowed and --fullscreen to be more Linux-y?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 31 Jan 2013, 03:58
EDIT: But you should better not change that, because it's used to check if a game is compatible with the engine.
You can always change the help text in Engine/main/main.cpp.

I'm no C++ guru but I think I hacked together BUILD_STR as a make option. Can someone with git access see if my pull requests are correct? I haven't used git until yesterday. All the projects I've worked on in the past have been SVN. Git is new to me.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 31 Jan 2013, 07:33
Be VERY careful when changing existing command line options, Editor may use these to run games. If you change in one place, make sure you scan ALL the code and make appropriate changes.

Regarding version string. I do not know what were CJ's rule to change it. Maybe ask tzachs?
So far we were very shy and did not modify it. I think this should be done, eventually. Since the code is now pretty different, with all those ports, compatibility/portability fixes, as well as huge file splitting and refactoring, I suggest changing one of the major numbers (like to 3.3). The last number could be changed after certain number of commits (or any significant change)? Well, at least any public release which has differences in how engine work should have a new minor number IMO.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 31 Jan 2013, 16:32
Be VERY careful when changing existing command line options, Editor may use these to run games. If you change in one place, make sure you scan ALL the code and make appropriate changes.

My understanding was that they were JUST added last week. The Editor should not rely on these flags for anything.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 31 Jan 2013, 16:54
Be VERY careful when changing existing command line options, Editor may use these to run games. If you change in one place, make sure you scan ALL the code and make appropriate changes.

My understanding was that they were JUST added last week. The Editor should not rely on these flags for anything.

-windowed and -fullscreen commands exist since CJ's version of AGS. And - I just checked- they are used by the Editor.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 01 Feb 2013, 01:04
Are we ready to release an official version 0.9 of the Linux engine? BigMc can you create another version of your package that includes the binary and the libs?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 01 Feb 2013, 01:45
Couple quick questions:

#1) What are the default windowed/fullscreen/gfxfilter settings if no acsetup.cfg is found? I'm thinking a sane default is "-fullscreen and StdScale4" i.e. Fullscreen + stretch?
#2) Is there any real case where you want fullscreen but NOT stretch? I hate doing -fullscreen and the game loads and it's 320x200 with black border around the whole game. I'm thinking maybe we want to default to "stretch to fit" if the user selects fullscreen?
#3) Do we need a StdScale5 or maybe even StdScale6? A 1080P display is 1920x1080p. If you scale up a 320x200 game 4x (the current highest) you only get 1280x800. I'm thinking we want a full 1080P option?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 01 Feb 2013, 07:34
#1) What are the default windowed/fullscreen/gfxfilter settings if no acsetup.cfg is found? I'm thinking a sane default is "-fullscreen and StdScale4" i.e. Fullscreen + stretch?
Factual implementation, it is Fullscreen + Software Filter (No Scale). I doubt x4 scale is sane default, because the game may have large resolution. 800x600 with x4 scale will be 3200x2400.

#3) Do we need a StdScale5 or maybe even StdScale6? A 1080P display is 1920x1080p. If you scale up a 320x200 game 4x (the current highest) you only get 1280x800. I'm thinking we want a full 1080P option?
I am not an expert in this area, but from quick glance in the code I see that there's no such filter objects as "x2" or "x3", instead there's a single Scaling Filter class, which takes "multiplier" as parameter. I think few simple experiments could show if this may be 5, 6, or more.
E: actually, there are Hqx2 and Hqx3 filters.
Title: Re: AGS engine Linux port
Post by: BigMc on 01 Feb 2013, 09:40
Are we ready to release an official version 0.9 of the Linux engine?

It is upon Crimson Wizard and JJS to decide when AGS gets a new version number. I don't think it is a good idea to diverge from that for single platforms. I also don't think it will happen while a savegame compatibility breaking change is right ahead.

BigMc can you create another version of your package that includes the binary and the libs?

Why should I do that right now? There was not a single change to the code since the last one.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 01 Feb 2013, 09:49
I also don't think it will happen while a savegame compatibility breaking change is right ahead.
It's in "develop" branch. That branch currently contains only changes to (de)serialization routine. I tested that on number of games and it looks working. If it does not break anything, they could be merged to master right away.
Right now I am working on a simple savegame conversion utility that will help fix savegames for Gemini Rue (again) - that's the only game I know that may be affected by these changes.
Title: Re: AGS engine Linux port
Post by: JJS on 01 Feb 2013, 10:41
^^ If you think it is stable, feel free to merge it into master.

#2) Is there any real case where you want fullscreen but NOT stretch? I hate doing -fullscreen and the game loads and it's 320x200 with black border around the whole game. I'm thinking maybe we want to default to "stretch to fit" if the user selects fullscreen?
This seems to be a bug in Allegro to me or maybe it is just how Linux works, no idea. The problem is that on Windows the request for a fullscreen resolution that is not supported by the graphics driver will just fail. But on Linux it looks like the system returns success and then switches to the next best supported resolution (or does not switch at all in fact) which puts the game unscaled in the middle of the screen.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 01 Feb 2013, 18:35
Why should I do that right now? There was not a single change to the code since the last one.

I thought the savegame fix Crimson Wizard did landed. I misunderstood.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 16:06
Is there currently a way to do Fullscreen + Stretch on Linux? Or is your best bet to just do StdScaleX where X is as close as you can get? Does allegro offer any screen stretching modes?
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Feb 2013, 16:19
Or is your best bet to just do StdScaleX where X is as close as you can get?

I am doing it like that manually currently. I also have the problem that if AGS changes my resolution, it does not change it back afterwards. This could be Allegros fault. Maybe it would be best to let AGS never change the screen resolution on Linux, but choose an appropriate scaling automatically instead. What do you think JJS?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 16:35
Where do we stand on that savegame bug? I only ask because Wadjet asked me to package up a beta version of GeminiRue this morning.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Feb 2013, 16:53
Where do we stand on that savegame bug? I only ask because Wadjet asked me to package up a beta version of GeminiRue this morning.
Ouch. Didn't realize it is this urgent.
Well, I can push the changes to master right away, but some people, who were playing the games using those ports and have saves, will experience errors when loading em. By the way, Gemini Rue is exactly one such game, affected by the bug. With my latest changes, the original Gemini Rue saves should load, but older saves made by our engine wont work. I was only worried about possible complains, and wanted to finish convertion utility first, but seeing you want to make beta rigth away I may do merge.

Also, since now it is related to official release of commercial game, I guess we should be ready to fix anything ASAP, hmm? :)
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 16:56
I'd rather do the launch right. I can tell Wadjet there is minor savegame bug we're still working on, and want to hold off. I'll defer to you as to when you feel comfortable with the engine. Seeing as this would be the beta of GeminiRue on Linux, most of the savegames should be new (i.e. not from an older version of the engine) so we should be OK there?
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Feb 2013, 16:59
No, if we can provide an engine compatible with Windows savegames, we should do it.
Title: Re: AGS engine Linux port
Post by: JJS on 04 Feb 2013, 17:00
Maybe it would be best to let AGS never change the screen resolution on Linux, but choose an appropriate scaling automatically instead.
I would say that this would be the best for Windows too. The engine knows the game resolution and it queries the desktop resolution so it would be possible to calculate the appropriate scaler automatically. Sinced scaled graphics are more costly on the CPU we should make this optional, maybe with a new scaler parameter like "StdScaleAuto".
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 17:00
Still the whole savegame issue is a bit of a mess. What I mean is that savegames have a different size on all platforms, which is something that I do not at all understand.

I was under the impression that save games were not compatible across platforms.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Feb 2013, 17:04
Ah, right, that plugin thing. They may save data differently on different platforms.
But, actually, I never tried Gemini Windows saves on Linux, I only know that PSP has difference from Windows. I may check Windows-Linux compatibility now.
Well, and I can as well just make the merge. If something goes terribly wrong we may make a revert.
Title: Re: AGS engine Linux port
Post by: JJS on 04 Feb 2013, 17:07
The original saves from Gemini Rue will not load on any other platform. Exactly because of the different plugin used. But if you use the same plugin on Windows, they are all compatible. In fact you don't even need the external DLL because ags_snowrain is built into the engine on Windows. (At least this is how it theoretically should work, I haven't tried in some sime :-)

Edit: Update on this issue. I could successfully load games made with the Windows engine with builtin plugin on Ubuntu 64 bit and vice versa. I had to fake the operating system version to return "Windows" on Linux because otherwise the game doesn't enable the rain effects.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Feb 2013, 17:09
Okay, I did it. If something happens, you know whom to blame.  (roll)
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Feb 2013, 17:13
Yes, scottchiefbaker.  ;)
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Feb 2013, 17:16
I still don't understand what is going on with plugin data in savegames. If the plugin is the same, why it saves different data?
I just checked snow/rain plugin quickly (one used by Gemini Rue). Why does it ever need to save something if its not Windows, while Windows does not save a thing? Or, putting this other way, why doesnot Windows version save anything? I am very confused.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 17:23
BigMc: can you do a build of your ags+libraries with the big merge that just happened? Can you give is a BUILD_STR=$(date +%F)? I'll use that binary as a basis for my Gemini Rue beta.
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Feb 2013, 17:34
I would say that this would be the best for Windows too. The engine knows the game resolution and it queries the desktop resolution so it would be possible to calculate the appropriate scaler automatically. Sinced scaled graphics are more costly on the CPU we should make this optional, maybe with a new scaler parameter like "StdScaleAuto".

If it is better, I think it should be the default and the option should be to turn it off. Something like allow_screen_resolution_change? One could use filters (including "None") to disable auto scaling. In windowed mode, the window could be scaled to something like the screen resolution minus 50(?) pixels in height per default.

BigMc: can you do a build of your ags+libraries with the big merge that just happened? Can you give is a BUILD_STR=$(date +%F)? I'll use that binary as a basis for my Gemini Rue beta.

BUILD_STR is not merged.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 18:52
Now that the savegame code is merged, are we ready to release beta test of GeminiRue? Wadjet has given me the data, we just need an engine to go along with it.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Feb 2013, 19:11
I guess so. Since it's beta test. Let's hope testers will test it good.




*chuckle*
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 19:14
I guess so. Since it's beta test. Let's hope testers will test it good.

Well that's the intention! BigMc can you please build a new version of your ags+libraries? If you don't have time I can spin up a Debian Wheezy 32/64bit VM and build them. You already have that stuff, so it's probably easier for you. Should we need to look in to setting up a build system? Right now BigMc is our build system :)
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Feb 2013, 19:26
I'll have a look at the scaling first and then upload another build (today). It is ok if I make autoscaling the default as suggested in the last post?
Title: Re: AGS engine Linux port
Post by: Sslaxx on 04 Feb 2013, 20:32
Using with the demo version of the game? I've got the full game installed and the Linux binaries built.

This is interesting. Using the game's data files with a freshly-compiled executable is giving me sound corruption/speed issues (at random it seems, for at least a couple of seconds and usually longer).
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 21:04
This is interesting. Using the game's data files with a freshly-compiled executable is giving me sound corruption/speed issues (at random it seems, for at least a couple of seconds and usually longer).

Can you provide more details? You're using an engine compiled today (after the big checkin of savegame stuff)? What game are you having problems with? Gemini Rue?
Title: Re: AGS engine Linux port
Post by: Sslaxx on 04 Feb 2013, 21:25
This is interesting. Using the game's data files with a freshly-compiled executable is giving me sound corruption/speed issues (at random it seems, for at least a couple of seconds and usually longer).

Can you provide more details? You're using an engine compiled today (after the big checkin of savegame stuff)? What game are you having problems with? Gemini Rue?
Yup. Compiled today using the savegame changes, using it with the full version of Gemini Rue.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 04 Feb 2013, 22:01
Yup. Compiled today using the savegame changes, using it with the full version of Gemini Rue.

Where did you experience slowdowns? I just watched the whole intro, and walked around the first two screens for three minutes. No issues.
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Feb 2013, 22:04
Here is the new build: http://people.debian.org/~thansen/ags+libraries_20130204.tar.xz

I added automatic selection of the appropriate StdScale filter for the case that no filter is set, but did nothing to make sure that the screen resoltion is not changed.

EDIT: By the way, missing menu sound and rain in Gemini Rue are expected, because they were disabled by the creators unless you use Windows.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 04 Feb 2013, 22:17
Here is the new build: http://people.debian.org/~thansen/ags+libraries_20130204.tar.xz

I added automatic selection of the appropriate StdScale filter for the case that no filter is set, but did nothing to make sure that the screen resoltion is not changed.

EDIT: By the way, missing menu sound and rain in Gemini Rue are expected, because they were disabled by the creators unless you use Windows.
Not worried about the missing rain sounds, aware that that's due to platform issues. Issues noticed primarily during the introduction sequence, during the start of the game and sometimes when you switched tasks.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 00:04
Not worried about the missing rain sounds, aware that that's due to platform issues. Issues noticed primarily during the introduction sequence, during the start of the game and sometimes when you switched tasks.

I did not experience any of the sound or delay problems you mentioned. I'm running Fedora 64 bit, what are you running?
Title: Re: AGS engine Linux port
Post by: Sslaxx on 05 Feb 2013, 00:18
Not worried about the missing rain sounds, aware that that's due to platform issues. Issues noticed primarily during the introduction sequence, during the start of the game and sometimes when you switched tasks.

I did not experience any of the sound or delay problems you mentioned. I'm running Fedora 64 bit, what are you running?
Ubuntu 12.10, 32-bit.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 00:19
I've packaged up GeminiRue per Wadjet's request. Here is the beta version that I'm proposing to give to them to start their Linux beta testing. Anyone care to take this package out for a test drive and give me any feedback before I send it off to Wadjet.

[link to full commercial game removed by moderator]

I'd like to get something to them tomorrow in the morning.
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 01:54
Looking good so far, Scott.  I am hearing some audio glitching on my office workstation which is not present on my laptop (both 64-bit Ubuntu 12.04), but I did run updates and have not rebooted.  I'm hoping it's that;  it's occurring on other games as well (Shivah demo), though audio works fine on a music player and for HTML5 videos in a browser.  Another note;  on a multi-monitor setup (with full-screen and StdScale2 by default) it's looking pretty tiny, and split down the middle on my setup.

Is this binary the version with BigMC's StdScale auto-select?  If so, then I suggest removing the gfxfilter setting from acsetup.cfg completely.

Again, my (brief) test on the laptop had no troubles at all.

Also, that's not the demo... you probably ought to pull the URL tomorrow after you deliver it to them  8-)
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 02:00
Is this binary the version with BigMC's StdScale auto-select?

It appears that it is not... in testing for it, Gemini Rue just came up as a tiny postage stamp on my monitor :)
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 06:00
I think I can confirm what Sslaxx saw, and it is, indeed the same glitching as I observed on my workstation.  When I observed it in The Shivah, it sounded so awful that I shut it off without noticing any speed distortion.  This time in Gemini Rue, however, my save was right before a cut-scene (Matthias' apartment), and in my case, game speed and audio were accelerated.  Should I have a peek through the sources and see if I can find where in the code the engine speed or script interpreter speed is governed?

If anyone has seen timing bugs like this, a pointer to where to begin debugging would be greatly appreciated.  I'm suspicious of this entirely being AGS's fault, though, as it persists between game loads, so I'm really not sure where this hysteresis is coming from.  Perhaps some odd Allegro problem?

Edit:  I have video clips of the bug/glitch in action, and could put them somewhere if that would help (they are 2MB and 5MB).
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 05 Feb 2013, 07:27
Is this problem you mention anyhow similar to what I reported a while ago here?: https://github.com/adventuregamestudio/ags/issues/18

E: The BigMC's auto-filter seem working for me on Windows. If I don't have a filter set in config file, it will calculate monitor/game resolution ratio and set maximal possible filter.
This is not a problem for linux, I guess, but for Windows we need to add "Auto" option in the filter list in setup window, because as soon as you run setup at least once, the "None" will be set for filter.
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 07:34
Progress!  I think we're OK, after all.

Crimson Wizard; no, I don't think it's like that.  I have a video clip I could share (not sure what the best way is).  It's very distinctive, and involves no repetition.

Sslaxx;  please try restarting PulseAudio when this glitches out.  Simply run pulseaudio -k and wait a second or two.  For me, I hear the DAC pop softly when it comes back up, then I see the audio control icon change to the "muted" graphic and change back, and lastly reset to my default volume.  After doing this, the game's behavior and audio go back to normal.

If this is actually PulseAudio losing it's brain, then it's nothing to do with AGS (unless we're perturbing it somehow), and further explains the hysteresis.  Aside from being mystified at how the actual gameplay speed could be linked to the glitching, I'm feeling very confident in this build, now... 8-)
Title: Re: AGS engine Linux port
Post by: BigMc on 05 Feb 2013, 08:25
Anyone care to take this package out for a test drive and give me any feedback before I send it off to Wadjet.

Here, autoscaling is disabled, because gfxfilter=StdScale2 is set in acsetup.conf. Also, is ags_shell.dll a Windows plugin?
Title: Re: AGS engine Linux port
Post by: JJS on 05 Feb 2013, 08:45
Also, is ags_shell.dll a Windows plugin?
There is a function stub for it in the engine. This plugin basically provides access to the ShellExecute Windows API function. The Gemini Rue Demo uses it to open a website in the browser.
Title: Re: AGS engine Linux port
Post by: BigMc on 05 Feb 2013, 08:46
So the file is not needed on Linux right?
Title: Re: AGS engine Linux port
Post by: JJS on 05 Feb 2013, 08:51
Correct.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 05 Feb 2013, 11:37
The version label built in program is "3.21.1115", although the build is technically not 3.21.1115 anymore (and for quite a long time already).
Since it is going to be used for official game releases (commercial or not), I think it would be appropriate if the version is updated.
We just have to think this out carefully and preview what consequences such change will have (if any).
I am going to investigate more on this.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 05 Feb 2013, 12:38
No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 05 Feb 2013, 12:53
No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.
But these changes have nothing to do with audio nor game speed. It sounds like this effect is either random, or changes with every rebuild?
Title: Re: AGS engine Linux port
Post by: Sslaxx on 05 Feb 2013, 12:57
No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.
But these changes have nothing to do with audio nor game speed. It sounds like this effect is either random, or changes with every rebuild?
Sounds like an unintended side-effect of the scaling code, perhaps? It seems odd that it should change anything sound-wise though.
Title: Re: AGS engine Linux port
Post by: BigMc on 05 Feb 2013, 12:59
Sounds like something I once experienced with a different engine. There was a bug in a sound library that was used, and the sound got corrupted sometimes. Even after quitting the game engine and restarting, the sound was still corrupted. Rebooting would help. That sound library is not used in AGS though.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 05 Feb 2013, 13:07
Sounds like something I once experienced with a different engine. There was a bug in a sound library that was used, and the sound got corrupted sometimes. Even after quitting the game engine and restarting, the sound was still corrupted. Rebooting would help. That sound library is not used in AGS though.
That possibility did cross my mind. So we need to eliminate the possibility of it being outside of the AGS source?
Title: Re: AGS engine Linux port
Post by: BigMc on 05 Feb 2013, 13:18
Maybe AGS uses external code incorrectly. Does not shut it down properly or so. But the bug could still also be in AGS.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 05 Feb 2013, 13:45
Maybe AGS uses external code incorrectly. Does not shut it down properly or so.
Easily possible. Have you seen quit() function? It basically aborts the application at any random point, without returning to main loop. It does some cleanup, but may miss some things.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 16:09
The version label built in program is "3.21.1115", although the build is technically not 3.21.1115 anymore (and for quite a long time already).
Since it is going to be used for official game releases (commercial or not), I think it would be appropriate if the version is updated.
We just have to think this out carefully and preview what consequences such change will have (if any).
I am going to investigate more on this.

Should we change this before we release?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 16:12
Here, autoscaling is disabled, because gfxfilter=StdScale2 is set in acsetup.conf. Also, is ags_shell.dll a Windows plugin?

Good catch I'll remove the .dll. The acsetup.cfg is direct from the Windows version. Since 90% of those options are ignored on the Linux version what SHOULD the config look like? I'm thinking ALL we need is:

[misc]
gamecolordepth=16
titletext=Gemini Rue Setup
windowed=0

Do we need any of the sound settings on Linux?
Title: Re: AGS engine Linux port
Post by: BigMc on 05 Feb 2013, 16:54
The version label built in program is "3.21.1115", although the build is technically not 3.21.1115 anymore (and for quite a long time already).
Since it is going to be used for official game releases (commercial or not), I think it would be appropriate if the version is updated.
We just have to think this out carefully and preview what consequences such change will have (if any).
I am going to investigate more on this.

Should we change this before we release?

I guess you could start the beta test without it.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 17:14
Ultimately the simple solution would be a BUILD_STR. Did that get rejected? I didn't get any feedback, or maybe I just don't understand how github works.
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 17:20
I strongly suggest advancing the build number, in some way, prior to the beta.
Title: Re: AGS engine Linux port
Post by: BigMc on 05 Feb 2013, 17:30
Ultimately the simple solution would be a BUILD_STR. Did that get rejected? I didn't get any feedback, or maybe I just don't understand how github works.

You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 17:32
No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.

Well, yes, it's an intermittent bug, but I seriously doubt it was fixed by those changes (they were nowhere near that behavior, as best I can tell).  What I assumed was my own setup, on one machine, is actually the bug.  I've observed it in earlier revisions as well.

It is possible that it is a race-condition, and the latest changes perturbed it so that they don't show up on your hardware, but it's unlikely that it's fixed.  Just masked.

I was hoping to find a workaround since it's difficult to reproduce.  When the OS, or audio subsystem, are in that state, where you would be convinced that a reboot is necessary, then that is the time to try to restart pulse.  I've confirmed (now that I'm at my office) that restarting pulse on that workstation immediately fixes it, as well.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 17:33
I strongly suggest advancing the build number, in some way, prior to the beta.

I think games rely on the version number. I think the easier thing to do, is just version the Linux version separately.
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 17:34
I think games rely on the version number. I think the easier thing to do, is just version the Linux version separately.

OK, in that case, we should at least include the Git revision hash and MD5 of the binary in a readme or something similar.  It's critical that beta testers can know for sure what they're running.
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 17:39
You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)

Would that be Crimson Wizard or JJS?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 05 Feb 2013, 17:52
You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)

Would that be Crimson Wizard or JJS?
He did create a pull request: https://github.com/adventuregamestudio/ags/pull/53
It's just named afer last commit, which is unrelated to BUILD_STR.
I can merge requests, but I think JJS knows makefiles (and linux in general) better.

But, regarding the version. What is exactly a problem here? We need a 1) "base" version of the engine, which determines its features and overall behavior, and since AGS is now being released in open-source format, being built on daily basis 2) a build information, that will not be a decisive factor to determine game-to-engine compatibility.

My suggestion is:
1) increase major version once for now to reflect the huge changes made to the code. This will render all savegames made by new engine "conventionally" incompatible with original games, but as soon as savegame conversion utility is made, that won't be a much of a problem (it will need to replace version string inside savegame, because the format is still totally compatible to AGS 3.2.*; oh, and plugin stuff, but thats other story). Besides, no other platforms can run original Windows games anyway.
2) use any sane method to put purely informative build string into application. scottchiefbaker's suggestion seem to do this, although his code will only work for printing version info at console, and not in game (the Ctrl+V method). But that may work for starters.
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 17:59
You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)

Would that be Crimson Wizard or JJS?
I can merge requests, but I think JJS knows makefiles (and linux in general) better.

Ok, thanks!  I was just curious about that.

But, regarding the version. What is exactly a problem here?

In my mind it's primarily an issue for tracking bugs filed during beta testing (in general).  It would be better for games not to pay attention to the micro-version/build-number (e.g., bug fixes), but only look at "major.minor", going forward.  Anything beyond that is not really important right now for beta testing.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 18:00
For doing one off testing, it would be VERY useful to include a BUILD_STR that's only present at the commandline (I don't see why it would be needed in game) to indicate the difference between two builds that are the same version numbers.

Sort of like how the kernel has an -AC branch and a -linus etc. Even though they're working on the same core version.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 18:32
I pulled the ags_shell.dll from my GeminiRue install. We need to finalize an acsetup.cfg file, and I think we're ready for a beta I can give to Wadjet? Anything else we need?
Title: Re: AGS engine Linux port
Post by: s_d on 05 Feb 2013, 18:58
Not really!

If you wish to include a README.beta or something like that, you might mention the audio corruption issue observed on Ubuntu 12.04 & 12.10 systems, and the workaround of "pulsaudio -k".

So, what's next?  Resonance? Primordia?   (laugh)
Title: Re: AGS engine Linux port
Post by: JanetC on 05 Feb 2013, 21:55
So, what's next?  Resonance? Primordia?   (laugh)

I hope we can do all of them! :)
Title: Re: AGS engine Linux port
Post by: BigMc on 05 Feb 2013, 22:28
Do we need any of the sound settings on Linux?

No idea, I guess most Linux players kept them so far and they didn't do any harm.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 05 Feb 2013, 22:55
Ok I removed that Windows DLL, and simplified the acsetup.cfg like I mentioned in the previous post. I'm pretty happy with this release:

[link to full commercial game removed by moderator]

I'll send this on Wadjet as their initial beta test.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 01:27
So, what's next?  Resonance? Primordia?   (laugh)

I hope we can do all of them! :)

Awesome!  A drive-by Janet response  ;-D

Getting a game working on one's platform of choice for the first time is incredibly satisfying!  I'm hooked... it's so much more fun than writing drivers  :P
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 04:38
Ok I removed that Windows DLL, and simplified the acsetup.cfg like I mentioned in the previous post. I'm pretty happy with this release:

http://www.perturb.org/tmp/GeminiRue-beta-2013-02-05.tar.gz

I'll send this on Wadjet as their initial beta test.

Yep, looks good.  Probably don't need any agsgame.log files or unins000.dat, but these are harmless and tiny.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 16:31
EDIT: By the way, missing menu sound and rain in Gemini Rue are expected, because they were disabled by the creators unless you use Windows.

Can you shed some more light on this. It came up a LOT during the beta test we ran yesterday.
Title: Re: AGS engine Linux port
Post by: JJS on 06 Feb 2013, 16:58
For some reason the game checks the platform it is running on. Only if the platform is "Windows" it will enable the rain plugin.

The mobile platform ports all report back "Windows" to avoid this issue (and similar ones with other old games). But for a new release this check should be removed in the game script itself.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 17:02
I want to write a small configuration generator script for the releases. Is there a way to get the current display resolution from ags/allegro? Would it be possible to add a --display_geometry or something that would spit out: color depth, resolution, etc? Then my script could parse that and "suggest" intelligent defaults for the config?

For the Gemini Rue beta, a LOT of people complained about the game launching in fullscreen and only seeing a tiny postage stamp sized window in the middle.
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 17:36
I want to write a small configuration generator script for the releases. Is there a way to get the current display resolution from ags/allegro? Would it be possible to add a --display_geometry or something that would spit out: color depth, resolution, etc? Then my script could parse that and "suggest" intelligent defaults for the config?

For the Gemini Rue beta, a LOT of people complained about the game launching in fullscreen and only seeing a tiny postage stamp sized window in the middle.

Yes, because you used my binary from January 30. *facepalm*
Title: Re: AGS engine Linux port
Post by: JanetC on 06 Feb 2013, 17:40
For some reason the game checks the platform it is running on. Only if the platform is "Windows" it will enable the rain plugin.

The mobile platform ports all report back "Windows" to avoid this issue (and similar ones with other old games). But for a new release this check should be removed in the game script itself.


This is puzzling. The latest build of Gemini Rue for PC does *not* use the SnowRain plugin. The snowrain plugin caused some problems on some people's PCs, so we got a custom module made that does the same thing. Gemini Rue shouldn't require any plugins at all.
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 17:47
Is there maybe still a check for the platform to be Windows in place somewhere?
Title: Re: AGS engine Linux port
Post by: JanetC on 06 Feb 2013, 17:50
Is there maybe still a check for the platform to be Windows in place somewhere?

You are right. There is still some stray code that checks that it is windows. We will remove it and recompile.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Feb 2013, 17:53
I actually remember I once made some mistake in game loading code (not sure), and when Gemini loaded, there was no rain. I could not believe my eyes :) Now I think I maybe screwed platform check return value.

But, hmm, thinking further about this. If rain is in script module, it might be pretty slowing factor for weaker platforms. Is it possible to, for instance, disable it for PSP, where we had speed issues lately? Just a thought.
Title: Re: AGS engine Linux port
Post by: JJS on 06 Feb 2013, 17:59
I just tried the beta upload with the original Linux engine and a modified one that always returns "Windows".

Original: Neither rain sound effect nor rain.
Fake version: Rain sound effect but no rain.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 18:02
Is it feasible to remove the Windows binary of AGS, and just leave the data files for Linux AGS to run? We had a user report that they double clicked GeminiRue.ags (which is the renamed .exe) because Gnome reported that it was a Windows executable and launched it with wine. Not sure if it's a big deal or not. Might not be worth the effort.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Feb 2013, 18:09
Yes it's possible. There was an utility made for similar task: https://github.com/rofl0r/agsutils
Title: Re: AGS engine Linux port
Post by: JJS on 06 Feb 2013, 18:14
That utility cannot directly chop off the engine though. It can only extract everything and then pack it again. It should be trivial to make a script that removes the exe directly (if you don't suck at scripts like me). It is certainly no problem with a hex editor. The engine exe ends with "PADDINGXXPADDING", the data starts with "CLIB". Cut must be made in between. Also the end of the file contains the offset to the CLIB start iirc. Edit: Yeah, it is the 4 bytes directly before CLIB at the end of the file.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Feb 2013, 18:18
Well, yes. I thought cutting data off will break offsets, but I rechecked the code and see that executable size is only added at the runtime (if it exists).
Also, ideally it should be Editor to allow compilation without windows executable.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 18:25
If I remove the Windows exe I save about 2MB on GeminiRue.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 18:40
For the Gemini Rue beta, a LOT of people complained about the game launching in fullscreen and only seeing a tiny postage stamp sized window in the middle.

Yes, I mentioned that night before last  ;)

Since Janet is spinning a new version without the OS check, it would be a good time to repackage it with BigMC's autoscale feature.  Introducing a config editor, simple or otherwise, seems like unnecessary work.  Has anyone pinged Electroshokker?  Might as well check out the old GUI code and see how portable it is.  Why reinvent the wheel?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 18:42
Since Janet is spinning a new version without the OS check, it would be a good time to repackage it with BigMC's autoscale feature.  Introducing a config editor, simple or otherwise, seems like unnecessary work.  Has anyone pinged Electroshokker?  Might as well check out the old GUI code and see how portable it is.  Why reinvent the wheel?

I thought the autoscale feature did make it in the release that we used?

As for a config editor, it's SO simple I think we should do it. I have half a perl script written already. I'm thinking we should check for acsetup.cfg on launch, if it's not there launch the configuration editor.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Feb 2013, 18:46
Introducing a config editor, simple or otherwise, seems like unnecessary work.
It should be fairly easy program to write when such need arises, at least for Windows/Linux, using Qt, wxWidgets, maybe Python, idk, there's many.

Might as well check out the old GUI code and see how portable it is.
Do you mean Elektroshokker's one, or vanilla AGS? The latter is non-portable, because it uses WinAPI.

Why reinvent the wheel?
We don't re-invent, we re-implement, that's totally different thing :D.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 18:50
Do you mean Elektroshokker's one, or vanilla AGS? The latter is non-portable, because it uses WinAPI.

Yes, Elektroshokker's.  Looks like he logged in here not too long ago, so a PM might get his attention  :)

Though, if I recall, it used an old GTK or something and may need to be rewritten anyway.  I suppose we could bung it out in Python and use iniparse & PyGtk to make it pretty.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 18:53
As part of the Gemini Rue beta we had several reports of people running at 1920x1080. Currently the engine only supports up to StdScale4, are we able to do 5 or 6?
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 18:56
I thought the autoscale feature did make it in the release that we used?

Well, as I mentioned, I didn't see it working.  I just assumed that you expected us to build our own ags binary to go with the new library set (and I did so), not that exact specific tar archive.  Mea culpa.  I could have been noisier about that.

As for a config editor, it's SO simple I think we should do it. I have half a perl script written already. I'm thinking we should check for acsetup.cfg on launch, if it's not there launch the configuration editor.

Have at it!  My point is that if the only feature is scaling, then why bother for beta?  Just re-roll ags & re-release while testers are still engaged (they get bored too).
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 18:56
Here is a simple perl script I wrote up that we can use to detect resolution and pick StdScaleX appropriately:

http://www.perturb.org/tmp/ags_config

Comments?
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 18:58
I thought the autoscale feature did make it in the release that we used?

It is in my upload from February 4, but you used the older one (at least concerning ags64).
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 19:00
It is in my upload from February 4, but you used the older one (at least concerning ags64).

I did? That was an oversight on my part. I should rebuild.

Just to clarify the autoscale works in both windowed and fullscreen mode?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Feb 2013, 19:00
As part of the Gemini Rue beta we had several reports of people running at 1920x1080. Currently the engine only supports up to StdScale4, are we able to do 5 or 6?
Simple answer is - not fully sure.
The filter classes take multipliers as constructor parameters (I think I mentioned this somewhere already), so it's only to add few more options.
However, I cannot tell if there's something hidden deep in the code that would cause problems with new scaling. A quick discussion about this: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636444924#msg636444924

I'd say, let's try out, this could be an opportunity to test this.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 19:01
As part of the Gemini Rue beta we had several reports of people running at 1920x1080. Currently the engine only supports up to StdScale4, are we able to do 5 or 6?

Crimson Wizard answered this last week;  there are Hqx2 and Hqx3 filters.  Higher multipliers would need to be implemented (I'm at work right now, so I can't look at that to see if there are any inherent limitations, sorry).  It may be easy it may be hard, someone will have to look.

For what it's worth, I'm on 1920x1080 as well (on a workstation).
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 19:03
Crimson Wizard answered this last week;  there are Hqx2 and Hqx3 filters.  Higher multipliers would need to be implemented (I'm at work right now, so I can't look at that to see if there are any inherent limitations, sorry).  It may be easy it may be hard, someone will have to look.

Ya I'm only concerned with the StdScaleX scaling. The Hqx2 is a complicated algorithm, but StdScale6 should be simple to implement. BigMc will your autoscale go beyond StdScale4? With GeminiRue being 320x200 that could still be considered small on a 1080p monitor.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 19:35
I can't believe I released the Gemini Rue beta without BigMcs autoscale! That really sucks. I did an overzealous cp -a when moving from one release to the other and included the ags32 and ags64 binaries when I shouldn't have.

Doh!

If you haven't seen it yet Wadjeteye posted the public beta on their forums (http://www.wadjeteyegames.com/forum/index.php?topic=1673). There is lots of good feedback there, mostly about the scaling and windowed vs fullscreen mode. Some reports of a "slugish" mouse also.
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 19:44
I pushed a change enabling StdScale up to 8x. Seems to work just fine. Don't know about performance, my PC handles it.
Title: Re: AGS engine Linux port
Post by: JanetC on 06 Feb 2013, 19:52
But, hmm, thinking further about this. If rain is in script module, it might be pretty slowing factor for weaker platforms. Is it possible to, for instance, disable it for PSP, where we had speed issues lately? Just a thought.

Linux is basically the same as PC in system requirements. We have no plans for a PSP release, so it shouldn't be an issue.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 19:57
I can't believe I released the Gemini Rue beta without BigMcs autoscale! That really sucks.

Hey, it happens!  That's what beta is about.  I'll be a more diligent helping in the future, since I did notice it.

This way we get a nice bump in scale from BigMC as well!  Just turn another package and get the beta folks going again, it will all work out  ;)
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Feb 2013, 20:12
We have no plans for a PSP release, so it shouldn't be an issue.
But it is already possible to run Gemini Rue on PSP using PSP port...

Well, this situation is a bit complicated. The AGS game is resources + script, so what counts for game release on other platform? On other hand, from end-user point of view the publisher should be responsible for both engine and game quality, so they see them as a single whole, I guess.

I was just thinking that maybe, since there are ports to number of different platforms already, we could encourage game developers to add perfomance options to their games, like switching extra effects on/off.
These options could be hidden, and activated only from script as a reaction to platform check, like either game runs on "hi-end" or "lo-end" platform.
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 20:33
We have no plans for a PSP release, so it shouldn't be an issue.
we could encourage game developers to add perfomance options to their games, like switching extra effects on/off.
These options could be hidden, and activated only from script as a reaction to platform check, like either game runs on "hi-end" or "lo-end" platform.

Please don't use the platform check for that. Remember what the result was for Gemini Rue. For example, there are slow and quite fast Android devices.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 21:15
from end-user point of view the publisher should be responsible for both engine and game quality, so they see them as a single whole, I guess.

Also, and to the point, from the publisher's perspective they should be responsible for both engine and game quality.  Clearly, Wadjet Eye takes that very seriously.
Title: Re: AGS engine Linux port
Post by: Spummy on 06 Feb 2013, 21:57
Yes, Elektroshokker's.  Looks like he logged in here not too long ago, so a PM might get his attention  :)

Though, if I recall, it used an old GTK or something and may need to be rewritten anyway.  I suppose we could bung it out in Python and use iniparse & PyGtk to make it pretty.

I'm up for programming a new config tool if needed. Is there a preference of language and widget toolkit? Because Python and wxWidgets would certainly get it done fast, but creates the requirement of python and wxPython to be installed. If we only want to use it for Linux then most distros appear to come with Python so that's not much of an issue, and I suppose if a dev REALLY wanted to idiot proof it they could prebundle wxPython, but that may be more of a hassle than wanted.

Of course, I'm going to wait around a wee while to see if Elektroshokker is around and can throw the code for his tool at us.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 22:12
I pushed a change enabling StdScale up to 8x. Seems to work just fine. Don't know about performance, my PC handles it.

Can I request a build of ags+libraries that has this check? I'll build a new GeminiRue package with it. Please and thank you.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 22:31
He said he already pushed it.  Just update and rebuild (I'll do it when I get home, if necessary).  The libraries have not changed.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 22:34
Oh I've rebuilt it locally on my box. But I'm running Fedora with Glibc 2.15, and we're building on Debian which includes 2.13, and is thus more universally compatible. Our build environment for this project has been a Debian Wheezy install. Plus we'd need a 32bit and a 64bit version of Wheezy to build both versions. BigMc already has this all setup, so it's easier for him to put it all together.

If need be I can build two Debian boxes that can be used JUST for building. It'd just take time I don't really have right now.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 22:52
Ah, yes the glibc versioning.  I forgot.  I have that set up partially (I set up my 32-bit build environment on Debian because of that issue, but have continued building 64-bit on Ubuntu).  I might as well set up the 64-bit version as well.  Thanks!
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 22:52
Of course, I'm going to wait around a wee while to see if Elektroshokker is around and can throw the code for his tool at us.

I PM'ed him  :)
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 22:58
I just have one Debian installation and use chroots for building. One can easily build the Debian package using pbuilder or cowbuilder. I think it's also no big deal to set up Debian chroots on Ubuntu and use them for building.

Here you go: http://people.debian.org/~thansen/ags+libraries_20130206.tar.xz
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 22:59
Ah, yes the glibc versioning.  I forgot.  I have that set up partially (I set up my 32-bit build environment on Debian because of that issue, but have continued building 64-bit on Ubuntu).  I might as well set up the 64-bit version as well.  Thanks!

If you could setup Debian 32/64bit installs, that would be awesome. That way BigMc isn't the only one who can do official builds.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 23:15
I think it's also no big deal to set up Debian chroots on Ubuntu and use them for building.

Exactly;  that's my 32-bit build environment, a Debian chroot running on 64-bit Ubuntu 12.04, I just hadn't bothered with a 64-bit chroot as well, since I was already building natively.  Might as well do so, so that you don't have to roll all the builds.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Feb 2013, 23:17
That way BigMc isn't the only one who can do official builds.

Hah, exactly  8-)
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 23:22
How exactly does your auto scaling code work? Is it something like this?

scale_factor = floor(display_resolution / game_resolution);

Here you go: http://people.debian.org/~thansen/ags+libraries_20130206.tar.xz

You are awesome... thanks!
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 23:27
if windowed
  display_resolution_y = display_resolution_y - 100

scale_factor_x = display_resolution_x / game_resolution_x;
scale_factor_y = display_resolution_y / game_resolution_y;
scale_factor = min(scale_factor_x, scale_factor_y)

since these are integers, "floor" is implied. Next time look at the commits. ;)
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Feb 2013, 23:42
Those of you building ags on other platforms, can you please respond to this forum post I just made:

http://www.adventuregamestudio.co.uk/forums/index.php?topic=47590

I want to get a collection of super simple instructions for various distros that will allow anyone (even a novice) to build ags. Specifically what the dependancy names are. On Fedora it's dumb-devel, but I think Ubuntu is libdumb-devel?
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Feb 2013, 23:58
The dependency names for Ubuntu are in the readme.
Title: Re: AGS engine Linux port
Post by: s_d on 07 Feb 2013, 01:25
Yeah, I just used the README.md from github.  Probably, Scott, you should just add a Fedora section to that document, that way the repo describes itself (rather than needing to go to a forum to learn to build it, where links can break, etc).

I could write up a Gentoo ebuild when I get around to it, as well, or just update the old AGS 2.72 ebuild (not sure how much as changed, in terms of how it's built).
Title: Re: AGS engine Linux port
Post by: s_d on 07 Feb 2013, 02:04
BigMC, just noticed something in widescreen mode, with auto-scaling.  It seems to not be adding widescreen borders (i.e., it's off-center) even though it claims to have checked it and found it unnecessary:

Quote
AGS: Widescreen side borders: game resolution: 320 x 200; desktop resolution: 1366 x 768
AGS: Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)

Title: Re: AGS engine Linux port
Post by: s_d on 07 Feb 2013, 07:59
Also, there is an utility, made by one guy, which allows to "cut" Windows binaries from game exe, producing a clean game data package (this also saves 0.5-1.5 megs depending on game version): https://github.com/rofl0r/agsutils. That may be used meanwhile.

FYI, this utility ("agstract" specifically), while awesome and useful, is alpha-quality code.  In particular, it has trouble with packfiles split into multiple pieces (there is an enumeration/off-by-one-error I'm tracking down).  Just fair warning!

My debugging is complicated by the fact that I'm pretty new to AGS, and properly debugging this requires a great deal of knowledge of the packfile format that AGS uses.  At any rate, if I can get it fixed, there will be a nifty side-effect, which is that we could extract the contents of multiple data files to a temp directory, and then pack them cleanly into a single archive.  I'll continue the convention we've established here, where we name those "EXE"-less data files with the ".ags" extension.

In the mean time, we may need to just get used to packing up games like that with the EXE bits intact.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 07 Feb 2013, 08:48
As JJS mentioned, you can just cut off file contents between two signatures: "CLIB" and "CLIB\x1\x2\x3\x4SIGE" (inclusive!!)
To see how these are being looked for check AssetManager class - Common/core/assetmanager.h and .cpp (this is a refactored version of older Clib32 unit). Specifically: AssetManager::_IsDataFile and AssetManager::RegisterAssetLib:

Code: C++
  1.     // check multifile lib signature at the beginning of file
  2.     ci_s->Read(&clbuff[0], 5);
  3.     if (strncmp(clbuff, _libHeadSig /*"CLIB"*/, 4) != 0)
  4.     {
  5.         // signature not found, check signature at the end of file
  6.         ci_s->Seek(Common::kSeekEnd, -12);
  7.         ci_s->Read(&clbuff[0], 12);
  8.         // signature not found, return error code
  9.         if (strncmp(clbuff, _libTailSig, 12) != 0)
  10.         {
  11.             return false;
  12.         }
  13.  
  14.         // read multifile lib offset value
  15.         abs_offset = ci_s->ReadInt32();
  16.         ci_s->Seek(Common::kSeekBegin, abs_offset + 5);
  17.     }
  18.  

The "end-of-file" signature is the path for data attached to the end of exe. abs_offset points to where data actually starts. What you should do is extract all data from abs_offset to the end of file.
Title: Re: AGS engine Linux port
Post by: BigMc on 07 Feb 2013, 08:55
BigMC, just noticed something in widescreen mode, with auto-scaling.  It seems to not be adding widescreen borders (i.e., it's off-center) even though it claims to have checked it and found it unnecessary:

That is probably because AGS expects Allegros graphics initialization to fail if the given resolution can not be set as display resolution, as explained earlier by JJS. This is not the case on Linux, so a different path through the spaghetti code in graphics_mode.cpp is taken.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 07 Feb 2013, 18:53
If there is NO acsetup.cfg file at all, we're going to default to BigMcs autoscale right? Do we default to -windowed or -fullscreen at that point?
Title: Re: AGS engine Linux port
Post by: JJS on 07 Feb 2013, 19:05
Yes and fullscreen is the default.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 07 Feb 2013, 23:40
Using the newest binary, when I run a test version of GeminiRue that Wadjet got me I get a "prog.res" and a "Saves" directory in the data/ directory. The Saves directory is chmoded 000, so it's hard to work with, and empty. Is this something the engine is creating, or is it a script in the game that's doing that?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 00:00
Looking in to it further, it appears the new GeminiRue creates a separate directory for the save games, and the achievements to go in. The problem is, that it defaults to creating the directory chmod 000. Does the AGS engine allow a game to create a directory? Does the game specify permissions for that directory, or does the engine?

If I manually chmod 755 the directory it works as it should. I'm thinking maybe it's a bug if we allow a directory to be created with 0 permissions?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 00:05
Not to spam the thread but I got this from Wadjet

I used the command

Game.SetSaveGameDirectory("Saves");

to do this.

http://www.adventuregamestudio.co.uk/manual/Game.SetSaveGameDirectory.htm


The documentation doesn't say anything about permissions. I believe the relevant piece of code is in ac/game.cpp at line #368:

#if defined (WINDOWS_VERSION)
    mkdir(newSaveGameDir);
#else
    mkdir(newSaveGameDir, 0);
#endif


Should that 0 be 0755 instead?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Feb 2013, 00:12
Yes, thats a bug.
I checked a code quickly, in some cases mkdir for unix platforms is made with 755 mod, but in some cases it is made with 0 mod.

E: Well, right as you say.
Better search all project for mkdirs and do as in validate_user_file_path():
Code: C++
  1.       mkdir(output
  2. #if !defined (WINDOWS_VERSION)
  3.                   , 0755
  4. #endif
  5.       );
  6.  
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 00:30
I just did an ack scan of all the mkdir commands in the source and didn't find any other permissions errors.

All the checks in platform/linux/acpllnx.cpp are correct
All the checks in platform/windows/acplwin.cpp are Windows only calls, and don't matter
ac/file.cpp while technically correct, it's some fugly code. Not that way I would do it :)
ac/game.cpp is the only one the needs to be corrected.
Title: Re: AGS engine Linux port
Post by: s_d on 08 Feb 2013, 00:43
So it's disobeying umask?  Probably we could use umask() to set the process permissions mask for file and directory creation somewhere in the Linux port's initialization code (in an "#ifdef linux" section).
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 01:00
So it's disobeying umask?  Probably we could use umask() to set the process permissions mask for file and directory creation somewhere in the Linux port's initialization code (in an "#ifdef linux" section).

I don't think it's disobeying, it's specifically being told use 0.

http://www.gnu.org/software/libc/manual/html_node/Creating-Directories.html
Title: Re: AGS engine Linux port
Post by: s_d on 08 Feb 2013, 01:03
I don't think it's disobeying, it's specifically being told use 0.

Ah!  So, we simply need to make a platform-dependant define and drop that into the mkdir() and open() calls (set to zero on on-UNIX platforms).  Or do something a bit more clever where we query the current umask on UNIX platforms.  I'll play with that this evening once my family is asleep (my kid is currently crawling up my shoulder and singing "She'll be coming 'round the mountain when she comes..." ... hard to concentrate (laugh) ).
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Feb 2013, 07:25
Ah!  So, we simply need to make a platform-dependant define and drop that into the mkdir() and open() calls (set to zero on on-UNIX platforms).
Windows (or rather DOS) version of mkdir does not take any permission parameter at all.
I'd suggest keeping the style when there's a helper functions made for tasks, that require different implementations/default parameters on different platforms. Check Common/util/file.h&cpp, Common/util/path.h&cpp.
It is ok to put the quick fixes in place, where needed, for now though, if you need that really urgent.
Title: Re: AGS engine Linux port
Post by: s_d on 08 Feb 2013, 09:02
No, quick hacks are bad news.  They just build and build until nobody wants to fix it!  We can do it properly and I have no problem conforming to the style.  Staying awake right now... that's another issue entirely.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Feb 2013, 09:13
No, quick hacks are bad news.  They just build and build until nobody wants to fix it!  We can do it properly and I have no problem conforming to the style.
I just remembered I have a branch with directory helpers in my local repository, and all mkdir calls are replaced with custom CreateDirectory implementation. Did that a while ago, but could not find time to finish/test these. Probably something to do on current weekends.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 22:03
I'm working with Wadjet to figure out the rain on the GeminiRue menu. They were able to fix the rain sound effect, but I still don't see actual rain falling from the sky:

http://www.perturb.org/tmp/20130207_153430.mp4
http://www.perturb.org/tmp/no-rain.png

Was this a rain plugin that was used? Is that something that's going to be available on their Linux build.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Feb 2013, 22:25
Was this a rain plugin that was used? Is that something that's going to be available on their Linux build.
I don't know the situation around this release, but doesn't WE have game source? In that case you could check how this rain was run.
Secondly, you may test your build on Windows using the very same package (running game data file as an executable). Does it behave same way?
Title: Re: AGS engine Linux port
Post by: BigMc on 08 Feb 2013, 22:28
Janet already said here that they are using a rain module.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 22:30
She said to me:

Quote
The plugin to create rain (the SnowRain plugin) was indeed removed. BUT it was replaced by the SnowRain module which does EXACTLY the same thing. We absolutely would not remove the rain from Gemini Rue as it would irreparably damage the atmosphere of the game. So if you see rain missing, it is a very, very bad bug!

I wasn't sure if that module was in the Linux version of the engine.
Title: Re: AGS engine Linux port
Post by: BigMc on 08 Feb 2013, 22:31
Modules are written in AGS code and included in games, not in the engine.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Feb 2013, 22:36
I'll ask this again: does the game behaves like this only on Linux, or on Windows too when using our engine(!!)?
Does this problem persist if the game is compiled and run from the Editor (on Windows)?
This is important to know, if that's Linux port problem, or general bug in the engine.

I can provide you with Windows build of our engine if you need one.
Title: Re: AGS engine Linux port
Post by: BigMc on 08 Feb 2013, 22:40
I can provide you with Windows build of our engine if you need one.

Didn't you know that JJS already does this?
http://jjs.at/daily/
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 22:53
I just loaded the GeminiRue build in Windows and I do see rain. It's not displaying via our Linux engine though. If need be I can post the updated package I have.
Title: Re: AGS engine Linux port
Post by: BigMc on 08 Feb 2013, 22:57
And you used the Windows engine from the link I just posted?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 23:14
I reran the test... When I use the .exe provided from Wadjet I see rain on the main menu. If I use the acwin.exe nightly (2013-02-07) build you posted I do NOT see rain. Looks like something is wrong with the engine?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Feb 2013, 23:18
I reran the test... When I use the .exe provided from Wadjet I see rain on the main menu. If I use the acwin.exe nightly (2013-02-07) build you posted I do NOT see rain. Looks like something is wrong with the engine?

Yes, it does.

Is it possible for us to examine the game script and test the compiled beta? This way we will be able to see what game is supposed to do, and what engine does wrong.

Also, I would like to make this clear: does the rain not run only in main menu, on in the rest of the game too?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 23:34
Wadjet asked me not to post it publicly, so I PMd you the address of where the beta and the SnowRain code is. If anyone else would like to take a look at it PM me.

I didn't check the rain any where other than the main menu.
Title: Re: AGS engine Linux port
Post by: JJS on 08 Feb 2013, 23:40
I think I know why there is no rain. The engine contains stubs for plugin functions. The snow/rain module uses the same functions as the plugin I think. Probably the stubs override the modules functions.

The code that registers the stubs should be made conditional on whether the plugin is actually loaded. I never got around to do that :/

Check this: https://github.com/adventuregamestudio/ags/blob/master/Engine/plugin/global_plugin.cpp#L419
Commenting out all calls that register snowrain functions should do the trick for now.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 08 Feb 2013, 23:45
I commented out lines 420 through 441 in plugin/global_plugin.cpp (all the SnowRain stubs) and recompiled. Now I get rain on the main menu, I think that did the trick!
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Feb 2013, 23:45
Oh my... that one was simple. Thanks JJS. And I even haven't dled the package fully yet :D.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 09 Feb 2013, 03:12
I think the next thing I'd like to tackle is cleaning up all the warnings on the build process. My OCD doesn't like a non-clean build process :) What are all these errors?

Code: Adventure Game Studio
  1. In file included from ac/drawingsurface.cpp:507:0:
  2. ../Engine/script/script_runtime.h:58:13: warning:   initializing argument 2 of ‘bool ccAddExternalFunctionForPlugin(const char*, void*)' [-fpermissive]
  3. ac/drawingsurface.cpp:676:89: warning: invalid conversion from ‘void (*)(ScriptDrawingSurface*, int, int, int, int, int)' to ‘void*' [-fpermissive]
Title: Re: AGS engine Linux port
Post by: JJS on 09 Feb 2013, 08:19
That warning is because the second parameter is implicitly cast to void* for every call to ccAddExternalFunctionForPlugin(). Generally it is a good idea to reduce the warning count and especially to get the source to compile without compatibility settings (e.g. -fpermissive). In this case it is easy and harmless, some others might be more subtle and indicate an underlying bug. So just explicitly casting everything (which would silence a lot the warnings) is not helpful in the long run.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 09 Feb 2013, 13:27
That warning is because the second parameter is implicitly cast to void* for every call to ccAddExternalFunctionForPlugin(). Generally it is a good idea to reduce the warning count and especially to get the source to compile without compatibility settings (e.g. -fpermissive). In this case it is easy and harmless, some others might be more subtle and indicate an underlying bug. So just explicitly casting everything (which would silence a lot the warnings) is not helpful in the long run.
Are you saying that it'd be better to do the explicit cast with the warnings scottchiefbaker has indicated?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 09 Feb 2013, 14:13
No, don't cast everything in program, of course. Every case should be investigated on its own.
In the case of ccAddExternalFunctionForPlugin, this is intended behavior (the function pointer cast to void*, not the warning ;)). It should have expilcit cast (void*) there, something I just forgot to add.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 09 Feb 2013, 18:46
Alright, I pushed a fix for these ccAddExternalFunctionForPlugin calls, because it's my fault and they are just too annoying.

But no worries! There are still loads of warnings, so everyone can participate in their elimination. :)

BTW, JJS, will there be any change to plugin stubs registration?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 09 Feb 2013, 19:39
Wow that is a MUCH cleaner build... I love it. Still more work to go, but that's a great start. Good work!
Title: Re: AGS engine Linux port
Post by: JJS on 09 Feb 2013, 20:46
BTW, JJS, will there be any change to plugin stubs registration?
I pushed the change. Stubs are now only registered if the game tries to load the plugin and neither the plugin can be loaded nor a built-in plugin is found.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 15 Feb 2013, 18:04
No git updates since the 8th? Other than perhaps some build clean up, anything else outstanding before we do an official commercial release?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 15 Feb 2013, 18:19
Scratch that, there was an update on the 11th, my git was screwed up. I can't build today though:

Code: Adventure Game Studio
  1. main/version.cpp: In member functionvoid AGS::Engine::Version::MakeString()':
  2. main/version.cpp:66:72: error: cannot pass objects of non-trivially-copyable type ‘class AGS::Common::String' through ‘...'
  3. compilation terminated due to -Wfatal-errors.
  4. make: *** [main/version.o] Error 1
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 15 Feb 2013, 18:54
Can't believe I missed that. Fixed.

Other than that, I think I will increase version number. I just want to do this on Saturday, to test a bit more and make sure it does not prevent to load savegames and such.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 15 Feb 2013, 19:12
Looking at cleaning up the build process, what are these errors?

Code: Adventure Game Studio
  1. script/runtimescriptvalue.cpp: In member functionbool RuntimeScriptValue::WriteValue(const RuntimeScriptValue&)':
  2. script/runtimescriptvalue.cpp:314:101: warning: cast from ‘char*' to ‘int32_t {aka int}' loses precision [-fpermissive]
  3. script/runtimescriptvalue.cpp:338:58: warning: cast from ‘char*' to ‘int32_t {aka int}' loses precision [-fpermissive]
  4. script/runtimescriptvalue.cpp:357:90: warning: cast from ‘char*' to ‘int32_t {aka int}' loses precision [-fpermissive]
  5. script/runtimescriptvalue.cpp:361:90: warning: cast from ‘char*' to ‘int32_t {aka int}' loses precision [-fpermissive]
  6. script/runtimescriptvalue.cpp:366:80: warning: cast from ‘char*' to ‘int32_t {aka int}' loses precision [-fpermissive]
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 15 Feb 2013, 20:14
Looking at cleaning up the build process, what are these errors?
These are legacy issues, there are pointer types stored as 32-bit ints. I think these parts of code may be removed, because AFAIK they never run anymore.
But I need to check more carefully first.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 16 Feb 2013, 00:09
Can someone review/check-in this patch to alfont.c to clean up the build process a little. It's just some char** to const char** clean up.

http://www.perturb.org/tmp/alfont.patch
Title: Re: AGS engine Linux port
Post by: s_d on 16 Feb 2013, 08:15
Can someone review/check-in this patch to alfont.c to clean up the build process a little.

Ok, buddy, I did that for you;  pull request sent.  If JJS agrees, then it will merge cleanly to the tip.  :)
Title: Re: AGS engine Linux port
Post by: s_d on 16 Feb 2013, 08:21
JJS, I have a bug report from a Linux tester on the Quest for Infamy demo.  It seems, at first blush, that odd/unusual screen resolutions make the new auto-scaling code bug out:

Code: Adventure Game Studio
  1. AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1680 x 1050
  2. AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 384 x 240 anyway
  3. AGS: Attempt to switch gfx mode to 384 x 240 (32-bit)
  4. X Error of failed request:  BadValue (integer parameter out of range for operation)
  5.   Major opcode of failed request:  150 (XFree86-VidModeExtension)
  6.   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  7.   Value in failed request:  0x4e00003
  8.   Serial number of failed request:  87
  9.   Current serial number in output stream:  92

I haven't dug into it much further.  I cannot actually reproduce it myself, as none of my hardware is compatible with that resolution.  Perhaps it's just arithmetic.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 16 Feb 2013, 11:11
JJS, I have a bug report from a Linux tester on the Quest for Infamy demo.  It seems, at first blush, that odd/unusual screen resolutions make the new auto-scaling code bug out:

Code: Adventure Game Studio
  1. AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1680 x 1050
  2. AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 384 x 240 anyway
  3. AGS: Attempt to switch gfx mode to 384 x 240 (32-bit)
  4. X Error of failed request:  BadValue (integer parameter out of range for operation)
  5.   Major opcode of failed request:  150 (XFree86-VidModeExtension)
  6.   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  7.   Value in failed request:  0x4e00003
  8.   Serial number of failed request:  87
  9.   Current serial number in output stream:  92

I haven't dug into it much further.  I cannot actually reproduce it myself, as none of my hardware is compatible with that resolution.  Perhaps it's just arithmetic.
Do you know what scaling was used?
Title: Re: AGS engine Linux port
Post by: BigMc on 16 Feb 2013, 11:49
Should be 4x, but it does not matter.

The engine should not change the resolution, at least on Linux and Windows when auto scaling is enabled. I had a look at it, but it is harder than it sounds to do it without breaking anything.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 16 Feb 2013, 14:10
Can someone review/check-in this patch to alfont.c to clean up the build process a little.
Ok, buddy, I did that for you;  pull request sent.  If JJS agrees, then it will merge cleanly to the tip.  :)

JJS seem to be absent for few days, so I'll do that.

EDIT: I fixed the explanation below, because what I wrote first was very unsafe thing to do.

For the future: I suggest doing fixes in separate branch, like "master-fixes". In such case, if something goes wrong, you may create new branch and copy only partial changes there (using "Cherry-pick commit" git function), and delete the original.
If changes are already in 'master', you can always make a revert, which is basically a commit that totally negates the changes by any previous commit.

Also, if you were working locally, and your local branch became a bit "dirty", you may then do this trick:
* create temporary local branch and copy the correct changes there by using "Cherry-pick commit" Git function. Or by manual copying. in extreme cases.
* hard-reset your working branch back to the last proper commit.
* apply changes back from the temporary branch.
* delete temporary branch.

I think it is unsafe to do this will remote branch though.

Also, important thing is - if there were significant change in the main repo, simply merge changes from it to your personal branch, that will make your pull request valid again.
You may reference as many remote origins to your repository as you want, so they will be "visible", and you can merge them to your personal branches. It should be
Code: Adventure Game Studio
  1. git remote add <something>
, well, check the help. I used this several times.



UPD: Increased version number to 3.30.
Title: Re: AGS engine Linux port
Post by: s_d on 17 Feb 2013, 05:50
The engine should not change the resolution, at least on Linux and Windows when auto scaling is enabled. I had a look at it, but it is harder than it sounds to do it without breaking anything.

When you say "should not change the resolution" do you mean that would like it not to, or that it is an error for that to occur?  I'm assuming the former, not the latter.  Also, I'm not really sure why I addressed that to JJS (brain fart on my part).
Title: Re: AGS engine Linux port
Post by: s_d on 17 Feb 2013, 07:51
JJS seem to be absent for few days, so I'll do that.

Thanks from Scott (by proxy)  :)

For the future: I suggest doing fixes in separate branch, like "master-fixes".

Aye, aye, Captain Wizard.  However you want it done ;-D

I've worked with half a dozen different SCM branch/merge models in the past decade, each with advantages and disadvantages, and there is very little I feel strongly about, provided a few things are in place.  One (as of recently) is distributed version control, which we have here with Git, and another is some kind of "gatekeeping" or curation on the official repository (which we have with a small group of JJS, you, BigMC, etc).  It would be nice to have continuous integration and nightly builds on all ports, but that requires infrastructure which requires money and volunteerism.  That one is great for regression testing, as well as pointing fingers when someone breaks the build on one of the ports, and helps make bisecting the offending changeset more simple.  Anyway, this was a cosmetic change authored by someone else, so I'm kind of digressing now  :P

Also, important thing is - if there were significant change in the main repo, simply merge changes from it to your personal branch, that will make your pull request valid again.

Since I was unsure of the procedure I simply cloned the repo freshly, expressly for the purpose of this changeset, applied the patch, committed it to my github clone, and then issue the pull request directly from github.  Unless I was in the unlikely situation that someone was merging into the mainline at the same time, then would not my pull request be guaranteed valid?  At any rate, am I to understand that this is *not* what you want?

Yes, I'm certainly aware that such a workflow is unnecessarily tedious for any real work on the AGS interpreter, but I've yet to accomplish any  ;)

Right now, I'm trying to discover the auto-scaling bug which is causing Quest for Infamy to crash on resolution change for a person in the Infamous Quests community.  He's able to play the demo by going to windowed mode instead, but I'd like to resolve any problems with auto-scaling that I can find.  That feature is very nice on Linux, and it is good that it is the default.  Just need to squash all the bugs...
Title: Re: AGS engine Linux port
Post by: s_d on 17 Feb 2013, 08:45
Should be 4x, but it does not matter.

The engine should not change the resolution, at least on Linux and Windows when auto scaling is enabled. I had a look at it, but it is harder than it sounds to do it without breaking anything.

Oh, also, another bug reporter claimed that the HqNx filters bug out really badly on full-screen.  I've confirmed that bug (he's on an AMD card using the open-source radeon driver running 64-bit Slackware 14, and I'm on an Intel integrated adapter on Ubuntu 12.04).  In this particular case (Quest for Infamy), they're not advising use of (or expecting to support) the smoothing filters at all, so it's not critical for this game.  It is, however, a bug.  The only things in common between his setup and mine are the game under test, and the fact that both of us are running in a 64-bit environment.  The bug does not trigger on a 32-bit Linux VM.

Here are screenshots of what I mean by "bugging out":

Spoiler: ShowHide
(http://filesmelt.com/dl/qfi-demo1.png)

Spoiler: ShowHide
(http://filesmelt.com/dl/qfi-demo2.png)


Please forgive me if this is a known issue.
Title: Re: AGS engine Linux port
Post by: BigMc on 17 Feb 2013, 10:25
The engine should not change the resolution, at least on Linux and Windows when auto scaling is enabled. I had a look at it, but it is harder than it sounds to do it without breaking anything.

When you say "should not change the resolution" do you mean that would like it not to, or that it is an error for that to occur?  I'm assuming the former, not the latter.  Also, I'm not really sure why I addressed that to JJS (brain fart on my part).

The problem is that if you just make up some bogus resolution and try to change the screen resolution to that (that is basically what AGS does), then on Windows Allegro just says it won't work and AGS tries something different, while on Linux Allegro tries to do it and crashes.

The bug has nothing to do with auto-scaling, which is just selecting a filter automatically.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 17 Feb 2013, 12:59
The problem is that if you just make up some bogus resolution and try to change the screen resolution to that (that is basically what AGS does), then on Windows Allegro just says it won't work and AGS tries something different, while on Linux Allegro tries to do it and crashes.
This sounds like there is a need of "CheckIfSupported" function (or "GetSupportedResolutions")? Maybe Allegro has one.
Title: Re: AGS engine Linux port
Post by: BigMc on 17 Feb 2013, 19:26
For the task of switching resolutions, yes I think a resolution should be selected from a list of supported resolutions, rather than being guessed. To be clear, this list must come from the OS, not from within AGS. But even if Allegro can provide such a list, there is still the problem that on Linux Allegro won't reliably switch the resolution back to what is was before upon quitting. And since we can avoid switching resolutions with filters, we should do it.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 18 Feb 2013, 18:35
Now that we have a 3.30, can I get a build of ags+binaries using that? Has anyone be able to setup a simple build system that could give us nightlies? I'm not an expert with Debian buildroots or I'd attempt it myself.
Title: Re: AGS engine Linux port
Post by: BigMc on 18 Feb 2013, 21:42
http://people.debian.org/~thansen/ags+libraries_20130218.tar.xz

It's no problem for me to update this if someone asks, but I don't have a good way to provide daily builds.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 18 Feb 2013, 21:54
It's no problem for me to update this if someone asks, but I don't have a good way to provide daily builds.

Ok... as long as it's not a big hassle for you to build every so often, as features land. Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding? I think the autoscale is in a pretty good place now right?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 18 Feb 2013, 21:54
On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?
Title: Re: AGS engine Linux port
Post by: BigMc on 18 Feb 2013, 21:59
Autoscale is fine, but changing to unsupported resoltions and crashing is still there. It depends on the combination of screen resolution and filter used.

On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?

Don't know.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 18 Feb 2013, 22:52
Autoscale is fine, but changing to unsupported resoltions and crashing is still there. It depends on the combination of screen resolution and filter used.

Are we still switching resolutions, or does it leave the resolution alone, and just pick the appropriate scale factor? I'm confused.
Title: Re: AGS engine Linux port
Post by: BigMc on 18 Feb 2013, 22:58
All I did was making sure an appropriate filter is selected. I didn't change the code that sets the video mode and that code still selects a resolution in questionable ways.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 18 Feb 2013, 23:02
All I did was making sure an appropriate filter is selected. I didn't change the code that sets the video mode and that code still selects a resolution in questionable ways.

For the reasons you mentioned, we probably do NOT want it to switch resolutions when using auto scale? We should probably ONLY change the resolution when the user picks both fullscreen and a specific scale value?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 18 Feb 2013, 23:03
Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding?
Well, I did not have any plans on that. I've switched working in a separate branch (develop) already, further cleaning/factoring the code.
Unless there are bugs or any issues preventing people from playing the game, I think it is ok to use current version.

On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?
No idea. But, frankly, I'd won't do that as a last-time update. As you may have already noticed, resolution stuff is pretty fragile in AGS.
In my vision, whole thing should be carefully investigated and documented first.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 18 Feb 2013, 23:07
Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding?
Well, I did not have any plans on that. I've switched working in a separate branch (develop) already, further cleaning/factoring the code.
Unless there are bugs or any issues preventing people from playing the game, I think it is ok to use current version.

On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?
No idea. But, frankly, I'd won't do that as a last-time update. As you may have already noticed, resolution stuff is pretty fragile in AGS.
In my vision, whole thing should be carefully investigated and documented first.
At this stage it might be worthwhile to re-write the whole thing. If the (eventual) plan is to switch to Allegro 5 (or something else), it'll likely become necessary anyway.
Title: Re: AGS engine Linux port
Post by: BigMc on 18 Feb 2013, 23:20
If someone with more patience than me wants to give the resolution issue a go: There is also another way to deal with it, namely to make the OpenGL backend JJS wrote for the mobile platforms ready for Linux. In that case AGS draws in whatever resolution it wants to a virtual screen which is stretched to the screen by OpenGL. I'm sure this will also increase speed.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 18 Feb 2013, 23:21
If someone with more patience than me wants to give the resolution issue a go: There is also another way to deal with it, namely to make the OpenGL backend JJS wrote for the mobile platforms ready for Linux. In that case AGS draws in whatever resolution it wants to a virtual screen which is stretched to the screen by OpenGL. I'm sure this will also increase speed.

That seems like the ideal solution. Probably something we should shoot at for the next version?
Title: Re: AGS engine Linux port
Post by: s_d on 19 Feb 2013, 00:32
For the task of switching resolutions, yes I think a resolution should be selected from a list of supported resolutions, rather than being guessed. To be clear, this list must come from the OS, not from within AGS. But even if Allegro can provide such a list, there is still the problem that on Linux Allegro won't reliably switch the resolution back to what is was before upon quitting. And since we can avoid switching resolutions with filters, we should do it.

I think that filtering for the closest supported resolution would be the quickest fix to avoid a crash bug (which is my worst reported Linux issue).  It does nothing, as BigMC astutely notes, to solve the problem of reliably restoring the original resolution, but perhaps it is worth me trying to fix now, rather than waiting what could be weeks or months to rewrite or port a bunch of backend code in.  It appears that the OGLGraphicsDriver::IsModeSupported() and OGLGraphicsDriver::FindSupportedResolutionWidth() functions aren't actually trying to query or filter anything (IsModeSupported returns true, and FindSupportedResolutionWidth returns whatever you pass in, for example).  Is that how they are built?

Also, is Linux using OGLGraphicsDriver or ALSoftwareGraphicsDriver?

At any rate, without a way to actually test an odd resolution from my home (right now) it will be tough to validate, but I'll try to run it by our bug reporters.

If someone with more patience than me wants to give the resolution issue a go: There is also another way to deal with it, namely to make the OpenGL backend JJS wrote for the mobile platforms ready for Linux. In that case AGS draws in whatever resolution it wants to a virtual screen which is stretched to the screen by OpenGL. I'm sure this will also increase speed.

We have had reports of performance issue.  Perhaps it is related to this.  Interestingly, the reporter stated that when using the HqNx filters, the performance improved, which was surprising to me since I assumed that they do more work.  I'm not terribly familiar with that section of the code, but
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 19 Feb 2013, 00:44
Linux is using ALSoftwareGraphicsDriver.
Portable devices are using ALSoftware and OpenGL drivers.
Windows allows all three, although it does not allow to set OpenGL it in config (there's an automatic selection algorythm which I do not know well).

Spoiler: ShowHide

Code: C++
  1. void create_gfx_driver()
  2. {
  3. #ifdef WINDOWS_VERSION
  4.     if (stricmp(usetup.gfxDriverID, "D3D9") == 0)
  5.         gfxDriver = GetD3DGraphicsDriver(filter);
  6.     else
  7. #endif
  8.     {
  9. #if defined(IOS_VERSION) || defined(ANDROID_VERSION) || defined(WINDOWS_VERSION)
  10.         if ((psp_gfx_renderer > 0) && (game.color_depth != 1))
  11.             gfxDriver = GetOGLGraphicsDriver(filter);
  12.         else
  13. #endif
  14.             gfxDriver = GetSoftwareGraphicsDriver(filter);
  15.     }
  16.  
  17.     gfxDriver->SetCallbackOnInit(GfxDriverOnInitCallback);
  18.     gfxDriver->SetTintMethod(TintReColourise);
  19. }
  20.  
  21.  
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 19 Feb 2013, 00:48
AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1680 x 1050
AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 384 x 240 anyway
AGS: Attempt to switch gfx mode to 384 x 240 (32-bit)

How/where are you getting this information? When I run ags on GeminiRue I don't see the output you're mentioning. Is there some debug mode I'm not using?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 19 Feb 2013, 00:58
AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1680 x 1050
AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 384 x 240 anyway
AGS: Attempt to switch gfx mode to 384 x 240 (32-bit)

How/where are you getting this information? When I run ags on GeminiRue I don't see the output you're mentioning. Is there some debug mode I'm not using?
This information should be printed in console (at Linux), and also in "agsgame.log".
The former is true for the latest build, there was a commit which updated debug output several days ago. But cvonsole output should have worked before, I think.
Title: Re: AGS engine Linux port
Post by: s_d on 19 Feb 2013, 01:41
How/where are you getting this information? When I run ags on GeminiRue I don't see the output you're mentioning. Is there some debug mode I'm not using?

Produced on the console, even from a stripped release build.
Title: Re: AGS engine Linux port
Post by: s_d on 19 Feb 2013, 02:00
Linux is using ALSoftwareGraphicsDriver.

Thanks CW!

Ok, interesting.  Either something fishy is going on, or the Allegro get_gfx_mode_list() function isn't working.  ALSoftwareGraphicsDriver::IsModeSupported() seems to be implemented and being used in ALSoftwareGraphicsDriver::Init().

Spoiler: ShowHide

Code: C++
  1. bool ALSoftwareGraphicsDriver::IsModeSupported(int driver, int width, int height, int colDepth)
  2. {
  3. #if defined(ANDROID_VERSION) || defined(PSP_VERSION) || defined(IOS_VERSION)
  4.   // Everything is drawn to a virtual screen, so all resolutions are supported.
  5.   return true;
  6. #endif
  7.  
  8.   if (_windowed)                                                                    
  9.   {
  10.     return true;            
  11.   }
  12.   if (_gfxModeList == NULL)
  13.   {
  14.     _gfxModeList = get_gfx_mode_list(driver);
  15.   }
  16.   if (_gfxModeList != NULL)    
  17.   {
  18.     // if a list is available, check if the mode exists. This prevents the screen flicking
  19.     // between loads of unsupported resolutions
  20.     for (int i = 0; i < _gfxModeList->num_modes; i++)
  21.     {
  22.       if ((_gfxModeList->mode[i].width == width) &&                                            
  23.         (_gfxModeList->mode[i].height == height) &&
  24.         (_gfxModeList->mode[i].bpp == colDepth))        
  25.       {
  26.         return true;
  27.       }
  28.     }
  29.     strcpy(allegro_error, "This graphics mode is not supported");
  30.     return false;      
  31.   }
  32.   return true;
  33. }  
  34.  


...and then...
Spoiler: ShowHide

Code: C++
  1. bool ALSoftwareGraphicsDriver::Init(int width, int height, int colourDepth, bool windowed, volatile int *loopTimer)
  2. {
  3.   _screenWidth = width;
  4.   _screenHeight = height;
  5.   _colorDepth = colourDepth;
  6.   _windowed = windowed;
  7.   _loopTimer = loopTimer;
  8.   int driver = GetAllegroGfxDriverID(windowed);
  9.  
  10.   set_color_depth(colourDepth);
  11.   int actualInitWid = width, actualInitHit = height;
  12.   _filter->GetRealResolution(&actualInitWid, &actualInitHit);
  13.  
  14.   if (_initGfxCallback != NULL)
  15.     _initGfxCallback(NULL);
  16.  
  17.   if ((IsModeSupported(driver, actualInitWid, actualInitHit, colourDepth)) &&
  18.       (set_gfx_mode(driver, actualInitWid, actualInitHit, 0, 0) == 0))
  19.   {
  20.     // [IKM] 2012-09-07
  21.     // set_gfx_mode is an allegro function that creates screen bitmap;
  22.     // following code assumes the screen is already created, therefore we should
  23.     // ensure global bitmap wraps over existing allegro screen bitmap.
  24.  


I see a bit of you in there, CW  :-D

Why would not strange resolutions be rejected?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 19 Feb 2013, 02:02
Produced on the console, even from a stripped release build.

Oh duh... I wasn't seeing the switch messages because I was running -windowed.
Title: Re: AGS engine Linux port
Post by: s_d on 19 Feb 2013, 06:47
Yeah, it's important to test in full-screen mode sometimes, too.  In fact, the only bugs reported on QFI so far have been 1) ALSA not set up properly in acsetup.cfg 2) full-screen crash or image corruption.
Title: Re: AGS engine Linux port
Post by: BigMc on 19 Feb 2013, 09:11
s_d, most of the iffy stuff goes on in graphics_mode.cpp.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 19 Feb 2013, 13:48
1) ALSA not set up properly in acsetup.cfg

Can you elaborate?
Title: Re: AGS engine Linux port
Post by: s_d on 19 Feb 2013, 18:15
s_d, most of the iffy stuff goes on in graphics_mode.cpp.

Ok, thanks.  I'll look in there and see how sad it makes me  ;)
Title: Re: AGS engine Linux port
Post by: s_d on 19 Feb 2013, 18:51
1) ALSA not set up properly in acsetup.cfg

Can you elaborate?

Certainly.

A tester on 64-bit Slackware 14 reported:

Quote
1. Audio didn't work for me, i use alsa and has no pulseaudio.
Checking sound inits.
AGS: Initialize sound drivers
Unable to initialize your audio hardware.
[Problem: No supported synth type found]

... and also ...

Quote
3. The game crashed.
AGS: Loading room 1
An error has occurred. Please contact the game author for support, as this is likely to be a scripting error and not a bug in AGS.
(ACI version 3.21.1115)
Error: Error running function 'room_Load':
Error: Null pointer referenced
AGS: ***** ENGINE HAS SHUTDOWN
AGS: Debug system: shutting down output subsystem... ()
It also dies trying to load room 39 and room 28.

One of IQ's gameplay engineers (chucklas, FYI) immediately recognized the source of the problem:

Quote
I have a pretty good idea as to why it is crashing in those rooms.  I believe it has something to do with the music errors you referred to previously.  When those rooms load, it checks what track is currently playing, and if you couldn't initilize the sound drivers that could result in the crash.

The tester checked out his MIDI setup (something, by the way, that our GUI acsetup configurator will be easily able to probe), and properly configured DIGIMID:

Quote
The problem was that i had no midi device since it's an internal sound card (codec).
"aplaymidi -l" does show midi support but there's no /dev/midi0X so i needed to add digiid.

Code: INI
  1. [misc]
  2. gamecolordepth=16
  3. titletext=Quest for Infamy Demo 2.0
  4. windowed=1
  5. gfxfilter=Hq2x
  6. [sound]
  7. digiid=1
  8. midiid=0
  9.  

Is there anywhere i can find valid options for acsetup.cfg and explanations of them?

With properly probed & set up audio configuration prior to game launch, most folks on ALSA without Pulse will be well-served, as those running Pulse now already are.  There is always the chance of really lacking MIDI support, in which case it would be good for the engine to simply not crash (and not play any audio), but I would consider that task to be very low priority.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 22 Feb 2013, 08:08
Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding?

Ah. We need to add CHANGES.TXT. Chris Jones had one, but it was not included to the SVN, as it seems. We may take latest from the 3.2 release package.


MUCH LATER EDIT:
Also, our Copyright.txt sais "Copyright (C) 1999-2012"
Title: Re: AGS engine Linux port
Post by: BigMc on 22 Feb 2013, 18:09
These things are more relevant for an AGS release. Or do you think about doing a beta AGS release?
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 22 Feb 2013, 18:12
These things are more relevant for an AGS release. Or do you think about doing a beta AGS release?

Do we want to clean up the build process a bit before we look at an "official" release? There are still quite a few warnings on compile.
Title: Re: AGS engine Linux port
Post by: BigMc on 22 Feb 2013, 18:18
Getting rid of compiler warnings doesn't necessarily fix real bugs. When you keep talking about this it sounds like there are no more important things to do.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 22 Feb 2013, 18:25
Do we want to clean up the build process a bit before we look at an "official" release? There are still quite a few warnings on compile.
Many of those warnings existed in AGS for years, I think.
I don't mean they should not be fixed, but, on other hand, they don't prevent a release.

These things are more relevant for an AGS release. Or do you think about doing a beta AGS release?
I was thinking merely about adding a human(end-user)-readable changelog to the repository.
Title: Re: AGS engine Linux port
Post by: BigMc on 22 Feb 2013, 18:28
I was thinking merely about adding a human(end-user)-readable changelog to the repository.

I'm thinking that is a very good idea.
Title: Re: AGS engine Linux port
Post by: s_d on 22 Feb 2013, 23:10
Do we want to clean up the build process a bit before we look at an "official" release? There are still quite a few warnings on compile.

Nah.  Those aren't customer facing, and very likely have little impact on the stability of the engine.  I would consider that a low-level background task.

I would consider crash bugs number 1 priority, and then graphical/audio artifacts or script interpreter bugs (any of those left?) as number 2 priority.  And after those, a proper setup utility, especially for non-PulseAudio sound device setup, since lack of audio init can crash games.  We can probe for PulseAudio, and if it's not there, check if ALSA is presenting a MIDI device, and index DIGIMID for it.  After covering PulseAudio and bare ALSA, that's nearly everyone (EsounD & aRtsd are almost dead, and JACK is mostly pro-audio, but has an Allegro plugin, so it probably wouldn't be too hard to support, just not high on my list).

By the way, regarding that setup tool, I did contact Electroshokker, and he replied that he's willing to give us that, pending CJ's permission.  Electroshokker is of the opinion that the sources he has are bound to the old (closed) license.  So, I PM'd CJ here, about two weeks ago, but no reply.  Does he come around still?  His last post was in January.
Title: Re: AGS engine Linux port
Post by: s_d on 24 Feb 2013, 09:47
s_d, most of the iffy stuff goes on in graphics_mode.cpp.

Along these lines, is it just me, or is init_gfx_mode() actually recursive?  Surely a loop would be more straightforward?  Especially since it appears this is where I'd be filtering (somehow? or probing?) for exotic resolution modes, and potentially fixing them up before whacking them into X.

Here's my take on the issue;  basically, it looks like we (or at the very least, Allegro) takes heavy advantage of an undocumented feature.  Or rather, undocumented, but compatible, resolution modes.  You can, of course, query your X display to print a list of compatible modes (for example, "xrandr --query"), but the list will be incomplete.  It will have none of the nice resolutions near 320x200 that we want.

So what do we do?  We calculate a scalar, apply it to the current resolution to calculate a target display mode, and just give it a shot.  More often than not, the display mode happens to be valid (in that the graphics driver supports it somehow).  I'm not sure why that is.  Anyway, we're not the only ones... apparently that's done elsewhere in the software world, as well.  Where we fall down here is that when X returns back the "unsupported mode" return code, we choke rather than doing... well, anything.

In fact, it would be better (in this case) to continue at the current resolution and skip the mode switch altogether!  But, I think, loads of things are already calculated by this point, and thusly it would be quite difficult to go fix them all up after the fact.   Which comes back to needing to somehow properly detect a bogus display resolution.  From a little research (now that I can access Wadjet Eye's beta bug reports) I see that 1680x1050 is not actually that uncommon of a display resolution for Linux users.  With further research, I've learned that it was actually a very popular display resolution for high-end gaming laptops (15.4"-17" panels) between 2003-2006.  Which is why so many appear to be running Linux now.

What I also learned is that others running that resolution are *not* crashing!  That certainly complicates matters.

Anyway, hopefully I'm not annoying you folks too much with my rambling... just thinking out loud (or in paragraphs, actually).
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 24 Feb 2013, 14:02
Along these lines, is it just me, or is init_gfx_mode() actually recursive?
Yes..... but I guess you haven't yet seen the parts with "goto" jumps up from "while" loop?

I see that 1680x1050 is not actually that uncommon of a display resolution for Linux users.  With further research, I've learned that it was actually a very popular display resolution for high-end gaming laptops (15.4"-17" panels) between 2003-2006.
It is also the resolution I am using right now on my desktop!

Anyway, hopefully I'm not annoying you folks too much with my rambling... just thinking out loud (or in paragraphs, actually).
The only thing that annoys me - and sorry for being so frank - is when people talk but not do. I hope you are not just telling us what's wrong, but planning to find an actual solution meanwhile ;).
Title: Re: AGS engine Linux port
Post by: s_d on 24 Feb 2013, 18:07
The only thing that annoys me - and sorry for being so frank - is when people talk but not do. I hope you are not just telling us what's wrong, but planning to find an actual solution meanwhile ;).

Yes, I am, of course.  I don't mean to criticize code quality, I'm just puzzled by CJ's intent, in some places.  I was hoping, rather than being pointed to even more mind-gobbling abuse of C, I might occasionally benefit from your insight into some of the weirdness.  But, of course, someone had to suffer first, and had no help, so I could do so as well.  Also, there isn't any while-loop escapism occurring in graphics_mode.cpp, where I'm looking now.  :)

I've only spent hardly a month in the code (plus a few weeks last summer building bero's port for a fan game project).  I'm trying to devise an adequate solution for these mode switching crashes on Linux.  I'm a little stuck right now when I learned that it's not the display mode specifically;  it appears that other Linux users, and indeed yourself, are able to play games in the full-screen scaled resolution mode for 1680x1050 (the one calculated in engine_init_gfx_filters() ).  So, the failure may be per-driver, per-adapter or something else.

I'm starting to understand why BigMC wants to eliminate the mode switching, though (in addition to not reliably switching back if the game crashes).  If we can't know ahead of time whether or not the mode switch is going to crash, then that makes this a sticky problem, indeed.  So, right now, my focus is to find a good method of discovering supported modes.  Also, I don't know Allegro very well either, so I'm studying that, too.

Perhaps just keep to myself until I have patches, then?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 24 Feb 2013, 18:20
I don't mean to criticize code quality, I'm just puzzled by CJ's intent, in some places.
I think the reason is very simple: these pieces were written by less experienced coder (and maybe hacked later to save time). If you compare different parts of engine, and, especially, new editor, you will notice a significant change in style and code quality between them. Engine bears legacy code from 1998.

Also, there isn't any while-loop escapism occurring in graphics_mode.cpp, where I'm looking now.  :)
https://github.com/adventuregamestudio/ags/blob/master/Engine/ac/dialog.cpp#L549
https://github.com/adventuregamestudio/ags/blob/master/Engine/ac/invwindow.cpp#L181
:)

Perhaps just keep to myself until I have patches, then?
Well, the thing is, there are very few people actualy working on the engine, and our work has been pretty separated so far, everyone keeping to its own task. It is a bit difficult to refer to everything... I mean, it would be nice if someone could help you, but I don't think it will be me, because I am pretty much focused on different things now.
Title: Re: AGS engine Linux port
Post by: BigMc on 24 Feb 2013, 19:03
So, right now, my focus is to find a good method of discovering supported modes.

Well there's Allegros get_gfx_mode_list(). But after another look at ali3dsw.cpp, I found that every mode is expected to work when get_gfx_mode_list() fails to supply the supported modes. Maybe the crashes are caused by the last 'return true' in the following code?

Code: Adventure Game Studio
  1. bool ALSoftwareGraphicsDriver::IsModeSupported(int driver, int width, int height, int colDepth)
  2. {
  3. #if defined(ANDROID_VERSION) || defined(PSP_VERSION) || defined(IOS_VERSION)
  4.   // Everything is drawn to a virtual screen, so all resolutions are supported.
  5.   return true;
  6. #endif
  7.  
  8.   if (_windowed)
  9.   {
  10.     return true;
  11.   }
  12.   if (_gfxModeList == NULL)
  13.   {
  14.     _gfxModeList = get_gfx_mode_list(driver);
  15.   }
  16.  
  17.   if (_gfxModeList != NULL)
  18.   {
  19.     // if a list is available, check if the mode exists. This prevents the screen flicking
  20.     // between loads of unsupported resolutions
  21.     for (int i = 0; i < _gfxModeList->num_modes; i++)
  22.     {
  23.       if ((_gfxModeList->mode[i].width == width) &&
  24.         (_gfxModeList->mode[i].height == height) &&
  25.         (_gfxModeList->mode[i].bpp == colDepth))
  26.       {
  27.         return true;
  28.       }
  29.     }
  30.     strcpy(allegro_error, "This graphics mode is not supported");
  31.     return false;
  32.   }
  33.   return true;
  34. }
Title: Re: AGS engine Linux port
Post by: s_d on 25 Feb 2013, 00:28
It is a bit difficult to refer to everything... I mean, it would be nice if someone could help you, but I don't think it will be me, because I am pretty much focused on different things now.

All very reasonable.  That's why I was "wondering out loud".  If someone sees something that rings a bell, then they could mention it, and otherwise ignore it.  Nobody should ever feel compelled to spend time helping me out, just if it's convenient the knowledge happens to be loaded in their local cache  ;)
Title: Re: AGS engine Linux port
Post by: s_d on 25 Feb 2013, 00:42
Well there's Allegros get_gfx_mode_list(). But after another look at ali3dsw.cpp, I found that every mode is expected to work when get_gfx_mode_list() fails to supply the supported modes. Maybe the crashes are caused by the last 'return true' in the following code?

Yes, I found the same thing, but it's worse than that.  I just learned that get_gfx_mode_list() always returns a null list for any GFX_SAFE type, GFX_AUTODETECT type, or any other "magic" Allegro driver.

Code: C++
  1. int ALSoftwareGraphicsDriver::GetAllegroGfxDriverID(bool windowed)
  2. {
  3. #ifdef _WIN32
  4.   if (windowed)
  5.     return GFX_DIRECTX_WIN;
  6.   return GFX_DIRECTX;
  7. #else
  8.   if (windowed)
  9.     return GFX_AUTODETECT_WINDOWED;
  10.   return GFX_AUTODETECT_FULLSCREEN;
  11. #endif
  12. }
  13.  

I'm not positive that GFX_AUTODETECT_* count as magic drivers, but I think it would be safe to assume so, since I just tested this, and sure enough, _gfxModeList is null.  We need another method (preferably standard to X) of discovering the modes.  I'm researching this now  :)
Title: Re: AGS engine Linux port
Post by: s_d on 25 Feb 2013, 06:32
BigMC, it appears that the crash here:

Code: Adventure Game Studio
  1. AGS: Attempt to switch gfx mode to 384 x 240 (32-bit)
  2. X Error of failed request:  BadValue (integer parameter out of range for operation)
  3.   Major opcode of failed request:  150 (XFree86-VidModeExtension)
  4.   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)

...is fundamentally caused because the Allegro auto-detect driver has no clue how to respond to X errors.  I read over the list of available Allegro graphics drivers, and saw that there is a native X windows driver (GFX_XWINDOWS).

So, I thought to try it out, and it Works For MeTM, including a properly returned list of modes.  I authored an awful patch on my github (https://github.com/s--d/ags/commit/2cc9298d231c79a41fe36deda03f1b987c7d919e) with some additional debugging (I co-opted the editor debugging options to add a verbosity control).  Now, the recursive mode-switching behaviour occurs, where the X mode-switch calls occur, and when the return failed, it iterates over the candidate resolutions and seems to finally settle on one:

Code: Adventure Game Studio
  1. AGS: Switching to graphics mode
  2. AGS: Widescreen side borders: game resolution: 320 x 200; desktop resolution: 1366 x 768
  3. AGS: Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)
  4. AGS: Attempt to switch gfx mode to 320 x 200 (16-bit)
  5. AGS: Failed, resolution not supported
  6. AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1366 x 768
  7. AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 426 x 240 anyway
  8. AGS: Attempt to switch gfx mode to 426 x 240 (16-bit)
  9. AGS: Failed, resolution not supported
  10. AGS: Attempt to switch gfx mode to 320 x 240 (16-bit)
  11. AGS: Failed, resolution not supported
  12. AGS: Widescreen side borders: game resolution: 320 x 200; desktop resolution: 1366 x 768
  13. AGS: Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)
  14. AGS: Attempt to switch gfx mode to 320 x 200 (15-bit)
  15. AGS: Failed, resolution not supported
  16. AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1366 x 768
  17. AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 426 x 240 anyway
  18. AGS: Attempt to switch gfx mode to 426 x 240 (15-bit)
  19. AGS: Failed, resolution not supported
  20. AGS: Attempt to switch gfx mode to 320 x 240 (15-bit)
  21. AGS: Failed, resolution not supported
  22. AGS: 320x200 not supported, trying with 2x filter
  23. AGS: Widescreen side borders: game resolution: 320 x 200; desktop resolution: 1366 x 768
  24. AGS: Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)
  25. AGS: Attempt to switch gfx mode to 320 x 200 (16-bit)
  26. AGS: Failed, resolution not supported
  27. AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1366 x 768
  28. AGS: Widescreen side borders: enabled, attempting resolution 320 x 240
  29. AGS: Attempt to switch gfx mode to 320 x 240 (16-bit)
  30. AGS: Succeeded. Using gfx mode 320 x 240 (16-bit)

I think this more like how it was intended to probe.

In addition to mangling the revision history of my github, this probably probably isn't "pull-request" quality code, but I'd appreciate a second set of eyes to peek at it before I try to send a build out to a tester.  Most of all, I'd like to see how a machine exhibiting this crash works with the X driver, and with "-verbose" so I can see it iterate over the available modes.
Title: Re: AGS engine Linux port
Post by: BigMc on 25 Feb 2013, 22:21
Allegros documentation says that get_gfx_mode_list() does not guarantee a result, so switching to another driver is still a hack. A better solution would be not to switch resolutions if there is no list of supported resolutions.
Title: Re: AGS engine Linux port
Post by: s_d on 25 Feb 2013, 23:31
Allegros documentation says that get_gfx_mode_list() does not guarantee a result, so switching to another driver is still a hack. A better solution would be not to switch resolutions if there is no list of supported resolutions.

Yeah.  You're right  :(

Should we allow it to probe the available resolutions (using the X windows driver), since it can at least properly catch the failure return codes, but upon reaching the end of the list unsuccessfully (or if the list is empty) stop it from switching?

EDIT:  On second thought, after looking through the mode fetching code, it looks like XF86VidModeGetAllModeLines() is used to query X for the modelines, and further, the only failures states for Allegro returning that list are if it cannot alloc a buffer for the list.  I think XF86VidMode is no longer an extension, but is now built into Xorg from 2010 or so, and further, if it were missing, then XF86VidModeSwitchToMode wouldn't be supported anyway.  I agree it is a hack, but the more I look, the more it seems like a hack which also is an incremental improvement.  The mode list returned should always contain at least one mode, the current mode.
Title: Re: AGS engine Linux port
Post by: BigMc on 26 Feb 2013, 22:54
I'm not objecting to any changes, I'm just advising. :)
Title: Re: AGS engine Linux port
Post by: s_d on 27 Feb 2013, 01:15
I'm not objecting to any changes, I'm just advising. :)

Ah, OK.  Thanks, it's super helpful!

The thing is, I only have one report of "crash on launch" and it's obvious that only the unsupported resolution was attempted.  It is probable that other modes were available, maybe compatible ones, but the first one AGS guessed was wrong.  My understanding is that major differences between the two drivers are XWINDOWS will make X calls to request mode lines, and has a handler for XF86VidModeSwitchToMode() failure return codes (also some caveat regarding hardware cursors), because the "magic" driver is going to use the underlying XWINDOWS driver, anyway.  But it chokes on a bad mode switch and bang, engine quits.  Anyway it's hard to contact this tester (he hasn't responded to me) and I have no other way to reproduce it because AGS is working well everywhere else.  Of course, that's the usual thing with random internet testers :)

So, what I will do is try to prepare a "pretty" patch using the X windows driver.  I will to make it refuse to switch modes if none are returned by get_gfx_mode_list().  A couple of opinions;  do you think it would be good to return false from IsModeSupported() only for Linux?  Right now the mobile ports return early.  Does Windows (or old OS X) need that return true?  Do you think it's worth plumbing up an undocumented "try anyway, shoot yourself in the foot" option to permit blind mode-switching?  I don't know for sure if this behavior is needed somewhere.
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Feb 2013, 13:10
So, what I will do is try to prepare a "pretty" patch using the X windows driver.  I will to make it refuse to switch modes if none are returned by get_gfx_mode_list().  A couple of opinions;  do you think it would be good to return false from IsModeSupported() only for Linux?  Right now the mobile ports return early.  Does Windows (or old OS X) need that return true?  Do you think it's worth plumbing up an undocumented "try anyway, shoot yourself in the foot" option to permit blind mode-switching?  I don't know for sure if this behavior is needed somewhere.

So you will implement the possibility to keep the desktop resolution? Because right now if IsModeSupported() always reports false somewhere (because there is no list of supported modes), then the engine won't start at all, right?
Title: Re: AGS engine Linux port
Post by: s_d on 27 Feb 2013, 21:26
So you will implement the possibility to keep the desktop resolution? Because right now if IsModeSupported() always reports false somewhere (because there is no list of supported modes), then the engine won't start at all, right?

Well, what choice do I have? :)

Of course Init() will fail (causing init_gfx_mode() to return, and eventually initialize_engine() returns, causing an AGS early exit), but I must somehow satisfy the feature of not requiring a mode switch if none is compatible.

We can either quit (gracefully?) with an AGS error informing the user that no compatible display mode ("Failed, resolution not supported"), which is not the same thing as an improperly handled internal X error, or I can figure out some way to display the game in the middle of the screen in it's native resolution (which is almost certainly smaller than the desktop display resolution).  I'm not really sure how to accomplish that, yet, but I at least have to try.
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Feb 2013, 21:47
We can either quit (gracefully?) with an AGS error informing the user that no compatible display mode ("Failed, resolution not supported"), which is not the same thing as an improperly handled internal X error,
It is effectly the same: AGS won't work in fullscreen mode for people who are affected.

Ok, that can maybe improved by changing the driver, but we are talking about changing the return value of IsModeSupported() now.
Quote
or I can figure out some way to display the game in the middle of the screen in it's native resolution (which is almost certainly smaller than the desktop display resolution).  I'm not really sure how to accomplish that, yet, but I at least have to try.
We still have StdScale filters and the possibility to select a matching one.
Title: Re: AGS engine Linux port
Post by: s_d on 27 Feb 2013, 22:23
Ok, that can maybe improved by changing the driver, but we are talking about changing the return value of IsModeSupported() now.

Most definitely.  There is no specific reason why the first attempted resolution would happen to be supported, but without changing the driver, it will not try any others.  The next one in the list could have worked!

We still have StdScale filters and the possibility to select a matching one.

In the tester's log output, I don't see the "Automatic scaling: disabled" message printed, so a candidate scaling factor was calculated.  I'll work on this for a while and see what I can do to apply it while in desktop resolution (for starters I'll try skipping engine_init_graphics_mode() and see what happens).
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Feb 2013, 22:31
There is no specific reason why the first attempted resolution would happen to be supported, but without changing the driver, it will not try any others.  The next one in the list could have worked!

But when we talk about changing the return value of IsModeSupported(), we talk about the case where no list of available modes is available and in that case it does not matter how many resolutions are tried, all will fail.
Title: Re: AGS engine Linux port
Post by: s_d on 27 Feb 2013, 22:48
Before I split the IsModeSupported() test away from set_gfx_mode(), I need to do some testing to be sure I haven't broken other things.  Or, another way I could start would be to hardcode the modelist to NULL on my machine and proceed from there until I can make it properly stay in my desktop resolution, with the correct scaling factor.
Title: Re: AGS engine Linux port
Post by: BigMc on 27 Feb 2013, 23:16
I suggest the scaling should stay as it is. Autoscaling only if no scaling is explicitly selected.
Title: Re: AGS engine Linux port
Post by: s_d on 27 Feb 2013, 23:30
Ok, so how about this.  I'll hardcode my modelist returned to NULL, and work on it until native game resolution is working (both with QFI at 320x240@32bpp which I'm trying to support for IQ, and Gemini Rue at 320x200@16bpp for Wadjet Eye's beta) no scaling at all, on my test machines in fullscreen mode.  Then, I will try get it working with autoscaling (to support the mode you built for no gfxfilter supplied).  Hopefully I won't make the code too ugly  :)
Title: Re: AGS engine Linux port
Post by: s_d on 28 Feb 2013, 02:46
Home from work now!  I've got _gfxModeList hardcoded to null, IsModeSupported() returning false, and am working on making it work anyway.  It is quitting out as expected, so I'm all set.  Wish me luck!  :)
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 06 Mar 2013, 16:44
Everyone still alive? Been awfully quiet around here lately.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Mar 2013, 17:02
Everyone still alive? Been awfully quiet around here lately.
And what we were supposed to do here? :)
s_d is working on resolution problem.
I am making an experimental build with Allegro 5 (not related to Linux).
Are there any news from Gemini Rue beta-testing?
Title: Re: AGS engine Linux port
Post by: s_d on 06 Mar 2013, 17:46
As CW says, I'm still working on the resolution switch problem.  The two major issues reported at QFI were crashes due to resolution or missing audio configuration.  I have a PM out to Pumaman about the nice setup utility from 2.X;  Electroshokker is totally on-board with sharing code, but needs his approval first (Pumaman hasn't visited here in a couple months though).  I can add to the GUI some automatic ALSA/DIGIMID index detection.  Could redo from scratch, but I really dislike GUI programming, and would much rather hack/refactor someone else's working GUI.

Full-screen resolution launch crash will be mostly covered by the Allegro driver switch, but BigMC has some confidence that we need to have a fall-back mode when no modes are detected.  I strongly respect his opinion, and am pursuing that with all my attention.  When I finish, then it's on to the setup util (hopefully CJ says yes).

CW, BigMC;  the changes to avoid mode switch require slightly more refactor than I'm comfortable with for an impending release. I suggest you only accept the driver change to GFX_XWINDOWS for 3.30.  This is a tiny patch, low risk, and it has the potential to bring playability to many more configurations (e.g., all boxes with compatible resolution that just happens not to be probed first).

What do you guys think?  If yes, then I'll prepare a pull request so you can pull the trigger on 3.30.

For the other part of the work, I will continue with my refactor, but maybe it will be better for me to co-ordinate that with your Allegro abstraction work, CW?  I don't want to get in your way though.
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Mar 2013, 21:06
CW, BigMC;  the changes to avoid mode switch require slightly more refactor than I'm comfortable with for an impending release. I suggest you only accept the driver change to GFX_XWINDOWS for 3.30.  This is a tiny patch, low risk, and it has the potential to bring playability to many more configurations (e.g., all boxes with compatible resolution that just happens not to be probed first).

I'm fine with that. The only other driver is GFX_XDGA2 and that requires root permissions, so it isn't an option anyway.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Mar 2013, 21:55
I'm fine with that.

Ok, great.  I'm at work now, but when I'm home, I will try to use a fix-branch as CW requested, and you/he/JJS could cherry-pick the revision.  I want to work with you guys the way that helps you the most  :)

The only other driver is GFX_XDGA2 and that requires root permissions, so it isn't an option anyway.

Well, yes root is bad, but compared to one major trouble you've highlighted, specifically unreliable mode switching back to the original mode, I'm quite certain that the failure mode using DGA is much worse.  Rather than leaving you in an unpleasantly tiny mode, you're scribbling directly onto internal X frame-buffer memory*, so the failure mode is trashing the X client, not just leaving the desktop in a bad state.  Much better that the grumpy player can log out and then back to get back to normal, than having X windows locked up (or worse, the kernel) :(

This way, at least, if the player's setup has mode detection and switching features, they will be reliable and properly handled.

EDIT:  *Oops, by "internal frame-buffer", I mean, "directly on video card memory".  Same outcome, though.
Title: Re: AGS engine Linux port
Post by: s_d on 09 Mar 2013, 23:17
CW, at long last, I've finally figured out how to clean up the fine hash I'd made of my master branch.  I think I have a functional branch & fix strategy (thanks for the advice back in mid-February, that is all working well now, I think).

All this for a three line patch on my new "linux-fixes" branch: https://github.com/s--d/ags/commit/a92b4b040ae449ef46e2c8886ff4cc30dfcb76cc (https://github.com/s--d/ags/commit/a92b4b040ae449ef46e2c8886ff4cc30dfcb76cc)

That should get mode list probing and mode switching errors to be handled properly.  Again, I'm terribly sorry for making everyone wait, but now I think I'm set up to work with you guys more cleanly.  With patches like this one, and future ones in a fix branch, should I still submit pull requests to you from it, or would you rather a different way to fetch specific commits?

Also, I've noticed your naming convention for commit messages, and probably should always put "Engine: ..." since that's where I'll work.  I'll remember to do that.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 10 Mar 2013, 14:26
Well, we were not in a big hurry, anyway, I think.
Any comments from other linux users on this patch?
I am still interested to hear about Gemini Rue status. Did they finish the beta test?


With patches like this one, and future ones in a fix branch, should I still submit pull requests to you from it, or would you rather a different way to fetch specific commits?
I don't know, we don't have an established rule for that, just some habits. I found it is simplier to make very small changes directly to "main" branch, and big changes that would require number of commits to the separate branch. Also, I think that it is not convenient to keep the "fix" branch for the future, because you will have to update it from master, practically creating parallel branch. The only parallel branch we should have is "develop".
Well, I made a note about branches here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912

Also, I've noticed your naming convention for commit messages, and probably should always put "Engine: ..." since that's where I'll work.  I'll remember to do that.
That was JJS's convention, he used to name commits like "Android:" or "Linux:" :)
Title: Re: AGS engine Linux port
Post by: JJS on 10 Mar 2013, 15:25
Any comments from other linux users on this patch?
It's pretty awesome I'd say. Mode switching for fullscreen now works on my Linux Mint and unsupported graphic modes properly return failure.

The only downside I could see is that running AGS without X will now always fail I guess. But since a) nobody does that and b) the Allegro 4.4 Debian package does not contain the framebuffer driver anyway, it doesn't really matter.
Title: Re: AGS engine Linux port
Post by: Sslaxx on 10 Mar 2013, 16:03
Any comments from other linux users on this patch?
It's pretty awesome I'd say. Mode switching for fullscreen now works on my Linux Mint and unsupported graphic modes properly return failure.

The only downside I could see is that running AGS without X will now always fail I guess. But since a) nobody does that and b) the Allegro 4.4 Debian package does not contain the framebuffer driver anyway, it doesn't really matter.
You saying framebuffer support under Linux should officially be removed (if it was ever really there or "official" in the first place) then? Makes sense.
Title: Re: AGS engine Linux port
Post by: s_d on 10 Mar 2013, 22:37
I am still interested to hear about Gemini Rue status. Did they finish the beta test?

My post with the test version of my patch is the last one, and received no PMs there.  I think (unfortunately for me) the Linux users are happy with the latest build enough that they're off thoroughly playing through Gemini Rue.  (laugh)  There are a couple of folks with outstanding issues, nearly all of which are related to the known PulseAudio corruption issue.  It is reportedly exacerbated by switching focus out of the game in windowed mode. That one has become "real" enough that I'm convinced to file an issue in our tracker (I've made video clips to illustrate the problem and such).  I can probably reproduce it, but it's going to be another research project to figure out how to actually root-cause the problem (from personal experience, I have a suspicion that the browser Flash plugin/player is guilty of same sin as well).  PulseAudio has some debugging features I can try out (and of course, sources are opened so I can lose my brain in that code also).

The way Wadjet Eye's beta 2 is distributed, the acsetup.cfg has a commented-out line setting gfxfilter to StdScale4, and instructions to uncomment it if the game crashes out.  I think the next build we give scottchiefbaker will solve the fullscreen problem for beta participants, but they apparently won't test it until Janet announces it, so I hope they will do another round of beta with my fix.

I don't know, we don't have an established rule for that, just some habits...
...
That was JJS's convention, he used to name commits like "Android:" or "Linux:" :)

I like habits & conventions better than hard-and-fast rules.  That said, I want to work with you folks in whatever way is most convenient (including diving into an ugly spaghetti mess that nobody else wants to touch  ;) ).  I like his convention, and will try to use it in the future.
Title: Re: AGS engine Linux port
Post by: s_d on 10 Mar 2013, 23:09
Any comments from other linux users on this patch?
It's pretty awesome I'd say. Mode switching for fullscreen now works on my Linux Mint and unsupported graphic modes properly return failure.

Wow, thanks!  It's incredible to me how much time and research it took to wrap my head around, and properly test, what amounted to a four-line patch.  But now, I have a 32-bit build chroot and test VM to do basic validation, so I should be able to accomplish further improvements.

The only downside I could see is that running AGS without X will now always fail I guess. But since a) nobody does that and b) the Allegro 4.4 Debian package does not contain the framebuffer driver anyway, it doesn't really matter.
You saying framebuffer support under Linux should officially be removed (if it was ever really there or "official" in the first place) then? Makes sense.

I see what you guys are saying here.  I should have thought of that.

I disagree that nobody does this, however.  For example, on embedded Linux gaming devices (Pandora, GP2X, GCW Zero) they do not use X11.  Now, granted, while the install base on those devices is very small, it could be argued that AGS games are a tiny niche of the larger gaming world, so I'd prefer not to simply "compile out" these folks.  Testing will become a burden eventually, but it is possible that a member of this community will step up, and maybe learn from JJS's work on PSP to design a proper gamepad-like control scheme for those platforms.

Plumbing an option through to the Makefile would be trivial.  I'll do that patch and send a pull request, which you could (of course) reject if you wish.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 11 Mar 2013, 00:14
Uhhhh... I don't get anything what people say here about XWindows, framebuffers and stuff. Was that sarcasm? You guys gotta be careful... I thought you agree with patch, so I merged the pull request. Did I do right or wrong?  (wtf)
Title: Re: AGS engine Linux port
Post by: s_d on 11 Mar 2013, 00:33
It's all good buddy  :)

They are happy, and the patch is good.

I've another patch just about ready to send, which will permit a compile-time option to restore the original behavior.  Basically, my first patch is great for desktop Linux users, but potentially not so nice for a (tiny) group of embedded Linux gamers, folks on old Linux distributions, or power users who hack the crap out of their install.  My second patch will allow the user to pass "ALLEGRO_MAGIC_DRV=1" to Make, and it will produce a version created the old way.  The level of support we provide for that feature, however, will depend on a dedicated community member.  It's ability to function may bitrot, otherwise.  We're basically all OK with this.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 12 Mar 2013, 07:22
I've another patch just about ready to send, which will permit a compile-time option to restore the original behavior.
Is it the proper thing to do? Can't the program test that XWindows first, and auto-driver later, when the first fails?
Title: Re: AGS engine Linux port
Post by: s_d on 12 Mar 2013, 08:32
No, I don't think that's a good idea.  I could do it, but if you peek at that area of graphics_mode.cpp, (engine_init_graphics_mode()->switch_to_graphics_mode()->init_gfx_mode()), I think you'll agree that it is hard to see how adding another loop around that whole initialization dance is going to make the code any better  :(

It already looks pretty fragile there, and there are a couple of gfxDriver related inits that occur before it.  The compile-time define is a pretty clean way to prevent things getting worse, I think.  The whole mode-selection strategy needs a serious refactor... what I've begun to do is to diagram a generic state machine to accomplish the goal that the current algorithm does.

So, that mode-selection strategy is either A) totally the wrong way to do it, or B) way simpler in intention than the code that implements it today.  Or, worst case, it is the way it is because it works around unusual corner-cases in a port I cannot test (such as Windows).  That possibility is what scares me the most about refactoring  :(

One central problem with that is that it's hard to know whether or not the X driver failed, except to exhaust the mode list returned by the driver.  I don't know for sure what way the Allegro X driver errors out when no X11 server is present.  Even then, the whole idea of preserving a way to use non-X11 mode (basically VGA mode 13h) is pretty much to service a whole different set of people.  I think the way it is now, with the first patch, is the right way going forward for all Linux desktops.  The alternate mode, which someone could choose to build using the compile-time directive, builds an interpreter for a different group of folks.  Those people, in general, are not running games on a desktop or laptop, but on an embedded Linux device (also, they may have to port the main Linux build to ARM).

So, doing the above described double initialization hack (try X and then try auto) significantly increases the complexity of an already buggy section, just to provide functionality to a small group who probably do not want it probing for X windows anyway (since their embedded device is almost certainly a low-power, possibly underclocked, mobile CPU).  :)
Title: Re: AGS engine Linux port
Post by: s_d on 18 Mar 2013, 03:32
Man, I really hope we can get in touch with Pumaman... I just noticed that Electroshokker's Linux ags-setup already does auto-detect for audio, which is precisely the feature I was most interested in implementing!

http://www.adventuregamestudio.co.uk/forums/index.php?topic=37968.msg501047#msg501047

Does anyone have a postal address for him?  At this rate, I could have posted a letter to him by now... (laugh)
Title: Re: AGS engine Linux port
Post by: AGA on 18 Mar 2013, 13:34
CJ says it's okay.  If Electroshokker is reading this, CJ is fine with you releasing this.
Title: Re: AGS engine Linux port
Post by: s_d on 18 Mar 2013, 17:14
Thanks, AGA!  I've replied to Electroshokker via PM, and CC'ed you and CJ, as well.  Hopefully we can get me going with this code without bothering anyone else  (nod)
Title: Re: AGS engine Linux port
Post by: s_d on 23 Mar 2013, 06:06
A couple of updates;  first, CJ himself has replied to me, and CC'd Electroshokker (who generously offered to spend some time to dig up his copy of the sources).  So, after he provides those, I'll get it building (for libraries circa glibc version 2.13), and then bring it into a Github pull request, with some instructions, etc.  So, that was really good news  :)

Second, I've built a new distributable ags+libraries (hopefully for another round of beta in the various communities running these).  Primarily, this contains the Allegro driver change and CW's new version numbering changes (SHA 3175c1a511da7f5cfb0f428d7308e6e933cb148 6).  The best place I have to host it freely is on Google Drive.

EDIT:  Link removed.
Title: Re: AGS engine Linux port
Post by: BigMc on 23 Mar 2013, 09:09
Second, I've built a new distributable ags+libraries

Great! Was the process documented well enough? Did you make sure to build the 32 bit executable with rpath "lib32"? If you use the debian stuff to build in a chroot, that works by setting the  environment variable DEB_BUILD_OPTIONS=rpath=lib32
Title: Re: AGS engine Linux port
Post by: Sslaxx on 26 Mar 2013, 16:54
Dunno if anyone else has had this happen to them, but AGS has stopped compiling for me using Raring (Ubuntu 13.04), saying "make: *** No rule to make target `/usr/include/c++/4.7/i686-linux-gnu/bits/c++config.h', needed by `libsrc/hq2x/hq2x3x.o'. Stop." - http://ubuntuforums.org/showthread.php?t=2129526&p=12574958 is the thread related to the issue on the Ubuntu forums.
Title: Re: AGS engine Linux port
Post by: BigMc on 26 Mar 2013, 17:10
build-essential is installed right?

EDIT: There's just /usr/include/c++/4.6/i686-linux-gnu/bits/c++config.h and /usr/include/i386-linux-gnu/c++/4.7/bits/c++config.h. Does make distclean; ./configure fix it?
Title: Re: AGS engine Linux port
Post by: Sslaxx on 26 Mar 2013, 17:14
build-essential is installed right?
Yup. It compiled just fine until last night. Raring is still in development, so it could easily be an error of omission on Ubuntu's part in their package changes. Of course, it could also be part of other package changes, which could mean having to find out what dependency/ies have to be installed to fix it. So long as it isn't something being removed, I guess.
Title: Re: AGS engine Linux port
Post by: BigMc on 26 Mar 2013, 17:20
Forget distclean. I forgot that this is a custom Makefile. Looks like a Ubuntu fuckup.
Title: Re: AGS engine Linux port
Post by: MrProsser on 21 Apr 2013, 07:27
I decided I wanted to check out the Linux port today and earlier on I was trying to build the Linux engine under lubuntu 12.10. I kept running to a problem. When I run make --directory=Engine I get an error telling me that allegro.h does not exist.
Quote
libsrc/alfont-2.0.9/alfont.c:14:21: fatal error: allegro.h: No such file or directory

Should this be included with ags? Or do I have to get it myself somehow? I have liballegro4.4.
Title: Re: AGS engine Linux port
Post by: BigMc on 21 Apr 2013, 08:05
You have to install liballegro4.2-dev. Please read debian/README.md.
Title: Re: AGS engine Linux port
Post by: MrProsser on 21 Apr 2013, 08:27
Shoot, it was a stupid thing. I had originally installed 4.2 when going through the readme, but I missed the fact that the dev one was required.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 21 Apr 2013, 15:03
Also see: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47590.0 for more build instructions.
Title: Re: AGS engine Linux port
Post by: BigMc on 21 Apr 2013, 20:57
liballegro4.2-dev contains the dev files of Allegro 4.4.
Title: Re: AGS engine Linux port
Post by: Cheeseness on 02 May 2013, 09:13
Hi fellow Linux shaped devpersons.

I'm packaging an AGS title for Linux for a friend of mine (who'd prefer that the title wasn't publicly announced for Linux prematurely), and I've been encountering audio issues with Pulse (which I've seen mention of in this thread) with my builds. I'd like to resolve these before we start broader testing and would consider an interim workaround if anybody's got any ideas (using padsp to force alsa doesn't help, and I haven't had much luck with any cfg settings either).

It sounds like the resolution for this that's currently being pursued is the Allegro5 port which Crimson Wizard and s_d (?) have been talking about. I have a tiny bit of allegro experience, but I don't feel like I have enough familiarity with how AGS' innards work to try tracking this down, and I don't have enough availability to sink my teeth into the Allegro5 porting effort. I can certainly offer encouragement though :D

So far I've been using Allegro4.4. I've noticed that some are talking about 4.2 - are there any know issues with 4.4 and AGS that I might have missed?


I also read a few pages back that people had been working on config generation scripts (and trying to get ahold of source for a UI?). I had planned to make something quick and dirty using Zenity, but if there's other stuff in the works, I might be able to throw a little time at helping things move forward.

Cheese
Title: Re: AGS engine Linux port
Post by: xenogia on 02 May 2013, 13:04
I noticed that the anti-aliasing option under the Linux engine doesn't work.  Is there any reason why this doesn't work? Or is it just not implemented?
Title: Re: AGS engine Linux port
Post by: BigMc on 02 May 2013, 20:47
I think antialiasing is provided by DirectX on Windows and if it works on mobile platforms then by OpenGL. The Linux engine uses software rendering.
Title: Re: AGS engine Linux port
Post by: JJS on 02 May 2013, 21:30
Antialiased sprite drawing is also available for the software renderer. I made a quick test and it works for me on Linux (tried with Pleurhburg and Ben Jordan 8) when I force the option via the acsetup.cfg file.
Title: Re: AGS engine Linux port
Post by: xenogia on 03 May 2013, 00:18
Interesting it didn't work for me when I had the game display at x2 with Antialiasing enabled via the winsetup.exe program.  The reduced scaled sprites looked considerably uglier than when loading it up in Wine.
Title: Re: AGS engine Linux port
Post by: xenogia on 03 May 2013, 10:36
I just realised what I'm talking about is not just anti-aliased sprites. But the whole filter.


Code: Adventure Game Studio
  1. gfxfilter=AAx3


Considering as you said it is a software render this isn't possible at all.


EDIT: Also to note - there is no vSync on AGS games under Linux.  I notice tearing during fade in and out transitions and in some animations.  Though if I run the game under Wine there is no tearing at all.
Title: Re: AGS engine Linux port
Post by: s_d on 06 May 2013, 07:52
Sorry to go off the ranch for so long, people.  It was because of Stuff & Things.   :(

No code from Electroshokker yet, but I don't want to push him very hard (he may have Stuff & Things as well).  I'll send another gentle nudge and hope he doesn't become upset.

Second, I've built a new distributable ags+libraries

Great! Was the process documented well enough? Did you make sure to build the 32 bit executable with rpath "lib32"? If you use the debian stuff to build in a chroot, that works by setting the  environment variable DEB_BUILD_OPTIONS=rpath=lib32

Man, BigMC... I totally messed up the RPATH setting!!  Many apologies.  Discovering what I did wrong there led me down a rathole to discover that I'd had some linking funny business all along... namely, I was linking to both A4.2 and A4.4 at the same time (?!).  At any rate I massaged both of my build roots (32 & 64) and believe that all is correct now, according to 1) ldd, 2) objdump, 3) testing.

URL: https://docs.google.com/file/d/0B6N-Dop3H_3IaG0tWF9vM2JtalU/edit

Thusly, I would be ever so grateful if you would give these a test-drive on Wheezy for me (we don't support Squeeze, right?).  I'm running Gentoo (by choice) & Ubuntu (for game dev) and currently have no Debian boxen set up for testing (nor Fedora, but I'm pretty comfortable with scottchiefbaker testing the RH-flavoured distros).
Title: Re: AGS engine Linux port
Post by: s_d on 06 May 2013, 08:24
Hey, Cheese, what's up?  :)

I'm packaging an AGS title for Linux for a friend of mine (who'd prefer that the title wasn't publicly announced for Linux prematurely), and I've been encountering audio issues with Pulse (which I've seen mention of in this thread) with my builds. I'd like to resolve these before we start broader testing and would consider an interim workaround if anybody's got any ideas (using padsp to force alsa doesn't help, and I haven't had much luck with any cfg settings either).

It sounds like the resolution for this that's currently being pursued is the Allegro5 port which Crimson Wizard and s_d (?) have been talking about. I have a tiny bit of allegro experience, but I don't feel like I have enough familiarity with how AGS' innards work to try tracking this down, and I don't have enough availability to sink my teeth into the Allegro5 porting effort. I can certainly offer encouragement though :D

So far I've been using Allegro4.4. I've noticed that some are talking about 4.2 - are there any know issues with 4.4 and AGS that I might have missed?

Ooh, exciting!  Another title!

Regarding the Pulseaudio corruption issue, yes, it is (sort of) known.

What are you running?  What is the nature of your Pulse glitches? The reports are of simultaneously distorted audio and playback speed.  Does that sound familiar?  I have a couple of video clips from GR and The Shivah demo I've been meaning to put up on YouTube for reference.  Everyone who has encountered the corruption bug (who I've been able to get to try it) has successfully reset their audio by restarting Pulse ("pulseaudio -k").  It has been reported that the problem is exacerbated in "windowed" mode by switching window focus out of the game (during gameplay), especially into another program using Pulse (for me, switching to a browser running flash does it almost every time... a fact that I can use to reproduce the problem for debugging/fixing purposes).

We have no reason to think that A5 will do anything to help this whatsoever, as it doesn't seem like an A4/Pulseaudio problem specifically (nobody is reporting this issue on other A4 Linux games).  Personally, I think it is 80% something we're doing, and 20% a Pulseaudio corner-case (which has, by the way, been reported to no longer occur on Ubuntu 12.10, which would be good to verify). A5 is mostly for the Mac port (and a little future-proofing in general).  Ideally, CW & I (and anyone else willing, who can do) would abstract the graphics, audio, and control API's enough to even make Allegro replaceable. Recently, I've had some personal challenges, and frustratingly, my work there has not progressed as I've wanted.  I am committed to working on it, though.

I also read a few pages back that people had been working on config generation scripts (and trying to get ahold of source for a UI?). I had planned to make something quick and dirty using Zenity, but if there's other stuff in the works, I might be able to throw a little time at helping things move forward.

Well, Electroshokker built this:  http://www.adventuregamestudio.co.uk/forums/index.php?topic=37968.msg501047#msg501047

...which apparently worked really well, and properly configured DIGIMID for ALSA (one bug report came from a Slackware user who was Pulse-free... setting up the proper DIGIMID index in the acsetup.cfg fixed his wagon).  I'm fairly content to continue porting forward the util, once code appears.

scottchiefbaker has a simple generator script in-place for the Gemini Rue beta which may be sufficient until we have a GUI.  Perhaps he'll share it with you?

Title: Re: AGS engine Linux port
Post by: BigMc on 06 May 2013, 21:17
Thusly, I would be ever so grateful if you would give these a test-drive on Wheezy for me (we don't support Squeeze, right?).

I'll do that next week. The only reason this might not work on Squeezy is the lower libc version 2.11 vs. 2.13.
Title: Re: AGS engine Linux port
Post by: Cheeseness on 07 May 2013, 13:17
Hey, Cheese, what's up?  :)
Small world, hey? :D

I'm packaging an AGS title for Linux for a friend of mine
Ooh, exciting!  Another title!
If all goes well, it'll be two titles :)

What are you running?  What is the nature of your Pulse glitches?

I'm currently running Fedora 17 32 bit on my main desktop and building stuff from a 64 bit Wheezy VM.

The issue I've been encountering can best be described as crackly audio (I'll see if I can get a recording of an example during the week). I had previously encountered sped up audio, but I haven't seen that for a while (and can't recall what I did to trigger it). I've had similar crackly audio issues with a number of titles in Wine which normally go away with a pulseaudio -k, and of course in the Gemini Rue beta.

We have no reason to think that A5 will do anything to help this whatsoever, as it doesn't seem like an A4/Pulseaudio problem specifically (nobody is reporting this issue on other A4 Linux games)... Recently, I've had some personal challenges, and frustratingly, my work there has not progressed as I've wanted.  I am committed to working on it, though.
Yeah, OK. I'd gotten the wrong impression from your post in the second Gemini Rue beta thread. I can see now that what you were saying about the issue was unrelated to the A5 migration.

Totally with you on the frustration front. We'd first started talking about packaging the project I'm helping out with on back in December, but due to a number of unforseen and unrelated circumstances, we had a number of false starts and it's taken till now to actually move forward with it. Don't feel bad - we do what we can.

I also read a few pages back that people had been working on config generation scripts (and trying to get ahold of source for a UI?). I had planned to make something quick and dirty using Zenity, but if there's other stuff in the works, I might be able to throw a little time at helping things move forward.

Well, Electroshokker built this:  http://www.adventuregamestudio.co.uk/forums/index.php?topic=37968.msg501047#msg501047

...which apparently worked really well, and properly configured DIGIMID for ALSA (one bug report came from a Slackware user who was Pulse-free... setting up the proper DIGIMID index in the acsetup.cfg fixed his wagon).  I'm fairly content to continue porting forward the util, once code appears.

Ah, so that's what was being discussed. Already sounds a lot more sophisticated than the quick hack I was looking at putting together.

scottchiefbaker has a simple generator script in-place for the Gemini Rue beta which may be sufficient until we have a GUI.  Perhaps he'll share it with you?
Could be worth taking a peek at. If you're keen, get in touch, scottchiefbaker :)


Thusly, I would be ever so grateful if you would give these a test-drive on Wheezy for me (we don't support Squeeze, right?).

Runs nicely on my F17 install. 0.5 sec worth of crackly sound when starting the title I'm packaging, but it comes right every time. It also seems to recover happily from switching focus after a second or so of crackly audio.

On my Wheezy VM, I get crackly audio no matter what I try (the same issues I'd been experiencing with my own build). I don't have a proper install to test on at the moment though.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 09 May 2013, 00:07
For what it's worth I run AGS on Fedora 17 and Fedora 18 both 64 bit, three different machines, and haven't had any audio crackling. Some users HAVE reported it though, I suspect a driver issue incompatibility with AGS/Allegro, but I'm not 100% sure. I haven't seen it enough to test.

What type of audio do you have? Any other audio issues on your system?
Title: Re: AGS engine Linux port
Post by: s_d on 09 May 2013, 05:48
The issue I've been encountering can best be described as crackly audio (I'll see if I can get a recording of an example during the week).

I got around to uploading to YouTube my instances of it:




I had previously encountered sped up audio, but I haven't seen that for a while (and can't recall what I did to trigger it). I've had similar crackly audio issues with a number of titles in Wine which normally go away with a pulseaudio -k, and of course in the Gemini Rue beta.

Am I to understand, then, that restarting Pulse no longer eliminates the current incarnation of your audio corruption?

Runs nicely on my F17 install. 0.5 sec worth of crackly sound when starting the title I'm packaging, but it comes right every time. It also seems to recover happily from switching focus after a second or so of crackly audio.

On my Wheezy VM, I get crackly audio no matter what I try (the same issues I'd been experiencing with my own build). I don't have a proper install to test on at the moment though.

This is good info, thanks.  It's probably fairly instructive that the glitch traverses distros, but follows Pulseaudio.  I can reproduce this at will on my test setup.  All that's left is the hard part :P (figuring out how to properly debug the problem).
Title: Re: AGS engine Linux port
Post by: s_d on 09 May 2013, 05:55
For what it's worth I run AGS on Fedora 17 and Fedora 18 both 64 bit, three different machines, and haven't had any audio crackling. Some users HAVE reported it though, I suspect a driver issue incompatibility with AGS/Allegro

Great!  Thanks for testing it.  I really want a good level of confidence in that new build I posted.

Since it's so intermittent, and Cheese has stated that he observes it in F17, and you do not, I'm thinking that it's a race-condition of some sort, perturbed by the usual suspects (CPU speed & other concurrent userspace activity).  That would be consistent with our other test reports (who either experience it, or never do, on Ubuntu 12.04LTS as well).
Title: Re: AGS engine Linux port
Post by: Cheeseness on 10 May 2013, 14:44
What type of audio do you have? Any other audio issues on your system?
I'm running a Creative Audigy 2 Platinum Ex. Never really had any issues beyond a couple of Wine games (like Rage and Orcs Must Die 2) having this crackly audio thing from time to time (quitting and running pulseaudio -k has always sorted it out). My partner encounters it when playing Dead Island as well. I think she's running onboard audio (looks to be an intel chipset).

The issue I've been encountering can best be described as crackly audio (I'll see if I can get a recording of an example during the week).
I got around to uploading to YouTube my instances of it:
Yep, that's it.

Am I to understand, then, that restarting Pulse no longer eliminates the current incarnation of your audio corruption?
With your build, pulseaudio -k doesn't fix it on my Wheezy VM. With my build, it doesn't fix it on my desktop :D
In all other cases a pulseaudio -k dies help (until it happens again).

This makes me wonder whether there's something I could be doing during my build process (I'm pretty much just using the ags+libraries script), or whether the bundled deps themselves are causing issues.

Runs nicely on my F17 install. 0.5 sec worth of crackly sound when starting the title I'm packaging, but it comes right every time. It also seems to recover happily from switching focus after a second or so of crackly audio.

On my Wheezy VM, I get crackly audio no matter what I try (the same issues I'd been experiencing with my own build). I don't have a proper install to test on at the moment though.

This is good info, thanks.  It's probably fairly instructive that the glitch traverses distros, but follows Pulseaudio.  I can reproduce this at will on my test setup.  All that's left is the hard part :P (figuring out how to properly debug the problem).
It's also interesting to note that my Wheezy VM is running from a MacBook Air rather than my F17 desktop.
Title: Re: AGS engine Linux port
Post by: SKYY on 03 Jun 2013, 20:10
I have a galaxy note, and for some reason every build has an issue with cursor placement being about 80 to 100 pixels lower than the actual stylus press. Is there any way to fix this?
Title: Re: AGS engine Linux port
Post by: BigMc on 03 Jun 2013, 21:37
Which Linux distribution?
Title: Re: AGS engine Linux port
Post by: s_d on 04 Jun 2013, 03:02
Galaxy Note is an Android phone/tablet... maybe they need the Android porting thread (http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.0) instead?

Cheeseness;  thank you for the valuable input!  I'm working on all of this, and will report back when I have more information.
Title: Re: AGS engine Linux port
Post by: JanetC on 04 Jun 2013, 21:56
Hi all,

Wadjet Eye has now got a programmer (not me) working on porting the Mac and Linux AGS engine so that we can commercially release Gemini Rue on those platforms. I know that the Linux build is in pretty good shape, but what needs doing at the moment apart from the crackly audio issues?

Thanks!
Title: Re: AGS engine Linux port
Post by: Snarky on 04 Jun 2013, 22:56
Hey, nice to see Wadjet Eye expanding, but honestly, I think your kid is too young to start programming Mac/Linux ports.  :)
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Jun 2013, 23:21
Hey, nice to see Wadjet Eye expanding, but honestly, I think your kid is too young to start programming Mac/Linux ports.  :)
He may approve the code by tasting it though  :P
Title: Re: AGS engine Linux port
Post by: s_d on 04 Jun 2013, 23:42
Wadjet Eye has now got a programmer (not me) working on porting the Mac and Linux AGS engine so that we can commercially release Gemini Rue on those platforms. I know that the Linux build is in pretty good shape, but what needs doing at the moment apart from the crackly audio issues?

Congratulations on the great new addition to your team!!  The programmer, of course  ;)

Ah.  Sorry I've been unable to resolve these issues quickly enough for you.

There, is, as mentioned the audio corruption issue.  It has only been reported on systems with the PulseAudio audio server (present on most installs);  however, those not using it do need to have audio settings configured properly in the config file ("acsetup.cfg").  If these settings are not present (DIGIMID index), then beyond sound not working, we also have seen instances of the engine crashing to the command line.  Solving it directly is, of course, desirable, but having functional audio is a very nice workaround, in that the user has audio and no crashing.  The previous closed AGS version, 2.72, had quite a nice GUI setup utility written by Tom Vandepoele (Electroshokker) which did do this, as well as other config settings, such as full-screen or windowed mode.  I've asked for, and received, permission from he and CJ to have access to, port, and publish, those sources with the current AGS sources, and under the same license.  It would permit a user to properly configure DIGIMID in the config file!  I'm waiting on he (or CJ) to provide these sources.

So, long story short, if audio is not properly initialized, there can be crashes (bug).  It can be bewildering for new users to adjust the (partially undocumented) config files by hand.  The setup GUI works-around the first and solves the second.

Next, some testers have reported performance issues.  I've not spent any time profiling, as I considered the audio corruption a higher priority.

Lastly, I began work on an installer (using Mojosetup) and got it sort of working for 64-bit Linux, but not for 32-bit.  I also dropped installer work for the same reason.

I'm curious;  how will you have your programmer work on the engine, in terms of availability of sources?  Will fixes and improvements be worked on in the open (for example, in coordination with CW and JJS using the public Github), or retained internally to Wadjet Eye?  I'm working with other teams to do this same work (on a volunteer basis), and it would be ludicrous to run separate parallel development, though I fully understand the commercial need to not wait on volunteers :P
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 05 Jun 2013, 08:33
Next, some testers have reported performance issues.  I've not spent any time profiling, as I considered the audio corruption a higher priority.
I made few optimizations in "develop" branch, mostly simplifying new class hierarchies and inlining functions. They did not increase perfomance really much, but were enough to fix desynchronization between animation and sound/music during cutscenes in particular games. I think it would be possible to partially merge (or cherry-pick) that to master.
(merging whole develop branch right before the release would be risky, because it has significant change in internal data structures).
Title: Re: AGS engine Linux port
Post by: JanetC on 05 Jun 2013, 12:17
I'm curious;  how will you have your programmer work on the engine, in terms of availability of sources?  Will fixes and improvements be worked on in the open (for example, in coordination with CW and JJS using the public Github), or retained internally to Wadjet Eye?  I'm working with other teams to do this same work (on a volunteer basis), and it would be ludicrous to run separate parallel development, though I fully understand the commercial need to not wait on volunteers :P

We want to keep everything that he (Edward) does open source so that everyone can benefit (including us!) I want to make sure what we do is compatible with the community's plans for AGS.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Jun 2013, 00:02
We want to keep everything that he (Edward) does open source so that everyone can benefit (including us!) I want to make sure what we do is compatible with the community's plans for AGS.

Awesome, I thought so.  You folks are the best  :)
Title: Re: AGS engine Linux port
Post by: s_d on 06 Jun 2013, 00:07
I made few optimizations in "develop" branch, mostly simplifying new class hierarchies and inlining functions. They did not increase perfomance really much, but were enough to fix desynchronization between animation and sound/music during cutscenes in particular games. I think it would be possible to partially merge (or cherry-pick) that to master.
(merging whole develop branch right before the release would be risky, because it has significant change in internal data structures).

I agree with your merge strategy;  would that be something you'd like me to cherry-pick and test, or would you prefer to?

Keep in mind, these performance issues were not reported on the Windows version.  Improving performance over-all is, of course, fantastic, but this particular issue may very well be a Linux thing (or an Allegro on Linux thing, or a "way the Linux AGS port uses Allegro" thing).  Or it may simply not exist;  I haven't attempted to verify those reports yet.

Title: Re: AGS engine Linux port
Post by: Calin Leafshade on 06 Jun 2013, 22:52
How does the midi setup work in the linux version?
How do I tell AGS which alsa port to use? I run timidity which works fine in everything else but I can't seem to get any midi signals from AGS at all.
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Jun 2013, 23:34
It uses Allegros built in midi player. You just need a file with patches, as described in the readme.
Title: Re: AGS engine Linux port
Post by: Calin Leafshade on 06 Jun 2013, 23:40
I tried that (put the file in the dir and renamed it patches.dat) and it doesnt seem to do anything.
Title: Re: AGS engine Linux port
Post by: s_d on 06 Jun 2013, 23:43
How does the midi setup work in the linux version?
How do I tell AGS which alsa port to use? I run timidity which works fine in everything else but I can't seem to get any midi signals from AGS at all.

Yep;  what BigMC said.  Though, this is so poorly documented (between AGS & Allegro) that I'm glad you asked.  I'll go ahead and reply at length, so we may link to the post itself, in the future.

Calin, you need a couple of things.

First, you need to verify that you have MIDI supported (i.e., that either your sound driver supports MIDI directly, as most do, or through Timidity or similar).  Run aplaymidi -l (that's "l" for "list") to display ALSA ports which support MIDI.  The output might look like:

Code: Text
  1.   Port    Client name                      Port name
  2.   14:0    Midi Through                     Midi Through Port-0

Note the port number (zero in this case).

Next, you need to verify that MIDI works at all (through a MIDI player unrelated to AGS, or similar).  At this point, you can be certain that you'll be able to play any AGS game with MIDI sound (modulo bugs of course).

To set up a specific game, first you'll need to put a patches.dat file in it's data directory (you can choose one from here (http://alleg.sourceforge.net/digmid.html)).  I believe it must be named patches.dat for the Allegro library to find it.  I'm mostly using this one (http://www.eglebbk.dds.nl/program/download/digmid.dat).

Lastly, you must set up the acsetup.cfg in the data directory, to properly index your MIDI port:

Code: INI
  1. [sound]
  2. digiid=1
  3. midiid=0

You may not even have a "sound" section in the config file, but you'll need to add it. The parameter midiid is set to your port number from the aplaymidi listing.  For me, digiid needed to be set to 1, for MIDI port 0.  I'll go figure out why, and update this post with the reasoning.
Title: Re: AGS engine Linux port
Post by: Calin Leafshade on 07 Jun 2013, 00:22
Nope, still doesnt work.

My MIDI is working fine and when I run the game (5 Days a Stranger) in Wine the midi works fine but not if i use the native linux port.
Title: Re: AGS engine Linux port
Post by: s_d on 07 Jun 2013, 01:11
Is your MIDI port also zero?  What's in your acsetup.cfg?
Title: Re: AGS engine Linux port
Post by: Calin Leafshade on 07 Jun 2013, 01:56

┌─[steve][archlaptop][~/games/yahtzee/5das]
└──╼ aplaymidi -l
 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0
128:0    TiMidity                         TiMidity port 0
128:1    TiMidity                         TiMidity port 1
128:2    TiMidity                         TiMidity port 2
128:3    TiMidity                         TiMidity port 3
┌─[steve][archlaptop][~/games/yahtzee/5das]
└──╼ cat acsetup.cfg
[sound]
digiid=1
midiid=0
[misc]
defaultres=1
screenres=0
letterbox=0
defaultgfxdriver=DX5
gfxdriver=DX5
windowed=1
refresh=0
gfxfilter=StdScale3



I've connected port 14:0 to 128:0 and aplaymidi -p 14:0 music0.mid plays midi files just fine.
Title: Re: AGS engine Linux port
Post by: s_d on 07 Jun 2013, 02:32
Ok, you've got native MIDI support on 14:0, so I don't think you need TiMidity (but that doesn't really matter too much).  Either way, it should be working.

Is it only 5 Days, or is it not working on other games as well?

BTW... please don't interpret my analysis & probing here as any kind of judgement against you.  This very well may be a bug!  I simply need to be certain, and as long as you're helping me, I prefer to gather as much information as I can.
Title: Re: AGS engine Linux port
Post by: BigMc on 07 Jun 2013, 09:17
Allegros DIGMID does not output midi (to Timidity or whatever), it uses the patches to output the audio itself. I could not get Allegro to output midi either.
Title: Re: AGS engine Linux port
Post by: Cheeseness on 07 Jun 2013, 14:13
Cheeseness;  thank you for the valuable input!  I'm working on all of this, and will report back when I have more information.

No worries - wish I had a bit more time to dive into it. If you want to grab me on Steam/IRC (I can normally be found in #steamlug on freenode)/whatever I can try to work with you to try to further track stuff down when I'm around.


Also awesome to hear that Wadjet have brought somebody onboard and are looking to keep them contributing back :D
Title: Re: AGS engine Linux port
Post by: Calin Leafshade on 07 Jun 2013, 15:58
Allegros DIGMID does not output midi (to Timidity or whatever), it uses the patches to output the audio itself. I could not get Allegro to output midi either.

I thought this would be the case since it takes a patch file.

It's a shame AGS can't output pure midi in linux though.
Title: Re: AGS engine Linux port
Post by: BigMc on 07 Jun 2013, 17:13
If you want to figure this out: I would start with the MIDI example program (exmidi.c) that comes with Allegro 4 and try to get that to work first.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 11 Jun 2013, 21:58
I made few optimizations in "develop" branch, mostly simplifying new class hierarchies and inlining functions. They did not increase perfomance really much, but were enough to fix desynchronization between animation and sound/music during cutscenes in particular games. I think it would be possible to partially merge (or cherry-pick) that to master.
(merging whole develop branch right before the release would be risky, because it has significant change in internal data structures).

I agree with your merge strategy;  would that be something you'd like me to cherry-pick and test, or would you prefer to?

I am going to try merging the first part of "develop" branch up to the point where I started to change internal implementation of game objects. It contains an improvement that seem to have a noticable effect on amount of processor load "Nelly Cootalot II" does (according to my examinations).
Also IIRC the changes in that part are strictly dedicated to optimizing utility classes and few engine routines.
Title: Re: AGS engine Linux port
Post by: WizardStan on 14 Jun 2013, 04:04
Hi guys.
So I'm trying to build for a touchscreen oriented device running linux.  The problem is that the pointer is always offset if the window isn't a perfect fit.  Like, a 320x200 game in a 320x240 window has a 20 pixel bar at the top and bottom, right?  But then the mouse cursor is similarly 20 pixels lower than where it actually is.  Have I explained that well?  I've built it on my desktop (also running linux) and it's the exact same situation, the mouse pointer (and click region) appears 20 pixels below where it actually is according to the system, except on a desktop with a relative pointing device it doesn't make a difference.  When using an absolute coordinate device like a tablet it's a right pain.
I have a build from 8 months ago that didn't exhibit this problem and despite all the awesome cleanup that's been done to the code since then I can see that not a lot has changed with respect to how the pointer is handled, so I'm at a bit of a stall trying to figure out how to proceed.  Anyone have any ideas?  I'm assuming it's a mouse issue (or an "I'm-an-idiot" issue, those happen often enough) otherwise the iOS and Android devs would have had the same problem long ago.  Most curious is the fact that it used to work and now it doesn't and I can't see what the difference is.  Same version of allegro even!
Title: Re: AGS engine Linux port
Post by: WizardStan on 16 Jun 2013, 03:11
I very nearly have a fix but I can't figure out where to get the really real screen size.  Ostensibly final_scrn_wid and final_scrn_hit should give me what I need, but I'm finding that not to be the case: even though the window is clearly 960x720 these two variables continue to say 320x240.  The scaling seems to be entirely automatic, too: if I reduce my screen resolution to 800x600 I only get a 640x480 window, and if I reduce it to 640x480 then it sticks with a 320x240 window.  current_screen_resolution_multiplier is of no help either, it is always 1, just as final_scrn_wid is always 320 even when the window itself is much larger.  Can anyone shed any light on why this might be the case?  What part of the code is causing the window to be dynamically scaled with my screen resolution, and can I find out exactly what scale it is using?
Thank you!
Title: Re: AGS engine Linux port
Post by: BigMc on 16 Jun 2013, 19:42
The code that selects the scaling filter for windowed mode is here:
https://github.com/adventuregamestudio/ags/commit/3b9b41448500132a665e9dd3e15b22eac9a43126

It selects a resolution smaller than your desktop resolution to leave space for window borders and taskbar.

The Android port works well with touchscreen devices, it draws the game in native resolution to a surface that is then displayed and scaled using OpenGL. One could get rid of the scaling hacks on Linux and Windows if these ports would also use OpenGL. They could share more code with Android then.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 12 Nov 2013, 19:11
I build AGS from the master branch and tried to run Wadjeteye's new Shivah demo and I get this error:

AGS: Built library path: ./libagstouch.so
AGS: dlopen returned: ./libagstouch.so: cannot open shared object file: No such file or directory
AGS: Built library path: /tmp/The Shivah - Kosher Edition (DEMO)/libagstouch.so
AGS: dlopen returned: /tmp/The Shivah - Kosher Edition (DEMO)/libagstouch.so: cannot open shared object file: No such file or directory
AGS: Plugin loading failed, trying built-in plugins...
AGS: No built-in plugin found. Plugin loading failed!
AGS: No placeholder functions for the plugin found. The game might fail to load.
AGS: Built library path: ./libagswadjetutil.so
AGS: dlopen returned: ./libagswadjetutil.so: cannot open shared object file: No such file or directory
AGS: Built library path: /tmp/The Shivah - Kosher Edition (DEMO)/libagswadjetutil.so
AGS: dlopen returned: /tmp/The Shivah - Kosher Edition (DEMO)/libagswadjetutil.so: cannot open shared object file: No such file or directory
AGS: Plugin loading failed, trying built-in plugins...
AGS: No built-in plugin found. Plugin loading failed!
AGS: No placeholder functions for the plugin found. The game might fail to load.
AGS: Built library path: ./libags_shell.so
AGS: dlopen returned: ./libags_shell.so: cannot open shared object file: No such file or directory
AGS: Built library path: /tmp/The Shivah - Kosher Edition (DEMO)/libags_shell.so
AGS: dlopen returned: /tmp/The Shivah - Kosher Edition (DEMO)/libags_shell.so: cannot open shared object file: No such file or directory
AGS: Plugin loading failed, trying built-in plugins...
AGS: No built-in plugin found. Plugin loading failed!
AGS: Placeholder functions for the plugin found.
Script link failed: Runtime error: unresolved import 'IsOnPhone'

Is this an AGS error, or a Wadjeteye error?
Title: Re: AGS engine Linux port
Post by: BigMc on 12 Nov 2013, 19:43
The plugins have to be compiled on Linux. Closed source plugins make it impossible to port a game retroactively without reverse engineering the plugins, so plugins should be ideally replaced by modules or open sourced.
Title: Re: AGS engine Linux port
Post by: s_d on 12 Nov 2013, 20:25
Those plugins are due to Janet's iOS build.  Recall that they used the snowrain plugin for Gemini Rue and moved that to a module.

I thought the ags_shell issue was dealt-with, though... we should simply not load it, and then URL's become not click-able.  I've been meaning to build a Linux version since it would be trivial to shell out to a browser ("sensible-browser", or "$BROWSER" or whatever), but it takes a back seat to the audio corruption bug.  (Yes, I'm still working on it, but haven't fixed it yet, so nothing to report.)

Once we get Gemini Rue solid for release (including audio and our ags-setup util) we can ask Janet to strip out those libraries from The Shivah, and take a look at wadjetutil, not sure what that is.  Until then, I can't imagine bothering her.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 12 Nov 2013, 20:45
Isn't that new Shivah demo a special build for iOS? Maybe it is not even supposed to run on other platforms due change in UI or something?

EDIT: Oh, nevermind, noticed the thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=49522
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 15 Nov 2013, 18:16
I'm just getting back in to github and AGS, what branch are we working on currently?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 15 Nov 2013, 18:20
I'm just getting back in to github and AGS, what branch are we working on currently?
Here's the plan on branch usage: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912
The master is temporarily not updated, while most recent updates are made to "release-3.3.0".
Title: Re: AGS engine Linux port
Post by: TazX on 21 Nov 2013, 08:22
Firstly, thanks!.  A lot of work has gone into the Linux port, and it's awesome you're spending so much time on us.  Secondly, I'm going to ask for a little more of your time to (hopefully) help me get it working on my computer.  (roll)

I'm trying to install AGS from the github (https://github.com/adventuregamestudio/ags/blob/master/debian/README.md) on Linux Mint.  Kernal Version (if that's helpful) 3.8.0-33-generic #48-Ubuntu x86_64 GNU/Linux
I've tried both techniques (Ubuntu / Debian based (which Mint is), and the more generic Linux instructions) and it errors out with the following message:
Linking engine...
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
make: *** [ags] Error 1
make: Leaving directory `/home/username/ags/Engine'


I've tried googling the error but haven't found much, and forcing links (which seems like it might work) hasn't ever worked well, and I'm not sure where to begin, or what I should be linking.  I've tried an apt-cache search for lstdc and haven't found any compatible libraries.

Long story short, I guess I'm asking for help installing AGS as I've reached the end of my problem solving skills.  ???
Title: Re: AGS engine Linux port
Post by: BigMc on 21 Nov 2013, 14:36
Hi. Looks like you are missing the C++ standard library. Did you install build-essential as described in the Debian instructions?
Title: Re: AGS engine Linux port
Post by: monkey0506 on 21 Nov 2013, 17:10
Well I'm not sure exactly why you'd be getting that issue (I have successfully compiled the current repos on 32- and 64-bit Linux Mint). The very first link when Googling "linux cannot find lstdc++" is this StackOverflow question (http://stackoverflow.com/questions/2086072/linking-using-g-fails-searching-for-lstdc). Perhaps installing g++-multilib would resolve the issue for you?

Edit: I didn't even see there was another page, so I didn't see BigMc's post, but that also. :P
Title: Re: AGS engine Linux port
Post by: TazX on 24 Nov 2013, 09:06

Hi. Looks like you are missing the C++ standard library. Did you install build-essential as described in the Debian instructions?

Yes, I installed all of the suggested packages.  They seemed to be successful.  This is what I get when I try and install them:
$ sudo apt-get install git debhelper build-essential pkg-config liballegro4.2-dev libaldmb1-dev libfreetype6-dev libtheora-dev libvorbis-dev libogg-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
build-essential is already the newest version.
debhelper is already the newest version.
git is already the newest version.
libfreetype6-dev is already the newest version.
libogg-dev is already the newest version.
libtheora-dev is already the newest version.
libvorbis-dev is already the newest version.
pkg-config is already the newest version.
libaldmb1-dev is already the newest version.
liballegro4.2-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 43 not upgraded.


Well I'm not sure exactly why you'd be getting that issue (I have successfully compiled the current repos on 32- and 64-bit Linux Mint). The very first link when Googling "linux cannot find lstdc++" is this StackOverflow question (http://stackoverflow.com/questions/2086072/linking-using-g-fails-searching-for-lstdc). Perhaps installing g++-multilib would resolve the issue for you?

Edit: I didn't even see there was another page, so I didn't see BigMc's post, but that also. :P

BigMc's post?  I can only see 3 responses, none of whom are called BigMc?  Am I looking in the right place (http://stackoverflow.com/questions/2086072/linking-using-g-fails-searching-for-lstdc)?

My full error message is this, hope it helps:

~/ags $ make --directory=Engine
make: Entering directory `/home/tamsyn/ags/Engine'
CFLAGS = -O2 -g -fsigned-char -Wfatal-errors -DNDEBUG -DAGS_RUNTIME_PATCH_ALLEGRO -DAGS_HAS_CD_AUDIO -DAGS_CASE_SENSITIVE_FILESYSTEM -DALLEGRO_STATICLINK -DLINUX_VERSION -DDISABLE_MPEG_AUDIO -DBUILTIN_PLUGINS -DRTLD_NEXT -I/usr/include/freetype2 -I../Engine -I../Common -I../Common/libinclude -I../Plugins

CXXFLAGS = -fno-rtti -Wno-write-strings -fpermissive -O2 -g -fsigned-char -Wfatal-errors -DNDEBUG -DAGS_RUNTIME_PATCH_ALLEGRO -DAGS_HAS_CD_AUDIO -DAGS_CASE_SENSITIVE_FILESYSTEM -DALLEGRO_STATICLINK -DLINUX_VERSION -DDISABLE_MPEG_AUDIO -DBUILTIN_PLUGINS -DRTLD_NEXT -I/usr/include/freetype2 -I../Engine -I../Common -I../Common/libinclude -I../Plugins

LDFLAGS = -Wl,--as-needed

LIBS = -rdynamic -L/usr/lib/x86_64-linux-gnu -lalleg -laldmb -ldumb -Wl,-Bdynamic -ltheora -logg -lvorbis -lvorbisfile -lfreetype -logg -ldl -lpthread -lm -lc -lstdc++

Linking engine...
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
make: *** [ags] Error 1
make: Leaving directory `/home/tamsyn/ags/Engine'
Title: Re: AGS engine Linux port
Post by: David Ostman on 24 Nov 2013, 10:46
BigMc's post?  I can only see 3 responses, none of whom are called BigMc?
You quoted said post by BigMc in your reply above, I think.

Hi. Looks like you are missing the C++ standard library. Did you install build-essential as described in the Debian instructions?
Title: Re: AGS engine Linux port
Post by: TazX on 25 Nov 2013, 01:01
BigMc's post?  I can only see 3 responses, none of whom are called BigMc?
You quoted said post by BigMc in your reply above, I think.

Hi. Looks like you are missing the C++ standard library. Did you install build-essential as described in the Debian instructions?

*facepalm* - oops, sorry.  Yes, I've installed build-essentials:
build-essential is already the newest version.

Any other tips?  Should I be linking something to something else?
Title: Re: AGS engine Linux port
Post by: JJS on 26 Nov 2013, 13:57
You can change the linker flags to produce verbose output. This will show what files the linker checks before the linking fails. In the file Makefile-defs.linux change the line:
Code: Adventure Game Studio
  1. override LDFLAGS  += -Wl,--as-needed $(addprefix -L,$(LIBDIR))
to
Code: Adventure Game Studio
  1. override LDFLAGS  += -Wl,-verbose,--as-needed $(addprefix -L,$(LIBDIR))

This will give a lot of additional output, for my system the relevant output lines are:
Code: Adventure Game Studio
  1. attempt to open /usr/lib/x86_64-linux-gnu/libstdc++.so failed
  2. attempt to open /usr/lib/x86_64-linux-gnu/libstdc++.a failed
  3. attempt to open /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so succeeded
  4. -lstdc++ (/usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so)
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 27 Nov 2013, 06:08
What does -hicolor do exactly? And while we're at it, what does -letterbox do? I've never used either of them. Are they still relevant?

I'm looking at changing the --help to be more helpful.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 27 Nov 2013, 07:25
-hicolor => downgrade 32-bit game to 16-bit
-letterbox => wiki describes this better (http://en.wikipedia.org/wiki/Letterboxing_(filming))
Title: Re: AGS engine Linux port
Post by: TFeldt on 17 Dec 2013, 19:36
First off, fantastic work on the linux port. So far I've not encountered a single crash and the compilation instructions were clear as crystal.

Secondly, I apologize if I have somehow missed a bug report or thread about this issue. I did check both the tracker, repository and this forum. The only thing that seemed to be vaguely related was http://www.adventuregamestudio.co.uk/forums/index.php?topic=48948.0 but I'm not sure if it is since I never encountered this problem while running the windows version of AGS.

Finally, the actual post. I'm having issues with pointer accuracy. The in-game software pointer always seem to trail behind the actual pointer. If I move it too fast the pointer appears to grow hysterical, jump around at random and then eventually settle down (I know, not a particularly technical description but it's the best I can muster). It does not affect my actual pointer, which can be confirmed by moving it outside the ags window. What have I done wrong?

There's no errors in stdout, the games work fine otherwise, it happens in both windowed and fullscreen mode, it happens on every game I've tried but for reference the two last ones were Technobabylon and Beacon. I'm running a stock ubuntu 13.10, only thing that should be related is that I'm running the official nvidia drivers, not the noveau ones. I have not made any modifications to X related to my mouse.

I would post this in the bug forum, but it feels like this is a user specific problem so I'll refrain from doing so until confirmed.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 17 Dec 2013, 19:43
Have you tried it with the Noveau drivers? I've definitely had the issue you describe in other programs (not specifically ags), that was related to a bad video driver.

There are no known pointer lag issues, especially on an updated distro like you have.
Title: Re: AGS engine Linux port
Post by: TFeldt on 17 Dec 2013, 22:12
Have you tried it with the Noveau drivers? I've definitely had the issue you describe in other programs (not specifically ags), that was related to a bad video driver.

There are no known pointer lag issues, especially on an updated distro like you have.
Thank you for your quick reply mate. Your confirmation that there were no reported problems like this got me going. I first tried the noveau driver, but it made no difference. Then I started getting exotic. Long story short; it wasn't at all related to nvidia. It was in fact a hardware problem. With my darn mouse, a Mad Catz RAT 7. The part of ags that interprets mouse movement (allegro? or is there a custom input layer?) does not receive the correct information from X. It does not correspond to actual mouse movement, which is bizarre since the mouse works perfectly in regular X and other applications.

I verified that this was the problem by connecting a second mouse to the same system at the same time. The logitech one was smooth as butter in ags, the RAT continued to manifest the problem. I'm going to keep poking at this, if I figure out how to solve it I'll post back in case anyone else runs into the issue and finds the post via google. But for now this can be ignored, it is not related to ags.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 17 Dec 2013, 23:11
Great... glad it was "simple". If you notice any other issues please let us know.
Title: Re: AGS engine Linux port
Post by: Cheeseness on 18 Dec 2013, 00:53
It was in fact a hardware problem. With my darn mouse, a Mad Catz RAT 7.
Since that's the model of mouse that I use, I thought I'd pipe in and say that I've not encountered the sort of issues you've described either either of the ones I've had so far :(
Title: Re: AGS engine Linux port
Post by: TFeldt on 18 Dec 2013, 13:51
Unfortunately I'm back. It turns out it wasn't a problem with my mouse but a built-in input event throttling in either AGS or Allegro (or a performance bottleneck related to input events). It'd take far too long to describe in text exactly what transpires so I made a video instead. They say a picture is worth a thousand words, so 30 frames per second for 288 seconds would be worth 8.6 million words(!). Hopefully I made everything clear, in case you have any questions then I'll always be available for further testing. You can find the youtube video below.

Title: Re: AGS engine Linux port
Post by: s_d on 09 Jan 2014, 04:09
Hopefully I made everything clear, in case you have any questions then I'll always be available for further testing. You can find the youtube video below.



Yeah, that was super clear, and this is really great information, TFeldt!  Thanks for the video.  We've had other testers intermittently report input lag as well.

Looks like http://code.google.com/p/aseprite/issues/detail?id=283 to me, so maybe a known-issue with A4 at present (or at least with the way we're using it and polling inputs).
Title: Re: AGS engine Linux port
Post by: TFeldt on 09 Jan 2014, 09:20
Yeah, that was super clear, and this is really great information, TFeldt!  Thanks for the video.  We've had other testers intermittently report input lag as well.

Looks like http://code.google.com/p/aseprite/issues/detail?id=283 to me, so maybe a known-issue with A4 at present (or at least with the way we're using it and polling inputs).
That's great, I'm happy it was useful. I had a look at that issue tracker and it does appear to be a likely culprit. If it's yielding for more than 1ms in a non-blocking mode then it'll create a queue build-up that keeps increasing over time. It might also be aggravated by the host's performance. For me 500hz polling was fine, so as long as it yields less than 2ms then it works fine for me. Actually had this exact problem with the unity3d engine a while back, but they eventually fixed it internally.

Easiest way to fix it might be to just have it block events instead of creating a queue, the net result would be the same as reducing your polling rate only done in the application itself. They do seem to be considering a more long-term fix though, using message queues provided by allegro 5 instead. If I remember correctly that would remove the necessity to yield since it'd be processed on creation instead of having the main thread keep checking for it manually and thus spiking the cpu usage.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 14 Jan 2014, 17:07
Where do we stand on a Mac build? I know the Humble Bundle guy sent us a lot of Mac code. Are we anywhere close to merging that? If we did merge it, do we have a Mac guy who could compile/test it?
Title: Re: AGS engine Linux port
Post by: BigMc on 14 Jan 2014, 17:09
There is also a Mac thread on this forum.
Title: Re: AGS engine Linux port
Post by: JanetC on 14 Jan 2014, 17:45
Hey guys,

Since we now have a commercial-ready Linux port courtesy of the Humble Bundle, I want to release Wadjet Eye's games on Linux as soon as possible. What's the Linux community preferred way of building an installer for games?

Janet
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 14 Jan 2014, 17:45
Janet from Wadjeteye contacted me about releasing their games commercially on Linux. One question she asked me was about an installer. I don't have any experience with creating an installer, so I wasn't much help.

1) Do you think they need an installer? Or would a .tar.gz be enough?
2) If they do decide to do an installer, what should they use?

Maybe I'm old school, but I'd prefer a simple .tar.gz with the binaries/assets in it.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2014, 17:50
Where do we stand on a Mac build? I know the Humble Bundle guy sent us a lot of Mac code. Are we anywhere close to merging that? If we did merge it, do we have a Mac guy who could compile/test it?
I don't know if anyone is working on that. I was thinking about having closer look, but could not find time yet. Also, I do not have a possibility to compile Mac code at the moment, nor I have much knowledge of OSX anyway. That said, I am afraid I won't be that much help in this case, other than checking out pull requests and making sure engine core code is not screwed by the changes.

Generally, Edward's OSX commits include all the allegro headers and binaries, that should not be added to AGS repository. Instead, the possible ways could be to either communicate with Allegro 4 team and find out if they would like to patch official A4 with those changes, or create a new repository (forking from Allegro official source maybe) and apply those patches there. In the second case we will need to reference this separate repository from AGS readme.

Yes, and it is better to discuss Mac port in the dedicated thread:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.0
Title: Re: AGS engine Linux port
Post by: BigMc on 14 Jan 2014, 18:12
An installer has the disadvantage that it copies stuff to locations that are normally controlled by the package manager and it's not always clear how to get rid of that stuff again.

deb and rpm packages have the advantage that they can be cleanly deinstalled later, but you still need something else in addition because not every distribution has deb or rpm.

What I like most is a tar.gz where you can decide if you want to start the game immediately after extracting or run an install script that copies the game and a .desktop file somewhere else so that you have a menu entry.
It's nice if the script is short and simple so that you can have a look at it before running it. That also helps with uninstalling.

If you look at the Humble Bundles, games often have multiple options, for example deb + rpm + something for all distributions.

EDIT: If you want an installer, have a look at MojoSetup: http://www.icculus.org/mojosetup/
Title: Re: AGS engine Linux port
Post by: JanetC on 15 Jan 2014, 16:23
A lot of Linux people are "Old-school" so if what Linux users like is "No installer" I'm happy to save myself some work :D

Any linux-users here want to say "No, I really do like installers!"?
Title: Re: AGS engine Linux port
Post by: JanetC on 15 Jan 2014, 18:00
deb and rpm packages have the advantage that they can be cleanly deinstalled later, but you still need something else in addition because not every distribution has deb or rpm.

What I like most is a tar.gz where you can decide if you want to start the game immediately after extracting or run an install script that copies the game and a .desktop file somewhere else so that you have a menu entry.
It's nice if the script is short and simple so that you can have a look at it before running it. That also helps with uninstalling.

If you look at the Humble Bundles, games often have multiple options, for example deb + rpm + something for all distributions.

I have no experience using Linux. I installed it for the first time yesterday. I'm trying to understand expectations that are very obvious to people who have been using Linux for years (such as the differences between the different distributions of Linux.)

So, tar.gz files have scripts that allow you to set up install locations? How does one set this up?

What is the best way of building AGS on Linux to make a simple package that contains game files? The instructions on Github assume that you are wanting to load multiple game files that you have obtained elsewhere. I want to produce something like the Gemini Rue package that the Humble Bundle guys produced - it just runs one game.

What is a deb and rpm package?
Title: Re: AGS engine Linux port
Post by: BigMc on 15 Jan 2014, 18:12
.tar.gz files are similar to .zip files. On Linux this is done in two steps: tar bundles multiple files into one file and .gz means that this file was subsequntly compressed with gzip. This is all done automatically by double clicking on a .tar.gz file or doing right-click->compress on something nowadays.

I created a script that summarizes the steps that are necessary to create a bundle that should work on most Linux systems. It includes libraries taken from Debian, the licenses, and 32 and 64 bit versions of AGS:
https://github.com/adventuregamestudio/ags/blob/master/debian/make_ags%2Blibraries.sh

On Linux package managers are used to install and update software that is included in the archives that make up the distributions. Debian and Ubuntu use the deb format for software packages, Fedora, Red Hat and OpenSUSE use rpm, others use something else or nothing at all.
Title: Re: AGS engine Linux port
Post by: JanetC on 15 Jan 2014, 19:09
Thanks, but the script says it should only be used on Debian, not Ubuntu, and I installed Ubuntu.

Is there a simple way to build a Linux application for most commonly used Linux versions? This all seems fantastically complicated. I feel I am going to end up maintaining 7+ compiled versions of each game for Linux and installing multiple versions of Linux just to build with. Am I wrong? For a small market it may simply be too fragmented to be worth it, unfortunately :(
Title: Re: AGS engine Linux port
Post by: BigMc on 15 Jan 2014, 19:21
It should be used on Debian 7 (wheezy) to build the package, then the game will run pretty much everywhere. The thing is just that (assuming everyone uses glibc) there can be problems when a program is run with an older libc than the one that was used for building. Most reasonably recent distributions (for example Ubuntu 12.04) use glibc 2.15. Debian 7 uses glibc 2.13 so if you build there that should be good enough.

I don't know if there is a safe way to use a newer libc to build programs for use with an older libc.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 15 Jan 2014, 19:40
BigMc can you make us a current build of the engine/libraries that Janet can use to bundle Gemini Rue?
Title: Re: AGS engine Linux port
Post by: BigMc on 15 Jan 2014, 19:51
I could, but then I would have to do that every time you want to change something in AGS to fix a bug. I would also have to set up two Debian 7 chroots (32 and 64 bit) because I'm using Debian testing. Oh by the way you can also do that on Ubuntu so you don't need to install Debian 7 to build with Debian 7. It's described in debian/README.md and in more detail on https://wiki.ubuntu.com/PbuilderHowto

BTW, if the Humble Bundle build of AGS works well you could use that also for other games.

EDIT: pbuilder is the easiest way to build for the other architecture (i386 or amd64) anyway so you would do that in any case if you want to use the ags+libraries script.
Title: Re: AGS engine Linux port
Post by: JanetC on 16 Jan 2014, 14:09
To clarify, I'm talking about the Humble bundle port, not the main project that you guys are working on. The Humble bundle version is ready to go (in terms of code.) I'm not asking BigMc to change the code in the main AGS project at all. I just don't know how to compile in terms of a commercial-ready release. I have compiled it just fine with the instructions at:

https://github.com/adventuregamestudio/ags/blob/master/debian/README.md

But that does not produce something I can package for release. I am wondering where to go from there.

I'm not familiar with Linux at all, so I'm not really understanding this thread in more than superficial terms. For instance I don't know if I want to use the ags+libraries script because I am not clear on what it does. I think I need some examples of a method to build a commercial-quality game to start from. People here are being very helpful in terms of "If you want X, you should do Y and Z," but I'm more stuck on whether I want to do X or something else, and why.

I know that Scott produced a commercial-quality build of Gemini Rue for us a while back (which never ended up getting released for various reasons) so I would be eager to know the method he used.
Title: Re: AGS engine Linux port
Post by: BigMc on 16 Jan 2014, 17:10
I think what Scott did was asking me to run ags+libraries.sh and upload the result, then he took that and copied your game into the folder and zipped it again.

Most of what the script does is to copy a bunch of files from Debian into a folder. You can just take all these files from the old "ags+libraries" tarball I uploaded that is somewhere in this thread. They don't change.

The only thing you need to do yourself is to build the 32 and 64 bit ags binaries. You need to be able to do that yourself so that you are independent and can change ags whenever you like.

So (on your Ubuntu) install ubuntu-dev-tools, then create the chroots

cowbuilder-dist wheezy i386 create
cowbuilder-dist wheezy amd64 create

Then you run in the ags source tree

debian/rules get-orig-source
debuild -us -uc -S

That creates a Debian source package in the folder above, ags_something.dsc

cd ..
cowbuilder-dist wheezy i386 build ags_something.dsc
cowbuilder-dist wheezy amd64 build ags_something.dsc

That creates Debian packages ags_something.deb in ~/pbuilder.
You can open that for example with file-roller and extract the binaries, so there you have your ags binary built with Debian 7. The only detail that is missing now is that you have to run cowbuilder-dist with an option to set an RPATH, that means that the binary looks in that path for the libraries (that you want to include with the binary; without RPATH it tries to use the system libraries which will cause problems if you run that on all kinds of different systems). I'll check later what exact line is needed, but until then you can try if you get along with this so far.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 16 Jan 2014, 17:15
Getting those old libraries should be easy (if we can find an old version of the GR beta). If compiled ags on Fedora 32/64 bit, the resulting binary would work? Or would it need to match the distro the libraries come from?
Title: Re: AGS engine Linux port
Post by: BigMc on 16 Jan 2014, 17:19
Your Fedora has most likely a newer libc, so the result will likely not work on Debian 7. If you do the same on Fedora you also have to make sure the libraries you include are compatible with the ones you build against.

The old ags+libraries is here: http://people.debian.org/~thansen/ags+libraries_20130218.tar.xz

EDIT: Ok the commands you need for building with RPATH are these:

DEB_BUILD_OPTIONS="rpath=$ORIGIN/lib32" cowbuilder-dist wheezy i386 build ags_$VERSION.dsc
DEB_BUILD_OPTIONS="rpath=$ORIGIN/lib64" cowbuilder-dist wheezy amd64 build ags_$VERSION.dsc

I also updated the script make_ags+libraries.sh in the release-3.3.0 branch to do all of this so you can build a new ags+libraries bundle now on any version of Debian or Ubuntu.

Run these commands just once:

sudo apt-get install ubuntu-dev-tools cowbuilder
cowbuilder-dist wheezy i386 create
cowbuilder-dist wheezy amd64 create

And then every time you want to create a new bundle make sure your ags tree is git clean and run

debian/make_ags+libraries.sh

Also see the comment in the script:
https://github.com/adventuregamestudio/ags/blob/release-3.3.0/debian/make_ags+libraries.sh
Title: Re: AGS engine Linux port
Post by: Problem on 17 Jan 2014, 08:23
Janet from Wadjeteye contacted me about releasing their games commercially on Linux. One question she asked me was about an installer. I don't have any experience with creating an installer, so I wasn't much help.

1) Do you think they need an installer? Or would a .tar.gz be enough?
2) If they do decide to do an installer, what should they use?

Maybe I'm old school, but I'd prefer a simple .tar.gz with the binaries/assets in it.

Oh, that's great news! For me a simple .tar.gz would be enough, but I guess that many people would like a simple installer script that generates an entry for the desktop menu.
Title: Re: AGS engine Linux port
Post by: scottchiefbaker on 17 Jan 2014, 19:17
Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.
Title: Re: AGS engine Linux port
Post by: JanetC on 08 Feb 2014, 02:57
Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.

Not for a commercial game - that would be fine for freeware. People already do that by buying the PC version and compiling the Linux runtime for their platform.
Title: Re: AGS engine Linux port
Post by: s_d on 18 Mar 2014, 05:32
Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.

Not for a commercial game - that would be fine for freeware. People already do that by buying the PC version and compiling the Linux runtime for their platform.

Janet, I'm working on a VM "appliance" that could be used to produce builds for the two architectures, with scripts to produce packaging (one "tar.gz" archive, one Mojosetup installer).  Some hand-massaging would be necessary of course as it would be producing generic builds, and Mojosetup installers need some customization (game name & file names, images, etc).  When it nears readiness, I'll share it with everyone.

I'm hoping that can ease the build and packaging woes somewhat!  I've several groups that are keenly interested in that.  Maybe I'll have better fortune at that than in working on the audio backend (as I'd intended before).

Incidentally CW, I think that your threading fix actually solved the audio corruption issue we were seeing on 32-bit Linux! I spent so many weeks debugging the Linux audio server (PulseAudio) and had no idea that multithreaded audio could be problematic for the ports. Unfortunately now, a tester has reported a different audio issue on 64-bit Linux, Fedora 20 >:(
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 22 Mar 2014, 20:50
Incidentally CW, I think that your threading fix actually solved the audio corruption issue we were seeing on 32-bit Linux! I spent so many weeks debugging the Linux audio server (PulseAudio) and had no idea that multithreaded audio could be problematic for the ports. Unfortunately now, a tester has reported a different audio issue on 64-bit Linux, Fedora 20 >:(
What fix? I didn't do anything yet...

But we too got a report about what seems to be memory corruption (possibly a deleted object accessed from other thread).
I am currently in a process of refactoring sound channels and sound clip objects in the engine code. After this is done, I will try to change the way threading works. I am afraid the way it was done originally made things more complicated.

I recommend to just disable threading in games where it causes problems, - for now. Should be:
Code: Text
  1. [sound]
  2. threaded=0 // or remove the line completely
  3.  
in acsetup.cfg.
Title: Re: AGS engine Linux port
Post by: s_d on 02 Apr 2014, 07:11
What fix? I didn't do anything yet...

Oh, is that right?  Well, I'd reviewed the past ~3m of patches and I swore I saw you commit audio fixes (including a thread locking fix from monkey_05_06).  There were too many for me to review in detail, and I see now that his patch was a deadlock fix.  Apologies for my sloppy review and assumptions made.

Anyway, the fact that the problem has been perturbed out of existence certainly makes it feel like a threading race condition.  Probably it will come back.

But we too got a report about what seems to be memory corruption (possibly a deleted object accessed from other thread).
I am currently in a process of refactoring sound channels and sound clip objects in the engine code. After this is done, I will try to change the way threading works. I am afraid the way it was done originally made things more complicated.

I recommend to just disable threading in games where it causes problems, - for now. Should be:
Code: Text
  1. [sound]
  2. threaded=0 // or remove the line completely
in acsetup.cfg.

For the projects I'm working with, we're already packaging a config file with the sound section empty, so the audio thread would not be run.
Title: Re: AGS engine Linux port
Post by: monkey0506 on 05 Apr 2014, 00:43
Also to note - there is no vSync on AGS games under Linux.  I notice tearing during fade in and out transitions and in some animations.  Though if I run the game under Wine there is no tearing at all.

Is this still an issue for the Linux port? We're looking to start releasing games on Steam for Linux and this could be an issue for games that use v-sync. :-X
Title: Re: AGS engine Linux port
Post by: Nachtvlinder on 06 Apr 2014, 11:32
Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.

Not for a commercial game - that would be fine for freeware. People already do that by buying the PC version and compiling the Linux runtime for their platform.

Janet, I'm working on a VM "appliance" that could be used to produce builds for the two architectures, with scripts to produce packaging (one "tar.gz" archive, one Mojosetup installer).  Some hand-massaging would be necessary of course as it would be producing generic builds, and Mojosetup installers need some customization (game name & file names, images, etc).  When it nears readiness, I'll share it with everyone.

There's one thing I really don't understand. Why are things done in such a complicated way? Why not use the package system?
The game author would only need to provide a package containing their game and make it dependent of ags. If they provide one rpm, one deb and one tar.gz, any Linux user could use it. The only thing needed for that would be setting up a few repositories for ags. I think you would need one for debian based systems. I'm not familiar with rpm, but I presume you could do the same for rpm. And anyone not using a mainstream distribution should have little problems compiling their own package.

I'm using Arch myself nowadays. And there it already works. :) This is the package for KQ1 for example:
https://aur.archlinux.org/packages/kq1vga/
It just downloads the original Windows files, adds an icon, a menu entry and uses ags to run the game.
Title: Re: AGS engine Linux port
Post by: BigMc on 06 Apr 2014, 18:25
There's one thing I really don't understand. Why are things done in such a complicated way? Why not use the package system?

Because AGS is currently not stable enough to rely on a binary that is controlled by someone else. If you do a commercial release of an AGS game it's good to have control over the engine to be able to fix bugs.
Title: Re: AGS engine Linux port
Post by: bgordebak on 15 Aug 2014, 11:02
I would really like it if I could embed the engine into the resulting binary. On either Linux or Windows. That would make a standalone game executable.

If the engine wouldn't embed it, I'd like to be able to do something like:
Code: Adventure Game Studio
  1. cat ags game.exe > standalonegame

I don't know if it's too hard to implement though.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 15 Aug 2014, 11:06
There were experimental Editor versions with "build for linux" support:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50421.0

Frankly I haven't tested how it works, but I think it is generally possible.
IIRC you need to select build target in the Editor Preferences.

This
Code: Bash
  1. cat ags game.exe > standalonegame
  2.  
won't work well, because the game data is seached by certain offsets inside big file. You would need to extract a stand-alone game data first, and append that to linux executable.

EDIT: fixed the link.
Title: Re: AGS engine Linux port
Post by: bgordebak on 15 Aug 2014, 11:11
Thanks. Not a big issue.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 15 Aug 2014, 11:13
Regarding cutting the game data from Windows exe, I explained how to do that manually here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46152.msg636445497#msg636445497
and here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.msg636469632#msg636469632

I guess someone will eventually add this feature to the Editor.
Title: Re: AGS engine Linux port
Post by: bgordebak on 15 Aug 2014, 12:06
There were experimental Editor versions with "build for linux" support:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50421.0

I tried this and mostly works except small issues. It puts the game, 32-bit and 64-bit engines in a folder, and creates an executable script which runs the game according to the architecture. It can be a good way to deploy the game for linux.
Title: Re: AGS engine Linux port
Post by: Gord10 on 01 Nov 2014, 19:36
I have a question. I compiled my own version of AGS in Linux by make --directory=Engine. The ags engine file I obtained has very poor performance, sounds are jittered and framerate is low. I also tried Wine for Self, I could make it work flawless, so I know that it's not because my virtual machine is too low. Do I need to use debian/make_ags+libraries.sh for an engine with good performance? (I failed to compile by debian/make_ags+libraries.sh).
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 01 Nov 2014, 19:38
I have a question. I compiled my own version of AGS in Linux by make --directory=Engine. The ags engine file I obtained has very poor performance, sounds are jittered and framerate is low. I also tried Wine for Self, I could make it work flawless, so I know that it's not because my virtual machine is too low.
I have the same on my Ubuntu virtual machine, but since no one real Linux user reported this, I was too lazy to investigate :tongue:.
Title: Re: AGS engine Linux port
Post by: BigMc on 01 Nov 2014, 19:52
The engine is the same whether built as a Debian package or not. I also have jittered sound since a few months, but since I have a somewhat exotic sound card and nobody else reported it, and my initial attempts to investigate failed, ...

Edit: Oh you asked about debian/make_ags+libraries.sh... That engine would maybe have some different library versions but even if that works better, it should work with what you have.
Title: Re: AGS engine Linux port
Post by: Gord10 on 01 Nov 2014, 21:06
That's bad news. So I guess I should wait for that problem be resolved before I publish Linux version of Self, if that's a common problem. I really don't want to publish something works worse than Wine.
Title: Re: AGS engine Linux port
Post by: Gord10 on 04 Nov 2014, 22:19
Guys, I found something strange in Linux port. It doesn't read acsetup.cfg file for audio (and maybe for nothing else). I have set Digital Sound as No Digital Sound. But when I runned ags, there was still the jitterish sound.

Why is it important? Because in Wine, I get the jitterish sound with Default DirectSound Device, which is the default value. Everything turns normal when it's set as DirectSound (Hardware Mixer). Obviosuly, ags can't understand that we want to use DirectSound (Hardware Mixer). I think the performance problem will resolve if ags can read acsetup.cfg.
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Nov 2014, 22:27
I don't think so. Some things in acsetup.cfg only make sense on Windows so they're not read on Linux. DirectSound is a Windows thing. It has worked before, so some change in the sound code must have caused this bug.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Nov 2014, 22:56
There's no "DirectSound" on Linux... it's a Microsoft thing (a part of DirectX).

Linux port does NOT read the sound options set by winsetup. Instead, it reads following audio options from cfg:
"digiid" - an index of digital sound driver;
"midiid" - an index of midi sound driver;
You have to write these manually.

E: Strangely, this is not mentioned in the readme.md. OTOH we do not have that much explanation for the contents of acsetup.cfg at all :tongue:

The only values for digiid and midiid I know
0 - no sound
-1 - auto-detect

Others are defined in Allegro as:

DIGI_OSS - 1330860868
DIGI_ESD - 1163084868
DIGI_ARTS - 1095914579
DIGI_SGIAL = 1397180737
DIGI_ALSA = 1095521089
DIGI_JACK = 1245791051

MIDI_OSS - 1330860877
MIDI_ALSA = 1095584068

The only name I recognize there is ALSA :).

It has worked before, so some change in the sound code must have caused this bug.
I believe multiple users build AGS from the latest commits, so if this was a general issue, it would be reported already.
As I told before, I have this problem on virtual machine with Ubuntu too, from the very beginning, but, as Linux is not my forte, I decided to ignore that for the time being.
I might look into this, since this causes trouble. But I would like to know too, if other people have these problems on Linux.
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Nov 2014, 23:13
This is the most stupid thing I've ever seen to encode these Ids like that...

They are for ALSA: 1095521089
and OSSD: 1330860868

EDIT: Ok, you've also computed them in the meantime. ALSA and OSS digital are the only ones worth trying though. I think the others are disabled in Allegro by default nowadays.

EDIT2: I get jittered sound with both. I don't know if that actually causes the engine to use OSS though.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Nov 2014, 23:23
The "autodetect" on my Ubuntu selects ALSA.
I know that because I have an IO error message from ALSA lib every time I exit the game. :-\

UPD: For the sake of experiment, I downloaded a free Linux game called "Pingus". And the sound works well there...
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Nov 2014, 23:37
It should always be ALSA unless it was changed in the Allegro config file. But getting an ALSA message doesn't prove it's not using OSS: On Linux OSS uses ALSA nowadays. It's just an API that exist across Unixes as opposed to ALSA which is Linux only.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Nov 2014, 23:40
This is so funny.

I ran with "no sound" once. Then run with "autodetect" again. And it worked! :shocked: No jittering, perfect sound.
E: Next time it has jittering again :(.
Something's fishy going on here.
Title: Re: AGS engine Linux port
Post by: BigMc on 04 Nov 2014, 23:41
I just installed alex4 from the official repos. It uses allegro 4 and also has broken sound. Can you confirm that?
Title: Re: AGS engine Linux port
Post by: Gord10 on 04 Nov 2014, 23:44
This is so funny.

I ran with "no sound" once. Then run with "autodetect" again. And it worked! :shocked: No jittering, perfect sound.
E: Next time it has jittering again :(.
Something's fishy going on here.
I have just tried that, it was jittering again.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 04 Nov 2014, 23:48
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 :).
Title: Re: AGS engine Linux port
Post by: Alberth on 05 Nov 2014, 18:03
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
  1. >>> hex(1330860868)
  2. '0x4f535344'
  3. >>> chr(0x4f) + chr(0x53) + chr(0x53) + chr(44)
  4. 'OSS,'
  5. >>> hex( 1095521089)
  6. '0x414c5341'
  7. >>> chr(0x41) + chr(0x4c) + chr(0x53) + chr(0x41)
  8. 'ALSA'
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Nov 2014, 16:26
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?
Title: Re: AGS engine Linux port
Post by: BigMc on 25 Nov 2014, 19:28
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.
Title: Re: AGS engine Linux port
Post by: monkey0506 on 22 Dec 2014, 21:07
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. >:(
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 22 Dec 2014, 21:26
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.
Title: Re: AGS engine Linux port
Post by: monkey0506 on 23 Dec 2014, 19:50
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
  1. #!/bin/sh
  2. SCRIPTPATH="$(dirname "$(readlink -f $0)")"
  3.  
  4. if test "x$@" = "x-h" -o "x$@" = "x--help"
  5.   then
  6.     echo "Usage:" "$(basename "$(readlink -f $0)")" "[<ags options>]"
  7.     echo ""
  8. fi
  9.  
  10. if test $(uname -m) = x86_64
  11.   then
  12.     ALLEGRO_MODULES="$SCRIPTPATH/data/lib64" "$SCRIPTPATH/data/ags64" "$@" "$SCRIPTPATH/data/"
  13.   else
  14.     ALLEGRO_MODULES="$SCRIPTPATH/data/lib32" "$SCRIPTPATH/data/ags32" "$@" "$SCRIPTPATH/data/"
  15. fi
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 23 Dec 2014, 22:18
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.
Title: Re: AGS engine Linux port
Post by: BigMc on 24 Dec 2014, 00:15
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.
Title: Re: AGS engine Linux port
Post by: monkey0506 on 24 Dec 2014, 03:11
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).
Title: Re: AGS engine Linux port
Post by: monkey0506 on 24 Dec 2014, 06:59
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) (https://github.com/adventuregamestudio/ags/commit/de3ac29c359403cbf7d94197e178af36e964b9d4#diff-fb92d4424bded7fe61dcc551bda15536R40)

a45f1a5, "Initial release of AGS Engine source code!" (https://github.com/adventuregamestudio/ags/commit/a45f1a55a2c41efae2246c24a7e5c6c1ecddfe6d#diff-c29f13220ce5eb744a21a9e4c61b4036R258)

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 (https://github.com/adventuregamestudio/ags/commit/fef66bfb9e7bd68175bab583b3f32c2c636f7178)), 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. 8-)
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 24 Dec 2014, 08:54
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:
Quote
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).
Title: Re: AGS engine Linux port
Post by: monkey0506 on 14 Jan 2015, 14:44
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. :-\
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 14 Jan 2015, 15:10
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.
Title: Re: AGS engine Linux port
Post by: monkey0506 on 14 Jan 2015, 16:04
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 (https://github.com/adventuregamestudio/ags/tree/93d13bdabc1d15f142fa7b0d8e0276137de0f92f) and 3.3.0-hotfix3 (https://github.com/adventuregamestudio/ags/tree/d7cdc2524cbfae6e668d19a21f89626b0bfbb198)).
Title: Re: AGS engine Linux port
Post by: monkey0506 on 16 Jan 2015, 15:45
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. >:(
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 16 Jan 2015, 18:21
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).
Title: Re: AGS engine Linux port
Post by: Problem on 24 Aug 2015, 17:01
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.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 24 Aug 2015, 18:49
I think Wadjet Eye has their own Linux build which is fixed, but better ask them for details, because I could be mistaken.
Title: Re: AGS engine Linux port
Post by: Problem on 26 Aug 2015, 09:47
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.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 26 Aug 2015, 10:16
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.
Yes, their version is outdated, but it is possible to merge it with latest version we have. This is something I suggested them to do some time ago; I guess they just did not have enough time to try it yet.

I think this should be possible to do, because their changes were mostly to Linux and OSX specific stuff, not engine core logic.

The question is, if they have that sound problem fixed, that is - whether they experience it with their build. I think it should be clarified first before trying this.


E: I could probably try to do this, but there is one thing: I am unable to test things on Mac, at least not right away (I do not own one), so someone else will have to test and approve my work.
If this will be done, that may server as a temporary alternate Linux & Mac port for some time, until we get a properly constructed Mac port someday in future.
Title: Re: AGS engine Linux port
Post by: Problem on 26 Aug 2015, 10:31
Well, their old Linux ports still seem to work. I just played The Shivah, and it doesn't have any sound issues at all.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 26 Aug 2015, 10:36
Well, their old Linux ports still seem to work. I just played The Shivah, and it doesn't have any sound issues at all.
To clarify, you are using Shivah version packed by Wadjet Eye (with their own port)?
Title: Re: AGS engine Linux port
Post by: Problem on 26 Aug 2015, 10:39
I have it on Steam, so I guess it's their port.
Title: Re: AGS engine Linux port
Post by: JanetC on 16 Oct 2015, 21:14
What bugs do we currently have on Wadjet Eye's Linux games and installers? I'm making a list for fixing. Have they been fixed in the latest version of the official engine?
Title: Re: AGS engine Linux port
Post by: Floob on 21 Feb 2016, 22:09
For those of you with a Raspberry Pi, here is a method to get it running with AGS.

Title: Re: AGS engine Linux port
Post by: Radiant on 20 Sep 2016, 23:44
Well, I've tried running the latest Linux build from TeamCity in a virtual machine running Ubuntu, and it works pretty well albeit at a poor framerate.

That's because of the VM setup, of course. Has anyone had success in running AGS in a VM? Or should I really have a dedicated Linux machine?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 21 Sep 2016, 00:00
Well, I've tried running the latest Linux build from TeamCity in a virtual machine running Ubuntu, and it works pretty well albeit at a poor framerate.

That's because of the VM setup, of course. Has anyone had success in running AGS in a VM? Or should I really have a dedicated Linux machine?
Except for VM being VM, Linux port does not support hardware acceleration at the moment, which means that all scaling is done by CPU.
Besides that, I experienced mouse issues on Ubuntu VM if mouse control is enabled in AGS (for mouse speed setting), but other people told me that they did not have similar issues on actual Linux machine.
Title: Re: AGS engine Linux port
Post by: Radiant on 21 Sep 2016, 07:14
Besides that, I experienced mouse issues on Ubuntu VM if mouse control is enabled in AGS (for mouse speed setting)
Thanks. What do you mean by this? I'd expect most AGS games to be mouse controlled.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 21 Sep 2016, 14:13
Besides that, I experienced mouse issues on Ubuntu VM if mouse control is enabled in AGS (for mouse speed setting)
Thanks. What do you mean by this? I'd expect most AGS games to be mouse controlled.
Sorry, I mean AGS directly controlling mouse position, instead of its position being read from the system and not adjusted. Since 3.3.5 AGS does that to implement cursor speed setting, but it is possible to disable by putting "control=never" string under "[mouse]" section in config. That also happens if mouse runs into screen border, and if you call Mouse.SetPosition from the script.
For some reason in all of those cases (simply running 3.3.5 engine fullscreen, for example) I got terrible mouse lag and weird behavior under virtual machine.
Title: Re: AGS engine Linux port
Post by: Radiant on 21 Sep 2016, 14:41
So by putting control=never in the config, it would act like 3.3.4 and before?

It also strikes me that having the game in a different color depth than the OS is a big slowdown. I'm not sure how well Linux deals with 320x200 fullscreen mode.
Title: Re: AGS engine Linux port
Post by: Radiant on 23 Sep 2016, 14:31
Is it correct that the Linux version ignores the windowed=1 and scaling parameters from the acsetup?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 23 Sep 2016, 15:31
Is it correct that the Linux version ignores the windowed=1 and scaling parameters from the acsetup?
No, it should read all the same parameters.

List of supported parameters for AGS 3.4.0: https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md
For 3.3.5: https://github.com/adventuregamestudio/ags/blob/release-3.3.5/OPTIONS.md
Title: Re: AGS engine Linux port
Post by: Radiant on 28 Sep 2016, 08:35
Thank you.

Since the engine under Linux tends to show a lot of MIDI warnings (which confuses users) and sometimes doesn't give music at all if MIDI is not found, would it be possible to have a Linux build with its MIDI functionality disabled? Personally I haven't used MIDI music in years, it's all OGG/MP3 these days as far as I can see.
Title: Re: AGS engine Linux port
Post by: JanetC on 29 Sep 2016, 20:50
I was pretty thrilled to see that the latest version of AGS has an option to build for Linux, but I'm not sure how it works. I tried to run the output on my CentOS installation, but no joy. I'm not all that knowledgeable about Linux. What's the status of the "Build for Linux" feature in AGS 3.4.0? What are the steps involved in getting it running?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 29 Sep 2016, 21:09
I was pretty thrilled to see that the latest version of AGS has an option to build for Linux, but I'm not sure how it works. I tried to run the output on my CentOS installation, but no joy. I'm not all that knowledgeable about Linux. What's the status of the "Build for Linux" feature in AGS 3.4.0? What are the steps involved in getting it running?
As far as I know it is guaranteed to work only on certain limited Linux systems, probably those derived from Debian. I know it should work on Debian and Ubuntu. But better consult with monkey0506 or BigMC about this.

For other systems you need to build Linux port from the repository source as usual. For that port you need to supply the contents of Compiled folder root (not subfolders) - that holds pure game data which may be deployed with any engine version (Windows, Linux etc).

NOTE: in the latest master branch state there is a distinct Compiled/Data subfolder that holds pure game data.
Title: Re: AGS engine Linux port
Post by: JanetC on 29 Sep 2016, 21:17
Thanks Crimson Wizard! That's cleared it up!
Title: Re: AGS engine Linux port
Post by: Radiant on 01 Oct 2016, 18:12
One user reports the following error/warning messages; is this something vital?

fixme:win:EnumDisplayDevicesW ((null),0,0x33f454,0x00000000), stub!
fixme:d3d:wined3d_device_decref Device released with resources still bound, acceptable but unexpected.
fixme:d3d:wined3d_device_decref Leftover resource 0x1903d8 with type WINED3D_RTYPE_SURFACE (0x1).
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:winediag:AUDDRV_GetAudioEndpoint Winepulse is not officially supported by the wine project
fixme:winediag:AUDDRV_GetAudioEndpoint For sound related feedback and support, please visit http://ubuntuforums.org/showthread.php?t=1960599
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:dsound:DSOUND_WaveFormat Limiting channels to 2 due to lack of multichannel support
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:win:EnumDisplayDevicesW ((null),0,0x33f864,0x00000000), stub!
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 01 Oct 2016, 18:18
One user reports the following error/warning messages; is this something vital?

fixme:win:EnumDisplayDevicesW ((null),0,0x33f454,0x00000000), stub!
fixme:d3d:wined3d_device_decref Device released with resources still bound, acceptable but unexpected.
fixme:d3d:wined3d_device_decref Leftover resource 0x1903d8 with type WINED3D_RTYPE_SURFACE (0x1).
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:winediag:AUDDRV_GetAudioEndpoint Winepulse is not officially supported by the wine project
fixme:winediag:AUDDRV_GetAudioEndpoint For sound related feedback and support, please visit http://ubuntuforums.org/showthread.php?t=1960599
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:dsound:DSOUND_WaveFormat Limiting channels to 2 due to lack of multichannel support
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:win:EnumDisplayDevicesW ((null),0,0x33f864,0x00000000), stub!
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.

This is probably from running under WINE? Because D3D does not work on Linux for obvious reasons.
I cannot immediately tell if these errors come from AGS or from WINE implementation...
Title: Re: AGS engine Linux port
Post by: Radiant on 04 Oct 2016, 19:22
Yes, turns out that was WINE output.
Title: Re: AGS engine Linux port
Post by: Radiant on 06 Oct 2016, 20:09
Several users report that the game runs in fullscreen despite having windowed=1 in its config. Any thoughts on what might cause this?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 06 Oct 2016, 21:21
Several users report that the game runs in fullscreen despite having windowed=1 in its config. Any thoughts on what might cause this?
Writing log (or copying console messages if engine is run from console) should explain everything.
Title: Re: AGS engine Linux port
Post by: Radiant on 07 Oct 2016, 07:34
Writing log (or copying console messages if engine is run from console) should explain everything.

Here you go,

Spoiler: ShowHide
ci_find_file: cannot change to directory: Compiled
Adventure Game Studio v3.4 Interpreter
Copyright (c) 1999-2011 Chris Jones and 2011-2016 others
ACI version 3.4.0.12

Initializing allegro
Reading configuration
Looking for game data file
Game data file: /home/rob/Errand/data/game.ags

Game data version: 43
Requested engine version: 3.3.0.1162
Setting up window
Initializing TTF renderer
Initializing mouse: number of buttons reported is 3
Checking memory
Initializing audio vox
Audio vox found and initialized.
Initializing keyboard
Install timer
Initialize sound drivers
Trying digital driver ID: 'Auto' (0xffffffff), MIDI driver ID: 'Auto' (0xffffffff)

Unable to initialize your audio hardware.
[Problem: /dev/sequencer: No such file or directory]
Installed digital driver ID: 'ALSA' (0x414c5341), MIDI driver ID: 'None' (0x0)
Install exit handler
Initialize path finder library
Load game data
Game data version: 43
Requested engine version: 3.3.0.1162
Game GUI version: 116
Errand
Checking for disk space
Initializing MOD/XM player
Initializing resolution settings
Game native resolution: 320 x 200 (32 bit)
Device display resolution: 1400 x 1050
Game settings: windowed = no, screen def: max, screen size: 0 x 0, match device ratio: yes, game scale: max_round
Using graphics factory: DX5
Created graphics driver: Allegro/DX5
Supported gfx modes (32-bit):
   640x480;800x600;800x600;1024x768;1280x1024;1400x1050;1600x1200;1680x1050;
   1920x1080;1920x1600;2048x1536;2560x1440;2560x1600;
Supported gfx modes (24-bit):
   640x480;800x600;800x600;1024x768;1280x1024;1400x1050;1600x1200;1680x1050;
   1920x1080;1920x1600;2048x1536;2560x1440;2560x1600;
Requested gfx filter: StdScale
Using gfx filter: StdScale
Switching to graphics mode
Attempting to find nearest supported resolution for screen size 1400 x 1050 (32-bit) fullscreen
Attempt to switch gfx mode to 1400 x 1050 (32-bit) fullscreen; game frame: 1280 x 800
Succeeded. Using gfx mode 1400 x 1050 (32-bit) fullscreen
   filter dest (60, 125, 1339, 924 : 1280 x 800), render dest (60, 125, 1339, 924 : 1280 x 800)
Preparing graphics mode screen
Initializing colour conversion
Mouse control: off, base: 1.000000, speed: 1.000000
Check for preload image
Initialize sprites
Set up screen
Initialize game settings
Cannot open translation: default.tra
Prepare to start game
Mouse confined: (60,125)-(1339,924) (1280x800)
Audio is processed on the main thread
Checking replay status
Engine initialization complete
Starting game
***** ENGINE HAS SHUTDOWN
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 07 Oct 2016, 14:12
It sais "windowed = no" in log.
Maybe they put windowed=1 into wrong section? Name of the section has changed in 3.4.0, now display mode is set up in "[graphics]".
TBH I had a request to support old configs, which may be a good idea to add.
Title: Re: AGS engine Linux port
Post by: Radiant on 07 Oct 2016, 14:14
It sais "windowed = no" in log.
Maybe they put windowed=1 into wrong section? Name of the section has changed in 3.4.0, now display mode is set up in "[graphics]".
TBH I had a request to support old configs, which may be a good idea to add.

Aha, that explains it. I was using the config file from an earlier version, and did not know that fullscreen had to be moved (and linux doesn't have a GUI for config). Note that this is an issue for backwards compatibility: if you take an earlier-version game and open it with the 3.4 engine, it will not work as expected.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 07 Oct 2016, 14:28
Aha, that explains it. I was using the config file from an earlier version, and did not know that fullscreen had to be moved (and linux doesn't have a GUI for config). Note that this is an issue for backwards compatibility: if you take an earlier-version game and open it with the 3.4 engine, it will not work as expected.
Yes, that may be an annoying issue, I am not sure why but I forgot to keep support for old settings.
New options are explained here: https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md
Title: Re: AGS engine Linux port
Post by: Radiant on 07 Oct 2016, 14:55
Sounds like a five-minute fix, no? :)

If I understand correctly, I should set auto_lock to 0 on Linux; and the log=1 command will write startup messages to a logfile instead of to stdout / stderr?
Title: Re: AGS engine Linux port
Post by: Radiant on 07 Oct 2016, 20:28
Wait, do the config settings digiwin, midiwin, digiindx, midiindx, digiwinindx, and midiwinindx (automatically generated in earlier versions) still do anything? What about gamecolordepth, defaultres, screenres, letterbox, defaultgfxdriver, and titletext; or the [disabled] section in the config file? If not, as of which version are they ignored? Does it harm anything if they're still present?

Also, is there something I can pass to midiid to disable midi entirely (since it causes error messages)?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 07 Oct 2016, 21:30
Wait, do the config settings digiwin, midiwin, digiindx, midiindx, digiwinindx, and midiwinindx (automatically generated in earlier versions) still do anything? What about gamecolordepth, defaultres, screenres, letterbox, defaultgfxdriver, and titletext; or the [disabled] section in the config file? If not, as of which version are they ignored? Does it harm anything if they're still present?

Yes, this list misses some options, mainly ones that are only required for winsetup (not engine).

digiwinindx and midiwinindx are used only on Windows. They define internal index of audio in AGS.
digiid and midiid are used on all other platforms. They contain packed ID of the Allegro's audio driver
digiwin and midiwin are some old options, that were never used by engine since AGS 3.2.1 at least (when we got open source).

defaultres, letterbox, gamecolordepth, as well as newer game_width and game_height options are describing game properties for setup program, but they are passed by the engine now, and ones in config are ignored. This is done for safety, because config content may be erroneous.

screenres was obsoleted since somewhere around 3.1, I think. It meant selection between low-res and high-res version of the game in the times when there were no scaling filters. It is potentially possible to support it again (currently you get similar effect using "upscale" options from "override" section).

titletext should be working.

defaultgfxdriver is obsoleted, and honestly I do not remember why it was required for setup.

disabled section should be working, and supporting following items: "speechvox",  "16bit", "filters" and separate filter names.


Also, is there something I can pass to midiid to disable midi entirely (since it causes error messages)?
You can pass MIDI_NONE id. However as I found out, with Allegro it is not always obvious what's causing trouble exactly. For instance, I did not find way to get a separate error message for MIDI, because the only audio initialization function initialzes both MIDI and digitial sound at once. So only way to know which works is to call it several times with different combinations of "on/off" (which may be noticed in logs).

If you are on Windows, set "midiwinindx = 1" for no midi driver.
On all other platforms (Linux etc) set "midiid = 0".
Title: Re: AGS engine Linux port
Post by: Radiant on 08 Oct 2016, 20:58
Thanks for the info!

digiwinindx and midiwinindx are used only on Windows. They define internal index of audio in AGS.
I suppose that corresponds to the pulldown in the winsetup menu. I've never seen reason to change these from their defaults.

Quote
digiid and midiid are used on all other platforms. They contain packed ID of the Allegro's audio driver
So how does a player know what the valid values are? Or should I just leave them at -1 which appears to be the default?

Quote
You can pass MIDI_NONE id.
Thanks, I'll have to check that. The cause is that most Linux distros don't include MIDI libraries available in their default installation, although I suppose you could apt-get them.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 08 Oct 2016, 21:12
Quote
digiid and midiid are used on all other platforms. They contain packed ID of the Allegro's audio driver
So how does a player know what the valid values are? Or should I just leave them at -1 which appears to be the default?
No way except for looking into which ids allegro supports. These IDs are 32-bit integers, each byte equals to the code of the letter. 4-letters form a meaningful id. Having these options as integers instead of strings is absolutely not the best way, but this is how they remain since earlier versions of ags.

0 = none
-1 = auto-detect.
Title: Re: AGS engine Linux port
Post by: Radiant on 12 Oct 2016, 23:15
Turns out gfxfilter=StdScale2 also no longer works in newer AGS versions (meaning they'll ignore it if it was in an earlier config file, and pick the default instead).
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 13 Oct 2016, 00:16
Turns out gfxfilter=StdScale2 also no longer works in newer AGS versions (meaning they'll ignore it if it was in an earlier config file, and pick the default instead).
Of course not, as I mentioned above, all the old graphics options were replaced.
I am working on reading old options now.
Title: Re: AGS engine Linux port
Post by: Danvzare on 13 Oct 2016, 10:38
I am working on reading old options now.
I thought you weren't going to work on the AGS engine anymore? ???
Not that I'm complaining of course. :-D
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 13 Oct 2016, 13:41
I will have to stick around for some time fixing problems in the latest version.
Title: Re: AGS engine Linux port
Post by: Radiant on 13 Oct 2016, 13:52
Much as I appreciate your work, please don't feel obliged to do so, especially if it stresses you out. The new version is perfectly usable, so you really don't have to stick around to fix every detail. Go make a cool game already :)
Title: Re: AGS engine Linux port
Post by: Radiant on 22 Nov 2016, 21:22
Playtesting reveals that under Linux, Steam achievements don't work. It may be the case that I'm using the wrong (or outdated) version of libagsteam.so and libsteam_api.so; can someone tell me where to find the correct ones please?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 22 Nov 2016, 22:01
Playtesting reveals that under Linux, Steam achievements don't work. It may be the case that I'm using the wrong (or outdated) version of libagsteam.so and libsteam_api.so; can someone tell me where to find the correct ones please?
AFAIK in previous times monkey0506 could only provide plugin stub for Linux, which essentially does nothing (only preventing AGS from bailing out with "plugin function not found" error).
I heard that later he was able to make a working one for Linux, when Valve updated steam API, or license, or something along those lines.
I think it it better to ask in the steam plugin thread for details: http://www.adventuregamestudio.co.uk/forums/index.php?topic=44712.0
There was also a unified client project, that supposedly should work for Steam, GOG etc, all in one, and date of release in newer: http://www.adventuregamestudio.co.uk/forums/index.php?topic=52432.0

 
Title: Re: AGS engine Linux port
Post by: Radiant on 23 Nov 2016, 07:32
Ok, thank you!
Title: Re: AGS engine Linux port
Post by: Radiant on 01 Dec 2016, 22:14
Players point out that under Linux in Steam (with the AGSteam library), the Steam overlay doesn't actually show. Does anyone have experience with this?
Title: Re: AGS engine Linux port
Post by: Radiant on 26 Dec 2016, 18:40
A player notes that the AGS engine doesn't work well on Ubuntu Mate, reporting problems with audio playback and with a single screen being spread over two desktop windows. Does anyone have experience with this? I'm not familiar with the "mate" version of Ubuntu.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 26 Dec 2016, 19:03
A player notes that the AGS engine doesn't work well on Ubuntu Mate, reporting problems with audio playback and with a single screen being spread over two desktop windows. Does anyone have experience with this? I'm not familiar with the "mate" version of Ubuntu.
Both of those two problems were reported before.

But I guess we must just admit that AGS does not support Linux. Over years no one actually took on maintaining the Linux version, so the chances anything will be fixed are close to zero.
Same goes for the other ports.
Title: Re: AGS engine Linux port
Post by: morganw on 26 Dec 2016, 19:38
I don't think using Mate instead of anything else would affect the screen being spread over two monitors, and I think ScummVM has the the same issue. Going fullscreen should go to the primary display. For the sound, I've only seen the audio break-up or stutter because of the display scaling increasing the CPU usage of Xorg; you might want to suggest running the game with no scaling and see if that fixes the audio.
Title: Re: AGS engine Linux port
Post by: 2ma2 on 18 Jan 2017, 19:58
But I guess we must just admit that AGS does not support Linux. ...

Would the "official" unofficial stance be 'better run it with Wine' instead of 'run it natively with the Linux port'? (I'm not speaking as a dev but as a user.)
Title: Re: AGS engine Linux port
Post by: morganw on 20 Jan 2017, 22:17
Unofficially, I would say that you will get less rendering issues with the native port but you need a decent-ish CPU to cover the scaling overhead. I've used it with a few different desktop environments and also built and used it on PowerPC, it's been fine in most cases. I've not tried with Hi-DPI though.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 20 Jan 2017, 22:30
Unofficially, I would say that you will get less rendering issues with the native port but you need a decent-ish CPU to cover the scaling overhead.
We need to make OpenGL renderer working properly on Linux to solve this. It kinda works for other ports now, but it was never made to compile for Linux. Maybe it's not too hard to do, just someone needs to find time to look into this.
Title: Re: AGS engine Linux port
Post by: Georgeqgreg on 25 Jan 2017, 04:18
For me, sound in AGS 3.4 Linux port is distorted and really fast. (like, double speed)
Ubuntu 14.04, desktop environment doesn't seem to matter, happens in Unity and Xfce, AGS 3.3 engine is fine.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Jan 2017, 18:17
For me, sound in AGS 3.4 Linux port is distorted and really fast. (like, double speed)
Ubuntu 14.04, desktop environment doesn't seem to matter, happens in Unity and Xfce, AGS 3.3 engine is fine.

I cannot think of anything that has changed in regards to sound in between those versions. Do you build engine yourself, or use prebuilt binaries?
Title: Re: AGS engine Linux port
Post by: Georgeqgreg on 25 Jan 2017, 18:22
First I tried the prebuilt binaries (included with the AGS Editor, which I've been using on Wine, but that's another story.) and then I tried building my own when I noticed problems. The only difference is that the one I built was for some reason HUGE. (20MB!) Uhh, but sound was still as messed up. Interestingly, the sound seems faster if I switch to my laptop's built in speakers, compared to HDMI speaker output. (Setting wrong sample rate?)
Title: Re: AGS engine Linux port
Post by: morganw on 25 Jan 2017, 19:18
It sounds a lot like this:
http://askubuntu.com/questions/492467/sound-problems-in-ubuntu-14-04 (http://askubuntu.com/questions/492467/sound-problems-in-ubuntu-14-04)

You could try removing your pulseaudio configuration or try to set the default format and sample rate:
http://manpages.ubuntu.com/manpages/trusty/man5/pulse-daemon.conf.5.html (http://manpages.ubuntu.com/manpages/trusty/man5/pulse-daemon.conf.5.html)
Title: Re: AGS engine Linux port
Post by: Georgeqgreg on 25 Jan 2017, 19:35
Indeed, as I thought about this issue, I began to wonder if it was an ALSA issue, then I remembered that when I first started using Ubuntu some games had problems with distorted audio. (Psychonauts comes to mind, if for only how it happened.)

Ahem, however, it seems I've already followed the instructions in the first link, and nothing else seems to have regressed to having problems. (Not sure what I'm supposed to do with the second link.)

One odd thing I observed was when doing some audio work in Audacity, I noticed sometimes when I'd press play the sound would play like in the current AGS, fast and distorted, for about a second before Audacity somehow fixes itself and makes the sound normal. You can even see the little needle move at light speed... weird.

But what really has me stumped is how older AGS versions run just fine. (Specifically, the GOG build of Quest for Infamy still works, and I seem to recall Steam and Humble versions of The Shivah and Gemini Rue working fine too.)

UPDATE: Hey, guess what guys? After messing with the PulseAudio default.pa (and I think at this point Pulse was the culprit) I eventually decided to restore my original config, with a key difference.

So you know how morganw earlier posted a link that suggested to add tsched=0 to fix audio problems? Well, months earlier, when I first started using Ubuntu, (And indeed, any GNU/Linux distro regularly) I did that because Psychonauts, and like, half my other Steam games, had audio problems. But guess what? when I removed it AGS 3.4 works. And it doesn't break Psychonauts, or any other game currently on my hard drive either! So if it's all the same to you guys I'm just gonna throw my arms up and chant "PULSEAUDIO IS WEIRD."

(The reason I remember Psychonauts specifically... when I first tried it, I had accidentally set audio for 22db amplification. Combine that with the fact that Psychonauts, like most linux games, locks mouse and keyboard input... yeah.)
Title: Re: AGS engine Linux port
Post by: Radiant on 11 Feb 2017, 12:26
A player on Linux Mint reports that in Heroine's Quest, the music comes through has garbled and the voices are speaking too fast to comprehend. Does anyone recognize this? We don't usually test on Mint but there appears to be no reason why it shouldn't work.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 11 Feb 2017, 14:04
A player on Linux Mint reports that in Heroine's Quest, the music comes through has garbled and the voices are speaking too fast to comprehend. Does anyone recognize this? We don't usually test on Mint but there appears to be no reason why it shouldn't work.

There are three posts just above your question, that discuss very similar issue. I think they also mentioned a possible solution. Haven't tried that myself yet.
Title: Re: AGS engine Linux port
Post by: Radiant on 11 Feb 2017, 15:39
Great, thanks for the tip.
Title: Re: AGS engine Linux port
Post by: vdeG on 20 Apr 2017, 17:51
Hi!

  I got a question for you guys concerning AGS on Linux;
  I built a fresh Raspberry Pi with the latest Retropie image (4.2)
  I only installed the AGS emulator (which installed all of the packages needed as in the README); they are all up-to-date.
  I downloaded King's Quest 3 Redux, installed it on my PC and then transferred all the files on my MicroSD for my Raspberry Pi.
  When I launch the game (via EmulationStation or commandline), the game is running fine, BUT, the voice acting is not working :( (It is working from my PC with the same files/acsetup.cfg)
  The sound effect and music are working though..
  The file speech.vox is there (I even tried to rename it to SPEECH.VOX). When I launch it from the commandline, I can see a line that notify that the speech file has been found..
  What should I do to make the voice acting work?

  Also, when launching the game, I have an error when it is supposed to play the cinematic of the developers; I got an error that it couldn't run the Theora video (something like AGDI.0GV).
  I don't know if this is normal, since it is on Linux.

Thanks!!
 
Title: Re: AGS engine Linux port
Post by: sigmich on 12 Jun 2017, 13:53
I've built latest ags engine from git repository (v3.4) on my two Ubuntu 16.04 x64 machines. But speech (voice acting) doesn't work. I am trying it with Wadjet Eyes Games. I've tried so far Blackwell Legacy, Shardlight and Technobabylon. It is the same in all games. It seems there are no other issues instead of missing voice acting.

It seems similar problem as has the poster before me - vdeG.

Any hints how to solve it?
Title: Re: AGS engine Linux port
Post by: sigmich on 12 Jun 2017, 14:20
Sorry for spaming but I only want to post that problem is solved. Everything works flawlessly incl. voice acting using already built executables downloaded from here http://www.adventuregamestudio.co.uk/forums/index.php?topic=54513.0
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 12 Jun 2017, 16:19
There was a known issue that voice-over does not work properly in latest master branch and release-3.4.1 branch. It was recently fixed 3.4.1 branch, but not merged to master yet (and not released yet too). Better build/use v3.4.0.16 on Linux for now.
Title: Re: AGS engine Linux port
Post by: Radiant on 15 Jul 2017, 23:11
Is there a way to either use AgsJoy in Linux, or at least a stub to keep a joypad-based game from crashing under Linux (because the DLL isn't there)?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 16 Jul 2017, 14:07
Is there a way to either use AgsJoy in Linux, or at least a stub to keep a joypad-based game from crashing under Linux (because the DLL isn't there)?

I answered similar question here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=45348.msg636560971#msg636560971

Other than that, hack engine code and integrate dummy functions linked to plugin function names.


EDIT: I just noticed that we already have agsjoy stubs in the engine. Now I recall that there was an opened issue about some stubs missing.
If I had a full list of functions, I could add them.
Title: Re: AGS engine Linux port
Post by: Radiant on 16 Jul 2017, 15:59
EDIT: I just noticed that we already have agsjoy stubs in the engine. Now I recall that there was an opened issue about some stubs missing.
If I had a full list of functions, I could add them.

Here you go:

bool IsJoyBtnDown (int button);
bool JoystickRescan ();
bool Unplugged ();
bool Valid ();
int GetAxis (int axis);
int JoystickCount ();
static bool IsOpen (int ID);
static Joystick* Open (int ID);
static void Click (MouseButton button);
String GetName ();
String JoystickName (int ID);
void Close ();
void DisableEvents ();
void EnableEvents (int scope = 0);
void Update ();
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 11 Aug 2017, 00:30
Radiant, I downloaded latest version of agsjoy plugin, and it does not have "IsJoyBtnDown" function, only Joystick.IsButtonDown. Is it a function from some older version?
Title: Re: AGS engine Linux port
Post by: Radiant on 11 Aug 2017, 07:38
That's possible, I was not aware there had been an update to this one. My version is labeled 1.2.0.0, by Ferry "Wiz" Timmers 2010, file size 90112 bytes. But this thread here (http://www.adventuregamestudio.co.uk/forums/index.php?topic=41658.0) also reads 1.2.0.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 11 Aug 2017, 07:44
Could you upload your version somewhere?
Title: Re: AGS engine Linux port
Post by: Radiant on 11 Aug 2017, 07:48
Here you go: http://crystalshard.net/test/agsjoy.dll
Where did you get your version, if it wasn't from that thread (http://www.adventuregamestudio.co.uk/forums/index.php?topic=41658.0)?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 11 Aug 2017, 14:48
Where did you get your version, if it wasn't from that thread (http://www.adventuregamestudio.co.uk/forums/index.php?topic=41658.0)?
It was from that thread, I clicked on Download v1.2.0 link.
Title: Re: AGS engine Linux port
Post by: Radiant on 11 Aug 2017, 15:23
Ok. Well let's go with that one, I'll sort things out on my end :) Thank you for your help.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 11 Aug 2017, 15:34
There actually IS "IsJoyBtnDown" function in your version of plugin. I believe I should add it too in case that was used in any released game.
Title: Re: AGS engine Linux port
Post by: Radiant on 11 Aug 2017, 15:51
It is, yes (e.g. Vector Vendetta).
Title: Re: AGS engine Linux port
Post by: eri0o on 09 Sep 2017, 00:14
Hey! I have a small problem on MY COMPUTER but I don't know how to solve. I built the Linux engine in Ubuntu 16.04 and if I try running a game with it, it's excruciatingly slow. So I test and run my own game using Wine. I have Steam in this computer too. I play the Wadjet Eye games and they all work well. When I tried running Until I Have You from Steam it ran as bad as my own built Linux Engine, so I guess there is something more to it. I don't have much installed on this Ubuntu computer since I mostly use it only for developing my game in Adventure Game Studio (with Wine).

My computer config is: i7-7500U CPU @ 2.70GHz, Video is Intel HD Graphics 620 - Kabylake GT2, 16GB RAM, 512GB SSD. Also it's not heating or anything and I can run some fairly heavy stuff on this notebook.
My kernel (cat /proc/version): Linux version 4.10.0-33-generic (buildd@lgw01-22) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #37~16.04.1-Ubuntu SMP Fri Aug 11 14:07:24 UTC 2017


I am posting this in case someone have any idea what's wrong, if I have some wrong library installed...
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 09 Sep 2017, 01:55
Hey! I have a small problem on MY COMPUTER but I don't know how to solve. I built the Linux engine in Ubuntu 16.04 and if I try running a game with it, it's excruciatingly slow. So I test and run my own game using Wine. I have Steam in this computer too. I play the Wadjet Eye games and they all work well. When I tried running Until I Have You from Steam it ran as bad as my own built Linux Engine, so I guess there is something more to it. I don't have much installed on this Ubuntu computer since I mostly use it only for developing my game in Adventure Game Studio (with Wine).

Linux port has only software renderer available at the moment, which runs slow, especially if game scales to larger display resolution. That would be my first guess. On Wine you have Direct3D and OpenGL (if you are using AGS 3.4.1).

The solution would be to make OpenGL renderer work on Linux, which may be trivial, except someone needs to make such change (this also requires a knowledge of what headers/libraries to add to the engine).
Title: Re: AGS engine Linux port
Post by: sigmich on 25 Sep 2017, 20:24
I have similar problem. In fullscreen games are running very slow with AGS engine 3.3 or 3.4.0 or 3.4.1 on my laptop. It is absolutely unplayable because it takes few minutes to even get over the first logo in the game. The screens are showing (drawing) slowly from top to down.

Games run fine in windowed mode or when I run them fullscreen with officially packed ags from GOG or when I run them on my desktop PC (different hardware). My graphic card in laptop is nvidia 840m = Nvidia Optimus card. It is interesting that using Wayland games runs also fine in fullscreen but keyboard doesn't work in game.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Sep 2017, 20:37
Games run fine in windowed mode or when I run them fullscreen with officially packed ags from GOG

Could you elaborate, what "officially packed ags from GOG" is?
Title: Re: AGS engine Linux port
Post by: sigmich on 25 Sep 2017, 21:16
Games run fine in windowed mode or when I run them fullscreen with officially packed ags from GOG

Could you elaborate, what "officially packed ags from GOG" is?

GOG.com sells Wadjet Eye games. I've bought all of them. Some of them have official linux versions which install game. I suppose there is bundled ags in every game installation. For example if I run A Golden Wake it runs fine fullscreen:

./A_Golden_Wake.bin.x86_64
AGS: Adventure Game Studio v3.3 Interpreter
Copyright (c) 1999-2011 Chris Jones and 2011-20xx others
ACI version 3.3.0.1132

AGS: ***** ENGINE STARTUP
AGS: Reading config file
AGS: Initializing allegro
AGS: Setting up window
AGS: Initializing game data
AGS: Initializing TTF renderer
AGS: Initializing mouse
AGS: Checking memory
AGS: Initializing speech vox
Speech sample file found and initialized.
AGS: Initializing audio vox
Audio vox found and initialized.
AGS: Initializing keyboard
AGS: Install timer
Checking sound inits.
AGS: Initialize sound drivers
AGS: Install exit handler
AGS: Initialize path finder library
AGS: Initialize gfx
AGS: Load game data
AGS: A Golden Wake
AGS: Checking for disk space
AGS: Initializing MOD/XM player
AGS: Initializing screen settings
AGS: Init gfx filters
AGS: Init gfx driver
AGS: Switching to graphics mode
AGS: Widescreen side borders: disabled in Setup
AGS: Attempt to switch gfx mode to 320 x 200 (32-bit)
AGS: Succeeded. Using gfx mode 320 x 200 (32-bit)
AGS: Preparing graphics mode screen
AGS: Initializing colour conversion
AGS: Check for preload image
AGS: Initialize sprites
AGS: Set up screen
AGS: Initialize game settings
AGS: Prepare to start game
AGS: Checking replay status
AGS: Engine initialization complete
AGS: Starting game
AGS: Loading room 83
AGS: Room change requested to room 82
AGS: Unloading room 83
AGS: Loading room 82
AGS: Room change requested to room 0
AGS: Unloading room 82
AGS: Loading room 0
AGS: ***** ENGINE HAS SHUTDOWN
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Sep 2017, 21:18
So, you are saying that these packed by GoG run fine for you, but when you build engine yourself it runs slow? I was wondering what could be the difference.
Unfortunately, I am not an expert in Linux, but maybe someone could do an investigation.
Title: Re: AGS engine Linux port
Post by: sigmich on 25 Sep 2017, 21:24
So, you are saying that these packed by GoG run fine for you, but when you build engine yourself it runs slow? I was wondering what could be the difference.

Yes, exactly. And when I build the same version of engine myself on the same system (Debian Stretch 64bit) but on different hardware (nvidia gtx 1050 vs nvidia optimus 840m) it also runs fine fullscreen.
Title: Re: AGS engine Linux port
Post by: eri0o on 26 Sep 2017, 02:45
Hey, which processor? I have similar performance issues on Until I Have Vou using KabyLake, but it works on my Sandy Bridge and Ivy Bridge laptops. Everything with Ubuntu 16.04 .
Title: Re: AGS engine Linux port
Post by: sigmich on 26 Sep 2017, 20:42
Hey, which processor? I have similar performance issues on Until I Have Vou using KabyLake, but it works on my Sandy Bridge and Ivy Bridge laptops. Everything with Ubuntu 16.04 .

I haven't Kabylake CPU.

There is:
in Laptop PC - i5-5200U (Broadwell)
in Desktop PC - Q6600 (Kentsfield)
Title: Re: AGS engine Linux port
Post by: Dave Gilbert on 27 Sep 2017, 20:32
I know GOG wraps the games in WINE, which isn't something I really know much about. Which is why it's available exclusively on GOG.
Title: Re: AGS engine Linux port
Post by: sigmich on 30 Sep 2017, 20:38
I know GOG wraps the games in WINE, which isn't something I really know much about. Which is why it's available exclusively on GOG.

Are you sure about it? It doesn't seem to me to be Wine wrapped. Same games with linux support are also available on Steam.

I was using Wine playing Technobabylon before I've found that it runs great using ags engine natively for linux. I experienced some issues using wine but it was playable. Using native ags engine for linux was perfect as well as installed packages from GOG. So I presume GOG is running native linux ags. I also don't see any running wine process in htop or another process manager playing GOG installment.

I suppose that issue I have now is hardware related using hybrid nvidia card on debian with bumblebee. Maybe I'm wrong. But on my another desktop PC native linux ags runs any ags game without any problem.

Anyway thanks for the great games! ;-)
Title: Re: AGS engine Linux port
Post by: sigmich on 01 Oct 2017, 18:51
... it's excruciatingly slow ...

Have you tried windowed mode? It has completely solved slowness for me and I have no problem playing adventure games this way until fix.

Title: Re: AGS engine Linux port
Post by: sigmich on 01 Oct 2017, 20:28
Information for linux gamers interested and absolutely new and unexperienced to this like me. Sorry for spaming if it's too obvious for someone. Launching games windowed could make bottom lines of text in game unreadable and unclickable. So I have to launch ags with gfxfilter option:

ags --gfxfilter stdscale 4 --windowed

You can set the different number from 1 to 4 to best fit to your monitor.

If launching ags without any gfxfilter it runs fine even fullscreen but it's too tiny:
ags --gfxfilter none --fullscreen
or
ags --gfxfilter stdscale 1 --fullscreen
Title: Re: AGS engine Linux port
Post by: Radiant on 24 Oct 2017, 20:14
My Linux build gives the following error,

ERROR: ld.so: object '/home/gamer/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory

Does this look familiar? The second line appears to be Steam initializing a 32-bit library for a 64-bit game, and the second line appears to be AGS trying to initialize MIDI on a system that doesn't have MIDI drivers installed. Any suggestions on how to fix this please? The engine is timestamped 5-11-2016, I think that's the latest 3.3 release.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Oct 2017, 10:11
My Linux build gives the following error,

ERROR: ld.so: object '/home/gamer/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory

For MIDI problem, there was this issue and potential workaround posted:
https://github.com/adventuregamestudio/ags/issues/367
Title: Re: AGS engine Linux port
Post by: Radiant on 25 Oct 2017, 11:00
Thanks, I'll add that. That leaves the 32bit / 64bit conflict... maybe my shellscript that detects this doesn't work properly on all versions of Linux?

(edit) wait, that workaround is for setting MIDI to device 2 in the specific case that device 0 doesn't exist but device 2 does; but we can't just assume that everybody's going to have Timidity installed, either. Is there an Allegro config line for omitting Midi entirely?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Oct 2017, 11:13
(edit) wait, that workaround is for setting MIDI to device 2 in the specific case that device 0 doesn't exist but device 2 does; but we can't just assume that everybody's going to have Timidity installed, either. Is there an Allegro config line for omitting Midi entirely?

Did you try setting "midiid = 0" in the acsetup.cfg? That will make AGS initialize allegro with MIDI_NONE parameter. But I do not know exactly under which condition Allegro attempts to open that device.
Also, is this ALSA message a fatal error or just warning? Earlier I got an impression that it may be ignored if having MIDI sound is not necessary.
Title: Re: AGS engine Linux port
Post by: Radiant on 25 Oct 2017, 13:16
Did you try setting "midiid = 0" in the acsetup.cfg?
Ah, that should work, thakns. I'm currently using midiid = -1, which I assume means "pick the default".

(edit) Wait again, per this bug report (http://www.adventuregamestudio.co.uk/forums/index.php?issue=552.0), if you use the ACSetup tool to set MIDI to off, then AGS will play no music at all. Was this fixed at some point? Your fix in that ticket suggests the opposite (it fixes MIDIs not playing when DIGIs are disabled, but my issue is DIGI music not playing when MIDI is disabled...)

Quote
Also, is this ALSA message a fatal error or just warning?
I think this is a warning and the other message (about 32bit vs 64bit) is the fatal error.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Oct 2017, 13:36
(edit) Wait again, per this bug report (http://www.adventuregamestudio.co.uk/forums/index.php?issue=552.0), if you use the ACSetup tool to set MIDI to off, then AGS will play no music at all. Was this fixed at some point? Your fix in that ticket suggests the opposite (it fixes MIDIs not playing when DIGIs are disabled, but my issue is DIGI music not playing when MIDI is disabled...)

There were two contrary issues, supposedly fixed in two sequential patches, according to changelog:

- Fixed MIDI music refuses to start if digital sound is disabled. (in AGS 3.3.4, July 2015)
- Fixed legacy audio functions did not start digital music playback if MIDI driver failed to initialize. (in AGS 3.3.5, March 2016)

Is it still not working?

Also, in regards to general issue with MIDI, I will repost my answer from another thread, since its more relevant here -
I've mentioned this before, that it is not AGS that insists on initializing MIDI anymore. There is one Allegro API function that initializes all sounds, and all AGS can do is to try it with different parameters (MIDI/DIGI, no MIDI/DIGI MIDI/ no DIGI, etc) until it returns positive answer.
That's a good point, but it may be that the first function call (for MIDI+DIGI both, if I understand correctly) is causing problems in Allegro.

Yes, it could be; I think this may be tested out by disabling MIDI in setup file ("midiid = 0"), then sound init will be called with DIGI/ no MIDI at the first try. If that works, unlike other attempts, then adding a MIDI-disabling switch will have an actual meaning.
Title: Re: AGS engine Linux port
Post by: Radiant on 30 Oct 2017, 09:42
I'm curious what the default folder is for running a Linux game? What my game does is check for .TRA files in the game's folder to show an in-game language selection window. This works fine in Windows, but in Linux it appears to be unable to find any of these files?


(the MIDI issue was not on my system, I'm still waiting to hear back from that particular player)
Title: Re: AGS engine Linux port
Post by: morganw on 04 Jan 2018, 20:47
Were you using the tag that expands to get the actual game directory?

Quote from: the manual
When specifying file path you may use special location tags:
$INSTALLDIR$, which allows you to explicitly read files in the game installation directory.
Title: Re: AGS engine Linux port
Post by: Radiant on 25 Jan 2018, 21:31
A player reports AGS running excessively slow when using any form of scaling.

"I can run the game without issue if I set it to run windowed at the standard 320x200 size that the art was done in, but I get a tonne of lag from the game when I set it to scale any amount. My CPU is at 15% when running at the unscaled size, and it is at 50% when scaled. I run a current Archlinux distro using the standard repositories. I run it with the Awesome window manager. Steam is the only other thing running when it happens.

CPU: Intel Centrino Duo: 2GHz
Memory: 4GB
Graphics: ATI Radeon HD 3470 with 256 MB onboard memory"

Any suggestions on how to help this player? Thanks!
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 Jan 2018, 21:33
Any suggestions on how to help this player?

Help implementing OpenGL renderer for Linux... :(

(or porting to SDL2/Allegro5)
Title: Re: AGS engine Linux port
Post by: morganw on 26 Jan 2018, 00:02
I found that fullscreen slowdown seems dependent on the graphics driver, as I lost all fullscreen slowdown when switching from on-board AMD graphics to an old AMD card. Is it still slow if scaled and using fullscreen mode, rather than a window? Otherwise the only solution I found was to change to a lower desktop resolution to remove the need for scaling.

I did go through the engine code to check where the slowdown is, and it did just seem to be the actual drawing to the display that caused the majority of the CPU load. I did change one thing which may drop CPU usage slightly (about 5 - 10% for me) so running on a recent engine build might give a slight improvement. You might suggest they try building the engine, as I would imagine someone using Arch would be okay with doing that.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 26 Jan 2018, 00:29
Help implementing OpenGL renderer for Linux... :(

Just to elaborate, assuming that OpenGL calls are more or less the same, or Linux function names could be translated using defines (same as we do for Android and iOS), making OpenGL renderer work on Linux might be a matter of:
* finding which headers to include and libraries to link;
* updating Linux-specific system code to make it switch to fullscreen with OpenGL properly (but even that is optional, since you can run always in window).

So, maybe finding a Linux coder who just knows how to link OpenGL to program may be sufficient.
Title: Re: AGS engine Linux port
Post by: morganw on 26 Jan 2018, 19:57
Do you think the built in Allegro 4 OpenGL wrapper would be usable?
https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL) (https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL))
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 26 Jan 2018, 21:04
Do you think the built in Allegro 4 OpenGL wrapper would be usable?
https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL) (https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL))

I wish we knew and used that years ago; I am afraid it will be more complicated to integrate that now.
Title: Re: AGS engine Linux port
Post by: null.painter on 25 May 2018, 16:20
TLDR; New user here - curious about the state of the port, and suggested methods for users who run into scaling slowdown issues. Solutions using emulation (wine, dosbox, whatever) are fine with me - I'm a fairly capable user.

Hi, I'm new here - so sorry to post if I've gotten the wrong forum or necro'ed this post inappropriately.

I'm a Linux user/gamedev who is interested in the possibilities of AGS. I actually came here via reading about Heroine's quest and wanting to give it a try, only to find it struggling on my machine. After some research and experimentation, it seems that I am falling prey to the scaling issue - game runs well without scaling, is terribly slow with any amount of scaling. I've read up and it looks like the issue is/was due to poor support for Linux graphics drivers (OpenGL?) by Allegro?

I don't see any recent activity around this (and I saw mentions that there are not linux-focused maintainers on the team, hard legacy code, etc) and was wondering what the current state of affairs was around this issue? This seems like a really cool and active community, and like a good tool, so I thought I'd ask some questions before dropping the idea entirely.

Are there any current workarounds for linux users to run AGS games that work well? I'm fine with using WINE (or DosBox, or whatever), personally (I haven't given it a try to see if it is feasible yet, but am about to), but is there a native solution? Perhaps designing assets so that they don't need to be scaled? I partly just want to try such a highly-regarded game, but I am also curious about using the engine for my own projects, but am concerned about ease of distribution for linux users - it's becoming a mainstream enough OS that I don't expect all users to be powerusers, anymore...

At any rate, I'm happy to see such a lively community still pushing ahead with these type of games!
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 25 May 2018, 18:15
null.painter, hello.

I had plans to look into supporting OpenGL renderer on Linux in the past, after making it work on Windows, and it seemed like a matter of finding which header to include and libraries to link, and maybe fixing few issues, but I never really got to try.

There is a work by Nick Sonneveld who is currently writing SDL2 backend for Allegro4 (which lets running engine on SDL2 through Allegro interface, thus not requiring to rewrite big portions of the engine itself). Recently eri0o mentioned that he managed to build and run one on Linux, and it worked much faster.

I hope eri0o may comment on that himself, but unless I am mistaken, this port may be found here:
https://github.com/sonneveld/agscommunity/tree/sdl2-port
Should be compatible with the latest 3.4.1 version of AGS.

I believe that either variant will be sooner or later incorportated in the main version of the engine.
Title: Re: AGS engine Linux port
Post by: eri0o on 25 May 2018, 18:18
CW is too fast.

Everything he said is true, but there is a catch, the default engine should run well windowed, independent of scalling.

So comes the question: which Linux distribution and version of the Engine did you test?
Title: Re: AGS engine Linux port
Post by: null.painter on 25 May 2018, 23:03
Thanks for the quick and friendly responses, folks!

I tried 3.4.0.13 (packaged with the Heroine's Quest linux distribution) and 3.4.0.16 (I grabbed it from some itch.io game that ran okay, but maybe wasn't scaling).

I also experimented with running the win distribution with Wine, which is running smoothly. I haven't played too much, but only noticed one artifact so far - the "language selection screen" at the beginning was mis-sized.
Title: Re: AGS engine Linux port
Post by: eri0o on 25 May 2018, 23:11
until latest 3.4.0 the engine does run well under Wine. Since 3.4.1, the engine doesn't run well under Wine- sometimes it crashes and require you to kill it (you can use xkill) - but the Linux build should run. It's available in the release of the Editor. If you use Ubuntu, building either the latest stable engine or the sdl2 port (still in development) should be easy. I've been thinking about packaging it as snap, if you think it's useful, let me know.

Edit: I started by going after the editor first, once it works, I will give a shot at the engine. github repo for ags-editor snap here (https://github.com/ericoporto/ags-editor-snap).

github repo for ags-engine snap here (https://github.com/ericoporto/ags-snap)

all snaps are still in development, but once they are solved, people with Debian derivatives will be able to snap install ahs-editor and snap install ags .
Title: Re: AGS engine Linux port
Post by: thedaemon on 29 May 2018, 17:38
I tried the Snap you built but was unable to get it to run, after reading the code I found out it was just using Wine and was pointless for me to use since I already am using AGS with Wine. I was hoping it was the native Linux port.

Why is there not a pre-built Linux build? Why do I have to compile it myself? Just curious, I will try to compile and share a package with others since there isn't a package. Cheers.
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 29 May 2018, 18:04
Why is there not a pre-built Linux build? Why do I have to compile it myself? Just curious, I will try to compile and share a package with others since there isn't a package. Cheers.

There is a package we make for the Editor to be able to deploy Linux builds of the game automatically. Such package is linked in every release thread, for example this: http://www.adventuregamestudio.co.uk/releases/finals/AGS-3.4.1-P2/AGS.3.4.1.13.Editor.Linux.Pack.zip
It may also be used to run any game. There is no guarantee that it runs on every Linux system, of course, but it should run on "common" ones, such as Ubuntu and Debian.

Alternatively, we could attach such package to the release tag in the repository, under better name (to make it clear what it is), it's just that no one asked us to do so, at least in my memory.

I've been told before, that in Linux community there should be a program "package maintainer" who makes and updates package for particular Linux system, and who is not necessarily a part of core development team.
For instance, I know that github user rofl0r is making AGS engine packages for "Sabotage Linix" system. On his request I am adding an archive with related source code for each stable release, which may be seen here for example: https://github.com/adventuregamestudio/ags/releases/tag/v.3.4.1.13
Title: Re: AGS engine Linux port
Post by: thedaemon on 29 May 2018, 19:52
Thank you for your reply. I will look into maintaining a Debian package.

From my understanding of your reply, and lack of access to Linux right now(I will check in a few hours), there is no native build of the Editor for Linux, just an export package for the editor to build for Linux?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 29 May 2018, 20:07
From my understanding of your reply, and lack of access to Linux right now(I will check in a few hours), there is no native build of the Editor for Linux, just an export package for the editor to build for Linux?

Right, there is no native build for the Editor. It is written in C#, which means to run on Linux it has to be ported to Mono (or rewritten completely, for what is worth).
There is an issue ticket opened regarding former: https://github.com/adventuregamestudio/ags/issues/442
Title: Re: AGS engine Linux port
Post by: thedaemon on 29 May 2018, 21:23
Thanks again for your timely reply. Above and beyond :)
I don't have the skill to port to another language at this time.. but subscribed to the thread.
I will continue to run via Wine. So far 3.41 has ran flawlessly this way!
Title: Re: AGS engine Linux port
Post by: eri0o on 30 May 2018, 01:05
wait, both snaps are work in progress! I think I wasn't clear when I wrote. I am currently having some trouble with lxd on my computer (which I need to snap wine in a reproducible manner), once I finish this, there will be a release (in Github->Release) and also on the snap store. But yes, it's the same as wine, the idea was just to make it easier to install. I just post work in progress with the hope that someone will find/solve the problem for me :-D.
Title: Re: AGS engine Linux port
Post by: thedaemon on 30 May 2018, 02:11
I did spend a good 30 minutes trying to fix it. It was not running the extension installations. It also worked half way with sudo and the other half with my user. I think it conflicts with user permissions because the files are installed with root? I'll try again later.
Title: Re: AGS engine Linux port
Post by: Radiant on 18 Jul 2018, 18:43
A player reports garbled sound on the Linux build, with the following system specs:

OS: Ubuntu 18.04
CPU: Intel(R) Core(TM) i7-7700 @ 3.60GHz
RAM: 32 GB
GPU: GeForce GTX 1060 6GB
NVIDIA driver: 396.24.02
Sound: I'm using the HDMI port from the graphics card: GP 106 High Definition Audio Controller

Does this sound familiar to anyone? Can someone give me an idea what could fix this please?
Title: Re: AGS engine Linux port
Post by: morganw on 18 Jul 2018, 20:54
First port of call is probably Pulseaudio settings:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46152.msg636552085#msg636552085 (http://www.adventuregamestudio.co.uk/forums/index.php?topic=46152.msg636552085#msg636552085)
Title: Re: AGS engine Linux port
Post by: toojays on 20 Sep 2018, 06:17
I'm new to AGS. Just bought Lamplight City which uses it last week. I was disappointed with the performance running fullscreen; it sounds like I've run into what you guys call the "scaling problem"?

Anyway, this inspired me to try and get AGS' OpenGL renderer working on Linux. I don't have previous OpenGL experience but was able to crib from enough tutorials to get it working in windowed mode.

Code is at https://github.com/toojays/ags/tree/ags3+linux-opengl , see the commit message at https://github.com/toojays/ags/commit/4ae20e7317241fe3b1435ccd0652956dfca38c88 for more detail.

I've only tested it with one game (Lamplight City) on one system (Ubuntu 18.04, Intel graphics) so far. Fullscreen mode isn't working yet. Somewhere in AGS the system tries to resolve the game's 640x400 against my PC's 1920x1080 and comes up with 1728x1080 (game res * 2.7). I fail to set this as a fullscreen mode and AGS falls back to windowed mode. I guess the driver is supposed to realize the system won't do 1728x1080 and ask the windowing system for 1920x1080? Does anyone know?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 20 Sep 2018, 10:32
Anyway, this inspired me to try and get AGS' OpenGL renderer working on Linux. I don't have previous OpenGL experience but was able to crib from enough tutorials to get it working in windowed mode.

Code is at https://github.com/toojays/ags/tree/ags3+linux-opengl , see the commit message at https://github.com/toojays/ags/commit/4ae20e7317241fe3b1435ccd0652956dfca38c88 for more detail.

I've only tested it with one game (Lamplight City) on one system (Ubuntu 18.04, Intel graphics) so far. Fullscreen mode isn't working yet. Somewhere in AGS the system tries to resolve the game's 640x400 against my PC's 1920x1080 and comes up with 1728x1080 (game res * 2.7). I fail to set this as a fullscreen mode and AGS falls back to windowed mode. I guess the driver is supposed to realize the system won't do 1728x1080 and ask the windowing system for 1920x1080? Does anyone know?

Hello, toojays. It's really nice to see someone tried doing this. I kept hoping to look into this myself but never found a moment to research the OpenGL working on Linux (also, there was ongoing Nick Sonneveld's SDL port attempt, but it seems to get delayed again).

Can't answer to the fullscreen problem right away, this is something to investigate. I may mention one thing though (and also the main reason that was stopping me). Since OpenGL does not support "dedicated fullscreen mode" on Windows I had to emulate fullscreen mode (probably this is how everyone do this) by switching desktop resolution. This is not done in ali3dogl.cpp itself, but in the "platform driver" class. You may find calls to "platform->EnterFullscreenMode", "platform->AdjustWindowStyleForFullscreen" and "platform->ExitFullscreenMode" in OpenGL renderer. The implementation for Windows is located in acplwin.cpp. But I honestly do not know if we should follow same procedure for Linux or not (also don't know X11 very well, I wrote literally couple of functions using it before).

Am I right that you are using "glew" library, that helps to bind function pointers to dynamically loaded OpenGL object? OpenGL renderer was originally written in such a way that on Windows we manually getting function addresses, and that would be actually a nice thing to get glew used on Windows eventually too (not sure why I never tried, maybe was worried to break something that was already working).

I have a proposal, since this forum thread is too long already and contains all kinds of various discussions, could we continue on github instead, by opening an issue ticket in our repository? I believe that would be more convenient especially since you already have account and some code in progress there.
Title: Re: AGS engine Linux port
Post by: toojays on 20 Sep 2018, 11:26
Hello, toojays. It's really nice to see someone tried doing this. I kept hoping to look into this myself but never found a moment to research the OpenGL working on Linux (also, there was ongoing Nick Sonneveld's SDL port attempt, but it seems to get delayed again).

Can't answer to the fullscreen problem right away, this is something to investigate. I may mention one thing though (and also the main reason that was stopping me). Since OpenGL does not support "dedicated fullscreen mode" on Windows I had to emulate fullscreen mode (probably this is how everyone do this) by switching desktop resolution. This is not done in ali3dogl.cpp itself, but in the "platform driver" class. You may find calls to "platform->EnterFullscreenMode", "platform->AdjustWindowStyleForFullscreen" and "platform->ExitFullscreenMode" in OpenGL renderer. The implementation for Windows is located in acplwin.cpp. But I honestly do not know if we should follow same procedure for Linux or not (also don't know X11 very well, I wrote literally couple of functions using it before).

Am I right that you are using "glew" library, that helps to bind function pointers to dynamically loaded OpenGL object? OpenGL renderer was originally written in such a way that on Windows we manually getting function addresses, and that would be actually a nice thing to get glew used on Windows eventually too (not sure why I never tried, maybe was worried to break something that was already working).

I have a proposal, since this forum thread is too long already and contains all kinds of various discussions, could we continue on github instead, by opening an issue ticket in our repository? I believe that would be more convenient especially since you already have account and some code in progress there.

Thanks for your response about how you did fullscreen on Windows, I'll do some investigation along those lines.

Yes, I used GLEW. It was a bit annoying to figure out how to get it working, because I didn't see any official documentation saying that you need to set a current GL context before you initialize GLEW. But once you get it set up, it sure is nicer than having an explicit lookup for every single call you want to make.

I've opened https://github.com/adventuregamestudio/ags/issues/510 to continue discussion of OpenGL on Linux.
Title: Re: AGS engine Linux port
Post by: reportsthg on 20 Jan 2019, 00:05
Hey! I have a small problem on MY COMPUTER but I don't know how to solve. I built the Linux engine in Ubuntu 16.04 and if I try running a game with it, it's excruciatingly slow. So I test and run my own game using Wine. I have Steam in this computer too. I play the Wadjet Eye games and they all work well. When I tried running Until I Have You from Steam it ran as bad as my own built Linux Engine, so I guess there is something more to it. I don't have much installed on this Ubuntu computer since I mostly use it only for developing my game in Adventure Game Studio (with Wine).

Linux port has only software renderer available at the moment, which runs slow, especially if game scales to larger display resolution. That would be my first guess. On Wine you have Direct3D and OpenGL (if you are using AGS 3.4.1).

The solution would be to make OpenGL renderer work on Linux, which may be trivial, except someone needs to make such change (this also requires a knowledge of what headers/libraries to add to the engine).

I found something interesting about that topic.
It regards to intel graphics hardware.
When Xorg is started with Acceleration: SNA then graphics are not slow, they are usable.
But when usung the glamor acceleration of Xorg, then ags is unusable slow, with every game I tested.
I also compiled and tested the OpenGL build, which was linked here, it is working fine with glamor acceleration.

You can read more about intel graphic acceleration here (scoll up the page a little bit): https://wiki.gentoo.org/wiki/Intel#Modesetting_DDX

Glamor Acceleration has some problems. You can read about them here: https://www.x.org/wiki/Development/Documentation/GlamorPerformance/
Maybe AGS is using some methods (like many small overlapping blits?) which affect the performance with Glamor Acceleration that much?

BTW: those google reCAPTCHA just suck!
Title: Re: AGS engine Linux port
Post by: Dualnames on 22 Feb 2019, 20:45
https://steamcommunity.com/app/439310/discussions/0/1798529872636973338/

Any thoughts on this? The game is using 3.3.5 AGS I believe with the linux binaries.
Title: Re: AGS engine Linux port
Post by: eri0o on 22 Feb 2019, 23:59
Ok, I have ABSOLUTELY NO IDEA, but usually sound in AGS gets distorted when framerate is bad.

So I would guess the person is running the game in fullscreen in a Linux distribution, and it's getting fps drops. Now I will guess the person actually has a performant computer and reason the frames dropping is some weirdly written code in the engine.

For some reason in some Linux Systems the engine drops frames when Full Screen on Linux. I don't have this problem, but I've seem this problem reported. I think the magic line was LIBGL_DRI3_DISABLE=true in this code (https://github.com/adventuregamestudio/ags/issues/510#issuecomment-451679883)  from @vga256. I think this is what Mage's Initiation is using.
Title: Re: AGS engine Linux port
Post by: morganw on 23 Feb 2019, 00:17
It won't be using OpenGL, so the DRI3 setting won't make a difference. The easiest test to see if it is related to excessive CPU load is to start the game windowed with no scaling, and see if the audio is then working normally. Also if the game shipped with threaded audio playback enabled in the config file, I don't think this is very well tested on anything but Windows, so you'd probably want to check that this is turned off.
Title: Re: AGS engine Linux port
Post by: Dualnames on 23 Feb 2019, 19:32
He's running it on windowed and no luck!
Title: Re: AGS engine Linux port
Post by: Radiant on 10 Apr 2019, 18:30
A player reports that AGS games run unreasonably slow under lubuntu 16.04.6 lts, using a gfx hd6670 graphics card. Does this sound familiar to anyone and if so, what could be done about it?
Title: Re: AGS engine Linux port
Post by: Crimson Wizard on 10 Apr 2019, 19:11
A player reports that AGS games run unreasonably slow under lubuntu 16.04.6 lts, using a gfx hd6670 graphics card. Does this sound familiar to anyone and if so, what could be done about it?

Have you had a chance to try vga256's build with OpenGL support? People say it works great. Also added into upcoming 3.5.0 release. 3.5.0 also has a fixed threaded audio which supposedly should work on Linux without crashes now (still need testing).
Title: Re: AGS engine Linux port
Post by: Radiant on 10 Apr 2019, 20:10
I'm afraid I hadn't heard of that build before. Where can I find it?
Title: Re: AGS engine Linux port
Post by: vga256 on 10 Apr 2019, 20:42
@Radiant:
I'm using toojays' OpenGL implementation here (https://github.com/toojays/ags/tree/ags3+linux-opengl), applied to the 3.4.15 linux sourcetree. You may also want to build a custom Allegro 4.4.3 library to deal with spazzy mouse behaviour. If you're going to distribute this on say, Steam, you'll also want to update the make_ags+libraries script (https://github.com/adventuregamestudio/ags/issues/544).
Title: Re: AGS engine Linux port
Post by: blur on 19 Jul 2020, 09:13
I get the following error when compiling from git origin/master:
Code: [Select]
Linking engine...
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o): in function `it_filter':
(.text+0x11f9): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x123a): undefined reference to `__exp_finite'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o): in function `update_effects':
(.text+0x404b): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x4079): undefined reference to `__pow_finite'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o): in function `process_tick':
(.text+0x429c): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x42e0): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x4386): undefined reference to `__pow_finite'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o):(.text+0x4c34): more undefined references to `__pow_finite' follow
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(readmod.o): in function `dumb_read_mod_quick':
(.text+0x8d1): undefined reference to `__log_finite'
collect2: error: ld returned 1 exit status
make: *** [Makefile:40: ags] Error 1
Please send help.
Title: Re: AGS engine Linux port
Post by: morganw on 19 Jul 2020, 10:43
Does this make any difference?

Code: [Select]
make USE_BUILT_IN_LIBSRC=1
Title: Re: AGS engine Linux port
Post by: blur on 19 Jul 2020, 12:17
Cor blimey! Indeed, this works.
The system's libdumb is 0.9.3 while the libdumb in ags source is 0.9.2.
Title: Re: AGS engine Linux port
Post by: eri0o on 19 Jul 2020, 17:13
Why are you building from source?

I recommend using the Allegro4 from AGS repositories if the sound is broken.