AGS Ubuntu Linux 2.72 Binaries Released!

[EvilTypeGuy]

Moderators, please sticky this topic, unsticky all existing 'AGS Linux' topics if possible.

The AGS 2.72 Final runtime has been posted the Linux AGS website here:

http://drevil.warpcore.org/ags/

A reminder that the Linux version does NOT support plugins or movie playback (except FLC).

BIG CHANGES, PLEASE NOTE...to help ensure faster updates to the Linux engine in the future, and to allow further opportunities to enhance the user experience, all future versions of AGS for Linux now only officially support Ubuntu Linux. At this time "Edgy Eft" is the current build environment. In addition, all but a very small set of libraries are now statically linked. This means that the runtime engine now relies on the versions of Allegro, DUMB, and many other libraries on your system to run. This should make for a far better (and more optimised) experience for many users.

Why Ubuntu? Simple, it's the only one of two distributions that has a production release that will actually run on my new workstation. That and after years of using so many of them, it is the first one in a long time I've actually liked.

However, don't worry about the new library dependencies. You should be able to install whatever dependencies you need using this:

sudo apt-get install libaldmb1 liballegro4.2 libgtk1.2 libxml1

Obviously, the binaries should work on any distributions that meet these requirements or any Debian / Ubuntu derivatives:

gcc >= 4.1
glibc >= 2.4
aldmb >= 0.9.3-5
Allegro >= 4.2
GTK = 1.2
LibXML 1

Quite frankly, trying to build the AGS binaries in the past in a way that would run on many different Linux distributions was a nightmare, and was part of why it has always taken me so long to make a release. I no longer have the time (or ability due to hardware) to run and test on a handful of Linux distributions. Using Ubuntu will also provide me extra options in helping bring the AGS Linux port to be closer in features to the Windows version.

Thanks to all for your patience and understanding.

[strazer]

First of all, thanks for your continued efforts to support us Linux users!

In addition, all but a very small set of libraries are now statically linked.

You mean dynamically linked? I think I liked it better before, because of things like this:

Debian/testing: "ags: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ags)"

Edit:

Even unstable still has libc6 2.3.6. Looks like I will have to wait again.

[SSH]

Would it be very hard to provide both a statically and dynamically linked version?

[jkohen]

Same here. Glad to see this finally released, and I know you'll hate me/us for asking, but is it possible to link statically against glibc for now? As strazer said, Debian only includes the new libc on experimental and it's not going to enter unstable at least for a while. Definitely not until after the release of etch and the chaos ensuing right afterwards.

Edit: oh, well, I think it's not that bad to setup a chroot environment with Debian experimental to run AGS, is it?

[EvilTypeGuy]

First of all, thanks for your continued efforts to support us Linux users!

In addition, all but a very small set of libraries are now statically linked.

You mean dynamically linked? I think I liked it better before, because of things like this:

No, I mean statically linked. Really. I don't statically link anything but a few sound libraries.

Unfortunately libc is backwards compatible (you can use a new version with a binary built on an old version) but not forwards compatible (you can't use a binary built with a new version on an old version). This means that if I build it on a system with glibc 2.4, you *should* be able to use it on any system with glibc 2.4 or newer, but not older.

Debian/testing: "ags: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ags)"

Edit:

Even unstable still has libc6 2.3.6. Looks like I will have to wait again.

Sorry You may wish to consider using Ubuntu instead of Debian.

[EvilTypeGuy]

Would it be very hard to provide both a statically and dynamically linked version?

I have tried the statically linked and the dynamically linked. I really don't want to maintain two different binaries. I've had emails from both sets of people that have problems with both. I'm honestly not sure what to do.

What I do know is that I should not be statically linking things. In fact, I was told in so many words terms by a RedHat engineer a few years ago that I was crazy for expecting a statically linked binary to work properly when it was a graphical one and used X.

The problem is that even if I statically link the binary, the versions of libraries that I would be statically linking are likely to cause problems with systems that older versions. When I had my old system, I use to be able to build the binary on RedHat 9 and RHEL3 (which were really old) so it wasn't a problem.

My new workstation however (an Intel Dual Core) can only run glibc 2.4 or newer based distributions. So, unfortunately, I don't think I really can.

I will look into a few options, but for now this is what I can offer. It's great if you're an Ubuntu user.

[EvilTypeGuy]

Same here. Glad to see this finally released, and I know you'll hate me/us for asking, but is it possible to link statically against glibc for now? As strazer said, Debian only includes the new libc on experimental and it's not going to enter unstable at least for a while. Definitely not until after the release of etch and the chaos ensuing right afterwards.

I encourage you to use Ubuntu. At this time, I don't have another option. I will however look into see what I can do, though it is difficult with my system. I do *not* want to maintain multiple binaries. This whole mess is one of the reasons why I think Solaris, Mac OS X, and Windows are better platforms for users. You don't have to deal with these problems

[jkohen]

None of the platforms you mentioned are that great with forwards compatibility, for what it's worth. I've heard you can't expect much backwards compatibility from Windows Vista nor Mac OS's in general.

Although Ubuntu is probably what I'd use if I didn't use Debian, I'm quite happy with the latter for now. But thanks anyway!

[marceledward]

I am using fedora core 6 and I can't get it to run either

first it could not find some library's so I symlinked them:
# ln -T /usr/lib/libdumb-0.9.3.so /usr/lib/libdumb.so.1
# ln -T /usr/lib/libaldmb-0.9.3.so /usr/lib/libaldmb.so

But the fun didn't stop here, then ags returned:

./ags: symbol lookup error: /usr/lib/liballeg.so.4.2: undefined symbol: _blender_trans24

It seems to have to do with the allegro lib, but I am not sure..
Wich version of alllegro did you use to build the binary ?

[strazer]

His build environment "Edgy Eft" seems to use version 4.2.0 currently. Strange.

[farvardin]

thank you for your effort, but I can't even manage to pass the allegro test :

./ags: error while loading shared libraries: libaldmb.so.1: cannot open shared object file: No such file or directory

I don't understand what you said about statically linked libraries : for me, dynamically linked, means lots of dependancies, and we can see there are many here :

ldd ./ags Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã, linux-gate.so.1 => Ã, (0xffffe000)
Ã,  Ã,  Ã,  Ã, liballeg.so.4.2 => /usr/lib/liballeg.so.4.2 (0xf7e46000)
Ã,  Ã,  Ã,  Ã, libm.so.6 => /lib/libm.so.6 (0xf7e20000)
Ã,  Ã,  Ã,  Ã, libpthread.so.0 => /lib/libpthread.so.0 (0xf7e08000)
Ã,  Ã,  Ã,  Ã, libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xf7e02000)
Ã,  Ã,  Ã,  Ã, libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf7df7000)
Ã,  Ã,  Ã,  Ã, libXpm.so.4 => /usr/lib/libXpm.so.4 (0xf7de6000)
Ã,  Ã,  Ã,  Ã, libXext.so.6 => /usr/lib/libXext.so.6 (0xf7dd7000)
Ã,  Ã,  Ã,  Ã, libX11.so.6 => /usr/lib/libX11.so.6 (0xf7cba000)
Ã,  Ã,  Ã,  Ã, libdl.so.2 => /lib/libdl.so.2 (0xf7cb6000)
Ã,  Ã,  Ã,  Ã, libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7bd2000)
Ã,  Ã,  Ã,  Ã, libaldmb.so.1 => not found
Ã,  Ã,  Ã,  Ã, libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7bc5000)
Ã,  Ã,  Ã,  Ã, libc.so.6 => /lib/libc.so.6 (0xf7a97000)
Ã,  Ã,  Ã,  Ã, /lib/ld-linux.so.2 (0xf7f69000)
Ã,  Ã,  Ã,  Ã, libdumb.so.1 => not found
Ã,  Ã,  Ã,  Ã, libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf7a91000)
Ã,  Ã,  Ã,  Ã, libXau.so.6 => /usr/lib/libXau.so.6 (0xf7a8c000)
Ã,  Ã,  Ã,  Ã, libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf7a83000)
Ã,  Ã,  Ã,  Ã, libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf7a7d000)

I can't find this "dumb" library for my system (suse)

Maybe we're asking too much, but since it concerns only music, those libraries are not really compulsories for running a graphical games...
Anyway, with such libraries statically linked, I think it was easier to make it run on different systems...

[EvilTypeGuy]

Sigh, and to think of the nasty emails I got about statically linking the libraries. Well, for now, this is the best that I can do. I will be leaving the country shortly and won't have access to my workstation for a few months. So, it is likely there will not be a new release until I return from Australia in late March unless I can figure something out in a short time. Really, statically linking libraries is a pain.

...and people wonder why Linux doesn't get more games. *grumbles*

[EvilTypeGuy]

I am using fedora core 6 and I can't get it to run either

first it could not find some library's so I symlinked them:
# ln -T /usr/lib/libdumb-0.9.3.so /usr/lib/libdumb.so.1
# ln -T /usr/lib/libaldmb-0.9.3.so /usr/lib/libaldmb.so

But the fun didn't stop here, then ags returned:

./ags: symbol lookup error: /usr/lib/liballeg.so.4.2: undefined symbol: _blender_trans24

It seems to have to do with the allegro lib, but I am not sure..
Wich version of alllegro did you use to build the binary ?

I used Allegro 4.2 as built and distributed from the Ubuntu repositories. Which means that the Debian for your distribution is probably built differently. Joyous!

[EvilTypeGuy]

None of the platforms you mentioned are that great with forwards compatibility, for what it's worth. I've heard you can't expect much backwards compatibility from Windows Vista nor Mac OS's in general.

Although Ubuntu is probably what I'd use if I didn't use Debian, I'm quite happy with the latter for now. But thanks anyway!

Actually, they are great with forwards compatibility. Sorry, I swapped the forwards and backwards earlier

[EvilTypeGuy]

Maybe we're asking too much, but since it concerns only music, those libraries are not really compulsories for running a graphical games...
Anyway, with such libraries statically linked, I think it was easier to make it run on different systems...

No, trying to make a version that built without it would be painful. I have no answer to your quandary right now except to use Ubuntu. No one seems to have packaged the dumb and aldmb libraries for SuSE.

[jkohen]

None of the platforms you mentioned are that great with forwards compatibility, for what it's worth. I've heard you can't expect much backwards compatibility from Windows Vista nor Mac OS's in general.

Although Ubuntu is probably what I'd use if I didn't use Debian, I'm quite happy with the latter for now. But thanks anyway!

Actually, they are great with forwards compatibility. Sorry, I swapped the forwards and backwards earlier

Really? So you say that a program compiled for Windows XP will run on Windows 95? Or a Windows 95 application will run on Windows 3.1? Let's not even suggest the dready Windows 2.0 or 1.x. I'm not sure, but many applications targeted to Windows 3.1 probably didn't work on Windows 3.0, without its truetype and printer spooler support. Of course, I doubt you can get any of the latter to run in a modern computer without too much pain.

Apple never cared about backwards compatibility at all, and much less forward compatibility, so I don't see your point. I don't know much about Solaris, so I'll have to take your word for that one.

Anyways, this is all off topic. I hope glibc 2.5 gets into Debian/unstable soon, or Wine gets better supporting AGS, now that they finally seem to have fixed DirectInput.

[EvilTypeGuy]

Sorry, there appears to be confusion about how we view forwards and backwards compatability.

If you're talking about an OS in general, then backwards compatibility is the ability to run older programs on newer operating systems.

So, for example, glibc 2.4 programs are generally compatible going *forward* with newer versions of glibc, and newer versions of glibc (such as an elusive 2.6) are *backwards* compatible with glibc 2.4 programs. Yes, it's confusing

My whole point was that, generally speaking, dealing with libraries is easier on other platforms. On windows you can just distribute your apps with DLLs in its own directory, and its dead easy and it works. On Linux, distributing your own shared libraries doesn't guarantee you squat, since your shared libraries depend on others, and you quickly go mad! Not only that, but typically speaking, a DLL is a DLL on Windows. There aren't umpteen different builds of the same thing, unlike the Linux world.

Anyway, I digress. This mess is one of the reasons why I decided to just pick a distribution and be done with it.

[farvardin]

if I remember well, on Neverwinter night for Linux they put some libraries into the same folder, and a script to include them in the game, so most players can run the game :

#!/bin/sh

# This script runs Neverwinter Nights from the current directory

export SDL_MOUSE_RELATIVE=0
export SDL_VIDEO_X11_DGAMOUSE=0

# If you do not wish to use the SDL library included in the package, remov
e
# ./lib from LD_LIBRARY_PATH
#export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./miles:$LD_LIBRARY_PATH

./nwmain $@

[SSH]

That seems like a good solution, favabean. It should even be possible for someone else than EvilTypeGuy to package it up...

Sorry to sound like we're getting at you, EvilType... you've done a great job updating this, and thanks!

[jkohen]

The problem, at least for some of us, is that he's compiling against a more recent glibc than is bundled with our systems. Including glibc this way might or might not work, but it will definitely be a very large download in comparison.

[SSH]

Well, glibc will get linked the same way as all the other libraries: there's no special handling of it. But yes, it is a 19 or 20M download. Still, 20M is not as big as it used to be

[iPwnzorz]

With this is it possible to transfer works from a Windows AGS? I would like to be able to transfer my work to my Ubuntu PC

[jkohen]

With this is it possible to transfer works from a Windows AGS? I would like to be able to transfer my work to my Ubuntu PC

This is a port of the AGS run-time, not of the editor.

That being said, the AGS editor runs alright with Wine, so you should be fine (with some minor caveats). As usual, make backup copies, etc.

[iPwnzorz]

Oh right. Good thing I have Wine. Now if I can only get past my weird second GRUB install... Anyone know how to edit menu.lst with Arch?

[farvardin]

it tried also to copy the allegro libs from a debian system to my opensuse, I could start the runner, but it immediatly froze the system after that...
I think opensuse has a more recent glibc, but I'll need to compile the whole allegro stuff.

[EvilTypeGuy]

if I remember well, on Neverwinter night for Linux they put some libraries into the same folder, and a script to include them in the game, so most players can run the game :

#!/bin/sh

# This script runs Neverwinter Nights from the current directory

export SDL_MOUSE_RELATIVE=0
export SDL_VIDEO_X11_DGAMOUSE=0

# If you do not wish to use the SDL library included in the package, remov
e
# ./lib from LD_LIBRARY_PATH
#export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./miles:$LD_LIBRARY_PATH

./nwmain $@

Yes, but the problem is my libraries depend on other libraries, and depending on how the libraries on your system are built, it may or may not work. In addition, the disadvantage of distributing my own is that it isn't optimized for your distribution. For example, if your distribution uses JACK audio or aRTS or ESD, etc. you may not get any sound at all! Likewise, I would have to build my libraries for the lowest common denominator. Meaning, I would have to build them for i386, with no SSE, MMX optimizations, etc. Otherwise, systems that didn't have those would possibly fail and so on.

The other problem is Allegro itself and the libraries that AGS uses. They're not nice clean portable libraries you can just shuttle around, unlike SDL. SDL was meant to be redistributed with your game and because of that, it's much easier.

I'm well aware of the Neverwinter Nights solution, but I hate it since it involves a shell script.

As I said before, Linux development is a mess.

I appreciate that you all are trying to help, but I have been doing software development for the past eighteen years, there is no easy solution here.

All I can say for now is to use Ubuntu.

[Nais]

I'm using Ubuntu Edgy, but the 64 bit version. It's not working and I'm assuming it's because it's looking for the 32 bit libraries? In particular it is having a problem finding liballeg.so.4.2, which I do indeed have, albeit it the 64 bit version.
The last versions have worked for me, is it because of the new linking?

[jkohen]

Yes, that is the case. Install a 32-bit chroot inside your 64-bit system and you'll be fine. I guess Ubuntu has tutorials or automatic procedures to this end, just like Debian/AMD64 has.

Edit by strazer: No need to quote the whole post directly above yours!

[Nais]

Thanks for the confirmation, blashyrkh. I just wanted to be sure nothing else was going on. Not going to bother chrooting, because I do have a 32bit install on another partition. I'll just use that instead. Thanks.

[marceledward]

I am using fedora core 6 and I can't get it to run either

first it could not find some library's so I symlinked them:
# ln -T /usr/lib/libdumb-0.9.3.so /usr/lib/libdumb.so.1
# ln -T /usr/lib/libaldmb-0.9.3.so /usr/lib/libaldmb.so

But the fun didn't stop here, then ags returned:

./ags: symbol lookup error: /usr/lib/liballeg.so.4.2: undefined symbol: _blender_trans24

It seems to have to do with the allegro lib, but I am not sure..
Wich version of alllegro did you use to build the binary ?

I used Allegro 4.2 as built and distributed from the Ubuntu repositories. Which means that the Debian for your distribution is probably built differently. Joyous!

I got it running.!

I copied the liballeg.so.4.2 from the tar in the allegro deb file from the ubuntu repository ( http://us.archive.ubuntu.com/ubuntu/pool/universe/a/allegro4.2/liballegro4.2_4.2.0-1build1_i386.deb ) to /usr/lib/liballegdeb.so.4.2 and changed the liballeg.so.4.2 symllink to point to the deb library. And the other libs in the .deb file also. (I've simply overwritten these, after making a backup of the original library's, there are only a few packages on my fc6 box wich use allegro, they got now a risk of crashing now, the fun never stops ...)

oeps I find the above confusing.

So to get ags running on fedora core I had to make two symlink to existing libs in the /usr/lib dir and I had to copy the downloaded allegro lib to the libs dir.

This actually means we will have to include the libs in our linux games releases, to ensure they will run on other linux distros.
Or maybe not,
Today I got ags running with a self compiled allegro. 4.2.1
I used the following configure:
# ./configure --enable-staticprog=yes --enable-static=yes --prefix=/usr

>> So ags needs a static conpiled allegro to run.

And the sound is working. (I use ogg sounds with PlayMusic(x); and SetMusicRepeat(0); in the global script)

I think this would be something for a wiki page: 'how to get ags running on  fedora core'

=================================================================
I've made a download with the correct allegro ubumtu lib and with a setup.sh script to install it and make the correct symlinks, this script works for fc6 but should work on other distro's as long as there is a /usr/lib dir.

http://meverhagen.nl/tikiwiki/tiki-download_file.php?fileId=94
==================================================================

[farvardin]

I 've tried also to build my own version of dumb (for allegro), so now I have allegro and dumb, but it's not working at all. The lib went into a libaldmb.a and it's not the one requested by your build.
I didn't manage to compile it for 32 bits.

>distributing my own is that it isn't optimized for your distribution.

it's not a problem if it's 2% slower or what ? It would be better than not working.

>For example, if your distribution uses JACK audio or aRTS or ESD, etc. you may not get any sound at all!

again, it doesn't matter, if we only want to play the game and don't care about sound.

>Likewise, I would have to build my libraries for the lowest common denominator.
>Meaning, I would have to build them for i386, with no SSE, MMX optimizations, etc.

it would be still better to make it run for 95 % of linux users than to please only 2 % of them... ?

I managed to install autopackage programs made for 32 bits processors without any problem.

do you think it would be possible to share your work with someone who could build it for other systems ? I could try to do it if you wish...

[EvilTypeGuy]

Sorry, but I can't release any of the source code, nor object files for ags.

For now, it remains Ubuntu only. There are too many Linux distributions for me to support, and I am tired of users having a half-hearted experience.

With Ubuntu, I can provide them a simple, guaranteed experience.

[strazer]

If I may ask, what kind of problems did users report with the old versions?

[jkohen]

For what is worth, versions 2.62, 2.70 and 2.71 work *perfectly* on Debian. 2.61 works pretty much all right, except for MIDI which needs an external sequencer to play MIDI, but this is not a fault in the Linux port, and I understand I could set up a software sequencer with Timidity, if I really wanted to.

[EvilTypeGuy]

If I may ask, what kind of problems did users report with the old versions?

Everything from random colour corruption, runtime symbol errors like the ones listed here, sound problems, to complaints about dynamic linking not being used so they couldn't use their own special build of Allegro. Most of them because the version of X I statically linked to for Allegro was way older than theirs.

Plus I've been told to people who are part of managing some of the bigger distributions (RedHat, SuSE, etc.) that dynamic libraries are the way to go and static linking is something that is likely to cause more harm than help.

I may look into seeing what I can do with some virtual machine software to possibly have a build environment where I can build a binary for other distributions. But, I have no idea for sure yet, and my time is very limited as I'm preparing to leave for Australia. If I ever did support other distributions, it would likely be the latest Debian Stable, Fedora Core (current version) and possibly OpenSuSE. I hate the rest of them. To be quite honest, I'm extremely disappointed with the fact that the Linux community has hundreds of distributions. It makes the job of developers incredibly difficult, and really only serves to frustrate users.

It just takes a lot of disk space, time and effort to maintain so many different operating systems. I had about five different Linux distributions on my old workstation just to build and test ags, and it was a real pain.

[marceledward]

That impressive.

It must be a pain to even get all those different distrubutions up to date.
And all just for a build.

It's a bit off topic, but the there a so many different linux distributions since there are many different philosofies. Fedora is about getting the latest versions of open source. So it's without official mp3 support and with an estimates 10 gig download pro year for the updates and upgrades. There are people who hate fedora for that. So has every linux his own philosofy, I never critizese peolple for making a choise for specific distribution.

So I think the question is:

How do we get a ags release wich will run on as many  linux distribution as possible with the minimal effort of the ags builder.
The source isn't availible for recompiling to other ags users, and I think this is ok. Since I was actually working on making an adventure, not on developing the ags linux player.

Maybe you could make use of  a plague servers. These are servers wich are used to compile and make rpm's or deb files for a specific linux distribution.

[farvardin]

>Plus I've been told to people who are part of managing some of the bigger distributions
>(RedHat, SuSE, etc.) that dynamic libraries are the way to go and static linking is something
>that is likely to cause more harm than help.

yes, maybe in the case of opensource software, because this way it's flexible enough, but for ags we don't have access to them. I think most of binaries distributed this way are statically linked. And most people are able to run them, on whatever distribution. I could run ags271 on many different distributions.
I think with "support" for fedora core, it would run on almost everything else, from opensuse to debian, and even ubuntu

The idea of using external servers made for compilation could be great. I'm sure with your modified source code it wouldn't take very long to recompile for more standard systems.

[jkohen]

Maybe you could make use of  a plague servers. These are servers wich are used to compile and make rpm's or deb files for a specific linux distribution.

I agree that your solution would be really nice, but it were me compiling closed-source, I wouldn't upload it to a plague (sic) server where someone else could decide to keep a copy of my source code without me knowing.

[nahuel]

I've been trying out the linux port of the engine and I have to say it is quite impressive the work being done there. On the other hand, the mac beta port is not so good. As a linux and mac user I was wondering if it would be possible to compile the linux engine on a mac. Evidently if both are unix environments it should be straightforward. Of course, we would require X11 in mac, but that i included by apple anyway. So, my quetion is, would it be possible for anybody to do such a port? and if not? would the sourcecode of the linux port be available for anybody interested in producing mac binaries?

[Mould Cheeze]

Hello, I have downloaded AGSedit  and run itt under wine and it works fine. But when I test my game I cannot hear midi sounds. Wave works fine but no midi.
Please help me!

[Gilbert]

By testing your game did you mean via the editor (so it's the windows engine)?

Did you try testing it with the native linux binary?

If you're just testing with windows engine using wine, I'll say it's just a setting/emulation issue with wine, in that case it's not related to the Linux binaries (i.e. not belong to this thread).

[EvilTypeGuy]

Make sure you have downloaded and extract the the midi patches file I talk about on this page to your game's directory:

http://drevil.warpcore.org/ags/faq.html

[jkohen]

Libc6 2.5 is entering Debian/unstable today, so the latest AGS for Linux should finally work there as well!

[jkohen]

Make sure you have downloaded and extract the the midi patches file I talk about on this page to your game's directory:

http://drevil.warpcore.org/ags/faq.html

Hey Shawn, I'm afraid that the new engine (or maybe it's Allegro?) is looking for the MIDI patches not in the local directory, but in /usr/share/timidity/patches/patches.dat (thanks to strace). Is there a way to revert that behavior to that of the older versions?

I can also confirm that the engine starts on an up-to-date Debian/unstable now :-) Still haven't tried any games, though, but I trust that would work as well.

Also, are you still unable to use the ALSA driver of Allegro? Even with Timidity running as an ALSA MIDI server/client/whatyoumaycallit, AGS won't use that, because it insists on openning /dev/snd/midi*, which don't exist here. Still Timidity run this way seems to be good enough for dosbox and other apps.

Best luck.

[Tartalo]

I have a question. Not sure if I should reply here or create a new post.

While playing with AGT it seemed to me that all games that use ACI engine 2.7x work well with AGS Linux  2.72 and the same goes for 2.6x -> 2.62 and  2.5x -> 2.54

Can I expect this to happen always or I was very lucky until now? (This would simplify part of the project).

Thanks

[deadsuperhero]

Man, it's awesome that I'll be able to run AGS games in Ubuntu.
I just need to install Allegro (and the other required things)
Any chance of being able to download and install this through Ubuntu's "Click and Run" service? This would really help beginners like me.

[Tartalo]

Man, it's awesome that I'll be able to run AGS games in Ubuntu.
I just need to install Allegro (and the other required things)
Any chance of being able to download and install this through Ubuntu's "Click and Run" service? This would really help beginners like me.

Yes, a lot of required things! But you already can play most AGS games, only it's a repetitive process for each game.

If by "this" you mean AGS Linux, I guess it won't be in Ubuntu's repositories for now because CJ's distribution conditions are incompatible with Debian policy, and Ubuntu is only breaking this policy for "important" things. (CJ, go GPL! All your code are belong to us!)

If "this" means AGT Toolkit. I might prepare a deb package in a future, but before that there's quite work to do.

BTW... Anyone knows the answer to my question? Some changes to the installer are waiting to confirm if I can go just with the first two digits of the version and only 3 engines.

[Pumaman]

While playing with AGT it seemed to me that all games that use ACI engine 2.7x work well with AGS Linux  2.72 and the same goes for 2.6x -> 2.62 and  2.5x -> 2.54

Can I expect this to happen always or I was very lucky until now? (This would simplify part of the project).

Yes, the AGS engine policy is to be backwards compatible within the first level minor version number (ie.  2.62 can run any 2.6x game, 2.72 can run any 2.7x game, etc).

In some cases compatibility is actually better than this, but this should be the minimum to expect.

[EvilTypeGuy]

Make sure you have downloaded and extract the the midi patches file I talk about on this page to your game's directory:

http://drevil.warpcore.org/ags/faq.html

Hey Shawn, I'm afraid that the new engine (or maybe it's Allegro?) is looking for the MIDI patches not in the local directory, but in /usr/share/timidity/patches/patches.dat (thanks to strace). Is there a way to revert that behavior to that of the older versions?

I can also confirm that the engine starts on an up-to-date Debian/unstable now :-) Still haven't tried any games, though, but I trust that would work as well.

Also, are you still unable to use the ALSA driver of Allegro? Even with Timidity running as an ALSA MIDI server/client/whatyoumaycallit, AGS won't use that, because it insists on openning /dev/snd/midi*, which don't exist here. Still Timidity run this way seems to be good enough for dosbox and other apps.

Best luck.

That has nothing to do with the engine. I suspect that's how the version of Allegro you are using is configured to work. You're the second person I've seen mention this, though I have never seen the behaviour myself.

When I get a chance, I'll look into it.

Thanks.

[deadsuperhero]

Will there be any chance of this being in a .deb package?
I'm still new at Sudo, it would be nice to have an easier way to install AGS games. (As well as the engine)

[Timosity]

Hey Guys, I'm only fairly new to Ubuntu, I'm using Feisty, I haven't used any Linux systems since 1999 so I'm a bit out of practice.

I've been able to run AGS games but can't get the sound to work

To be honest I'm a bit confused about sound in general on my system as I have 2 sound cards and when I load up Ubuntu it is completely random as to which one it chooses, one is a built in SoundMax, the other is a Soundblaster

sound works in general on the system eg. music and video files but not with AGS games

I've followed the instructions from this thread, and put the patches.dat file in the game folder etc

This is the message I get in the terminal, the game runs but no sound

Adventure Creator v2.72 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 2.72.920
CD-ROM Audio support enabled.
Extended CPU detected.
Checking sound inits.
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory

Unable to initialize your audio hardware.
[Problem: No supported synth type found]

I guess it has something to do with ALSA and some files not existing, maybe I still have to install some more libraries or something.

I also read something about it not being tested with ALSA

maybe my system isn't using ALSA anyway?

Maybe I should remove my Soundblaster to stop confusing the system.

any advise would be great

Thanks


Edit: sorry, I noticed I was playing a game compiled in AGS 2.62 so I downloaded the 2.62 engine and it works

[Oncer]

About the "patches.dat" problem: Go to /usr/share/doc/liballegro4.2/examples and unpack allegro.cfg.gz as ~/.allegrorc.
Edit it and look for the line "patches =".
Set it to "patches = ." (patches equals dot)
Set the music driver to "Software wavetable" for your game. Make sure the patches.dat is in the same directory as your game.
Should work.

[covox]

Why not bite the bullet and get someone to port all the Allegro bits to SDL?

Allegro is a dinosaur. Regardless of the claims made on the project webpage about portability, the design remains over a decade old with the UNIX port originally made as a cruel practical joke. The numerous inter-UNIX build and runtime problems are testament to this, along with the exponentially worse CPU performance under X11 compared to Win32. While this may have saved bucketloads of time back in the halycon days where the only two platforms were DOS and Windows, things are different now that "multiplatform" means Windows and two types of UNIX.

You probably don't need anyone to harp on about how good SDL is. Almost every closed-source game for UNIX (e.g. Darwinia, Quake 4, Gish, Neverwinter Nights) uses SDL as a backend, and for good reason; it's rock-solid, fast, well documented, and has a brilliantly planned and -stable- API. Plus it's robust enough to work on (nearly) all platforms without fail, even just by dumping the .so libraries in with the binary.

Setting aside the twin issues of "not enough time" and "too much integral code relies on it",  would the idea of -experimentally- moving the Linux AGS dependancy off Allegro and onto SDL be considered a good move?

[Pumaman]

The original reason that I didn't use SDL was because it didn't support DOS, whereas Allegro did. However, nowadays I don't see that as an issue because nobody uses DOS any more.
Also, I think at the time you couldn't statically link the SDL binaries into your executable, is this still the case?

But, if the AGS graphics subsystem was to be re-written, I think it would make more sense to port it to Direct3D or OpenGL, since most modern graphics cards are not optimised for 2D.

[covox]

libSDL-dev appears to come decked out with a static library, no problems there  8)

Yeah, projects like SuperTux have shown a lot of potential in the idea of using 3D for accelerated 2D. Of course, one would have to consider the cons, such as locking out devices with only a 2D driver, and weigh them with the benefits, such as guaranteed smooth scrolling.

Also 3D can't pull off a few things taken for granted in 2D, such as raw pixel access to the display, which (depending on how things work behind the curtain) might require a rethink of strategy. It all depends on whether the losses are worth the gain I guess.

[Mould Cheeze]

OK, i installed all the libraries from the first post.
And now I can run AGSSetup, I copied it to the Compiled foldermade my settings and clicked on "Save settings and start game" but nothing happens. When i run the console with "ags game.exe" also nnothing happens. What do I habve to do to make it run?

[EvilTypeGuy]

Will there be any chance of this being in a .deb package?
I'm still new at Sudo, it would be nice to have an easier way to install AGS games. (As well as the engine)

No, since the engine can't really run "generically." Meaning, you pretty much have to have it run from the same directory as the game data at this point. Which in turn means that there isn't much point in packaging it.

The original reason that I didn't use SDL was because it didn't support DOS, whereas Allegro did. However, nowadays I don't see that as an issue because nobody uses DOS any more.
Also, I think at the time you couldn't statically link the SDL binaries into your executable, is this still the case?

But, if the AGS graphics subsystem was to be re-written, I think it would make more sense to port it to Direct3D or OpenGL, since most modern graphics cards are not optimised for 2D.

SDL still doesn't allow static linking because of the LGPL license.

SDL actually uses DirectX for the backend on Windows and a future version will have an OpenGL backend as well based off David Olfoson's glSDL backend work: http://olofson.net/mixed.html

OK, i installed all the libraries from the first post.
And now I can run AGSSetup, I copied it to the Compiled foldermade my settings and clicked on "Save settings and start game" but nothing happens. When i run the console with "ags game.exe" also nnothing happens. What do I habve to do to make it run?

As noted in the instructions that come with AGS, you must rename game.exe to ac2game.dat or make a symlink to game.exe as ac2game.dat.

You cannot tell ags which file to use as the game file. It looks for ac2game.dat in the current directory.

http://drevil.warpcore.org/ags/faq.html

libSDL-dev appears to come decked out with a static library, no problems there  8)

The issue is one of licensing, not technical capability.

From the SDL license page:

http://www.libsdl.org/license-lgpl.php

To comply with this license, you must give prominent notice that you use the Simple DirectMedia Layer library, and that it is included under the terms of the LGPL license. You must provide a copy of the LGPL license.
You must also do one of the following:

   1. Link with the library as a shared object (e.g. SDL.dll or libSDL.so)
   2. Provide the object or source code to your application along with any libraries and custom tools not available with a standard platform development kit. You may also simply provide a written offer, valid for three years, to provide these materials upon request to anyone with a legal copy of your application.

As AGS's source code cannot be released, that means shared link only.

[Pumaman]

I have investigated SDL recently, and in comparison to Allegro it doesn't really seem to have any benefits. They both run off DirectDraw behind the scenes, and SDL doesn't seem to have any advantages that would make porting the code worthwhile.

[deadsuperhero]

Well,
In any case, it'd be great to play AGS games easily, and also make AGS games easily, in Ubuntu. That'd be sweet.

[strazer]

No, since the engine can't really run "generically." Meaning, you pretty much have to have it run from the same directory as the game data at this point. Which in turn means that there isn't much point in packaging it.

You cannot tell ags which file to use as the game file. It looks for ac2game.dat in the current directory.

Are you sure? I put the AGS files into /usr/local/bin and usually run games like this:
  $ cd /usr/local/games/ags/6das
  $ ags 6das.exe
Works like a charm.
A problem is savegame compatibility, so you have to remember to always play the game with the same AGS version. That's why I have several AGS versions in /usr/local/bin, named ags262, ags271 and so on.

[Kweepa]

I have investigated SDL recently, and in comparison to Allegro it doesn't really seem to have any benefits. They both run off DirectDraw behind the scenes, and SDL doesn't seem to have any advantages that would make porting the code worthwhile.

The advantages I can think of are mostly to do with portability to platforms that Allegro doesn't touchlike consoles PDAs etc

[EvilTypeGuy]

No, since the engine can't really run "generically." Meaning, you pretty much have to have it run from the same directory as the game data at this point. Which in turn means that there isn't much point in packaging it.

You cannot tell ags which file to use as the game file. It looks for ac2game.dat in the current directory.

Are you sure? I put the AGS files into /usr/local/bin and usually run games like this:
  $ cd /usr/local/games/ags/6das
  $ ags 6das.exe
Works like a charm.
A problem is savegame compatibility, so you have to remember to always play the game with the same AGS version. That's why I have several AGS versions in /usr/local/bin, named ags262, ags271 and so on.

That's basically why I said same directory. That and I haven't always had it work when it wasn't in the same directory, it seems to vary based on which Linux distro/Allegro build I'm using.

I have investigated SDL recently, and in comparison to Allegro it doesn't really seem to have any benefits. They both run off DirectDraw behind the scenes, and SDL doesn't seem to have any advantages that would make porting the code worthwhile.

SDL would probably be better in some aspects. However, it doesn't provide the software wavetable sound system that Allegro does and its more of a generic platform library for graphics and audio. Allegro, on the other hand as you well know, is a *game* library as well.

Suffice to say that for now, Allegro remains a good choice for AGS best I can tell.

[Baffo32]

AGS 2.72 is segfaulting for me

I am running Gentoo Linux, with allegro 0.4.2.1 and aldmb 0.9.3 .  AGS 2.71 worked fine.  I had to make my own libaldmb.so.1 and libdumb.so.1 symlinks to *.so, so maybe I have the wrong libdumb -- but the crash looks like it is in graphics code rather than sound code.

Code: ags

$ gdb ags
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /mnt/hda1/ags/ags 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1213122896 (LWP 25334)]
Adventure Creator v2.72 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 2.72.920
[New Thread -1213949040 (LWP 25337)]
Unknown CPU detected.
Speech sample file found and initialized.
Music file found and initialized.
Checking sound inits.
[New Thread -1230132336 (LWP 25338)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213122896 (LWP 25334)]
0x08102750 in stretch_masked_line16 ()
(gdb) bt
#0  0x08102750 in stretch_masked_line16 ()
#1  0x08103157 in _al_stretch_blit ()
#2  0x0810346e in Cstretch_sprite ()
#3  0x0808cb52 in initialize_sprite ()
#4  0x080504c0 in SpriteCache::loadSprite ()
#5  0x0805096c in SpriteCache::precache ()
#6  0x0809d7ce in init_game_settings ()
#7  0x080bd06c in main ()
(gdb) 

EDIT:
maybe this problem was due to gentoo allegro patches or wrong allegro version... using marceledward's debian allegro shared library, ags runs fine =D

[Radiant]

If one of the resident Linux gurus has the time to check this, I would like to know whether the instructions and package included in the zipfile for ATOTK are clear enough and sufficient. I don't have the Ubuntu to test it on myself.

http://crystalshard.net/atotk.php?page=down (the zip, not the windows .exe )

[deadsuperhero]

If one of the resident Linux gurus has the time to check this, I would like to know whether the instructions and package included in the zipfile for ATOTK are clear enough and sufficient. I don't have the Ubuntu to test it on myself.

http://crystalshard.net/atotk.php?page=down (the zip, not the windows .exe )

I'll test it out, I've  got everything dualbooted.
Everything but midi works, but that could just be me not installing something.

On the other hand, I have a VERY helpful tip for anyone wanting to run an AGS game in Linux, without using the terminal much(with the exception of getting things first set up)
-Go through these simple instructions to install ATOTK
1. Download the .zip file
2. check on the offical AGS Linux page, make sure you have all dependencies.
3. Extract the .zip file to somewhere easy to remember, such as /home/yourusername/Games/AGS/ATOTK
4. Download the latest ags engine, and the midi patch
5. Type cd /home/yourusername/Games/AGS/ATOTK
6. Type tar -xjf /home/yourusername/whereyoudownloaded/ags-v2_72_920.tar.bz2 , then hit enter
7. tar -xjf /home/yourusername/whereyoudownloaded/midiptch.tar.bz2 , then hit enter again.
8. Type ./ags-setup, hit enter, then select "force Alternate letterbox resolution", then 640 x 480, then hit Save.
9. Type ./ags to play

However, after you do this once, you're not going to want to use this process a whole lot. Fear not!

Go to /home/yourusername/Games/AGS/ATOTK in whatever file browser you use
Right click on ags, choose "use custom command"

For the custom command type "gnome-terminal" if you use regular Ubuntu with the GNOME desktop
Do the same for ags-setup.
You'll be able to run them by clicking them now, and you may even be able to run it through launchers if you want.
I'm still experimenting, but it seems to work.

EDIT: Fixed, thanks Gilbot!

[Radiant]

The music isn't MIDI, it's MP3.

I fail to see what your instructions do, except for unpacking everything and creating a shortcut??

[deadsuperhero]

It's essentially the same thing as EvilTypeGuy's instructions for setting up the game.
However, I also set it to work not as a shortcut, but as a working linux executable, seeing as that gnome-terminal (or whatever you use for the terminal) will read it, and run it.

[strazer]

Go to /home/yourusername/Games/AGS/ATOTK in whatever file browser you use
Right click on ags, choose "use custom command"

For the custom command type "gnome-terminal" if you use regular Ubuntu with the GNOME desktop

I also don't understand what this is supposed to do. I don't even have have a "use custom command" option when I right-click either the ags binary or the game exe.

(Edit: Ah, you didn't say to click "Open with Other Application" first.)

I do it this way: I have several ags versions stored in a single location, usr/local/bin, i.e.
/usr/local/bin/ags272
/usr/local/bin/ags272-setup
/usr/local/bin/ags271
/usr/local/bin/ags271-setup
...and so on.
I have ags272 associated with exe files (via "Open with Other Application...") so I can quickly test games by double-clicking, or I can create a launcher (shortcut) that runs
"ags272 /usr/local/games/ags/twokingdoms/ATOTK.exe".

The music isn't MIDI, it's MP3.

Ah, I thought I hadn't set up MIDI correctly when I heard no music.
I had to check "Use digital music pack if available" in ags-setup and now there's music.

--

Hm, strange. Recently, every game I play, either with the 2.71 or 2.72 engine (btw: no matter if run from /usr/local/bin or copied to the gamedir), crashes with this error message when I exit (via a Quit function or Alt+X):

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  134 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0x2800001
  Serial number of failed request:  4635
  Current serial number in output stream:  4640

Error: the program has exited without requesting it.
Program pointer: +9902  (write this number down), ACI version 2.72.920
If you see a list of numbers above, please write them down and contact
Chris Jones. Otherwise, note down any other information displayed.
Aborted (core dumped)

And it doesn't restore my previous desktop resolution so it's very annoying having to revert it every time.

It only happens when I run games fullscreen, when running in a window they exit without the error message. Looks like I have to run them in a window for now.

[deadsuperhero]

Erm, really? I get a "Open With Other Application", and at the bottom of the list, there's a text box, saying "use custom command"

[deadsuperhero]

Random thought today. Seeing as the current process to get AGS games to run in Linux, is it possible to package the engine with the game in a .deb package? That might make for an easy install and setup for it...
I also hope to see the ALSA support in the future, as that's the chipset that I unfortunately have. Oh well. All in good time. 

[jkohen]

Version 2.72 of the native Linux interpreter uses 100% CPU for most, if not all games. This frequently cause short stuttering and also forces the CPU fan to be on all the time, thus making for a noisy game experience.

Since I have a fairly powerful computer and the same games running in the native Win32 interpreter running thanks to Wine do not exhibit the same behavior (they normally use less than 50% of CPU), I think this is a bug. Actually, the game uses the same amount of user time with both interpreters, but the Linux one maxes out the rest in system time. That means that the time is spent inside the kernel.

Strace on the AGS process tells me that nanosleep(2) is being called non-stop with an argument of (0, 1000), which tells the kernel to stop the process for 1 microsecond. In reality it's sleeping a bit longer here: 25 microsenconds, which means 40,000 wake-ups in a second. That is way too much for a game. I don't know what subsystem of AGS is causing this, since obviously I don't have its source code, but please let it sleep longer and preferrably use some sort of notification mechanism (i.e. poll(2), audio buffer signals, or whatever makes sense for this subsystem) instead of system unfriendly sleeps.

I don't know when this bug started, but it's been around for a while, and it affects at least a few kernels up to the latest: 2.6.22, both pristine and patched with CFS, which helps a bit evening out the bursts.

[EvilTypeGuy]

Version 2.72 of the native Linux interpreter uses 100% CPU for most, if not all games. This frequently cause short stuttering and also forces the CPU fan to be on all the time, thus making for a noisy game experience.

I have not seen this, and suspect it is something local to your system, or to a particular configuration, though I will check into it best I can.

Strace on the AGS process tells me that nanosleep(2) is being called non-stop with an argument of (0, 1000), which tells the kernel to stop the process for 1 microsecond. In reality it's sleeping a bit longer here: 25 microsenconds, which means 40,000 wake-ups in a second. That is way too much for a game. I don't know what subsystem of AGS is causing this, since obviously I don't have its source code, but please let it sleep longer and preferrably use some sort of notification mechanism (i.e. poll(2), audio buffer signals, or whatever makes sense for this subsystem) instead of system unfriendly sleeps.

I don't know when this bug started, but it's been around for a while, and it affects at least a few kernels up to the latest: 2.6.22, both pristine and patched with CFS, which helps a bit evening out the bursts.
[/quote]

ags relies on many libraries, anyone of them could be calling it. It's important to note that the ags linux port uses the exact same codebase that the Windows port does. Thus, the behaviour you see in one is very likely present in the other. The linux port has very few differences relative to the size of the actual codebase compared to the Windows version.

[Nazgul]

Hello guys,

I had the same problem with Midi on Ubuntu linux when trying to load AGS. It kept displaying the same error message:

Checking sound inits.
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory

Unable to initialize your audio hardware.
Problem: No supported synth type found

After checking my /dev/snd directory, I couldn't find any midi files there. The only solution I thought of was to emulate a midi port using a link. So, i opened a terminal and loaded the virmidi module:

$ sudo modprobe snd_virmidi

After that, my /dev/snd/ directory had lots of midiCxDx files. But still, AGS wanted specifically the midiC0D0 file. So i linked it, creating a "fake" midiC0D0:

$ sudo ln -s midiC1D1 midiC0D0

And, voilá, AGS run smoothly and i can finally play A Tale of Two Kingdoms on linux.

Perhaps it's not the "cleanest" solution, but it worked here :-)

I hope it helps you people.

[farvardin]

with the new Asus EEE Pc, which is running linux, it would be cool to be able to play AGS games on it. But unfortunately they're using a stable, old, version of Xandros / Debian, and there is a problem to run ags because of glibc. Would it be possible to release a version of ags for linux compiled with an older glibc ? (debian etch would be fine)

[covox]

I have investigated SDL recently, and in comparison to Allegro it doesn't really seem to have any benefits. They both run off DirectDraw behind the scenes, and SDL doesn't seem to have any advantages that would make porting the code worthwhile.

SDL would probably be better in some aspects. However, it doesn't provide the software wavetable sound system that Allegro does and its more of a generic platform library for graphics and audio. Allegro, on the other hand as you well know, is a *game* library as well.

Suffice to say that for now, Allegro remains a good choice for AGS best I can tell.

Normally I'd agree with you about the usefulness of software wavetable support, but won't on the grounds that it is damn-near impossible to get working. Sticking patches.dat in the same folder as AGS and forcing Software Wavetable gives "[Problem: DIGMID patch set not found]". The dodgy ancient wavetable engine bundled with SDL_mixer loads fine.

ALSA's software and hardware MIDI support (timidity and snd-emu10k1) also fail without error on my system, probably something to do with the dodgy OSS layer. By contrast, running AGS under Wine with ALSA produces perfect MIDI.

The main reason why SDL shines over Allegro is its cross-platform robustness. Take, for instance, the Nintendo Wii. A brilliant hypothetical platform for adventure games. Right now it's closed off, but a month ago some bloke figured out how to dump the console's private keys. Yesterday someone figured out how to perform a buffer-overflow attack in Zelda Twilight Princess. Give it another month or three and it'll run Linux, at which point SDL should just compile off the bat without having to change a single line of code. I can't remember what the cross-platform robustness of Allegro is like, however given that sketchy OSX support is relatively new there might be issues building on an undocumented PPC Linux system.

The big question now is, will AGS v3 get ported? I'm on tenterhooks, as I have the script/dialogue for a game prewritten and am tossing up between AGS2 or 3 to develop it in. (The other option is to write an engine from scratch in pygame, but that'd probably look worse and be easier to cheat and have a much smaller target audience)

with the new Asus EEE Pc, which is running linux, it would be cool to be able to play AGS games on it. But unfortunately they're using a stable, old, version of Xandros / Debian, and there is a problem to run ags because of glibc. Would it be possible to release a version of ags for linux compiled with an older glibc ? (debian etch would be fine)

If you're feeling adventurous (see what I did there!), you can always install Ubuntu on the EeePC. It's guaranteed to be more up-to-date than the ASUS-branded copy of Xandros.

[deadsuperhero]

Well, I don't know about AGS getting ported, it's a huge undertaking, and Chris has been working his butt off just getting v3 to work.
Personally, I'd just run v2 in Wine, seeing as it's not .NET-based, and I kind of like the older interface (as well as old functions) anyway.

[SSH]

The engine for 3.00 is little changed from 2.72, so I'd expect games that didn't use 3.00 features (just the 3.00 editor) to still work, perhaps?

[yztlyrn]

You guys have is all figured out.  However, it's a little technical for some of us.  As Ubuntu is kind of the non-techies Linux, pleas wrap this up into a .deb that will draw it's dependencies automatically.  That would go a long way to getting more people to try your games.

[Pumaman]

The engine for 3.00 is little changed from 2.72, so I'd expect games that didn't use 3.00 features (just the 3.00 editor) to still work, perhaps?

The file formats have changed, so you wouldn't be able to play a 3.0 game with the 2.72 engine.

[SuperDre]

The file formats have changed, so you wouldn't be able to play a 3.0 game with the 2.72 engine.

then it would be wise to make sure the Linux engine can run both, so no need for different 'files' for different games, just like ScummVM, one engine to rule them all Hell, it would even be unbelievable cool to have AGS support in ScummVM, so really only one engine to play all your favorite adventure games..

As noted in the instructions that come with AGS, you must rename game.exe to ac2game.dat or make a symlink to game.exe as ac2game.dat.

You cannot tell ags which file to use as the game file. It looks for ac2game.dat in the current directory.

Hmm.. why not just look for any .exe (and check some data to see if its an AGS exe (that's just reading a binaryblock and check for some specifics, so real easy)) in the current path and show a little selectionscreen (if there are more than one).. this would be much better/userfriendly than having to rename blahblah.exe to ac2game.dat.. Also config files and savegame files can be named the same as the exe, so everything can go in one folder (or any specific folder).. But then again, linux never has been really userfriendly..

Keep up the good work, and hopefully a new version will be able to run all video's/animations... And for plugins it would be better to get a framework/api (if it isn't already) so it would be possible to port plugins from windows to linux..

[deadsuperhero]

You guys have is all figured out.  However, it's a little technical for some of us.  As Ubuntu is kind of the non-techies Linux, pleas wrap this up into a .deb that will draw it's dependencies automatically.  That would go a long way to getting more people to try your games.

Unfortunately, I think that's up to EvilTypeGuy to do, as he's the only one who can build a .deb package from the source code.

[EvilTypeGuy]

You guys have is all figured out.  However, it's a little technical for some of us.  As Ubuntu is kind of the non-techies Linux, pleas wrap this up into a .deb that will draw it's dependencies automatically.  That would go a long way to getting more people to try your games.

Unfortunately, I think that's up to EvilTypeGuy to do, as he's the only one who can build a .deb package from the source code.

There's little point in packaging it, as the version of the engine depends on the game.  You really want to play the game with the same version of the engine it was published with on Windows, etc.

[EvilTypeGuy]

Moderators, please lock this topic.

[Gilbert]

I'll unsticky this and sticky the new notice.