Linux Gaming Experience – 3

Not everything in Linux ecosystem is pleasant. There are issues that plague the community driven development and maintenance of the various components in Linux ecosystem, and depending on the features being used, things that were working fine may suddenly give up, for no fault of the user. In the last 2 posts, I shared some excellent experiences I have had with Gaming on Linux. Let me also share the other side of the coin today.

3/n. Broken Proton releases ruin the Linux gaming experience

Steam’s Proton is the way to play Windows games on Linux. A decade ago, this was magic, but now not so much. Wine had been for a long time, extending compatibility to executables built for Windows (a completely different OS architecture) one application at a time. Back in the days when I was in college, being able to run just Winzip through Wine also seemed to be a heavenly achievement. Nowadays, Wine can run AAA games with ease (conditions apply).

Proton is a wrapper on Wine aimed at making the configs one-click for the user. It creates wine config per game, including synthetic Windows filesystem. It is a project by Valve, and have come leaps and bounds over the years. However, Proton is very moody; some versions work for some games but not for others.

Proton 3.16.x was a pretty stable version, followed by 4.11.x. However, 5.0.x seems to be breaking stuff that were working perfectly fine. There are known issues like “Proton does not like NTFS”, support for ESYNC (not sure why they cannot turn the damn thing off by default), fuzzy support for the Steam Overlay (a Valve product by the way), etc. However, it is not acceptable when Steam updates itself automatically, installs the latest Proton (even if it is a major release), then breaks a perfectly working game just because it can. You need to manually select the older Proton version (thankfully they don’t uninstall it) and it starts working again – which means the issue is not with my system but the latest release.

You might be thinking now – “Meh, big deal. You just need to select another option in a dropdown”. That is really not the point of this post. When the new version was updated, I did not see any message from Steam that some games may stop working, try this if so, etc. I have to spend time on the internet to search for the issue, then make the changes. I have better things to do as a consumer. It is not their business to waste my time.

I am not being ungrateful here. If it was a new, “early access” product, 0.x version, I get it. But this is the 5th “major” version, was perfectly working before, which they did not bother to test properly. Clearly, the quality of testing done before releasing a major version is poor. The last thing any software application wants is regression – i.e. breaking something that was working before. In any software company, new features are often not released if regression tests fail (i.e. if a regression is found on the new build).

Now, unlike many community driven projects, Proton has the backing of Valve, a not so small company. And Valve does want the gaming community to not be dependent on its Big Neighbor of Seattle. However, it fails to shine over the typical mindset of the community in general, when developing a Linux product or its next major release.

Somehow developers think that product/ user experience is immaterial to the user, and it is okay to release a broken product just because it is free (there is no warranty anyway). If you point to them these flaws, they snap at you that they are working for free, so you should just take the code yourself and fix it. As if the user is just sitting in his mother’s basement without any real work and with all the time in the world. When you complain, apart from being called names you will also be given the “advice” of paying for Windows and be done. It is beyond the comprehension of these p*****s that criticism is the first step of improvement. If you cannot accept criticism, how can you grow?

And why cannot I complain without personally contributing to the code base? I am a consumer. Wouldn’t it be my “choice” (holy grail of the community) whether I want to contribute or not? Tomorrow if I watch a movie, I cannot criticize the performance of an actor because I cannot act? Or cannot criticize a footballer because I don’t play football?

Yes the above two examples generate income, unlike our developers. But here is the thing. If I pay for an open source software product (remember open-source and free are orthogonal), are these developers mature enough to provide a warranty or own it up? No. They will need a business focused management over them to do so, like Red Hat. Because individually they don’t care.

No product would have survived so many broken releases like Linux ecosystem does. Any complain, criticism, will still not be looked upon, but instead shelved with a comment that “fix it yourself if you think it is broken”. This is really the ONLY reason we are yet so see the year of Linux Desktop.

Linux Gaming Experience – 2

Even with Steam making available more titles to game on Linux, certain things were still “Windows only”, like modding the game. Some video games are popular only because of the plethora of mods available, like the Elder Scrolls series or the Fallout series. It is really too much to ask the mod author to also support another platform, when he is already distributing mods for free, developing which he must have put numerous hours in, without any monetary expectations. Especially if mods require some “dll” files to be modified – which are Windows specific.

But if WINE or Proton can run an executable, why can’t they run those cooked dlls too? Of course they can, so lets see how it turned out!

2/n: Modding the Elder Scrolls 4: Oblivion on Linux

The Elder Scrolls 4: Oblivion (2006) for PC is available on Steam as a Delux edition containing all DLCs and official mods. It was a big hit on non-PC platforms like XBOX and Playstation as well, but unfortunately, controller support is not great for PC editions. It is a shame really, for games released also on consoles to not have native gamepad support on PC, when it is just a matter of providing multiple input controls config. There is no justification why the PC master race cannot have the best of both worlds. But more on that in another post maybe.

In order to use a XBOX controller on PC, we have to install a mod, which not just replaces some static files in the data directory, but also uses some cooked dlls, since it has to alter the input configuration at runtime. The Oblivion modding community uses OBSE for the purpose. OBSE has support for both Steam and Non-Steam versions, though I found that it required some additional steps to run via Proton in Linux.

After installing Steam Oblivion on Linux (and running it once, so that Proton creates the required Windows directories), we need to

1. Download the mod archive from Nexus

2. Download OBSE and install to game Data directory. Then follow these steps as it seems there is some issue with OBSE running via Proton.

3. Extract the mod to some location

Here is where things are a little different in Linux compared to Windows – Oblivion uses timestamp of the files in Data directory to determine whether to use loose files (assets) that exist there, in place of the packed assets (.bsa files) that were installed with the game. For loose files to be recognized, they must have a later timestamp than the installed files. Steam sets timestamp of the files as the one during installation, so any mod that has a past timestamp compared to this (i.e. virtually all mods) will not be picked up by the game during launch.

There are two ways to overcome this. First is to use archive invalidation. There are multiple ways to do so, among which this mod is simplest to use. It is basically a .bsa file that we register manually in Oblivion.ini, so that the game ignores this rule. It did not work just by itself in my case, so I had to do an additional thing – artificially alter the timestamps of all asset files of the mod before putting them in the Data directory.

4. Open a terminal in the mod extracted location and run

find . -exec touch {} \;

This will run the Linux “touch” command on all files inside the current directory recursively, which basically sets the modified timestamp to current. This would be later than the Steam installation timestamp, so our mod will now be recognized by the game.

5. Copy the contents of mod directory now, to game Data/

Another thing to note in Linux is that filenames are case sensitive. So “meshes” and “Meshes” are different! So if we install multiple mods, one way is to convert all asset filenames in lowercase, or another way is to keep track of what files are being replaced, and convert only the required ones but keep it consistent.

6. Apart from the above mod, I also used a texture pack for which I had to ensure this was the case.

7. For OBSE to work, we need Steam Overlay to be active. Although sometimes it breaks controller support, assuming our mod will take care of it, I enabled it.

8. Now I could launch Oblivion from Steam through OBSE – it will first be launched, and it will in turn launch the main executable. Once in the game, I could use controller as if it has native support, with button prompts changed as well. The mod also offers XBOX or Playstation theme for the buttons.

The only issue I faced was in the inventory menu, where controller did not give me a way to switch between main, quest, and magic inventories – I had to do that using the mouse! This looks like a mod issue, and would probably occur in Windows too.

Oblivion is an award-winning game, and being able to play with controller and using some high resolution textures in a 2006 game was really a great experience. Whatever concerns I had about modding the game on Linux, were completely taken care of. I played it on Linux as if I was playing on a console!

Linux Gaming Experience – 1

Gaming on Linux has evolved leaps and bounds. Compared to some 10 years ago, when we had to run games as Windows executables on WINE, Linux now has much better native support, and cross-platform compatibility thanks to Steam’s Proton.

But lets keep that discussion for another day. For now, let me share some unique experiences I have had while gaming on Linux in an n-part series. Most of these happened in the past, but never had a chance to put up here till now.

1/n. What happens to your Steam games if you re-install Linux

By re-installing Linux, I mean the whole shebang, not just “upgrading” to a newer version of the same distribution in place. I have had Linux Mint for a long time, and decided to try out Pop OS on the same partition after reading favorable reviews. So I formatted clean and installed Pop.

I had some Steam games installed on a secondary drive, one of them being Doom (2016). Since it was a mechanical drive, the game would take 5 mins to load into menu and another couple to load into a map, not to mention occasional micro-stuttering. I wanted to try it out on the home partition (SSD), but did not have space on it earlier so had installed on the mechanical drive. With the new Pop OS installation, I now had space in the home directory to do so.

But I did not want to re-download 70 GB for the experiment. So I copied the game directory and manifest from original location into the new steam installation. Booted up Steam, and it automatically found that Doom was playable (though it did download around 100 MB of shaders and the newer Proton 4.11). Clicked on Play, and it ran like a fresh installation! SSD made it much better than earlier, with absolutely no stutter, and frames locked at 60 fps. And with Steam cloud saves, you continue in the new installation right from where you left off in the previous!

Though performance boost was due to SSD, the main thing to note here is how easy it was to simply copy an existing game installation into fresh Linux partition and start playing. It would have worked even if the game was originally on the partition I wiped clean, just that I would have had to take a backup to external drive. This is not the same as adding back the secondary steam games location to the library since that location was not formatted (which also works flawlessly).

Credit is to Steam of course, since this situation would work in case of Windows also, but had to mention how Linux, Steam, Proton, Vulkan, all came together to offer an efficient and smooth experience to the consumer.

Gaming on Linux is not just easy, but so is taking backups and restoring them, without having to download scores of gigabytes thereby preventing unnecessary wastage of network.

Quick fstab reference

/etc/fstab

The /etc/fstab file is used to set permissions on disk drives when mounted at boot. Based on this, one is able to read/ write/ execute files on the disk. The /etc/fstab is general permissions file for disk partitions, so it works on any Linux distribution.

Below is the typical contents of /etc/fstab for a 2-disk setup (OS installed on primary, applications/ media on secondary, both internal), which enables the user to run executable files. [Note that UUID values are faked; actual fstab entries should have the right values].

The ntfs-3g package must be installed for support of NTFS partitions; usually it is bundled with the distribution, but in case it isn’t, we can install using the distribution’s package manager.

Example fstab file

# # /etc/fstab: static file system information. 
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to 
# name devices # that works even if disks are added and removed. 
# See fstab(5). 
# # 

# / was on /dev/sda5 during installation 
UUID= / ext4 errors=remount-ro 0 1 
# /home was on /dev/sda6 during installation 
UUID= /home ext4 defaults 0 2 
# swap was on /dev/sda8 during installation 
UUID= none swap sw 0 0 
# s33 on /dev/sdb5 (Secondary Drive) 
UUID=UUIDOFS33PARTITION  /media/jdoe/s33 ntfs-3g defaults 0 0 
# s34 on /dev/sdb6 (Secondary Drive) 
UUID=UUIDOFS34PARTITION /media/jdoe/s34 ntfs-3g uid=1000,gid=1000,fmask=0000,dmask=0000,exec 0 0 
# s35 on /dev/sdb7 (Secondary Drive) 
UUID=UUIDOFS35PARTITION /media/jdoe/s35 ntfs-3g uid=1000,gid=1000,defaults 0 0
# s36 on /dev/sdb8 (Secondary Drive) 
UUID=UUIDOFS36PARTITION /media/jdoe/s36 ext4 defaults 0 0

The last 4 entries are for 3 NTFS partitions (/dev/sdb5, /dev/sdb6, /dev/sdb7) and a ext4 partition (/dev/sdb8) on a secondary internal hard drive. These were added manually after the OS install on primary, which automatically added the first 3 entries (root, home, swap), which may or may not be added by the installation.

The options column above decides which permissions to be set for the drive. The value defaults contains the options rw, suid, dev, exec, auto, nouser, and async. This is a typical usage of a file system, where the user will be able to read, write, execute files. The contents specified by defaults can be checked in the manual for mount, towards the end:

$ man mount

Write Access

If the mounted partition does not have write access, manually “own” the mounted folder as logged in user:

$ sudo chown -R jdoe:jdoe /media/jdoe/s36

Setting explicit user id and group id in fstab permissions

Above has two examples of how to set the permissions, with the second line explicitly mentioning the user id and group id to which the user belongs. To check what the value of these should be, we can run

$ cat /etc/passwd | grep jdoe

which returns

jdoe:x:1000:1000:John Doe:/home/jdoe:/bin/zsh

The part 1000:1000 corresponds to uid:gid

For more restrictive permissions, we can individually set permissions via fmask (for files), dmask (for directories), and umask (for both) by providing the bitwise inverse of the actual chmod permission number we want to set, since these are bit masks. More details can be found in the community guide for fstab in Ubuntu here.

Getting UUID of partitions to be mounted

The UUID values for these drives/ partitions can be obtained by running

$ sudo blkid

as suggested in the fstab header above.

To use the new fstab content without rebooting, we can simply run

$ mount -a

Steam/ Proton support for NTFS

Proton, the wrapper of WINE to play Windows games on Linux, is finicky about NTFS drives. It may or may not work depending on the distribution, and Proton version. I have seen Proton work with any of the 3 options we have used in NTFS above, but none of them worked for Proton 5.x. So if you are in the same boat, downgrade the Proton version to 4.x with the above fstab options, and it should work.

While most suggestions on the internet are to use ext4 as the format type, it misses the point – Linux is always about choice, and if someone wants to install Steam games on a partition and also use the same to install apps/ games under Windows, so be it.