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.
Sir_Diealot Sep 2, 2017
Quoting: TheSHEEEPI might have worded that poorly.
I know WHY all the data is there, what I find generally unpleasant is how much of that is redundant data and just general developer carelessness. Take Atom, for example. That editors seems to store all its previous versions since original installation (and all of them are about 400MB).
After deleting all those folders, Atom worked just as well, so all of those folders were completely useless, just hogging up GBs of space.
You cannot blame the OS for that, it really is on the developers. That's what I meant.
Oh Atom. That actually is a great argument against static linking. It's for the most part not 'linking' in the strict sense, but it shows just what happens when programs ship their own dependencies. Stuff doesn't get updated.
https://twitter.com/jacobrossi/status/851992646151278592
But in the Atom case, I don't think it is a problem of static linking. I'm pretty sure the folders would be just as big if Atom was dynamically linked - which it maybe is, I don't know. Either way, the problem is developers being messy, not the linking type.
Quoting: fagnerlnWe really need a massive adoption of appimage/flatpaks/snaps...
Completely agreed but not sure which of the above issues that solves? Properly stable and updated application on all distros will be awesome though (AppImages aren't auto-updated by default so the argument applies to the other two better). I try to do some work on snapping applications and participating in snapcraft forum discussions but it's time-consuming and I really need to get on with university work... If anyone else would like to learn, to me it seems a tad easier than Flatpak (though they haven't got round to proper support for distros (tons of other features they're working on) doing different stores yet so it's not as distro-agnostic - also having one central store does seem to make it a bit easier for the end-user, developer, and snapcrafter) because (nearly) all the packaging is in one declarative `snapcraft.yaml` but I'm not much of a developer so I've only been able to help with bits and bobs rather than actually produce a working snap. The tutorial for snapping is here and you can use the Discourse forum to get help and to see what people are working on. Also fork this repo and use it to get a snap released.
Last edited by Ads20000 on 2 September 2017 at 1:41 pm UTC
Quoting: GuestThe problem with the "just ship all your dependencies" argument is how far do you take it ? A simple example, we need to ship libcurl. If we want https support, that typically depends on OpenSSL. Do we now have to ship OpenSSL ? What about the things OpenSSL depends on ?
Say we have a GTK3 UI somewhere. Do we ship the whole of GTK3 and all its dependencies ? That's pretty large. You're probably thinking "but everyone will have GTK3" - not so. Some people use setups which are exclusively Qt, or GTK2.
"Just statically link" is also a bad idea - that doesnt solve anything, and in fact it makes future compatibility WORSE because now you cannot replace the older versions of libraries at all. If there's a security issue in the old build, you're stuck with it. Not to mention if you are a complex game (like ARMA 3) then statically linking libs is a huge waste of VM space.
IMO, the Linux runtime linker (ld.so) needs support for two things:
1) Library versioning *at the load stage*, with embedded version numbers in the library files themselves. The method Mach-O uses of dual version numbers - library version and ABI compatibility version, should be adopted. It's easy to add to ELF.
2) Weak linking. This means that you can specify you want to link to a library IF it exists, but still run if it doesn't - you can check at run time if the library loaded or not. Currently this has to be implemented manually with dlopen/dlsym, and it's a lot of hassle.
#1 have existed on Linux since day one. This is where the semantic versioning of the shared library kicks in, unfortunately not everyone who writes shared libraries follows the rules for semantic versioning and simply put their actual version there.
Quoting: GuestQuoting: F.Ultra#1 have existed on Linux since day one. This is where the semantic versioning of the shared library kicks in, unfortunately not everyone who writes shared libraries follows the rules for semantic versioning and simply put their actual version there.
No it hasn't, not as I describe. Semantic versioning is basically naming symbols in a particular way, but then the programmer has to go to a lot of effort to explicitly bind to those symbols rather than the library's default ones.
Also .so has no version number embedded in it - this is only actually ever indicate by the file name, which is arbitrary and can be modified too easily to falsify or remove this information. It would be better if it was explicitly stated inside the ELF file.
Are you talking about linking with an older version of a lib than what you have installed? Because by default the linker (when compiling) will bind to the SONAME version of the library that you have installed.
The SONAME is also not only in the filename but also stored inside the ELF file:
f.ultra@ubuntu:~$ objdump -p /usr/lib/x86_64-linux-gnu/libmysqlclient.so | grep SONAME
SONAME libmysqlclient.so.18When you try to run an application linked with this on a machine which only have .so.17 or .so.19 then ldd will fail since your application needs the v18 ABI interface of this library. I don't really understand what it is that your extended version from Mach-O is supposed to do more than this anyway, it cannot make your application use v17 or v19 since it cannot know what it is that have changed in between those versions.
So I might misunderstand what you are saying, so please enlighten me!
Quoting: WildyQuoting: kfLD_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.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.
Quoting: DrMcCoyQuoting: 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 :P
I want to thank both Wildy and DrMcCoy for this info. I just recently started working on a small personal coding project (my first in over a decade and first ever on Linux) and was trying to figure out how to do exactly this when I took a break to come read on here as it's been a couple weeks, and lo serendipity.
Quoting: GuestThis is probably for the best. Hyper Light Drifter, Switchcars and Nuclear Throne are examples of GameMaker games that never got their controller support for linux working properly. Feels that most GameMaker-made games are of a type that is best played with a controller. But I wonder how Broforce and Hotline Miami got it working?I seem to remember reading that both of them had a wrapper written to let them compile their existing code against a different engine for Linux. That's hearsay and it was long enough ago that I can't cite a source, so grain of salt and all that.
Quoting: Sir_DiealotGame 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.They already have released Mac support for the latest version of the IDE, and Linux is likely something they will get to at some point.
Patreon
PayPal
See more from me