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
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:
Do you agree with those, or would you change/add something?
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]"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.
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.
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
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)
(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
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)
(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
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
9 Jul 2017 at 10:48 pm UTC Likes: 2
Quoting: GuestGreat article Liam,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 :)
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.
Some things developers might want to think about when bringing a game to Linux
5 Jul 2017 at 3:16 pm UTC
5 Jul 2017 at 3:16 pm UTC
Quoting: Mountain ManOff-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).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.
Some things developers might want to think about when bringing a game to Linux
5 Jul 2017 at 10:35 am UTC Likes: 3
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:
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)
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:
(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.
5 Jul 2017 at 10:35 am UTC Likes: 3
Quoting: GuestIf you are using steam, right click on your game>Properties>Set launch Options>typeQuoting: rkfgHello, could I please ask how to implement that code? Is it in bashrc? Thank you.Quoting: ShmerlWhile it's annoying, I found one relatively simple workaround. Run such games with: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.
HOME=$HOME/.local/share
Then all that clutter will move to more appropriate location.
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.zniUber 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
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
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
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 :)
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
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 :)
Not that interested into that game myself, but I see the potential with VR headsets :)
- Planetary Annihilation: TITANS gets revived as the devs ask for Linux help and feedback
- STALKER 2: Cost of Hope expansion announced for Summer 2026
- Hytale update 4 is another absolute whopper with over 500 new blocks
- Grounded 2 gets Steam Deck Verified with the latest updates
- Rebellion revealed first-person action horror Alien Deathstorm
- > See more over 30 days here
- Away all of next week
- Ehvis - What Multiplayer Shooters are yall playing?
- Liam Dawe - The Great Android lockdown of 2026.
- Strigi - Proton/Wine Games Locking Up
- Caldathras - What have you been playing recently?
- Strigi - See more posts
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck