Messages

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?

Hi. In the first post of the Linux engine thread in this forum there is a link to instructions.

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.

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.

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

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.

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?

Better report that in the bug tracker (here or on github).

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.

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.

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.

yes, copy liballeg.so.4.4.2 and the symlink liballeg.so.4.4, etc to libs/ in the same dir.

You can take the libraries from a distribution.

Build AGS with

Code: AGS

make LDFLAGS="'-Wl,-rpath,\$\$ORIGIN/libs'"

and put the required shared libraries in the folder libs relative to the binary.

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.

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 to provide AGS packages for all major distributions.

When using the distributions Allegro, two binaries should be enough: one using Allegro 4.2 and one 4.4.

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.

Why don't you link dynamically against Allegro 4.2 then?

I think Crimsons class will be for storing, he didn't imply reinventing the wheel for parsing.