Topic: AGS engine Linux port

[eri0o]

until latest 3.4.0 the engine does run well under Wine. Since 3.4.1, the engine doesn't run well under Wine- sometimes it crashes and require you to kill it (you can use xkill) - but the Linux build should run. It's available in the release of the Editor. If you use Ubuntu, building either the latest stable engine or the sdl2 port (still in development) should be easy. I've been thinking about packaging it as snap, if you think it's useful, let me know.

Edit: I started by going after the editor first, once it works, I will give a shot at the engine. github repo for ags-editor snap here.

github repo for ags-engine snap here

all snaps are still in development, but once they are solved, people with Debian derivatives will be able to snap install ahs-editor and snap install ags .

[thedaemon]

I tried the Snap you built but was unable to get it to run, after reading the code I found out it was just using Wine and was pointless for me to use since I already am using AGS with Wine. I was hoping it was the native Linux port.

Why is there not a pre-built Linux build? Why do I have to compile it myself? Just curious, I will try to compile and share a package with others since there isn't a package. Cheers.

[Crimson Wizard]

Why is there not a pre-built Linux build? Why do I have to compile it myself? Just curious, I will try to compile and share a package with others since there isn't a package. Cheers.

There is a package we make for the Editor to be able to deploy Linux builds of the game automatically. Such package is linked in every release thread, for example this: http://www.adventuregamestudio.co.uk/releases/finals/AGS-3.4.1-P2/AGS.3.4.1.13.Editor.Linux.Pack.zip
It may also be used to run any game. There is no guarantee that it runs on every Linux system, of course, but it should run on "common" ones, such as Ubuntu and Debian.

Alternatively, we could attach such package to the release tag in the repository, under better name (to make it clear what it is), it's just that no one asked us to do so, at least in my memory.

I've been told before, that in Linux community there should be a program "package maintainer" who makes and updates package for particular Linux system, and who is not necessarily a part of core development team.
For instance, I know that github user rofl0r is making AGS engine packages for "Sabotage Linix" system. On his request I am adding an archive with related source code for each stable release, which may be seen here for example: https://github.com/adventuregamestudio/ags/releases/tag/v.3.4.1.13

[thedaemon]

Thank you for your reply. I will look into maintaining a Debian package.

From my understanding of your reply, and lack of access to Linux right now(I will check in a few hours), there is no native build of the Editor for Linux, just an export package for the editor to build for Linux?

[Crimson Wizard]

From my understanding of your reply, and lack of access to Linux right now(I will check in a few hours), there is no native build of the Editor for Linux, just an export package for the editor to build for Linux?

Right, there is no native build for the Editor. It is written in C#, which means to run on Linux it has to be ported to Mono (or rewritten completely, for what is worth).
There is an issue ticket opened regarding former: https://github.com/adventuregamestudio/ags/issues/442

[thedaemon]

Thanks again for your timely reply. Above and beyond
I don't have the skill to port to another language at this time.. but subscribed to the thread.
I will continue to run via Wine. So far 3.41 has ran flawlessly this way!

[eri0o]

wait, both snaps are work in progress! I think I wasn't clear when I wrote. I am currently having some trouble with lxd on my computer (which I need to snap wine in a reproducible manner), once I finish this, there will be a release (in Github->Release) and also on the snap store. But yes, it's the same as wine, the idea was just to make it easier to install. I just post work in progress with the hope that someone will find/solve the problem for me .

[thedaemon]

I did spend a good 30 minutes trying to fix it. It was not running the extension installations. It also worked half way with sudo and the other half with my user. I think it conflicts with user permissions because the files are installed with root? I'll try again later.

[Radiant]

A player reports garbled sound on the Linux build, with the following system specs:

OS: Ubuntu 18.04
CPU: Intel(R) Core(TM) i7-7700 @ 3.60GHz
RAM: 32 GB
GPU: GeForce GTX 1060 6GB
NVIDIA driver: 396.24.02
Sound: I'm using the HDMI port from the graphics card: GP 106 High Definition Audio Controller

Does this sound familiar to anyone? Can someone give me an idea what could fix this please?

[morganw]

First port of call is probably Pulseaudio settings:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46152.msg636552085#msg636552085

[toojays]

I'm new to AGS. Just bought Lamplight City which uses it last week. I was disappointed with the performance running fullscreen; it sounds like I've run into what you guys call the "scaling problem"?

Anyway, this inspired me to try and get AGS' OpenGL renderer working on Linux. I don't have previous OpenGL experience but was able to crib from enough tutorials to get it working in windowed mode.

Code is at https://github.com/toojays/ags/tree/ags3+linux-opengl , see the commit message at https://github.com/toojays/ags/commit/4ae20e7317241fe3b1435ccd0652956dfca38c88 for more detail.

I've only tested it with one game (Lamplight City) on one system (Ubuntu 18.04, Intel graphics) so far. Fullscreen mode isn't working yet. Somewhere in AGS the system tries to resolve the game's 640x400 against my PC's 1920x1080 and comes up with 1728x1080 (game res * 2.7). I fail to set this as a fullscreen mode and AGS falls back to windowed mode. I guess the driver is supposed to realize the system won't do 1728x1080 and ask the windowing system for 1920x1080? Does anyone know?

[Crimson Wizard]

Anyway, this inspired me to try and get AGS' OpenGL renderer working on Linux. I don't have previous OpenGL experience but was able to crib from enough tutorials to get it working in windowed mode.

Code is at https://github.com/toojays/ags/tree/ags3+linux-opengl , see the commit message at https://github.com/toojays/ags/commit/4ae20e7317241fe3b1435ccd0652956dfca38c88 for more detail.

I've only tested it with one game (Lamplight City) on one system (Ubuntu 18.04, Intel graphics) so far. Fullscreen mode isn't working yet. Somewhere in AGS the system tries to resolve the game's 640x400 against my PC's 1920x1080 and comes up with 1728x1080 (game res * 2.7). I fail to set this as a fullscreen mode and AGS falls back to windowed mode. I guess the driver is supposed to realize the system won't do 1728x1080 and ask the windowing system for 1920x1080? Does anyone know?

Hello, toojays. It's really nice to see someone tried doing this. I kept hoping to look into this myself but never found a moment to research the OpenGL working on Linux (also, there was ongoing Nick Sonneveld's SDL port attempt, but it seems to get delayed again).

Can't answer to the fullscreen problem right away, this is something to investigate. I may mention one thing though (and also the main reason that was stopping me). Since OpenGL does not support "dedicated fullscreen mode" on Windows I had to emulate fullscreen mode (probably this is how everyone do this) by switching desktop resolution. This is not done in ali3dogl.cpp itself, but in the "platform driver" class. You may find calls to "platform->EnterFullscreenMode", "platform->AdjustWindowStyleForFullscreen" and "platform->ExitFullscreenMode" in OpenGL renderer. The implementation for Windows is located in acplwin.cpp. But I honestly do not know if we should follow same procedure for Linux or not (also don't know X11 very well, I wrote literally couple of functions using it before).

Am I right that you are using "glew" library, that helps to bind function pointers to dynamically loaded OpenGL object? OpenGL renderer was originally written in such a way that on Windows we manually getting function addresses, and that would be actually a nice thing to get glew used on Windows eventually too (not sure why I never tried, maybe was worried to break something that was already working).

I have a proposal, since this forum thread is too long already and contains all kinds of various discussions, could we continue on github instead, by opening an issue ticket in our repository? I believe that would be more convenient especially since you already have account and some code in progress there.

[toojays]

Hello, toojays. It's really nice to see someone tried doing this. I kept hoping to look into this myself but never found a moment to research the OpenGL working on Linux (also, there was ongoing Nick Sonneveld's SDL port attempt, but it seems to get delayed again).

Can't answer to the fullscreen problem right away, this is something to investigate. I may mention one thing though (and also the main reason that was stopping me). Since OpenGL does not support "dedicated fullscreen mode" on Windows I had to emulate fullscreen mode (probably this is how everyone do this) by switching desktop resolution. This is not done in ali3dogl.cpp itself, but in the "platform driver" class. You may find calls to "platform->EnterFullscreenMode", "platform->AdjustWindowStyleForFullscreen" and "platform->ExitFullscreenMode" in OpenGL renderer. The implementation for Windows is located in acplwin.cpp. But I honestly do not know if we should follow same procedure for Linux or not (also don't know X11 very well, I wrote literally couple of functions using it before).

Am I right that you are using "glew" library, that helps to bind function pointers to dynamically loaded OpenGL object? OpenGL renderer was originally written in such a way that on Windows we manually getting function addresses, and that would be actually a nice thing to get glew used on Windows eventually too (not sure why I never tried, maybe was worried to break something that was already working).

I have a proposal, since this forum thread is too long already and contains all kinds of various discussions, could we continue on github instead, by opening an issue ticket in our repository? I believe that would be more convenient especially since you already have account and some code in progress there.

Thanks for your response about how you did fullscreen on Windows, I'll do some investigation along those lines.

Yes, I used GLEW. It was a bit annoying to figure out how to get it working, because I didn't see any official documentation saying that you need to set a current GL context before you initialize GLEW. But once you get it set up, it sure is nicer than having an explicit lookup for every single call you want to make.

I've opened https://github.com/adventuregamestudio/ags/issues/510 to continue discussion of OpenGL on Linux.

[reportsthg]

Hey! I have a small problem on MY COMPUTER but I don't know how to solve. I built the Linux engine in Ubuntu 16.04 and if I try running a game with it, it's excruciatingly slow. So I test and run my own game using Wine. I have Steam in this computer too. I play the Wadjet Eye games and they all work well. When I tried running Until I Have You from Steam it ran as bad as my own built Linux Engine, so I guess there is something more to it. I don't have much installed on this Ubuntu computer since I mostly use it only for developing my game in Adventure Game Studio (with Wine).

Linux port has only software renderer available at the moment, which runs slow, especially if game scales to larger display resolution. That would be my first guess. On Wine you have Direct3D and OpenGL (if you are using AGS 3.4.1).

The solution would be to make OpenGL renderer work on Linux, which may be trivial, except someone needs to make such change (this also requires a knowledge of what headers/libraries to add to the engine).

I found something interesting about that topic.
It regards to intel graphics hardware.
When Xorg is started with Acceleration: SNA then graphics are not slow, they are usable.
But when usung the glamor acceleration of Xorg, then ags is unusable slow, with every game I tested.
I also compiled and tested the OpenGL build, which was linked here, it is working fine with glamor acceleration.

You can read more about intel graphic acceleration here (scoll up the page a little bit): https://wiki.gentoo.org/wiki/Intel#Modesetting_DDX

Glamor Acceleration has some problems. You can read about them here: https://www.x.org/wiki/Development/Documentation/GlamorPerformance/
Maybe AGS is using some methods (like many small overlapping blits?) which affect the performance with Glamor Acceleration that much?

BTW: those google reCAPTCHA just suck!

[Dualnames]

https://steamcommunity.com/app/439310/discussions/0/1798529872636973338/

Any thoughts on this? The game is using 3.3.5 AGS I believe with the linux binaries.

[eri0o]

Ok, I have ABSOLUTELY NO IDEA, but usually sound in AGS gets distorted when framerate is bad.

So I would guess the person is running the game in fullscreen in a Linux distribution, and it's getting fps drops. Now I will guess the person actually has a performant computer and reason the frames dropping is some weirdly written code in the engine.

For some reason in some Linux Systems the engine drops frames when Full Screen on Linux. I don't have this problem, but I've seem this problem reported. I think the magic line was LIBGL_DRI3_DISABLE=true in this code  from @vga256. I think this is what Mage's Initiation is using.

[morganw]

It won't be using OpenGL, so the DRI3 setting won't make a difference. The easiest test to see if it is related to excessive CPU load is to start the game windowed with no scaling, and see if the audio is then working normally. Also if the game shipped with threaded audio playback enabled in the config file, I don't think this is very well tested on anything but Windows, so you'd probably want to check that this is turned off.

[Dualnames]

He's running it on windowed and no luck!