Messages

Sounds good to me as it is.

Maybe that's also a good time to remind everyone of http://nvie.com/posts/a-successful-git-branching-model/
If we still want to do it like this everybody has to be aware of this:
master is the branch we suggest everybody to use and is only changed when a release is done (the release branch is merged into master and the commit is tagged).
All development happens in other branches.

EDIT: As you say there are sometimes small but important fixes needed for ports (e.g. Linux version does not build with new library version) that don't make a new Windows build / version number necessary. Maybe these should be done in master and always merged into the release branch and/or develop right away.

So is this more portable? Will this work with mono on Linux?

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

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.

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.

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.

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

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/

There is also a Mac thread on this forum.

Yes, tex files are just text files and edited with text editors. They are source code for generating documents in other formats. Personally I use pdflatex (available in any Linux distribution) to generate pdfs from tex files.

This tex file is in another TeX or LaTeX dialect that works only with tex2rtf as far as I know. You can generate the htm files from the ags.tex on Linux with the compile_documentation_unix.sh I created and on Windows it should somehow work with the tex2rtf.exe that is included in the same folder.

EDIT: Ah yes the Windows equivalent to compile_documentation_unix.sh is run.cmd, but I never tested it.

My impression is that custom resolution is the hardest problem and potentially most distracting so I would put that into a feature branch and everything else (limit removal and cleanup, Draconian changes) in the develop branch. The current custom resolution build based on 3.3 is usable right? So people could use that or the custom resolution feature branch (that could be regularly rebased on develop).

If you want to add someone elses branch to your repository asking him for a pull request is a very complicated way of doing it. In your repo add his repository as remote (git remote add), check out the branch and push it to your remote repoostory. That's it.

3. Copy his new code over and make a one big commit.
Then, continue with pull request as usual.

Even if there's no history it can be useful to commit the changes in multiple steps, which may be doable to some extend if unrelated changes are in different files. But let's hope history exists.

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

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.

See the bug: http://www.adventuregamestudio.co.uk/forums/index.php?issue=438.0

I have the following to say for myself:

lol

monkey, making mistakes is ok but if you refuse to learn from them and get sassy instead don't be surprised if someone decides you should better work in your own repo.

Windows larger than the screen size should not be a problem on Linux.

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.