[OLD-1] AGS engine Linux port

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

Previous topic - Next topic

sigmich

Quote from: eri0o on Sat 09/09/2017 00:14:12
... it's excruciatingly slow ...

Have you tried windowed mode? It has completely solved slowness for me and I have no problem playing adventure games this way until fix.


sigmich

Information for linux gamers interested and absolutely new and unexperienced to this like me. Sorry for spaming if it's too obvious for someone. Launching games windowed could make bottom lines of text in game unreadable and unclickable. So I have to launch ags with gfxfilter option:

ags --gfxfilter stdscale 4 --windowed

You can set the different number from 1 to 4 to best fit to your monitor.

If launching ags without any gfxfilter it runs fine even fullscreen but it's too tiny:
ags --gfxfilter none --fullscreen
or
ags --gfxfilter stdscale 1 --fullscreen

Radiant

My Linux build gives the following error,

ERROR: ld.so: object '/home/gamer/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory

Does this look familiar? The second line appears to be Steam initializing a 32-bit library for a 64-bit game, and the second line appears to be AGS trying to initialize MIDI on a system that doesn't have MIDI drivers installed. Any suggestions on how to fix this please? The engine is timestamped 5-11-2016, I think that's the latest 3.3 release.

Crimson Wizard

Quote from: Radiant on Tue 24/10/2017 20:14:12
My Linux build gives the following error,

ERROR: ld.so: object '/home/gamer/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory

For MIDI problem, there was this issue and potential workaround posted:
https://github.com/adventuregamestudio/ags/issues/367

Radiant

#644
Thanks, I'll add that. That leaves the 32bit / 64bit conflict... maybe my shellscript that detects this doesn't work properly on all versions of Linux?

(edit) wait, that workaround is for setting MIDI to device 2 in the specific case that device 0 doesn't exist but device 2 does; but we can't just assume that everybody's going to have Timidity installed, either. Is there an Allegro config line for omitting Midi entirely?

Crimson Wizard

#645
Quote from: Radiant on Wed 25/10/2017 11:00:28
(edit) wait, that workaround is for setting MIDI to device 2 in the specific case that device 0 doesn't exist but device 2 does; but we can't just assume that everybody's going to have Timidity installed, either. Is there an Allegro config line for omitting Midi entirely?

Did you try setting "midiid = 0" in the acsetup.cfg? That will make AGS initialize allegro with MIDI_NONE parameter. But I do not know exactly under which condition Allegro attempts to open that device.
Also, is this ALSA message a fatal error or just warning? Earlier I got an impression that it may be ignored if having MIDI sound is not necessary.

Radiant

#646
Quote from: Crimson Wizard on Wed 25/10/2017 11:13:42
Did you try setting "midiid = 0" in the acsetup.cfg?
Ah, that should work, thakns. I'm currently using midiid = -1, which I assume means "pick the default".

(edit) Wait again, per this bug report, if you use the ACSetup tool to set MIDI to off, then AGS will play no music at all. Was this fixed at some point? Your fix in that ticket suggests the opposite (it fixes MIDIs not playing when DIGIs are disabled, but my issue is DIGI music not playing when MIDI is disabled...)

QuoteAlso, is this ALSA message a fatal error or just warning?
I think this is a warning and the other message (about 32bit vs 64bit) is the fatal error.

Crimson Wizard

#647
Quote from: Radiant on Wed 25/10/2017 13:16:03
(edit) Wait again, per this bug report, if you use the ACSetup tool to set MIDI to off, then AGS will play no music at all. Was this fixed at some point? Your fix in that ticket suggests the opposite (it fixes MIDIs not playing when DIGIs are disabled, but my issue is DIGI music not playing when MIDI is disabled...)

There were two contrary issues, supposedly fixed in two sequential patches, according to changelog:

- Fixed MIDI music refuses to start if digital sound is disabled. (in AGS 3.3.4, July 2015)
- Fixed legacy audio functions did not start digital music playback if MIDI driver failed to initialize. (in AGS 3.3.5, March 2016)

Is it still not working?

Also, in regards to general issue with MIDI, I will repost my answer from another thread, since its more relevant here -
Quote from: Crimson Wizard on Wed 25/10/2017 13:43:01
Quote from: Radiant on Wed 25/10/2017 10:59:21
Quote from: Crimson Wizard on Tue 24/10/2017 21:29:22
I've mentioned this before, that it is not AGS that insists on initializing MIDI anymore. There is one Allegro API function that initializes all sounds, and all AGS can do is to try it with different parameters (MIDI/DIGI, no MIDI/DIGI MIDI/ no DIGI, etc) until it returns positive answer.
That's a good point, but it may be that the first function call (for MIDI+DIGI both, if I understand correctly) is causing problems in Allegro.

Yes, it could be; I think this may be tested out by disabling MIDI in setup file ("midiid = 0"), then sound init will be called with DIGI/ no MIDI at the first try. If that works, unlike other attempts, then adding a MIDI-disabling switch will have an actual meaning.

Radiant

I'm curious what the default folder is for running a Linux game? What my game does is check for .TRA files in the game's folder to show an in-game language selection window. This works fine in Windows, but in Linux it appears to be unable to find any of these files?


(the MIDI issue was not on my system, I'm still waiting to hear back from that particular player)

morganw

Were you using the tag that expands to get the actual game directory?

Quote from: the manual
When specifying file path you may use special location tags:
$INSTALLDIR$, which allows you to explicitly read files in the game installation directory.

Radiant

A player reports AGS running excessively slow when using any form of scaling.

"I can run the game without issue if I set it to run windowed at the standard 320x200 size that the art was done in, but I get a tonne of lag from the game when I set it to scale any amount. My CPU is at 15% when running at the unscaled size, and it is at 50% when scaled. I run a current Archlinux distro using the standard repositories. I run it with the Awesome window manager. Steam is the only other thing running when it happens.

CPU: Intel Centrino Duo: 2GHz
Memory: 4GB
Graphics: ATI Radeon HD 3470 with 256 MB onboard memory"

Any suggestions on how to help this player? Thanks!

Crimson Wizard

Quote from: Radiant on Thu 25/01/2018 21:31:59
Any suggestions on how to help this player?

Help implementing OpenGL renderer for Linux... :(

(or porting to SDL2/Allegro5)

morganw

I found that fullscreen slowdown seems dependent on the graphics driver, as I lost all fullscreen slowdown when switching from on-board AMD graphics to an old AMD card. Is it still slow if scaled and using fullscreen mode, rather than a window? Otherwise the only solution I found was to change to a lower desktop resolution to remove the need for scaling.

I did go through the engine code to check where the slowdown is, and it did just seem to be the actual drawing to the display that caused the majority of the CPU load. I did change one thing which may drop CPU usage slightly (about 5 - 10% for me) so running on a recent engine build might give a slight improvement. You might suggest they try building the engine, as I would imagine someone using Arch would be okay with doing that.

Crimson Wizard

Quote from: Crimson Wizard on Thu 25/01/2018 21:33:30
Help implementing OpenGL renderer for Linux... :(

Just to elaborate, assuming that OpenGL calls are more or less the same, or Linux function names could be translated using defines (same as we do for Android and iOS), making OpenGL renderer work on Linux might be a matter of:
* finding which headers to include and libraries to link;
* updating Linux-specific system code to make it switch to fullscreen with OpenGL properly (but even that is optional, since you can run always in window).

So, maybe finding a Linux coder who just knows how to link OpenGL to program may be sufficient.


Crimson Wizard

Quote from: morganw on Fri 26/01/2018 19:57:57
Do you think the built in Allegro 4 OpenGL wrapper would be usable?
https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL)

I wish we knew and used that years ago; I am afraid it will be more complicated to integrate that now.

null.painter

TLDR; New user here - curious about the state of the port, and suggested methods for users who run into scaling slowdown issues. Solutions using emulation (wine, dosbox, whatever) are fine with me - I'm a fairly capable user.

Hi, I'm new here - so sorry to post if I've gotten the wrong forum or necro'ed this post inappropriately.

I'm a Linux user/gamedev who is interested in the possibilities of AGS. I actually came here via reading about Heroine's quest and wanting to give it a try, only to find it struggling on my machine. After some research and experimentation, it seems that I am falling prey to the scaling issue - game runs well without scaling, is terribly slow with any amount of scaling. I've read up and it looks like the issue is/was due to poor support for Linux graphics drivers (OpenGL?) by Allegro?

I don't see any recent activity around this (and I saw mentions that there are not linux-focused maintainers on the team, hard legacy code, etc) and was wondering what the current state of affairs was around this issue? This seems like a really cool and active community, and like a good tool, so I thought I'd ask some questions before dropping the idea entirely.

Are there any current workarounds for linux users to run AGS games that work well? I'm fine with using WINE (or DosBox, or whatever), personally (I haven't given it a try to see if it is feasible yet, but am about to), but is there a native solution? Perhaps designing assets so that they don't need to be scaled? I partly just want to try such a highly-regarded game, but I am also curious about using the engine for my own projects, but am concerned about ease of distribution for linux users - it's becoming a mainstream enough OS that I don't expect all users to be powerusers, anymore...

At any rate, I'm happy to see such a lively community still pushing ahead with these type of games!

Crimson Wizard

#657
null.painter, hello.

I had plans to look into supporting OpenGL renderer on Linux in the past, after making it work on Windows, and it seemed like a matter of finding which header to include and libraries to link, and maybe fixing few issues, but I never really got to try.

There is a work by Nick Sonneveld who is currently writing SDL2 backend for Allegro4 (which lets running engine on SDL2 through Allegro interface, thus not requiring to rewrite big portions of the engine itself). Recently eri0o mentioned that he managed to build and run one on Linux, and it worked much faster.

I hope eri0o may comment on that himself, but unless I am mistaken, this port may be found here:
https://github.com/sonneveld/agscommunity/tree/sdl2-port
Should be compatible with the latest 3.4.1 version of AGS.

I believe that either variant will be sooner or later incorportated in the main version of the engine.

eri0o

#658
CW is too fast.

Everything he said is true, but there is a catch, the default engine should run well windowed, independent of scalling.

So comes the question: which Linux distribution and version of the Engine did you test?

null.painter

Thanks for the quick and friendly responses, folks!

I tried 3.4.0.13 (packaged with the Heroine's Quest linux distribution) and 3.4.0.16 (I grabbed it from some itch.io game that ran okay, but maybe wasn't scaling).

I also experimented with running the win distribution with Wine, which is running smoothly. I haven't played too much, but only noticed one artifact so far - the "language selection screen" at the beginning was mis-sized.

SMF spam blocked by CleanTalk