Support us on Patreon
PayPal
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!
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
I can confirm Feral uses the .sh trick as well, could verify it for example in TW : WARHAMMER.
1 Likes, Who?
Sir_Diealot 31 Aug 2017
Game Maker Studio is quite a bit of garbage. I couldn't even get it to work properly in Wine when I tried about two years ago.
I have seen touchpad as gamepad issues with some games, I think they were mono based. With those the issue was that the game only expected one gamepad and that was the touchpad, because it was registered first.
With that list of issues and the low probablility of getting them fixed I'd rather port it to some sensible engine. That would equal a rewrite, save for the assets.
I have seen touchpad as gamepad issues with some games, I think they were mono based. With those the issue was that the game only expected one gamepad and that was the touchpad, because it was registered first.
With that list of issues and the low probablility of getting them fixed I'd rather port it to some sensible engine. That would equal a rewrite, save for the assets.
3 Likes, Who?
We really need a massive adoption of appimage/flatpaks/snaps...
5 Likes, Who?
hardpenguin 31 Aug 2017
In short - hire a Linux specialist to make a port and oversee the QA! ;)
3 Likes, Who?
- 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.
0 Likes
About 1/3 of all steam games I have currently installed use a Shell start script.
0 Likes
Yeah, the worst part about linux is that app/lib version mess.
Honestly, it should just be like on Windows - look in the executable folder first, done. Would solve all problems, at least for closed source distributions.
Instead you gotta do some tricks like this script or my preferred method - changing rpath of the executable (and recursively the other dependencies).
Both is hacky, though.
But at least there are solutions to this, hacky or not.
The main problem here is Game Maker... really, I'm surprised anyone uses this for actual games and more than just fooling around. There are so many better alternatives.
Last edited by TheSHEEEP on 31 Aug 2017 at 8:14 pm UTC
Honestly, it should just be like on Windows - look in the executable folder first, done. Would solve all problems, at least for closed source distributions.
Instead you gotta do some tricks like this script or my preferred method - changing rpath of the executable (and recursively the other dependencies).
Both is hacky, though.
But at least there are solutions to this, hacky or not.
The main problem here is Game Maker... really, I'm surprised anyone uses this for actual games and more than just fooling around. There are so many better alternatives.
Last edited by TheSHEEEP on 31 Aug 2017 at 8:14 pm UTC
0 Likes
loved their transparency, i hope at least one other developer that planing to use game maker studio change its mind with that news (very unlikely they're reading this, but who knows?)
"Perhaps one of our lovely porters like Icculus, Ethan Lee, Knockout Games or someone else could arrange a port."
the issue is, the thing that should be "arranged" is game maker in order to fix this, so he will need the source code of both.
that is a quite strange game, i dont see my self buying it, but their transparency makes me want to support then if the game runs on wine.
"Perhaps one of our lovely porters like Icculus, Ethan Lee, Knockout Games or someone else could arrange a port."
the issue is, the thing that should be "arranged" is game maker in order to fix this, so he will need the source code of both.
that is a quite strange game, i dont see my self buying it, but their transparency makes me want to support then if the game runs on wine.
1 Likes, Who?
- 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.
Yes, it's basically the equivalent of how they on Windows have to bundle all their external dependencies and install them in the same folder as the game (and thus users have millions of the same DLL:s on their hard drives).
If only writers of shared libraries would think more about backwards compatibility...
1 Likes, Who?
Sir_Diealot 31 Aug 2017
The main problem here is Game Maker... really, I'm surprised anyone uses this for actual games and more than just fooling around. There are so many better alternatives.
It's surprising, but even some relatively well known developers have done so. For example Vlambeer. But from what I've seen, game maker is horrible. Even simple things are incredibly difficult in the "click-click"-mode. However, they have integrated ruby or somesuch. But when you're programming you can just use any of the many free 2D game engines.
0 Likes
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.- 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.
3 Likes, Who?
If 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).
0 Likes
If 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.
1 Likes, Who?
Honestly, 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](https://en.wikipedia.org/wiki/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](https://nixos.org/patchelf.html). If you do
$ patchelf --set-rpath '$ORIGIN/lib' ./foobaryou 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 :P
Last edited by DrMcCoy on 31 Aug 2017 at 9:16 pm UTC
6 Likes, Who?
The issue with mice being detected as controllers may not be a Gamemaker issue: https://github.com/denilsonsa/udev-joystick-blacklist .
0 Likes
Liam, feature request: I'd like to block people directly from a post of their's.
0 Likes
Yeah, the worst part about linux is that app/lib version mess.
Honestly, it should just be like on Windows - look in the executable folder first, done. Would solve all problems, at least for closed source distributions.
Having . in [LD_LIBRARY_]PATH is a terrible idea. Easiest way to spread viruses.
That aside, the real problem is in fact that they try to force a windowsish distribution on an operating system that has a proper package manager. The libraries on linux actually have pretty decent abi versioning, which means multiple libraries can co-exist and each application would choose the highest compatible version. Dependency-hell may be an issue for packagers, but the end results are damn nice for users.
Imagine for a moment if Linux games were also packaged like the rest of the system... No more 100 duplicates of .so files like on windows!
Last edited by ShabbyX on 1 Sep 2017 at 5:29 pm UTC
1 Likes, Who?
[quote=ShabbyX]
First of all, those duplicates were an issue many years ago when disk space was a problem. It simply isn't any more. This is a non-issue. Games nowadays can take any amount of space from 100MB to 60+GB. A few MB more in dependencies simply will not matter.
Also, yes that package managing stuff is nice. But only in theory, where it actually works.
In practice, games (and other software) are not constantly developed and updated with latest versions of libraries. And they shouldn't! Don't change a running system.
So at some point, version X of a dependency WILL rotate out. And then users have to find custom solutions, which is annoying as hell and will cause more people to switch to Windows for the product than it will cause them to fiddle around with their system. Fiddling around is nice for us proggers, but not for average users. This has happened SO MANY TIMES with open source libs that actually are maintained by someone - and so many times more by closed source software.
So either package maintainers have to carry ancient versions of their libs around (possibly even fixing critical bugs in them still if they appear) - and with that outlook, who still wants to maintain packages "properly"? Nobody.
Or developers are forced for a life long update-my-dependencies-game, including possible API changes and whatnot. Hooray.
No, I'm sorry. This package managing stuff may have noble goals, but in practice it is a terrible crux for developers that are actually paid for their work. And it throws more than just a few stones in the way of spreading linux.
That aside, the real problem is in fact that they try to force a windowsish distribution on an operating system that has a proper package manager. The libraries on linux actually have pretty decent abi versioning, which means multiple libraries can co-exist and each application would choose to higjest compatible version. Dependency-hell may be an issue for packagers, but the end results are damn nice for users.
Imagine for a moment if Linux games were also packaged like the rest of the system... No more 100 duplicates of .so files like on windows!
First of all, those duplicates were an issue many years ago when disk space was a problem. It simply isn't any more. This is a non-issue. Games nowadays can take any amount of space from 100MB to 60+GB. A few MB more in dependencies simply will not matter.
Also, yes that package managing stuff is nice. But only in theory, where it actually works.
In practice, games (and other software) are not constantly developed and updated with latest versions of libraries. And they shouldn't! Don't change a running system.
So at some point, version X of a dependency WILL rotate out. And then users have to find custom solutions, which is annoying as hell and will cause more people to switch to Windows for the product than it will cause them to fiddle around with their system. Fiddling around is nice for us proggers, but not for average users. This has happened SO MANY TIMES with open source libs that actually are maintained by someone - and so many times more by closed source software.
So either package maintainers have to carry ancient versions of their libs around (possibly even fixing critical bugs in them still if they appear) - and with that outlook, who still wants to maintain packages "properly"? Nobody.
Or developers are forced for a life long update-my-dependencies-game, including possible API changes and whatnot. Hooray.
No, I'm sorry. This package managing stuff may have noble goals, but in practice it is a terrible crux for developers that are actually paid for their work. And it throws more than just a few stones in the way of spreading linux.
2 Likes, Who?
lucifertdark 1 Sep 2017
Why am I not surprised? It's not like they promised a Linux port of the original Nidhogg & failed to deliver on that either is it?
0 Likes
My kid and many others have tens of native Linux games and they work without problems. Arguments of this developer are false, win,mac and linux are different platforms and requires different programming knowledge. This developer is just just lazy and stupid, sure the Linux gaming market is bigger than the mac gaming market. The developer should play Rocket League with Debian testing Xfce and not write shit.He did not say it's impossible to create proper games for linux. He says they have trouble bringing their specific game because it uses a specific engine. That engine claims to support linux, but has those mentioned bugs.
Maybe icculus could help GameMaker ^^
2 Likes, Who?
How to set, change and reset your SteamOS / Steam Deck desktop sudo password
How to set up Decky Loader on Steam Deck / SteamOS for easy plugins
See more from me