You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can support us on Paypal and Liberapay!

Nidhogg 2 [Steam, Official Site], the sequel to the indie hit of 2014 may not come to Linux and the developer has listed reasons why. Hopefully people can help get this going.

It's not the usual type of thing we hear, in fact the developer actually gave out some interesting details.

Here's what they said:

As for the actual Linux build, basically, things are so far not very good with Linux runtime in software used (GameMaker: Studio),
- Gamepads may or may not work because there's a limited (embedded) database for them instead of having an editable config file like SDL does.
- Mice can be detected as gamepads (I think because some distros register a generic device + mouse# device for them?).
- Depending on undetermined factors (library combinations?), audio may cease to play.
- Depending on desktop environment, different interesting things happen with graphics - ranging from garbage data outside the game area (i.e. on empty "letterbox" areas) to actual texture corruption or literally having half of game screen missing for no good reason.
- Depending on more factors (GPU drivers?), other interesting things happen with graphics - e.g. delays can be required when changing between window and fullscreen or display buffer ceases to change size or becomes garbled.
- Unless running via a .sh (LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATH DISPLAY=:0 stdbuf -i0 -o0 -e0 ./MainBinary), native extensions (.so) cease to load correctly.
- Compiled Steam builds are broken by default and will not hook up with Steam API unless moving files around and adding a steam_appid.txt (which is not supposed to be shipped with release builds).
- Related or not related to above two, sometimes Steam and/or Steam P2P native extensions cease to load for some users.
- When working with Steam Workshop, some users have GMS games unable to access downloaded items (permission issues?).
Overall it's a pretty tough decision to start making Linux builds if you know that they won't work for many people and you won't be able to do anything about that yourself (aside of waiting).

Hopefully things improve on this front by the time when current tasks on the game are finished.

That's quite a list of issues, although the one about running it via an .sh file isn't what I would say is an actual issue. Lots of Linux games use this method, including most Linux games available from GOG. I'm pretty sure all Feral games use that method too.

The other reasons are all likely quite valid and depend on GameMaker.

A shame, but I really hope they manage to pull it off. It certainly looks like a game I would enjoy, especially as it looks completely nuts.

Perhaps one of our lovely porters like Icculus, Ethan Lee, Knockout Games or someone else could arrange a port.

Thanks for letting me know, Luke!

7 Likes, Who?
Comments
Page: «2/5»
  Go to:

Wildy 31 August 2017 at 8:36 pm UTC
kf
Quote- Unless running via a .sh (LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATH DISPLAY=:0 stdbuf -i0 -o0 -e0 ./MainBinary), native extensions (.so) cease to load correctly.
Isn't this standard when you ship games that require specific versions of libraries? I've even seen many steam games do this even with the steam runtime avaliable.
LD_LIBRARY_PATH tells the runtime linker to prepend the given locations to the paths where shared objects (.so files) are looked up from by the runtime linker. It is widely used but it shouldn't be when one has control of the binary. There is RPATH for achieving the same and it could get added to the ELF executable during linking. As this header could contain relative locations like $ORIGIN/lib it should be easy to ship a binary with its own set of libraries included.
silmeth 31 August 2017 at 8:52 pm UTC
F.UltraIf only writers of shared libraries would think more about backwards compatibility...

It would suffice if they followed semantic versioning with regard to their libraries’ APIs – one would know which shared versions are compatible. Some libs would have a few hundred new major versions every year – but at least it’d be obvious that every game needs its own separate copy of it in its own version.

At least until we dive into compiled C++ libraries where the version of the compiler that compiled the library and a game binary matters, as C++ has no stable ABI (so library compiled with newer gcc might, and probably will, stop working with old executable).
F.Ultra 31 August 2017 at 9:15 pm UTC
silmeth
F.UltraIf only writers of shared libraries would think more about backwards compatibility...

It would suffice if they followed semantic versioning with regard to their libraries’ APIs – one would know which shared versions are compatible. Some libs would have a few hundred new major versions every year – but at least it’d be obvious that every game needs its own separate copy of it in its own version.

At least until we dive into compiled C++ libraries where the version of the compiler that compiled the library and a game binary matters, as C++ has no stable ABI (so library compiled with newer gcc might, and probably will, stop working with old executable).

Following the semantic versioning would most definitely help yes, but I see many libraries that make completely unneeded changes to both API and ABI.

Once in a while I think that whenever a library writer creates a version that is no longer ABI compatible then they should be required to write a shim library for the previous version that uses the new version, that way security fixes and so on would still be applied to the users of the old version and distributions could install all the hundreds of shims when you install a library (since all the old versions are just small shims they should be very small in size so the overhead should not be that great) or perhaps as a libxxx-shim package just like we have -dev/-devel packages on most distributions.
DrMcCoy 31 August 2017 at 9:15 pm UTC
TheSHEEEPHonestly, it should just be like on Windows - look in the executable folder first, done.

You can literally already do that in Linux. It's just not enabled by default (because that would be a huge security nightmare.

What you can do is set the RPATH field in the ELF binary, i.e. the game dev needs to do that on their game binary before release.

You can do that while compiling, or afterwards with patchelf. If you do

$ patchelf --set-rpath '$ORIGIN/lib' ./foobar

you modify the binary foobar to automatically search for the lib folder in its own path for libraries.

EDIT: And I was ninja'd again, great


Last edited by DrMcCoy at 31 August 2017 at 9:16 pm UTC
mcphail 31 August 2017 at 9:48 pm UTC
  • Supporter
The issue with mice being detected as controllers may not be a Gamemaker issue: https://github.com/denilsonsa/udev-joystick-blacklist .
jaycee 31 August 2017 at 10:13 pm UTC
At VP I used both a launch script to actually check if the game failed to launch due to dependancy issues, but libraries were dealt with via an rpath. However if you are not an experienced Linux developer these things will catch you out, and they are issues that don't really exist on Windows or OS X (i'm not interested in disputes on this one).

The GameMaker specific bugs also hobble them... there is little to nothing they can do about those, and if they launch a Linux version anyway even with an advisory about the problems, they will get roasted for it.
jaycee 31 August 2017 at 10:26 pm UTC
silmeth
F.UltraIf only writers of shared libraries would think more about backwards compatibility...

It would suffice if they followed semantic versioning with regard to their libraries’ APIs – one would know which shared versions are compatible. Some libs would have a few hundred new major versions every year – but at least it’d be obvious that every game needs its own separate copy of it in its own version.

At least until we dive into compiled C++ libraries where the version of the compiler that compiled the library and a game binary matters, as C++ has no stable ABI (so library compiled with newer gcc might, and probably will, stop working with old executable).

This is not a language problem, it is a GCC problem. Microsoft's compilers manage it, and Apple's builds of clang manage it.

Furthermore it would help if the ELF format had a versioning system which helped. Mach-O format on OS X has a pair of version numbers expressly to deal with this, and it works pretty well. It'd be pretty simple to add it to ELF, but I suspect requests to do so would fall on deaf ears.
DrMcCoy 31 August 2017 at 10:32 pm UTC
Liam, feature request: I'd like to block people directly from a post of their's.
jaycee 31 August 2017 at 10:35 pm UTC
Problem ?
jaycee 31 August 2017 at 10:42 pm UTC
To clarify my last posts:

QuoteThe GameMaker specific bugs also hobble them... there is little to nothing they can do about those, and if they launch a Linux version anyway even with an advisory about the problems, they will get roasted for it.

There have been plenty of games made with Unity for example, which have been released with known issues on the Linux platform, and the developers of the game have taken all of the blame despite the bugs being higher level engine issues they are unable to do anything about.

QuoteThis is not a language problem, it is a GCC problem. Microsoft's compilers manage it, and Apple's builds of clang manage it.

This again is truth. There are no problems using C++ compiled libraries between versions of MSVC, and there are no problems using C++ compiled libraries between the various releases of Xcode. ABI stability of C++ is not a language issue.

QuoteFurthermore it would help if the ELF format had a versioning system which helped. Mach-O format on OS X has a pair of version numbers expressly to deal with this, and it works pretty well. It'd be pretty simple to add it to ELF, but I suspect requests to do so would fall on deaf ears.

Similar cases have been made before e.g. by Icculus with FatELF. His documented frustration about trying to get FatELF incorporated into Linux distro's, but being refused on the grounds of "it only helps closed source" are well known. I suspect sensible library binary versioning would fall foul of the same criticism.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon or Liberapay. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

We also accept Paypal donations and subscriptions! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Livestreams & Videos
Official Livestreams
  • Borderlands: The Pre-Sequel continued again
  • Date:
Community Livestreams
  • RPGoodness: "Dragon Age Origins" (via Wine)
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Forum Posts
Facebook