Author Topic: AGS engine Linux port (Read 120205 times)

Calin Leafshade · « **Reply #20 on:** 21 Jun 2012, 08:59 »

I'm pretty sure the engine is not currently capable of running under 64bit even if it compiles. There are too many int to pointer conversions and stuff.

Getting a 64bit compliant version of the source should be of high priority in my opinion. (mainly for linux)

JJS · « **Reply #21 on:** 21 Jun 2012, 09:05 »

I remember that you said that the script interpreter is the source of the 64 bit problems. Specifically that it uses ints for storing pointers. I wonder if the problem could be solved by introducing a translation table that maps these 32 bit values to their real 64 bit addresses. It would cost a bit of performance but the script engine is already slow and 64 bit CPUs are usually fast so speed would not be the problem there. Maybe it could be implemented as a macro around all such accesses. The macro then resolves to nothing on 32 bit and a respective function call on 64 bit.

There is of course still a possibility that some compiled-in library has 64 bit issues.

Edit: Is the problem mostly with these "inst->registers" accesses in csrun?

BigMc · « **Reply #22 on:** 21 Jun 2012, 09:36 »

Quote from: Calin Leafshade on 21 Jun 2012, 08:59

I'm pretty sure the engine is not currently capable of running under 64bit even if it compiles. There are too many int to pointer conversions and stuff.

Getting a 64bit compliant version of the source should be of high priority in my opinion. (mainly for linux)

I'm not talking about compiling AGS as 64 bit application. With -m32 it is compiled as 32 bit application and that works on 64 bit Linux if 32 bit copies of all required libraries are there.

I also had a brief look into making AGS 64 bit compatible, but gave up quickly. My interpretation is the following. There's some guessing involved, but that's how it makes sense to me. The AGS scripting language has something like pointers (or needs pointer features for addressing stuff or whatever). They are based on 32 bit numbers and implemented by casting the numbers to pointers, and doing pointer-like stuff in C. The numbers are no real pointers pointing to memory, but only make sense in the AGS context.

If you would want to cast the 32 bit numbers to 64 bit pointers and back, that means you have to know exactly which pointers are AGS pointers and which are real C pointers. That's where it got too hard for me, because I don't know the code well. However, I would highly recommend not to make this even uglier by continue using pointers, but to implement the AGS pointer features properly without abusing C pointers.

BigMc · « **Reply #23 on:** 21 Jun 2012, 21:56 »

The instructions for building a Debian/Ubuntu package on amd64 should now work for Debian unstable and hopefully on Ubuntu Quantal Quetzal. We need someone to test it on Ubuntu. There the distribution parameter for "pbuilder create" is "quantal". I will update the instructions when it also works on Debian testing.

JJS · « **Reply #24 on:** 26 Jun 2012, 21:47 »

There is now a native 64 bit version of the engine in the "64bit" branch of the repository: https://github.com/adventuregamestudio/ags/tree/64bit

At the moment it runs only games made with AGS 3.x.

There seems to be an issue with liballegro-4.2 on 64 bit that causes WAV files to fail to load. Games that use this file format and don't check for successful file opening will crash with a script error ("null pointer dereferenced"). The problem appears to be fixed in Allegro 4.4.

Crimson Wizard · « **Reply #25 on:** 26 Jun 2012, 22:14 »

Are you going to merge 32 and 64 bit code one day?
I checked your commit, it looks like most changes are related to default int size (you changed a lot of ints to long). Since that does not make a difference for 32-bit platform, same could be used in the main branch, am I correct?
There are other cases though, I wonder if they could be merged in one source with limited use of macros.

JJS · « **Reply #26 on:** 26 Jun 2012, 22:41 »

The 64 bit branch will also compile for 32 bit. I only created a branch instead of pushing to main because I am not yet sure if the engine is 100% stable and always behaves the same as the 32 bit version under all circumstances. Also, as I wrote, it lacks backward compatibility.

I will eventually merge the branch to main.

Tobihan also suggested changing the variables from generic int and long to the "right" ones, which are int32_t and intptr_t. This is a good idea and should ensure compatibility with different platforms (like Windows 64 which defines long long int as 64 bit, and long int as 32 bit).

Tea23 · « **Reply #27 on:** 29 Jun 2012, 22:02 »

Hullo, been watching this thread for a while waiting for someone to say that it now builds on 64bit. Sure, you Debianites might have got it to build in your funky chroots but on Arch we couldn't get anywhere (well, I guess we could chroot but we're lazy).

Had a little play of Blackwell Legacy with the Linux build, all works fine until I need to get to the park and then I had a black screen. Had to go to tty to kill the process.

And to help my fellow Archers, I've created an AUR PKGBUILD which I think has all the right dependencies listed... Anyway, seems to work on this end.

Also, thanks so much for this port. Been looking at the forums since the source code was released waiting for a proper port (I'm no programmer to any degree, unfortunately) and it's great to finally see it!

BigMc · « **Reply #28 on:** 29 Jun 2012, 22:56 »

You don't need alfont, but libfreetype. The dependencies are listed in debian/README.md.

You can run games in windowed mode by writing into acsetup.cfg

[misc]
windowed=1

Then you can see the error and report the bug.

I'm getting random segfaults all the time with the 64bit branch, while JJS can't reproduce that. We're still a bit clueless why global variables are at random adresses on my system, although I think I have turned off all randomization.

Tea23 · « **Reply #29 on:** 29 Jun 2012, 23:47 »

Well I could get console output anyway, without running in a window. The thing is that there was no error, the room was still loading. I don't think it actually crashed, it just kept trying to load the room and couldn't make it.

JJS · « **Reply #30 on:** 29 Jun 2012, 23:48 »

I caved in and got the Blackwell games. The error was caused by the aastr library which used long* to access an int* value. Valgrind to the rescue again

. I pushed a fix to the repository.

About the error, that BigMc mentioned: It would be great if some more people would test the 64 bit branch on their system. Right now we don't have a lead on what is causing the engine to be loaded to different addresses on his system. This is something that should not happen for several reasons (1) The engine binary is not PIE enabled. (2) PIE is deactived in the system settings. Still, it is loaded to a different address every time. This is a problem because the script interpreter relies on global variables being accessible with 32 bit long pointers. As BigMc said, I cannot reproduce the error. It only occurs for me when I explicitly compile the engine with PIE support.

Tea23 · « **Reply #31 on:** 29 Jun 2012, 23:55 »

Quote from: JJS on 29 Jun 2012, 23:48

I caved in and got the Blackwell games. The error was caused by the aastr library which used long* to access an int* value. Valgrind to the rescue again . I pushed a fix to the repository.

About the error, that BigMc mentioned: It would be great if some more people would test the 64 bit branch on their system. Right now we don't have a lead on what is causing the engine to be loaded to different addresses on his system. This is something that should not happen for several reasons (1) The engine binary is not PIE enabled. (2) PIE is deactived in the system settings. Still, it is loaded to a different address every time. This is a problem because the script interpreter relies on global variables being accessible with 32 bit long pointers. As BigMc said, I cannot reproduce the error. It only occurs for me when I explicitly compile the engine with PIE support.

Ah yes, I just noticed that commit, recompiled and a gave it a try; the level loaded. Thanks.

I do need an excuse to play through Blackwell again so I'll get on that with this build. I needed an excuse to replay the Blackwell series so I'll keep an eye out for bugs. Just registered to Mantis so hopefully (or not) my reports should be flooding in.

JJS · « **Reply #32 on:** 30 Jun 2012, 12:50 »

I made another update to the source, again in aastr, because I noticed that scaled anti-aliased sprites were drawn incorrectly.

Tea23 · « **Reply #33 on:** 01 Jul 2012, 20:29 »

Spent all day yesterday battling with ALSA so I didn't get to play anything until today. I'm spotting very few issues in Blackwell Legacy although when Rosa moves away from the camera (like going into the doctor's office) her sprite gets pretty blurry. I don't know if you've ever played Broken Sword 2 but it looks a bit like George does when you set the graphics to low.

I haven't finished playing yet but I really can't see any issues. I don't think I'm getting the errors related to memory addresses, either.

xenogia · « **Reply #34 on:** 05 Jul 2012, 02:22 »

I get crackly sound in Ubuntu 12.04. Is this due to Pulseaudio by any chance?

BigMc · « **Reply #35 on:** 05 Jul 2012, 09:28 »

I have no problems with PulseAudio. Is this a slow computer? Are you using the 64bit branch?

xenogia · « **Reply #36 on:** 05 Jul 2012, 12:32 »

It is actually my work machine which is an AMD AM2 6000+. It does use an integrated nvidia solution (also the 32bit build). I'll try it on my home machine.

BigMc · « **Reply #37 on:** 05 Jul 2012, 12:43 »

You can try suspending PulseAudio, but I have no idea what causes this.

$ pasuspender -- ags game.exe

EDIT: Which games are affected?

xenogia · « **Reply #38 on:** 05 Jul 2012, 12:45 »

I also segmentation faults with Resonance and the latest Blackwell game, but this stopped once I removed the acsetup.cfg. But how can I get it so it is full screen?

BigMc · « **Reply #39 on:** 05 Jul 2012, 12:46 »

Use the acsetup.cfg, but remove the lines with D3D. We should do something about these lines crashing the engine.