Topic: AGS engine Linux port

[Milanium]

The package linux-glibc-devel was missing. Building and uploading now. Check http://software.opensuse.org/package/ags once the mirrors are synced.

[Milanium]

Tested works, except fullscreen mode on openSUSE 12.2 KDE 4.9.5, Mesa 9.0.1:

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.

[BigMc]

Use the master branch, not main. Don't know if that fixes it, but just saying.

[JJS]

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

[Milanium]

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". :/

[Sslaxx]

Got the libcda (CD Audio) devel files installed?

[BigMc]

libcda is included with the AGS source. And even if they were removed that would not cause sound problems, because this is never used.

[s_d]

Hey, JJS & BigMc, is the refactory branch merged upstream?  Is it, or main, a better branch for Linux builds?  How about Android builds?  Thanks!!

[Crimson Wizard]

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.

[s_d]

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

[Crimson Wizard]

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?

[s_d]

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!

[Crimson Wizard]

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.

[AGD2]

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!

[Crimson Wizard]

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.

[AGD2]

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).

[Crimson Wizard]

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).

[BigMc]

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.

[Crimson Wizard]

Or wait a bit, it will surely be more stable in a few months years.

[BigMc]

Definition of more stable: At least one more bug is fixed.