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.
Quoting: lucifertdarkWhy 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?
Maybe it uses the same engine? The provided list at least shows that they actually tried and tested. GameMaker Studio is not really an engine you can patch up yourself.
3 Likes, Who?
Quoting: GuestThis is not a language problem, it is a GCC problem. Microsoft's compilers manage it, and Apple's builds of clang manage it.Right, I should have written that C++ has no standard ABI, and while a lot of compilers (msvc and clang among them) keep their stable, others (like gcc) use the freedom to change it between versions for optimizations.
Maybe gaming distros should switch to stable-ABI compilers for C++? But they’d need to roll their own repositories then for everything instead of building on top of Debian.
And there are other compiled languages with no guarantees about ABI – there are games written in Rust appearing.
The easiest solution to the changing ABIs problem would be using dynamic libraries providing semantically versioned C API (eg. through open-source wrappers, or wrapping them in-house) and all others link statically to your binary (the problem then arises what to do, when the license does not allow you to link statically…).
Quoting: GuestFurthermore 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.
That does not sound bad – having binary say explicitly which version of the library it needs, and which version of the ABI it’s compatible with would make at least debugging more easily. But, you are right – it helps only the software that’s not provided in the official repositories, so the wider community might be reluctant to consider such a thing.
Last edited by silmeth on 1 September 2017 at 9:05 am UTC
0 Likes
lucifertdark Sep 1, 2017
Quoting: constPerhaps, but it's not like they're the only developer out there, there are others who have ported with that game engine to Linux & had success, they could ask for help if they really wanted to.Quoting: lucifertdarkWhy 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?
Maybe it uses the same engine? The provided list at least shows that they actually tried and tested. GameMaker Studio is not really an engine you can patch up yourself.
0 Likes
Quoting: GuestThis ^. Please don't act like a complete tool "debianxfce". The developer is clearly not lazy, or stupid. They're calmly and openly explaining problems, which gives us and other developers a chance to help. Leave those kind of idiotic comments on reddit.Quoting: GuestThis 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.Oh great, a regular Phoronix troll is here now, spreading his bile. I'm sure that you've never written a game that has to run on multiple platforms, or written much of anything, really. Well I have, and I can assure you that there are still issues in the Linux ecosystem. It's getting better all the time, but it's not perfect.
Calling the developer lazy, stupid, and writing shit is not the way to entice people to this platform. Liam posted as such a little while ago. Your kind is not welcome here; go back to trolling Phoronix, or more appropriately, get out of there too.
P.S. Nobody cares that you're using Debian and XFCE. And they are most certainly not the best that Linux has to offer.
6 Likes, Who?
Quoting: Sir_DiealotI couldn't even get it to work properly in Wine when I tried about two years ago.
Wine has improved a lot since two years ago :) For any GameMaker game you will need to run
winetricks d3dcompiler_43to avoid most crashes.
0 Likes
Sir_Diealot Sep 1, 2017
Quoting: JudasIscariotQuoting: Sir_DiealotI couldn't even get it to work properly in Wine when I tried about two years ago.
Wine has improved a lot since two years ago :) For any GameMaker game you will need to run
winetricks d3dcompiler_43
to avoid most crashes.
Oh, sorry, I was talking about GameMaker Studio itself, not any game made with it. No idea how it works today, the situation could have improved indeed.
0 Likes
Quoting: TheSHEEEPFirst 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.
Last year I bought an SSD. It was expensive and I got a 256GB one. On windows, I consistently see about 100GB~200GB of OS+programs storage while on Linux all my OS+programs (that is everything excluding /home) takes about 20GB. So yes, that _is_ an issue still. I'm not talking just about games.
Also, duplication of .so files has more implications than just disk space. Scenario: imagine some library X is used by 20 applications. On windows, those 20 applications each have a copy of the same version of the same .dll file:
- Security: If the library fixes some bug, 20 applications (on windows with 20 different updaters) have to update that dll. We all know (on windows) that not all of them will do it, and the buggy library will end up remaining on your pc.
- File System Cache: If the library was shared between the 20 applications, then loading one application after the other would be much faster given that the same .so files are either already in RAM or likely at least in the file system cache. Each application shipping a separate copy of its .so files mean slower application start.
- Memory: Unless the OS does a byte-to-byte comparison of the whole .so files, it cannot know that the applications are using the same .so file, which means running multiple of those applications results in the same .so files loaded multiple times in RAM, resulting in higher RAM usage, as well as worse CPU cache usage.
In short, duplicate .so files is still a terrible thing now and shows no indication of getting better.
Quoting: TheSHEEEPAlso, 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.
I'm not saying let's do this today. Just that if from the beginning things were thought of differently, we may have been in a better situation now. The solution to your "dependencies get old" argument is actually quite simple. Imagine if Debian instead of phasing out old packages on new releases, it would accumulate on top of it. Simple as that.
2 Likes, Who?
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?
Controllers for those games got added in a sort of database of controllers and their configurations. This is why you would see issues with specific controllers that weren't in the games so-called database of controllers.
0 Likes
Quoting: ShabbyXLast year I bought an SSD. It was expensive and I got a 256GB one. On windows, I consistently see about 100GB~200GB of OS+programs storage while on Linux all my OS+programs (that is everything excluding /home) takes about 20GB. So yes, that _is_ an issue still. I'm not talking just about games.Do you honestly think all those data is multiple versions of the same library?
That's utterly ridiculous.
I have about the same amount of SSD usage and regularly use WinDirStat to check what is taking that space.
By far the largest chunk is the user data directory, as every single program (unfortunately usually not configurable) stores its data there. And usually redundant data, too. Browsers, email clients, Windows installer caching nonsense, those are the evildoers.
I don't really have an explanation of why on Windows every programs just spams that folder (while on linux it doesn't?), but it has very little to do with duplicate libs.
You also forget that applications might share the same library, but certainly not the same version. So if 20 apps used the same library, it is pretty likely that they have been built against, let's say, 10 different versions. So even on linux, you will have 10 different library versions lying around. Not that much of a difference any more.
Again, storage is cheap. Except SSDs (for now). If you install all your programs on your SSD instead of just vital data (save games, coding profiles, etc. just usage data) - well, that is your fault.
I install everything on my non-SSD drive (given a choice), and it works just fine, since I'm not running a toaster and if you can afford a rather large SSD, chances are you aren't running one either.
Quoting: ShabbyX- Security: If the library fixes some bug, 20 applications (on windows with 20 different updaters) have to update that dll. We all know (on windows) that not all of them will do it, and the buggy library will end up remaining on your pc.Not wrong, but you are talking about bugs so important that applications HAVE to update. When does that actually ever happen? Once per year?
Usually, dependencies aren't updated simply because they don't need to be. Because most software doesn't actually deal with security issues.
Quoting: ShabbyX- File System Cache: If the library was shared between the 20 applications, then loading one application after the other would be much faster given that the same .so files are either already in RAM or likely at least in the file system cache. Each application shipping a separate copy of its .so files mean slower application start.Not wrong, but I think the last time I was actually bothered by an application starting up taking more than a few seconds must have been Win XP. Or one of my first smartphones.
I am a VERY impatient man, and if I'm not bothered, it really isn't bad. Another non-issue.
Quoting: ShabbyX- Memory: Unless the OS does a byte-to-byte comparison of the whole .so files, it cannot know that the applications are using the same .so file, which means running multiple of those applications results in the same .so files loaded multiple times in RAM, resulting in higher RAM usage, as well as worse CPU cache usage.I'm not really convinced the CPU cache argument is correct. Won't it actually be faster if each program runs its own version of a library as the data will be closer together? At least as a general rule, redundancy improves speed at the cost of space.
The RAM usage... my main PC has 12 GB. I have never seen that filled, and I do work some heavy applications regularly. My laptop even has 16GB. So, yeah... another non-issue.
Last edited by TheSHEEEP on 1 September 2017 at 9:54 pm UTC
0 Likes
I 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.
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.
0 Likes
Patreon
PayPal
See more from me