[OLD-1] AGS engine Linux port

Started by BigMc, Sun 03/06/2012 19:04:20

Previous topic - Next topic

Crimson Wizard

Quote from: scottchiefbaker on Tue 14/01/2014 17:07:52
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

BigMc

#501
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/

JanetC

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!"?

JanetC

Quote from: BigMc on Tue 14/01/2014 18:12:34
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?

BigMc

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

JanetC

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 :(

BigMc

#506
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.

scottchiefbaker

BigMc can you make us a current build of the engine/libraries that Janet can use to bundle Gemini Rue?

BigMc

#508
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.

JanetC

#509
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.

BigMc

#510
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.

scottchiefbaker

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?

BigMc

#512
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

Problem

#513
Quote from: scottchiefbaker on Tue 14/01/2014 17:45:33
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.

scottchiefbaker

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.

JanetC

#515
Quote from: scottchiefbaker on Fri 17/01/2014 19:17:04
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.

s_d

#516
Quote from: JanetC on Sat 08/02/2014 02:57:27
Quote from: scottchiefbaker on Fri 17/01/2014 19:17:04
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 >:(

Crimson Wizard

Quote from: s_d on Tue 18/03/2014 05:32:28
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

[sound]
threaded=0 // or remove the line completely

in acsetup.cfg.

s_d

Quote from: Crimson Wizard on Sat 22/03/2014 20:50:09
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.

Quote from: Crimson Wizard on Sat 22/03/2014 20:50:09
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

[sound]
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.

monkey0506

Quote from: xenogia on Fri 03/05/2013 10:36:04Also 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

SMF spam blocked by CleanTalk