I’ll often joke that Windows is just an advertising platform that plays games. It’s simply too lacking to be used productively. I haven’t had Windows on my personal desktop PC since around 2003, and I’ve typically just gamed on consoles. I currently have an XBox, and for the last few years it has enabled me to play the majority of Windows-exclusive games. After all, it’s just Windows PC hardware and kernel optimised for gaming.
Graphics Cards
I recently purchased my first discrete GPU for my desktop in a while. My last purchase was a Geforce4 MX440, if that gives you an idea of how long it’s been. For quite a while, a GPU just hasn’t been a good investment on Linux. They were plagued with compatibility and performance issues, and there were hardly any games that ran properly. The only drivers that worked without hassle were Intel’s. Intel integrated graphics is fine for day to day tasks, and is surprisingly good for video decoding and even encoding. AMD’s drivers have probably been in a first-class state for years, but I wasn’t willing to buy a GPU until the crypto market crashed and the prices became reasonable. This is now a reality.
Back to the new GPU. I got an AMD Radeon RX 6600 XT. I plugged it in, turned on the PC and started Steam on Ubuntu 22.10. I didn’t have to install drivers. I didn’t have to tinker with anything. It didn’t even have to download new packages. It’s the best OOBE imaginable. Native games such as CS:GO, Slime Rancher, Kerbal Space Program and Portal 2 ran flawlessly – even on wayland.
Windows Games on Proton
Proton has come a long way. In the past, I would cringe when I had to install WINE because it was bloated, unstable and cumbersome to configure. Valve has put a lot R&D into it and ultimately launched the Steam Deck console based on it. I can now comfortably say that Linux and Proton is a cleaner approach than dual-booting or installing a Windows desktop for gaming. Proton 7.0 consumes 2.1GB of disk space, and nearly half of it is duplicated libraries for 32-bit support. Linux typically ships with only 64-bit libraries, because every native Linux application supports 64-bit, and has done so for years.
The first game I tried to fire up with Proton was Slime Rancher 2. At first, it got stuck on the loading screen. I eventually noticed that I had the older 6.3 version of Proton installed, and 7.0 has since been released. After launching it on the current Proton it worked flawlessly. Here’s the kicker: this problem also exists on Windows 7, where the game will not run at all and is deemed incompatible. Meanwhile, it has a platinum rating on ProtonDB.
Slime Rancher 2 is written in Unity, and the first Slime Rancher (also Unity) included native Linux binaries. I’ve developed extensively in .Net Core in the past, and building a Linux binary isn’t a difficult thing to do, as long as you’ve made the right technical decisions along the way. It seemed odd that the sequel had this regression.
Peripherals
I plugged in an XBox One Controller via USB and fired up a game in Steam. It worked straight away. No driver installs. No configuration. Even the button mapping is good right out of the box.
My PC monitor works at full resolution at its fastest refresh rate (2560×1440@75Hz). The mouse, keyboard and gaming headsets all work just by plugging it in – including my Microsoft webcam mic. Discord has its own native Linux client, and voice chat works just as well as it does on Windows.
Improving Gaming with Filesystem Compression
It’s well known that games ship with a lot of heavy resource files such as maps and models. If you’ve ever seen a 10GB game download take up 20GB of space on your hard drive, it’s because these files are decompressed during installation and stay that way on your hard drive.
Using an additional 120GB (actually 112GiB) SATA SSD, I formatted the drive as btrfs and mounted it with the option “compress=zstd:9“. This transparently enables compression across the entire drive. I then put my steamapps directory on this drive.
After copying all my games across, I could query the amount of space used on the drive using df and the total size of all files using du.
$ df -h /mnt/steam
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 112G 90G 21G 82% /mnt/steam$ du -hsx /mnt/steam/
127G /mnt/steam/
As you can see, my 112GB SSD is now holding 127GB of game files, and it’s only taken 90GB of space to do it. There’s also another benefit to doing this – it will dramatically improve loading times on conventional hard drives. This is because a conventional HDD can only read at about 100 MB/sec (give or take). Meanwhile, zstd decompression has a throughput of over 4,000 MB/sec on a typical desktop CPU. The drive has to physically read less data, and the CPU will keep up with decompression while the drive is reading at maximum speed.
It’s worth noting that Windows does have filesystem compression, and some people even use it on their Steam library. It’s just nowhere near as good. There have been reports that the LZNT1 compression it uses suffers a lot of performance degradation, and it breaks with fragmented filesystems. Windows 10 has the new XPRESS4K algorithm that’s reportedly even slower. These compression algorithms don’t make good use of multiple cores, or have the smarts to selectively compress files.
You can read more about btrfs compression here.
De-duplicating Multiple Users
There’s a problem on both Windows and Linux where each user is given their own SteamApps directory. When multiple users have the same game in their library, the game is downloaded, stored and updated independently for each user. This is a waste of both storage space and bandwidth. The good news is, on Linux you can fix this using features its superior filesystem.
First you should create a steamapps directory outside of a single user’s home directory. Mine is at /mnt/steam/steamapps. Adjust the ownership of the directory so it’s assigned to the users group, and grant that group write access to all files. Then finally set the group sticky bit on all directories to ensure all new files will also be writable by the users group.
chgrp -R users /mnt/steam/steamapps/
chmod -R g+rw /mnt/steam/steamapps/find /mnt/steam/steamapps/ -type d -exec chmod g+s {} +
Then you should add all users on your system to the users group. Do this for each local user:
sudo addgroup [username] users
Run these commands to delete the user’s steamapps directory and symlink it to the shared copy. You will need to repeat this as each user:
rm -r ~/.local/share/Steam/steamapps
ln -s /mnt/steam/steamapps ~/.local/share/Steam/steamapps
You can now move between these user accounts and you will all have access to the same installed games. If you set up family sharing between the accounts, all games should be playable by all users too.
I understand this may appear difficult to do, but it would be even harder to do on Windows, if possible at all.
Anti-Cheat is Ready and Waiting
The only real drawback is a problem that plagues the Steam Deck and really shouldn’t be a problem. Anti-cheat platforms such as Easy Anti-Cheat and BattlEye now fully support Linux. We’re now waiting for the individual games to adopt support for it. Reportedly, it’s as simple as the developer flicking a switch to allow Linux clients to join. The problem is they don’t. You can take a look at areweanticheatyet.com to get an idea of the situation.
It’s only been a few months since support was added, and there are already more games that work than not. It’s promising.
However it still blows my mind that Epic went to all the effort to build Linux support into EAC, but don’t have the confidence to enable it in their most popular title, Fortnite.
In Conclusion…
Linux gaming is in a better state than many people realise, and I believe all the technical hurdles have been overcome (albeit some political hurdles remain). As a platform, I believe Linux is better suited to gaming than Windows. The games that do run actually run just as well, if not better. The underlying kernel has unique features which would allow your PC to hold more games and have them load faster, particularly in a multi-user environment.
Leave a Reply