Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by MayeulC
Some things developers might want to think about when bringing a game to Linux
16 Jul 2017 at 4:30 pm UTC Likes: 1

Quoting: gqmeloMost libraries will break with major updates, so you should bundle almost all your dependencies. But there are some libraries that should not be bundled, you should just use what the system provide instead. This page was not updated for a long time but it's still relevant: https://freegamedev.net/wiki/Portable_binaries#System_libraries_that_cannot_be_bundled [External Link]

I worked on a company that developed OpenGL applications and using this approach we were able to build on CentOS 5 and run on Ubuntu 16.10, for example. That's 9 years of backward compatibility.
"Bundling" can be interpreted differently form statically linking, though. I usually agree with "bundling"/providing the shared libraries along with the executable (and maybe a LD_LIBRARY_PATH "hack" in a launcher script), but not with static linking.

The only "valid" reason I can think of for statically linking executables is to distribute your program as only one binary. But even then, there are better options (sfxs, flatpack-like files with an embedded filesystem image or archive), and it only concerns a very nice portion of all applications (usually, portable ones).
Link time optimization and other optimizations are another reason it could be useful, but that's not true in practice (and ld can perform lto on shared objects as well, IIRC).

But yes, carefully pick the libs you bundle. To me, the general rules are:
  • Libs everyone have (double check everyone *is* everyone). Don't bundle them, dynamically link.

  • Libraries provided by a third party as part of a special contract with your studio/company: provide them as .so

  • Internal libraries developed by your studio/company: statically link them, perform a monolithic compilation with them or provide them as .so depending on your needs or update/modding/debug policy

  • Relatively common libraries that are well maintained: provide them with a .so, but prefer the ones on the system (query ld folders, add them to LD_LIBRARY_PATH, then add the folders they are in to LD_LIBRARY_PATH, essentially what Steam is doing)

  • "wild" libraries that are not very well maintained, or can break the API (early development version, for instance): avoid them, you will probably run into problems a few years down. If you must use them, provide them, don't statically link them but prefer them to the host libraries. That way, you make it possible to tinker with them if it stops working, but they should work the same way regardless of the system.

  • Prefer open source libraries whenever possible (still avoid the previous case): generally well maintained, people can fix them easily if they are broken a few years down the line, or write wrappers for them in the worst case.

  • Whenever possible (and that's usually a more general software rule), avoid complex dependencies. Both for the libs you choose (they should depend on a minimum of other libraries) and for your application. Bonus points if you can enable/disable some dependencies via a config file (though you may have to manually load your libraries. It's not *that* complicated, and as a bonus, you can gracefully fallback and disable features)


Do you agree with those, or would you change/add something?

Shakedown: Hawaii from the Retro City Rampage developer is now only a possibility for Linux
13 Jul 2017 at 11:26 am UTC

Do not lose hope just yet. RCR had a NES port!
(I believe it started as a homebrew NES project, actually)

Looks like the DOSBox wrapped Linux version of STAR WARS: Dark Forces might make it to Steam
12 Jul 2017 at 10:35 am UTC

This would set a nice precedent. I hope we'll eventually get all star wars games :)

(OK, I'm dreaming a bit, but hey)

Golf for Workgroups is a very weird golf game that's now on Linux
10 Jul 2017 at 3:24 pm UTC Likes: 1

Looks quitte Nice, it's a shame it probably requires Linux 3.11, though...

Some things developers might want to think about when bringing a game to Linux
9 Jul 2017 at 10:48 pm UTC Likes: 2

Quoting: GuestGreat article Liam,

One of my worries for Linux is how should developers code their programs and place all their folders and files so that 5 years down the line with newer hardware, kernel and distro and any updates associated, it can still be guaranteed that our purchased software will still be forward/backwards compatible and run? I personally find it annoying when your system is running fine for 2 years or so and just works, then have to do an update to the latest distro to get game x to work just to find you have to hunt down and figure out how to install xyz library or package to get an old game or software running again.

I'd like to point out that the community is great generally and with a little googling and patience one generally finds answers to solve your problems, for myself I guess I should save all those sources of help and index them all in a text file of sorts.
I second this. Usually this can be achieved by NOT STATICALLY LINKING the libraries (which is one of the reasons to have them in the first place). The libraries get updated (especially if they are open source), and make the games run in their new environment. This is why LGPL/zlib2 (iirc) is such a great thing :)

Some things developers might want to think about when bringing a game to Linux
5 Jul 2017 at 3:16 pm UTC

Quoting: Mountain Man
Quoting: HoriLearning bash has the second advantage of being helpful on Mac also.
If only for the purposes of transferring large number of files from one location to another. I've found the OSX GUI often chokes on the process making the command line the only reliable method for getting it done.
Off-topic, but ironically, this is also true on Windows, especially for long path names on network locations (cygwin, cmd or powershell, it doesn't matter; but the windows shell won't do it sometimes, at least on 7).

Some things developers might want to think about when bringing a game to Linux
5 Jul 2017 at 10:35 am UTC Likes: 3

Quoting: Guest
Quoting: rkfg
Quoting: ShmerlWhile it's annoying, I found one relatively simple workaround. Run such games with:

HOME=$HOME/.local/share

Then all that clutter will move to more appropriate location.
Good find! Redefining HOME could be used for many things, it's a cheap "user isolation/virtualization" technology, like chroot but for data. You can add any number of "profiles" in terms of settings/accounts/data to any app, even if it doesn't directly support it.
Hello, could I please ask how to implement that code? Is it in bashrc? Thank you.
If you are using steam, right click on your game>Properties>Set launch Options>type HOME=$HOME/.local/share %command%
That's typically where you change the command line for steam games, and this sets the $HOME environment variable for this game, so that the game will consider the new folder as your home directory.

You could also set the same before launching steam: in theory (never tried it), it should make the well-behaved apps save in $XDG_DATA_HOME (if set), and all the others in the right path.
But I must say that I usually prefer reporting this directly to the developers. Some are quite open about it, and it has led to quick updates in a few cases. The issue with this is that applications are not aware that this is a hidden directory, and might try to access $HOME/Music, or $HOME/Pictures/Screenshots, or whatever. There are sometimes a few legitimate uses for accessing the user directory (though the ones I provided were bad examples, they should use $XDG_MUSIC_DIR :)

To continue the rant on home folder cluttering:
Spoiler, click me

This is a real problem: a quick look at my home directory gives me (might not be 100% accurate, some apps might have moved since. I include both games and apps, to insist on the fact that this is a generalized pproblem, I don't think the data here is too sensitive. Game-related directories are marked with stars)
.adobe            ********
.alsoftrc
.android
.AndroidStudio1.3
.AndroidStudio1.4
.AndroidStudio2.2
.Anomaly 2        ********
.Anomaly Korea    ********
.anthy
.appdata
.arduino
.arduino15
.aspell.en.prepl
.aspell.en.pws
.audacity-data
.bash_history
.bashrc
.bitsquid         ********
.blender
.bout             ********
.bzr.log
.cache
.ccache
.codeblocks
.config          (I am OK with this one)
.cpan
.cups
.darwinia         ********
.dbus
.designer
.dillo
.directory
.dmrc
.dosbox
.electricsheep
.emacs.d
.esd_auth
.face
.face.icon
.filebot
.fltk
.fluxbox
.fontconfig
.fonts
.fonts.conf
.FoulPlay         ********
.frictionalgames  ********
.frozenbyte       ********
.ganttproject
.ganttproject.d
.gconf
.gconfd
.gdb_history
.gdbinit
.gftp
.gimp-2.8
.gitconfig
.gksu.lock
.gnome
.gnupg
.gnutls
.gphoto
.gradle
.gstreamer-0.10
.gtk-bookmarks
.gtkrc-2.0
.gtkrc-2.0-kde4
.gvfs
.hfconsolerc
.hfpdrc
.histfile
.hplip
.ICEauthority
.icons
.install4j
.installjammerinfo
.ipython
.java
.jfduke3d         ********
.john
.jssc
.JxBrowser
.kde4
.kde-old
.kde-services
.killingfloor     ********
.klei             ********
.kodi
.lesshst
.lgp
.links
.local            (I am OK with this one)
.loki             ********
.LUFTRAUSERS      ********
.lyx
.m2
.macromedia       ********
.mandelbulber
.mandelbulber_log.txt
.mbwarband
.minecraft        ********
.minetest         ********
.mono
.mozc
.mozilla
.mplayer
.MyWM
.nanorc
.netwatch.1.3.0
.netwatch.1.3.1
.node_repl_history
.npm
.octave_hist
.octave_packages
.openalrc
.openvr           ********
.ophcrackrc
.oracle_jre_usage
.Osmos            ********
.p7zip
.paradoxinteractive ******
.phoronix-test-suite
.pki
.platformio
.processing
.pulse
.pulse-cookie
.python_history
.qt
.QtWebEngineProcess
.quicksynergy
.recently-used
.renpy
.repoconfig
.repopickle_.gitconfig
.revenge_of_the_titans      ********
.revenge_of_the_titans_1.80 ********
.rnd
.Scilab
.screenrc
.secrets-of-raetikon *******
.serverauth.11609
.serverauth.1349
.serverauth.2431
.sidhe
.Skype
.smb
.solar2             ********
.Spyder
.spyder2
.spyder2-py3
.sqlite_history
.ssh
.starruler2         ********
.steam              ******** /!\
.steampath          ******** /!\
.steampid           ******** /!\
.subversion
.SupergiantGames    ********
.swt
.synergy
.teeworlds          ********
.texlive
.thumbnails
.thunderbird
.tilp
.traktor            ********
.ts3client
.uim.d
.ut2004             ********
.vim
.viminfo
.vimrc
.vnc
.vvvvvv             ********
.weblaf
.wget-hsts
.wine
.wireshark
.WorldOfGoo         ********
.wxHexEditor
.Xauthority
.xchat2
.Xilinx
.xine
.xinitrc
.xinitrc-backup
.xinstall
.xmms
.xscreensaver
.xscreensaver-getimage.cache
.xsession
.xsession-backup
.xsession-errors
.xwmconfig
.zcompdump
.zenmap
.zshrc
.zshrc.zni

Uber Entertainment deserves a special mention for getting it, but not quite right, and creating the ".local/Uber Entertainment/" folder on my computer :whistle:
On the other hand, wine games tend to clutter my home folder with non-hidden directories, which is worse. But to reiterate, I am against cluttering the home directory, even with dotfiles (that goes even for old-timers such as .vimrc, .bashrc, .ssh...).
Granted, I will need to wipe everything and start with a fresh home/system at some point.

Tip: something I sometimes do when I want to debug a title:
ORIGINAL_COMMAND=%command% konsole
(where konsole is your usual terminal emulator). What's nice here is that you will have a terminal with all environment variables (LD_LIBRARY_PATH, LD_PRELOAD, PWD) already set up, and launching the game is just $ORIGINAL_COMMAND away.

In most cases, games launch a script which then performs 36/64 bits detection, and sometimes distribution/DE specific tweaks. Feral's is quite interesting :)

I also have another old computer, that has a slow, 32bit only atom CPU, on which I like to play games every now and then, but these are obviously light ones (even super hexagon can be laggy at times), and I wouldn't mind not getting the latest releases, even the simple 2D games.

GamingOnLinux is turning 8 years old soon, here’s what we have planned and some thoughts on 2017
2 Jul 2017 at 11:53 am UTC

Added, added and added :)

I'm not 100% sure I'll be able to join, but it would be fun to play some Rocket league & Borderlands 2. (Maybe even a bit of PAYDAY? :P). I haven't played much lately (except the other day when I forgot to close TIS-100 in the background ^_^ )

Happy birthday :D

Edit: Why did my ^_^") got turned into ^_^") ? This is weird...

Quick tip: Adjusting video clip audio levels in Kdenlive
29 Jun 2017 at 4:01 pm UTC

I think this belongs to LOL as well... Is there an easy way for you to cross post articles? (Shared comments sections would be great :))

Oh, and also, I didn't see an announcement, but thank you for hiding the avatar and user info on mobiles in portrait mode :)

Scanner Sombre from Introversion Software adds experimental Linux support
27 Jun 2017 at 4:24 pm UTC

Lidar is the new wireframe! :P

Not that interested into that game myself, but I see the potential with VR headsets :)