Finally, after beginning soon after the game’s Windows release on Steam, and well over a month after I initially wrote my first post about this topic, I’m finally done with porting Gemstone Keeper to Linux (for the most part) and ready to write about what I’ve learned from porting it over. Since both the Framework and Level Generator have been ported, getting the whole game to compile and run wasn’t as confusing as the last two, but that didn’t stop it being tedious.
Part of these changes, is due to changes I made to the Vigilante Framework since my post about it. Since I made some changes to improve some features of the framework, turns out that didn’t mean Linux wouldn’t immediately accept them. Specifically the use of smart pointers.
The easiest way to set up a smart pointer (specifically unique pointers), would be doing this:
material = std::make_unique<V3DMaterial>();
However, GCC compiling with C++11 doesn’t like this, but will accept this:
material = std::unique_ptr<V3DMaterial>(new V3DMaterial());
Like I said, tedious.
After handling all the const/non-const conversions and adding additional includes, I got it to compile. Now time to make the main change.
The Intro Screen
So for those who haven’t played the game yet (and honestly, why haven’t you? :P), the intro has a command prompt appearance, and is made to be a fun way to set up the visual style and provide a bit of humour at the same time. For Windows, it made sense to emulate the white text on black Windows command prompt, but for Linux there need to be some change. There was a problem:
I asked around for what would be the ideal Linux terminal to emulate, most recommending xterm, and after a few tweaks, this is what I came up with.
Test Runs and Feedback
Now it was a good time to get Linux players to test a demo of the game. Since I created and tested the port on a Virtual Machine of Linux Mint, it was important to see how the game would run on not only different versions of the OS, but also proper installs on dedicated hardware.
I did my test runs on the SFML forum, Twitter and Reddit (both /r/gamedev and /r/linux_gaming), asking for Linux Gamers to try out the game and let me know if any issues arose.
Amazingly, there was only one instance of a crash, a bad_cast error thrown because of how I was converting a string to start with an uppercase letter (awfully specific I know). Aside from that, no platform specific or game breaking bugs.
One problem that was addressed was file permissions and runtime libraries. See, Gemstone Keeper uses the Steam API, and since there is no statically linked library, this needs to be included with the application.
For some reason, having the library in the same location as the executable doesn’t deal with Linux finding it when running the executable. I was able to get it to work by creating an .sh script that included the root of the executable to Linux’s library path temporarily. The .sh script does need to have read and write execute permissions though, and packaging it into a tar.gz will preserve it. How this will work for Steam will be interesting…
Finally, there is gamepad support, one person was able to get Xbox Controllers to work, and from what I see in the Linux Gaming community, those are the second most popular controllers so that’s good. One person tried with a PS3 controller, and while it works, the button mapping was all wrong.
I could use another gamepad controller API from the one I’m using to get them to work with both Windows and Linux, but that would mean a lot of testing. I could also add in controller configuration, but that would be a lot of work for an update that wasn’t meant to take nearly two months to work on.
As such, for the meantime, Gemstone Keeper will be XInput only. Steam Controllers should also work fine assuming either mapping works the same as XInput controllers or the device is mapped to keyboard and mouse controls.
GAMEPOPPER 
“However, GCC compiling with C++11 doesn’t like this”
Well, yeah, because std::make_unique isn’t in C++11; it was added with C++14. So with gcc, you need to give it the flag –std=c++14 (or –std=gnu++14). Or use the newly released gcc 7.1, where gnu++14 is default for C++ code now. 🙂
“For some reason, having the library in the same location as the executable doesn’t deal with Linux finding it when running the executable”
Yeah, Linux doesn’t include the current directory in the path or ld library at all by default. That’s by design (because of the security implications). Yeah, that’s probably something you won’t expect when coming from a Windows background. You can set LD_LIBRARY_PATH by a script, which, I guess, you have already figured out.
Steam should be able to preserve the executable permission, since other games do this as well (a starting script is also useful to check for x64 vs x86, too). The game executable also needs the executable bit set, after all.
Your game isn’t really my thing (sorry), but should you have any further questions about developing for Linux, or the reason why something works as it does on Linux, feel free to email me :). I’m not really a game dev (well, I’ve reverse engineered and reimplemented some older games, if that counts), but I have over 15 years of Linux C/C++ dev experience.
If you use SDL2’s gamecontroller API then your game should inherit the Steam Big Picture gamepad configuration chosen by the user, and almost all gamepads should work magically.
I’m also convinced that using SDL2 for everything else is better than SFML and Allegro.
Hmm, I think WordPress ate my comment here when I did the log-in dance. Or, if you just didn’t approve my comment (yet or at all), feel free to delete this, and sorry in that case :).
“However, GCC compiling with C++11 doesn’t like this”
Yes, because std::make_unique() isn’t in C++11, but in C++14. You need to add the –std=c++14 (or –std=gnu++14 to also enable non-standard GNU extensions) flag to gcc. However, this needs gcc of at least version 4.9. Or, alternatively, use the recently released gcc 7.1, where gnu++14 is the default for C++ code.
“For some reason, having the library in the same location as the executable doesn’t deal with Linux finding it when running the executable”
Yeah, Linux doesn’t by default search the current path for executables or libraries. That’s by design, because of security implications. You can instead use a shell script to set LD_LIBRARY_PATH, but it seems you already found out about this. A small script to start the game is pretty common, too, because it’s also useful to, for example, distinguish between x86 (aka i386, i586 or i686, i.e. 32-bit) and x64 (aka x86_64 or amd64, i.e. 64-bit).
Steam should preserve the executable bit for the shell script, because lots of games on Steam do this. And anyway, the actual game binary needs the executable bit set as well.
In either case, good job and congratz in getting your game ported! 🙂
While your game isn’t my cup of tea, please feel free to email me if you have any questions regarding Linux development or why something works like it does on Linux or stuff like that. I’m not exactly a game dev (I’m more into reverse engineering and reimplementing older games, if that counts), but I do have over 15 years of C/C++ Linux dev experience. I’m always happy to help if I’m able to and my help is wanted.
I did approve your earlier comment, but for some reason it’s not showing up.
EDIT: Ah apparently it was in the spam folder. Strange.
But thanks for the explanations, does help understanding these things. At the moment I’m using GCC 6.2 since that’s the highest I’m able to get on Linux Mint, and even then I had to look for a tutorial on what list of commands I have to do to get it.
Pingback: New Years Resolutions | GAMEPOPPER