[OLD-1] AGS engine Linux port

Started by BigMc, Sun 03/06/2012 19:04:20

Previous topic - Next topic

Spummy

Quote from: s_d on Wed 06/02/2013 18:50:47
Yes, Elektroshokker's.  Looks like he logged in here not too long ago, so a PM might get his attention  :)

Though, if I recall, it used an old GTK or something and may need to be rewritten anyway.  I suppose we could bung it out in Python and use iniparse & PyGtk to make it pretty.

I'm up for programming a new config tool if needed. Is there a preference of language and widget toolkit? Because Python and wxWidgets would certainly get it done fast, but creates the requirement of python and wxPython to be installed. If we only want to use it for Linux then most distros appear to come with Python so that's not much of an issue, and I suppose if a dev REALLY wanted to idiot proof it they could prebundle wxPython, but that may be more of a hassle than wanted.

Of course, I'm going to wait around a wee while to see if Elektroshokker is around and can throw the code for his tool at us.

scottchiefbaker

Quote from: BigMc on Wed 06/02/2013 19:44:45
I pushed a change enabling StdScale up to 8x. Seems to work just fine. Don't know about performance, my PC handles it.

Can I request a build of ags+libraries that has this check? I'll build a new GeminiRue package with it. Please and thank you.

s_d

He said he already pushed it.  Just update and rebuild (I'll do it when I get home, if necessary).  The libraries have not changed.

scottchiefbaker

Oh I've rebuilt it locally on my box. But I'm running Fedora with Glibc 2.15, and we're building on Debian which includes 2.13, and is thus more universally compatible. Our build environment for this project has been a Debian Wheezy install. Plus we'd need a 32bit and a 64bit version of Wheezy to build both versions. BigMc already has this all setup, so it's easier for him to put it all together.

If need be I can build two Debian boxes that can be used JUST for building. It'd just take time I don't really have right now.

s_d

Ah, yes the glibc versioning.  I forgot.  I have that set up partially (I set up my 32-bit build environment on Debian because of that issue, but have continued building 64-bit on Ubuntu).  I might as well set up the 64-bit version as well.  Thanks!

s_d

Quote from: Spummy on Wed 06/02/2013 21:57:12
Of course, I'm going to wait around a wee while to see if Elektroshokker is around and can throw the code for his tool at us.

I PM'ed him  :)

BigMc

I just have one Debian installation and use chroots for building. One can easily build the Debian package using pbuilder or cowbuilder. I think it's also no big deal to set up Debian chroots on Ubuntu and use them for building.

Here you go: http://people.debian.org/~thansen/ags+libraries_20130206.tar.xz

scottchiefbaker

Quote from: s_d on Wed 06/02/2013 22:52:06
Ah, yes the glibc versioning.  I forgot.  I have that set up partially (I set up my 32-bit build environment on Debian because of that issue, but have continued building 64-bit on Ubuntu).  I might as well set up the 64-bit version as well.  Thanks!

If you could setup Debian 32/64bit installs, that would be awesome. That way BigMc isn't the only one who can do official builds.

s_d

Quote from: BigMc on Wed 06/02/2013 22:58:33
I think it's also no big deal to set up Debian chroots on Ubuntu and use them for building.

Exactly;  that's my 32-bit build environment, a Debian chroot running on 64-bit Ubuntu 12.04, I just hadn't bothered with a 64-bit chroot as well, since I was already building natively.  Might as well do so, so that you don't have to roll all the builds.

s_d

Quote from: scottchiefbaker on Wed 06/02/2013 22:59:38
That way BigMc isn't the only one who can do official builds.

Hah, exactly  8-)

scottchiefbaker

How exactly does your auto scaling code work? Is it something like this?

scale_factor = floor(display_resolution / game_resolution);

Quote from: BigMc on Wed 06/02/2013 22:58:33
Here you go: http://people.debian.org/~thansen/ags+libraries_20130206.tar.xz

You are awesome... thanks!

BigMc

if windowed
  display_resolution_y = display_resolution_y - 100

scale_factor_x = display_resolution_x / game_resolution_x;
scale_factor_y = display_resolution_y / game_resolution_y;
scale_factor = min(scale_factor_x, scale_factor_y)

since these are integers, "floor" is implied. Next time look at the commits. ;)

scottchiefbaker

Those of you building ags on other platforms, can you please respond to this forum post I just made:

http://www.adventuregamestudio.co.uk/forums/index.php?topic=47590

I want to get a collection of super simple instructions for various distros that will allow anyone (even a novice) to build ags. Specifically what the dependancy names are. On Fedora it's dumb-devel, but I think Ubuntu is libdumb-devel?

BigMc

The dependency names for Ubuntu are in the readme.

s_d

Yeah, I just used the README.md from github.  Probably, Scott, you should just add a Fedora section to that document, that way the repo describes itself (rather than needing to go to a forum to learn to build it, where links can break, etc).

I could write up a Gentoo ebuild when I get around to it, as well, or just update the old AGS 2.72 ebuild (not sure how much as changed, in terms of how it's built).

s_d

BigMC, just noticed something in widescreen mode, with auto-scaling.  It seems to not be adding widescreen borders (i.e., it's off-center) even though it claims to have checked it and found it unnecessary:

Quote
AGS: Widescreen side borders: game resolution: 320 x 200; desktop resolution: 1366 x 768
AGS: Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)


s_d

Quote from: Crimson Wizard on Mon 14/01/2013 12:06:59
Also, there is an utility, made by one guy, which allows to "cut" Windows binaries from game exe, producing a clean game data package (this also saves 0.5-1.5 megs depending on game version): https://github.com/rofl0r/agsutils. That may be used meanwhile.

FYI, this utility ("agstract" specifically), while awesome and useful, is alpha-quality code.  In particular, it has trouble with packfiles split into multiple pieces (there is an enumeration/off-by-one-error I'm tracking down).  Just fair warning!

My debugging is complicated by the fact that I'm pretty new to AGS, and properly debugging this requires a great deal of knowledge of the packfile format that AGS uses.  At any rate, if I can get it fixed, there will be a nifty side-effect, which is that we could extract the contents of multiple data files to a temp directory, and then pack them cleanly into a single archive.  I'll continue the convention we've established here, where we name those "EXE"-less data files with the ".ags" extension.

In the mean time, we may need to just get used to packing up games like that with the EXE bits intact.

Crimson Wizard

#297
As JJS mentioned, you can just cut off file contents between two signatures: "CLIB" and "CLIB\x1\x2\x3\x4SIGE" (inclusive!!)
To see how these are being looked for check AssetManager class - Common/core/assetmanager.h and .cpp (this is a refactored version of older Clib32 unit). Specifically: AssetManager::_IsDataFile and AssetManager::RegisterAssetLib:

Code: cpp

    // check multifile lib signature at the beginning of file
    ci_s->Read(&clbuff[0], 5);
    if (strncmp(clbuff, _libHeadSig /*"CLIB"*/, 4) != 0)
    {
        // signature not found, check signature at the end of file
        ci_s->Seek(Common::kSeekEnd, -12);
        ci_s->Read(&clbuff[0], 12);
        // signature not found, return error code
        if (strncmp(clbuff, _libTailSig, 12) != 0)
        {
            return false;
        }

        // read multifile lib offset value
        abs_offset = ci_s->ReadInt32();
        ci_s->Seek(Common::kSeekBegin, abs_offset + 5);
    }


The "end-of-file" signature is the path for data attached to the end of exe. abs_offset points to where data actually starts. What you should do is extract all data from abs_offset to the end of file.

BigMc

Quote from: s_d on Thu 07/02/2013 02:04:30
BigMC, just noticed something in widescreen mode, with auto-scaling.  It seems to not be adding widescreen borders (i.e., it's off-center) even though it claims to have checked it and found it unnecessary:

That is probably because AGS expects Allegros graphics initialization to fail if the given resolution can not be set as display resolution, as explained earlier by JJS. This is not the case on Linux, so a different path through the spaghetti code in graphics_mode.cpp is taken.

scottchiefbaker

If there is NO acsetup.cfg file at all, we're going to default to BigMcs autoscale right? Do we default to -windowed or -fullscreen at that point?

SMF spam blocked by CleanTalk