GNU/Linux Ports

[keisari]

Hiya! Nice to see the linux port alive again.

I'm trying out the video test game on Ubuntu 64-bit. I ran install.sh but still get loads of warnings about missing plugins. I also tried running getlibs manually, with no luck. The video starts playing, but VERY slow without any sound, and then hangs after a while. I actually had to change the video file for another to find this out since the default one would just give a black screen.

The engine itself seems to work fine. Nice work!

EDIT: Well I don't know what happened, but now the video works just fine. I still get the warnings, but i guess they're not really relevant. Some weird problem with the codecs i guess... Thanks anyway!

EDIT: It seems my problem is sound related. The video won't play for me with certain MIDI settings in ags_setup. OSS seems to be the most reliable: other settings, even "No music" will hang the video. Sound and music for other AGS games work well. Pretty odd I think...

Also, the sound settings seem to have no effect on the audio playback of the video, the audio is always heard.

[Electroshokker]

Hiya! Nice to see the linux port alive again.

I'm trying out the video test game on Ubuntu 64-bit. I ran install.sh but still get loads of warnings about missing plugins. I also tried running getlibs manually, with no luck. The video starts playing, but VERY slow without any sound, and then hangs after a while. I actually had to change the video file for another to find this out since the default one would just give a black screen.

The engine itself seems to work fine. Nice work!

EDIT: Well I don't know what happened, but now the video works just fine. I still get the warnings, but i guess they're not really relevant. Some weird problem with the codecs i guess... Thanks anyway!

Yes, I also get weird problems on my 64-bit Ubuntu. Did you have a look at this post where I describe a way to sort out some of these problems?
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=37968.msg501855#msg501855

Note: Depending on the codec used to encode the video file, you might get different results. (If the codec is in the default gstreamer "good" or "ugly" plugins, it should play just fine. Codecs which exist in the "bad" or other plugins might not be properly supported and have playback issues. (which is the case with the example video file, I guess, since it uses an older version of DivX, though I'm not sure. It was made a few years ago.)

EDIT: It seems my problem is sound related. The video won't play for me with certain MIDI settings in ags_setup. OSS seems to be the most reliable: other settings, even "No music" will hang the video. Sound and music for other AGS games work well. Pretty odd I think...

Also, the sound settings seem to have no effect on the audio playback of the video, the audio is always heard.

The ags_setup setting do not affect the video playback whatsoever. I basically tell the gstreamer backend to play the video file, without bothering about setting audio playback volume or other stuff.

News update:

- I'm currently shifting my focus to AGS 3.1.2 SP1. Video playback for Linux will work identical, so any fixes (audio level, ...) I'll make later on to the new version I'll backwards install in the AGS 2.72 build.

- I'm leaving on holiday for a few weeks. In the meanwhile, please keep testing the current build and reporting any issues you come across. You can also post suggestions on what you want in the Linux video playback. (audio volume control with '+' & '-' keys, pause on pressing spacebar, ...)

Once I'm back I'll take a look at all bug reports & suggestions.

[EvilTypeGuy]

Allright!!!  

The patched static library is working like a charm!   All music and sounds now ok!

Packaging, adding instructions and uploading the new beta. Guys, give this one a try. You'll love it!

You shouldn't need to (and really shouldn't) use a static library.  Remember that the patches.dat has to be in the same directory as the runtime executable for ags for sound to work right.  However, if you can't get it working without using a static library, then I suppose that's the only option.

[EvilTypeGuy]

Update:

After a brief moment investigating Apeg & AllegAvi, I decided to continue with the GStreamer approach. (there were some licensing issues with apeg, and allegavi's only for windows.)

The good news: I figured out how to get the window XID I need.

It will still take me a while before I get it working, though. With luck, I'll get a break-through.

Gstreamer is your best bet.  I had the same problem you did with Video which is why I never added support for it.  Video playback under X11 was incredibly convoluted and difficult and the licensing issues surrounding most video playback libraries were more than annoying.

[roystonlodge]

Understanding that the Linux port is designed for Ubuntu, has anybody had any experience getting it to run on Damn Small Linux?

I'm using DSL to create a live Linux CD for my nieces and nephews, with lots of small games and educational software.

AGS would be a great way to create "getting started" tutorials for this little project of mine, reminiscent of the old "Macintosh Basics" and/or "Mouse Basics" tutorials that used to come with new Macs WAY back in the days of the Mac Plus/Mac Classic/Mac SE.

Thanks in advance!

[HeirOfNorton]

 

Appears to work fine in Arch Linux (64 bit). Nearly all of the libraries are available in lib32 versions, through AUR if nothing else. The only ones not available are libdumb and libaldmb. The Arch repos have static libraries for DUMB by default instead of shared libraries like Ubuntu. However, I was able to simply copy the relevant SOs out of the Ubuntu repos and put them in Arch's equivalent of lib32. It works fine, and the sound seems to work right even without patching Allegro.

Presumably it would be a bit simpler to get it working in 32-bit Arch, without needing to futz around with the AUR.

Great work, ES.

Edit: AGS 3.1.2 still isn't working, with the same errors as other folks have gotten. 

[Electroshokker]

If you can get it to run with the original libraries, stick with them. If you can't, there's some notes in the package (either of this one or the 3.1.2 package) which will help you fix the sound bug in the allegro library. Not all distros suffer from this bug, but if yours does, read the readme.txt I included!

[kylebrandt]

With the install script, be sure to double quote the $LOC variable in the cp and mv commands, lines 52-57.  When setting up a game that is in a dir with spaces, those commands won't work correctly otherwise.

[deadsuperhero]

Bit of a hypothetical question here, I'd love to see some clarification.

I'm looking at packaging my game with this runtime for Ubuntu in a .deb file. In theory, this process is relatively simple (I'd imagine the binary would be moved into a folder with the games file, so something like /usr/share/games/GAMENAME strikes me as fitting)

However, a problem arises. For most native linux games, savegames don't actually go in the directory of the binary. Since AGS does this, and since this binary would be installed into a place that doesn't have root write access for good reason, this means that there is no logical way to save a game. Likewise, putting saved games in this directory would require quite a bit of know-how. As Ubuntu is a distribution dedicated to making things easier for the end user, this isn't the best way to deal with the issue.

Would it be logical sometime in the future to implement a save directory tantamount with other native linux games in which it saves into a hidden directory in the home folder? For example, King's Quest could theoretically write into the directory /home/user/.kingsquest/ rather than /usr/share/games/kingsquest/

Also, what about re-naming the game binary and setup utility to be more aligned with that of the game's name? ags-setup works great, but what if a user installs several ags linux games under /usr/share/games, and a link is put under /usr/bin/? This would cause confusion in the system, and running a setup utility from the command line would end up requiring the user to navigate to different folders just to set up their game of choice.

Here's what I propose: allow an updated version of the linux runtime to put game saves in a .GAMENAME file under the /home/username/ directory, and rename the binary executable and the setup tools to be named "GAMENAME" and "GAMENAME-Setup", respectively?

How trivial would it be to implement something like this?

[Electroshokker]

With the install script, be sure to double quote the $LOC variable in the cp and mv commands, lines 52-57.  When setting up a game that is in a dir with spaces, those commands won't work correctly otherwise.

Thanks for the tip!

For most native linux games, savegames don't actually go in the directory of the binary. Since AGS does this, and since this binary would be installed into a place that doesn't have root write access for good reason, this means that there is no logical way to save a game.

Yes. I suppose it would be ideal to put the savegame location into the configuration file so the end user can choose where save games should go.

Say, Chris, I believe not only Linux would benefit from such a change. Right now the windows versions also put the savegames in a fixed location which can be a little obscur to the player.

This needs some more thought to make it more uniform on all platforms.

Also, what about re-naming the game binary and setup utility to be more aligned with that of the game's name? ags-setup works great, but what if a user installs several ags linux games under /usr/share/games, and a link is put under /usr/bin/? This would cause confusion in the system, and running a setup utility from the command line would end up requiring the user to navigate to different folders just to set up their game of choice.

I've got a different solution for that problem, but haven't had the time to work on it yet. For the moment, games can't be in the same location.

[deadsuperhero]

Good to hear that you might be updating the runtime soon!   I'd really love to see a fix for the save issue, especially since the game seems to generate an agssave.999 every time the game is run. (As far as I can remember, anyways.)

I've got a different solution for that problem, but haven't had the time to work on it yet. For the moment, games can't be in the same location.

I, too, realized a workaround for this one. This would be more of a packaging issue than anything else.

Games reside in their own personal folders under...let say, /usr/share/games/$GAMENAME/

A packager could just make a link to the binary and the setup by having it work like so:

$GAMENAME would be a link to /usr/share/games/$GAMENAME/ags272
$GAMENAME-Setup would be a link to /usr/share/games/$GAMENAME/ags-setup

Of course, this would have to be done every time for the sake of packaging, but the end user wouldn't really have to do anything. Especially if these said games were just in some convenient PPA on Launchpad.

Another thing of note: audio. Technically speaking, it's possible to get sound effects, music, and voice files to work, though this requires your patched liballegro-4.2 library. Is it more beneficial to rely on liballegro-4.3, since that's what you're patching from anyways? If so, are there any plans to do so? This would probably save a lot of Ubuntu users the hassle of having to have the correct library to run the game. (Not PATCH the game, of course, but to just use the runtime itself)

Keep up the good work!  

[Pumaman]

save games should go.

Say, Chris, I believe not only Linux would benefit from such a change. Right now the windows versions also put the savegames in a fixed location which can be a little obscur to the player.

This needs some more thought to make it more uniform on all platforms.

Well, although a properly customizable location might be a good for a future version, for now AGS already handles this issue on Windows by saving games to the My Documents/My Saved Games folder.

For the Linux port, the Linux platform driver could override the virtual method AGSLinux::ReplaceSpecialPaths and replace the $MYDOCS$ tag with a standard writable location that it would be safe to save games to.

[deadsuperhero]

For the Linux port, the Linux platform driver could override the virtual method AGSLinux::ReplaceSpecialPaths and replace the $MYDOCS$ tag with a standard writable location that it would be safe to save games to.

A standard way for doing this would be under the home folder, in /home/$USERNAME/ and then a hidden directory .GAMENAME. Most Linux games and applications save user-specific settings and save files in this manner. (Actually, now that I think of it further, something like /home/$USERNAME/ .ags/ $GAMENAME might actually work better.)

Anyways, the benefit of doing so would allow for me to generate .deb Ubuntu packages and put it in a PPA. Currently the archive is empty, but I plan on going to development teams of the most popular AGS games in the future and using the runtime to generate the Linux binary. Then I can package it up, and Ubuntu users will finally have a simple enough way to play AGS games natively, without fiddling with configurations and packages too much.

The PPA is available here, although it is currently empty.
https://launchpad.net/~iliketowritestuff/+archive/agslinuxgames

[deadsuperhero]

Hate to bump this up, but is there any word on that save fix for the runtime?

[eriktorbjorn]

If you encounter any problems running AGS 2.72 games, let me know. Your feedback is appreciated!

I'm not sure if Trilby's Notes is AGS 2.72 or not, but the graphics look pretty strange in it for me. It's a 256-colour game and apparently the Red and Blue colour components have been swapped. This problem has been mentioned once or twice before, so maybe it's old news. Do you know if it's a problem with AGS, or if it's a problem with the Allegro library under Linux?

I eventually worked around the problem by compiling my own version of Allegro (4.2.3.1, to be exact) where I changed src/x/xwin.c so that the _xwin_private_hack_shifts() function doesn't ever set the use_bgr_palette_hack variable. That made the colours look like they should so that could indicate an Allegro bug, I guess. On the other hand, I wrote a trivial Allegro test program that ran in 8-bit mode and printed the words "Red", "Green" and "Blue" in their respective colours. That one worked fine with the unmodified Allegro library.

(I also noticed two rather minor glitches in 5 Days a Stranger and 7 Days a Sceptic, but they're too old to have been written for AGS 2.72 so maybe that's to be expected.)

[eriktorbjorn]

Another game I tried briefly was Adventures in the Galaxy of Fantabulous Wonderment. There's a graphics effect on the title screen that, when I run it under Windows, happens almost in the blink of an eye. When I run it under Linux it takes 40 seconds or so when I run the game at 640x400 pixels. Even at 320x200 it takes somewhere between 5 and 10 seconds. I guess this is an AGS 2.62 game, not 2.72, but both were equally slow when I tried them. The rest of the game (at least what little I looked at) seemed to run well, except for Red and Blue being swapped.

Just for fun I tried the 3.12 release candidate on it, and it was almost the exact opposite: The graphics effect on the title screen worked fine, but the rest of the game was unplayably slow.

[Electroshokker]

Hate to bump this up, but is there any word on that save fix for the runtime?

It's been a loooong time and I'm sad to say I couldn't get around to it 'till today. Anyways, you'll find the link in the first post.

Games will get saved to /home/$username$/.ags/$gamename$ with this build.

[Electroshokker]

I'm not sure if Trilby's Notes is AGS 2.72 or not, but the graphics look pretty strange in it for me. It's a 256-colour game and apparently the Red and Blue colour components have been swapped.

Looks like an old problem. I'll look into it, though. Having to re-compile Allegro is something I'd prefer avoiding wherever possible (though it can't be helped for those who have the no sound problem.)

Another game I tried briefly was Adventures in the Galaxy of Fantabulous Wonderment. There's a graphics effect on the title screen that, when I run it under Windows, happens almost in the blink of an eye. When I run it under Linux it takes 40 seconds or so when I run the game at 640x400 pixels.

Looking into it.

Just for fun I tried the 3.12 release candidate on it, and it was almost the exact opposite: The graphics effect on the title screen worked fine, but the rest of the game was unplayably slow.

Yes, the 3.12 candidate is really slow. Haven't gotten around to it. Will do so right after fixing the 2.72 build;

[deadsuperhero]

Tried getting a game to work with the new runtime patch for savepaths, unfortunately I get this error whenever I try and launch the game (For sake of reference, the latest version of Space Quest 4.5: Roger Wilco and the Voyage Home)

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

A quick Google search shows that this has something to do with allegro libraries. If we could smooth this one out, that'd be dandy.

[Electroshokker]

Tried getting a game to work with the new runtime patch for savepaths, unfortunately I get this error whenever I try and launch the game (For sake of reference, the latest version of Space Quest 4.5: Roger Wilco and the Voyage Home)

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

A quick Google search shows that this has something to do with allegro libraries. If we could smooth this one out, that'd be dandy.

This error means the wrong Allegro library is used. Are you using the one I recompiled or the standard one?