Messages

Be VERY careful when changing existing command line options, Editor may use these to run games. If you change in one place, make sure you scan ALL the code and make appropriate changes.

My understanding was that they were JUST added last week. The Editor should not rely on these flags for anything.

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.

I'm no C++ guru but I think I hacked together BUILD_STR as a make option. Can someone with git access see if my pull requests are correct? I haven't used git until yesterday. All the projects I've worked on in the past have been SVN. Git is new to me.

The demo works fine for me on Debian Wheezy 64 bit. 
Now the only thing that's missing is a linux equivalent to winsetup.exe, so you don't have to find and edit acsetup.cfg to switch between fullscreen and windowed mode. A basic setup tool would be a good idea if you want to distribute a commercial game this way.

If you run ./shivah --help it will give you the help output of ags, which includes the -windowed and -fullscreen options. Even if you don't know how to edit the config, the binary gives you the options now. Did we decide to switch to --windowed and --fullscreen to be more Linux-y?

Now the only thing that's missing is a linux equivalent to winsetup.exe, so you don't have to find and edit acsetup.cfg to switch between fullscreen and windowed mode. A basic setup tool would be a good idea if you want to distribute a commercial game this way.

That's on my list of things to do. I'll probably whip up a quick perl script that writes our your acsetup.cfg for you. I want to use dialog, but most boxes probably don't have that installed. It'd only be 2 questions:

1) Window/Fullscreen
2) GFX Filter

We probably don't NEED one, if we ship sane defaults.

EDIT: Oh, I see, you didn't read the README. You must put the game into "data".

After RTFM I packaged up my Shivah demo using your engine and posted it here. Looks like it works pretty well. Want to take it out for a spin on your various distros?

http://www.perturb.org/tmp/shivah-demo-2013-01-30.tar.gz

I just setup a github account and sent a "pull request" (I think). To add the strip option to the Makefile. Can someone tell me if I did it correctly?

Aha! Well if I RTFM then everything works fine!

It works great with my Shivah demo. Let me throw something else at it. Thanks for putting this all together.

That is exactly what I want! Both 32 and 64bit versions, and a launcher that picks for you! I did run in to some issues on my Fedora 17 machine:

#1) The binary doesn't seem to find my GeminiRue.ags file, and neither does the launcher. If I run data/ags64 GeminiRue.ags it launches just fine. Did the game detection code change?
#2) I get no sound. Not sure why. The ags I compiled on this machine works fine. I'm assuming it has something to do with the libraries?
#3) Does this include the save game fix Crimson Wizard mentioned?

My bad... I posed the wrong link (to yesterday's build). Try this guy, that's from TODAY.

http://www.perturb.org/tmp/shivah-demo-2013-01-29.tar.gz

Can you guys test my latest creation:

http://www.perturb.org/tmp/shivah-demo-2013-01-28.tar.gz

This should include a 32bit AND 64bit executable. I haven't built it against glibc 2.13, so currently Wheezy won't work, but everything else (modern) should.

Once we get a stable binary and libs/ directory, that works on multiple distros, we shouldn't need to change much. If we compile ags, and get the libs/ from it once, it's not like we'll need to do it every night. I consider the linux binary to be pretty solid, so I feel comfortable releasing with it. What do you guys think?

Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).

I had that same problem with the demo. I didn't try the windows version, I just assumed it was a bug in the demo.

Another idea would be to use the openSUSE Build Service to provide AGS packages for all major distributions.

I like the idea of getting ags into a lot of the major Linux distros. I have some experience getting a package into the Fedora repositories.

For me this would be a secondary goal, primary being getting a generic (cross distro) ags binary I can package up for Wadjet's Linux releases. Once I get something to Wadjet I'd love to work on getting this packaged. AGS compiles quite simply, so it should be easy to package up.

I don't know much C, but I can edit a Makefile. Consider this formal patch my contribution to the code:

http://www.perturb.org/tmp/ags-strip.patch

The resulting binary was ~10MB, and ~2MB after being stripped. I've been using:

Code: AGS

make clean && make all && make strip

to get my binaries. I will feel very accomplished if I can get some actual code committed, even insignificant code such as this

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?

[ags]

Holy crap I think that just might work! I made up an updated standalone (distro agnostic) package of the Shivah demo:

http://www.perturb.org/tmp/shivah-demo-2013-01-28.tar.gz

This was compiled on 32 bit Fedora 18. I've tested the following distros so far:

Fedora 18 32bit
Fedora 17 64bit
Ubuntu 12.10 32bit
Linux Mint 13 32bit

And it run just fine. Anyone else want to help test, please let me know.

I renamed the ags executable shivah, so it looks more legit (better than ./ags shivah.ags) and ran in to two minor issues:

#1) It seems to ignore the acsetup.cfg, the gfxfilter isn't applied.
#2) If you run ./shivah --help the usage still says Usage: ags [<options>] [<gamefile or directory>]

Is it possible to make the usage output $0 (executable name) instead of the hardcoded string "ags"? Not a huge deal, purely cosmetic.

EDIT2: We could include build date and time there.

Better than a build date, would be a build string. Then I could do

make BUILD_STR="3.1-TestFixes" or something to give textual information as well as a version number?

While we're on the topics of builds. Is there a way to include the version number in the --help? Specifically like build date/time? Or some unique number? Right now ALL my builds say 3.21.1115.

make VERSION_STRING=foo

Something like that?

You can take the libraries from a distribution.

Oh! I was thinking they'd have to be the statically linked libraries. You're talking about just copying liballeg.so.4.2, etc to lib/ in the same dir?

That seems possible. We'll need someone whose capable of building the the libraries, and the binary. That's a little beyond my basic compiling skills.

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.

Ah ok... well that causes problems because we can't just link against /lib64/libaldmb.so.

If you're Wadjet and you want to release a Linux version of your game you want to sell on Steam and have it be cross distro (not have a diff executable for each distro combination) what's their best bet? Statically linked?