[low prio, for later] Dynamically linked allegro executable

[Blackence]

Hi!

So this is not really an idea, it's just a suggestion / wishful thinking for the way factorio is distributed on Linux. It tries to solve a problem that does not actually exist yet, so simply ignore it for some time.

As we all know, most libraries used on GNU/Linux systems have problems with ABI and API stability, so what you compile today for today's linux distros will most likely fail to work in a few years, which is why we need distributions to do all the rebuilds for us, and sometimes adapt to new APIs.

Factorio does a pretty good job avoiding this, because most dependencies are statically linked into the factorio executable. So there will be no issues when curl, libpng, libjpeg, that delta thingy or even allegro change their ABI/API because the code is copied into the factorio executable. It's guaranteed to still work until Linux drops support for the current binary format, which will hopefully never happen.

I'm worried about the external libX* dependencies though:

• [libX11.so.6]
• [libXcursor.so.1]
• [libXinerama.so.1]
• [libXrandr.so.2]

It's likely that X11 will be deprecated soon(-ish) on most Linux distros. There will probably be a compatibility layer for quite a long time, so hopefully it's still possible to play factorio after everyone switched to Wayland or Mir.

However, if that is not a difficult thing for you to do, how about linking to allegro dynamically and shipping the tested & definitely working allegro .so file with the factorio tarball? You can use RPATH so the shipped library is used instead of the system allegro library (if a system allegro library exists). Of course, that's only useful if factorio itself does not require libX*. If everything that needs X is abstracted away into liballegro, then it should be possible for any future factorio player to replace the allegro lib that uses X11 with a patched/newer allegro that supports wayland if some future contributor decides to spend his time on adding wayland support to allegro.

If this is more work than just a few changes to your build and packaging systems, then don't do it.

Also, I'm not 100% sure if this a good idea. Maybe others have some comments on this. I'd guess that getting rid of a direct dependency on a few soon-to-be-deprecated libraries at the cost of introducing a new dependency on a library having a smaller public API is a nice trade-off. I don't know how stable allegro's ABI is, if it's very unstable this might not be a good idea after all. (We'd need a Wayland-patched version of exactly the same allegro version the factorio devs used for their last build.)

I've also seen some work on allegro to use SDL2 as a backend instead of X11, and SDL2 supports X11, Wayland and Mir already, so that is another option. SDL2 appears to become the standard API for setting up OpenGL contexts etc. for most steam Linux games, because it is supported by Valve. I don't think allegro plans to mainline their SDL2 support though.

[MF-]

I'm not sure what's the threat here.


When DOS vanished, smart coders found the way how to run their favourite games.
If X11 ever follows it, someone will find a way too. (Hey, virtualization is quite widespread right now..)

Are those libraries even included directly? or just via GTK/QT?

PS:
I think I read, that factorio's copy of allegro contains some factorio-specific hacks, separating it thus doesn't make much sense.

[kovarex]

Yes, the problem really is, that we have made some custom changes to allegro.

[Blackence]

Alright, never mind then.

MF-, yes, there are already plans and code for XWayland. As far as I know, there is a separate X.org process for each running legacy application, and instead of rendering the window content to the screen, XWayland acts as a Wayland client and forwards the window content to a Wayland compositor. It's like an X->Wayland translation proxy. So I'm not afraid of no longer being able to play factorio using Fedora 2x or Ubuntu 1y.04.

I was just hoping to get rid of X eventually. A native game "feels" nicer than a dosbox / wine / emulated / XWayland-supported game. However, since the factorio guys have made custom allegro changes, I agree it's not a very good idea to dynamically link against it (unless those changes are made public). It probably has some performance impact as well. So forget about this idea.

Who knows, it seems like "only" 92 X*() API calls are required by factorio. Some of them like "XcursorImageCreate" are probably from unused allegro code, at least I haven't noticed factorio messing with my cursor. Maybe a very thin wrapper that translates from some basic X API calls to Wayland calls is feasible to run factorio almost native without a fat X server implementation inbetween. If Wayland ever becomes the default I might give that a try.

[Programmdude]

Personally I want a dynamic allegro library for a different reason, the last time I played on linux I had sound issues due to ubuntu and pulseaudio. If the allegro library was dynamically linked in, I could have fixed it a lot easier just by replacing the factorio allegro library with one that had pulseaudio compiled in. Instead I had to hack around with things and get an oss wrapper working, which was a lot more annoying.

Sure, I doubt that a lot of these issues will come up while factorio is being developed, but what about in 5 years? 10 years? Just because it might be possible to virtualize a lot of things, and have lots of workarounds, doesn't mean the developers shouldn't help and make things easier for us when they are working on their next big project.