[OLD-1] AGS engine Linux port

[JanetC]

Hopefully, if I provide nicely packaged installers for all the demos in their catalogue, I can convince Dave Gilbert to just sell native Linux versions of the games on Desura, Steam, and their website

We really want to release all our games on Linux before too long. We are concentrating on iOS for now but Linux is definitely on the list! We are mainly limited by manpower - there is only one of me, and I'm doing the ports. Linux should hopefully be easier as we won't have to change all the controls like we did on iOS.

- Janet from Wadjet Eye.

[scottchiefbaker]

I just updated and recompiled ags from the master branch and it plays and runs VERY smooth. I played through most of the Primordia demo and didn't run in to any issues. I think the tree is ready to see some real releases. I'd be happy to help get them packaged up and tested.

[scottchiefbaker]

I'd like to request an addition to the ags Linux launcher. Can we add a "--windowed" and a "--fullscreen" option at the command line that would override whatever is in the config file?

[BigMc]

They are already there, but called "-windowed" and a "-fullscreen". I also added "--help" and "-gfxfilter" earlier today. The latter can be used to scale games up more to use more of the screen.

[Crimson Wizard]

They are already there, but called "-windowed" and a "-fullscreen".

Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.

[scottchiefbaker]

That's awesome! I'll work on packaging up some Linux releases. What are the default places for game data?

(Unable to find game data file in any of the known locations.)

Here is what I have founds works:

#1) ./ags something.exe
#2) ./ags /path/to/dir
#3) ./ags

#3 works if you're in the dir with a .exe in it? If we were to do Linux release we probably don't want to include a .exe file. Could we use something like ./ags agsdata.bin to launch? Where agsdata.bin is just the .exe file renamed?

Ideally I'd just rename ags to "resonance" or whatever is appropriate, and let the binary "find" where the data files are.

[scottchiefbaker]

They are already there, but called "-windowed" and a "-fullscreen".

Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.

I totally agree with this. Not sure how you're doing it, but if you're using getopt you get that functionality for free.

[BigMc]

Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.

I could do this using getopt.h, but that's not available on Windows. Should we keep the current code with only long options for Windows and use getopt for everything else? Or can we live without commandline options on Windows? Everything should also be accessible via the config file right?

[Crimson Wizard]

What are the default places for game data?

I think we should put this in a readme. Anyway, here how it should work.
The engine accepts ANY file, provided that it is a valid game data format, of course.
The search for the game data is done in a following order of priority:

1. From command line argument. If the path was supplied as cmdline parameter, engine will use it. Currently it cannot distinguish directory from file in a correct way, and treats path as dir if it has a trailing '/'. Otherwise it will think it's a file.
If a directory is supplied this way, engine will search for the first valid game file in that directory, matching following pattern: "*.exe", "*.ags" or "ac2game.dat".
2. From config file. The game file could be set in group "misc" as "datafile" option.
3. If path is not supplied either in cmdline or config, the engine will search:
3.1. For data attached to the engine executable (like AGS always did on Windows).
3.2. For game file in current working directory (same patterns as mentioned above).
3.3. For game file in the same directory as where engine executable is located (if it is different from current dir).

KNOWN ISSUES:
1. Engine does not understand relative paths, only absolute ones. http://www.adventuregamestudio.co.uk/forums/index.php?issue=370.0
2. Engine has problems with paths, containing spaces. At least on Windows (don't remember about Linux).

I could do this using getopt.h, but that's not available on Windows. Should we keep the current code with only long options for Windows and use getopt for everything else? Or can we live without commandline options on Windows? Everything should also be accessible via the config file right?

I was thinking about writing a class for storing cmd args. That could also come handy to fullfil this user request: http://www.adventuregamestudio.co.uk/forums/index.php?issue=322.0

[BigMc]

If we were to do Linux release we probably don't want to include a .exe file. Could we use something like ./ags agsdata.bin to launch? Where agsdata.bin is just the .exe file renamed?

You can also strip off the Windows engine.

I think we should put this in a readme.

Ok, do it.

I was thinking about writing a class for storing cmd args. That could also come handy to fullfil this user request: http://www.adventuregamestudio.co.uk/forums/index.php?issue=322.0

Ok go ahead. One common way to separate different sets of command line options is to use "--", e.g.

ags --engine --options -- --script --options

That doesn't mean that getopt wouldn't help with the actual parsing though.

[scottchiefbaker]

getopt is freaking phenomenal. At least look at it before you implement your own. No sense in re-inventing the wheel when getopt is already done, and very powerful. Are you sure getopt isn't available on Windows? It should come with glibc, which you can get from cygwin if nothing else.

If we can't get getopt on Windows, I don't think that's a big deal. You already have the short version strings.

[BigMc]

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

[scottchiefbaker]

Is there a way to make a static build of ags? I'm seeing that the executable I made links against allegro 4.4, which my target machine doesn't have.

[BigMc]

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

[scottchiefbaker]

I was trying to make a "universal" binary that would be portable on different machines/distros. At least get the low hanging fruit: Ubuntu, Fedora, Mint in one binary.

[BigMc]

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.

[Sslaxx]

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.

My understanding is he wants to do a static build against Allegro 4.4?

[scottchiefbaker]

My understanding is he wants to do a static build against Allegro 4.4?

I'm not very good at C or Makefiles, what do I need to do to build a static binary? Ultimately we should add an option to Makefile to allow a static build.

[Crimson Wizard]

Errr, is this all about linking Allegro as static lib?
In Windows this is done by the use of ALLEGRO_STATICLINK flag (preprocessor definition). Probably Linux can use this too?

[scottchiefbaker]

I see -DALLEGRO_STATICLINK in the Makefiles-defs.linux file. Looks like it's already set?

Also, if I add -static the CFLAGS I get:

Linking engine...
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbeginT.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [ags] Error 1

Unless -static is positional somehow?