A few weeks ago, Valve‘s official Linux binaries for its steamclient got an update. The 220.127.116.11 version is built using an updated Steam client:
Client timestamp 1676336721 (2023-02-14)
Steam Runtime version 0.20221019.0
The steamclient package which I create from this release tarball is meant to bootstrap the installation of Valve’s Steam gaming platform on your Slackware computer. The package installs a couple of scripts and a 32-bit Linux runtime based on Ubuntu, and adds a desktop menu entry so that you can easily start Steam.
When you first start ‘steam’ from the menu or from the X terminal command-line, the client scripts will download a larger set of runtime libraries, including 64-bit support. From then on, the steamclient will keep its runtime libraries up-to-date automatically, every time it starts up and connects to the Steam servers.
The Slackware package has a couple of tweaks because we obviously do not have all the expected Ubuntu tools on board. With the help of these tweaks, Steam works out of the box on Slackware – both 32bit and 64-bit with multilib!
If you are using Steam for gaming, be sure to check out its Slackware community. It’s not really chatty in there but last time I checked, the group listed over 400 Slackware users and there’s always a few online and playing.
Back to the issue at hand and their common root cause.
Starting with Wine 5.x, the developers added support for compiling wine’s Windows programs and DLLs into Microsoft PE (portable executable) format instead of building them as Linux ELF binaries. This has advantages, one of the more obvious ones adding compatibility with some copy protection schemes in Windows games.
However with wine-5.12 and newer, it appears that the PE binary format is now a requirement for some modern Windows-based games that you can play in Wine on Linux. Diablo III, World of Warcraft and others are mentioned in the relevant bug report.
This meant that I needed to do something if I ever wanted to update my own Slackware package for wine to a newer version than the 5.6 I had in my repository. Apparently to compile binaries into native MS Windows PE format, you need MinGW, the “Minimalist GNU for Windows“. In fact, I needed MinGW-w64 whichs is a fork made in 2007 of the original MinGW which adds 64bit Windows support and a lot of other enhancements, and is actively developed. Since this is not available for Slackware as a package or SlackBuild yet, I needed to come up with my own version.
The LQ thread mentions an OS-agnostic project from developer ‘Tk-Glitch’ called “(Mostly) Portable GCC/MinGW” which people used successfully to obtain a working MinGW compiler on Slackware. Since I was completely clueless about MinGW I started with that script, and for me indeed it built a MinGW compiler suite with support tools. Alas, the script was only meant for 64bit OS-es and of course it was not a proper SlackBuild script. So I used the project as inspiration (like, I used the script’s flow and logic) to write a SlackBuild script that would also work on 32bit Slackware.
The result is that I now have MinGW-w64 packages in my repository for Slackware-current as well as 14.2 (32bit and 64bit). The package installs a profile script to “/etc/profile.d/” which adds the MinGW binaries to your $PATH environment variable. On 64bit Slackware you will get both the MinGW programs that create 64bit Windows PE binaries (x64_64-w64-ming32-*) and those that create 32bit Windows PE binaries (i686-w64-mingw32-*). While on 32bit Slackware you will get programs that create 32bit Windows PE binaries (i586-w64-mingw32-*).
Having a MinGW-w64 package finally enabled me to compile the newest wine (enhanced with the wine-staging patch set) properly.
Since the MinGW compilers are in the $PATH, the wine-build will automatically use those where needed, no change to the SlackBuild was required. The result is a wine-5.17wine-5.18 package which has grown considerably in size due to the addition of PE binaries. I hope this package will enable you gamers to play your favorite game again.
Note that I have added new dependencies to the wine package for Slackware-current. In order to improve DirectX sound support you need FAudio. For Direct3D 12 support, wine additionally depends on vkd3d. You’ll have to install those from my repository as well.
Both FAudio and vkd3d fail to compile on Slackware 14.2, due to a lack of Vulkan library support and outdated other libraries such as Gstreamer, so the wine package for Slackware 14.2 was built without them (but it does need OpenAL as a dependency there. This got added to slackware-current as ‘openal-soft’).
And then there was Carla, the subject of that other LQ thread.
Carla is an audio plugin host; it is contained in my Slackware Live DAW project. It supports a lot of plugin formats, like LADSPA, DSSI, LV2, VST2, VST3 and more. It turned out that my Slackware package for Carla did not support Windows VST plugins. VST is mostly used on Windows, VST is a proprietary format from Steinberg which requires a licence from them to create or host a plugin. The VST3 source code is placed under a GPL3 license; however you still need written agreement from Steinberg if you want to distribute a plugin. Nevertheless, if you are a mucisian and purchased a VST plugin then Carla needs some additional work to use that Windows VST plugin.
Again, MinGW-w64 (and wine) were needed to expand the capabilities of my carla package. Luckily, a new version of Carla was released yesterday so I could apply my newfound knowledge immediately. The new carla-2.2.0 package supports Windows VST’s. Go get it.
For the techies:
Note the different architecture used in the names of the MinGW 32bit binary compilers: “i686” on Slackware64 and “i586” on Slackware. On 64bit Slackware I compile a new gcc, binutils and all the libraries they need first, and use them as a bootstrap for compiling MinGW-w64. That is why I could switch away from Slackware’s “i586” to a new “i686” architecture target, and in principle I can use a different version of GCC than the one shipped with Slackware. On the Slackware 32bit OS I was unable to compile this “bootstrap GCC” so I needed to stick to the version of GCC which is present on Slackware and use that to compile MinGW-w64.
If someone feels adventurous and has a lot of free time, the issue on 32bit Slackware is that after I compile various support libraries, then binutils and then gcc, I can not complete the gcc compilation because it ends prematurely with an error “/tmp/build/mingw_gcc_bootstrap/bin/ld: cannot find -lc“. Apparently the linker does not search /lib or /usr/lib for whatever reason. If I add symlinks for libc into “/tmp/build/mingw_gcc_bootstrap/lib/” then I get a little further in the process, but then the same happens for -lm”. Etcetera. I do not have this issue on 64bit Slackware where I use my multilib version of gcc packages… no idea whether that makes the difference. So in 32bit Slackware I just skip compiling my own GCC and move immediately to compiling MinGW. Suggestions are welcome and appreciated.
When it comes to audio and sounds in Slackware, we’re happy to have ALSA as the sound subsystem. It works reliably, and has done so ever since it replaced OSS in Slackware all those years ago. In due course ALSA got capable of dynamically mixing multiple sound sources – which is basically what a sound server does, too. We were never plagued with the issues of other distros when they abandoned ALSA for PulseAudio.
When the Arts sound daemon of KDE was deprecated and finally removed with the release of KDE4, Slackware was left without a sound “server” that ran out of the box. We still have ESD, the Enlightened Sound Daemon but that one has limited use because of the wrapper programs it needs.
There are however scenarios where you wish Slackware had some sort of audio server. Until now, the only times when that thought crossed my mind it was related to streaming audio over a network – think of remote desktop sessions and virtual machines. I may write some more about that topic in a future post because I think I have the solution now – read on.
A more immediate need arose when I went looking for software that can record videos of my Slackware desktop – individual program windows and gameplay footage. My son is a huge Minecraft fan and wants to be able to do in Slackware what he already does with Fraps in Windows. My intention is to task him with creating some Slackware “end-user” videos to attract newcomers to the distro 🙂
It turns out that there really is not all that many good desktop video recording software in Linux land. I have tried recordmydesktop and like it well enough (that is how it ended up in Slackware’s “/extra” section) but it does not deliver stellar videos, in particular I don’t think it is suited for recording gameplay. It also produces OGG video only, which is OK since that gives you the only free and open video format and codecs… but I believe this design decision limits my options too much.
I read up on ArsTechnica’s attempts to record gameplay footage on SteamOS. To this day, the ArsTechnica folk have not found a way to record the audio of a game… apparently it is not as easy as you might think, to record OpenGL games. Programs like FFMPEG and VLC are able to record (parts of) your desktop but it is cumbersome and also does not deliver high-quality video with properly synced audio. These programs are not capable of intercepting OpenGL renders either, which limits their use.
So I went looking… and came across GLC, an ALSA & OpenGL recording software for Linux which was inspired by Fraps and Yukon, but it seems mostly abandoned by its author. Then there also is SimpleScreenRecorder, a relatively new piece of work by Maarten Baert. The program uses FFMPEG’s codecs to allow you to record audio and video into any format supported by the locally installed version of ffmpeg. It supports the recording of ALSA sound sources (think of a microphone). The word “simple” in its name only characterizes the ease-of-use, not the featureset! And it has a Qt-based GUI which nicely blends into my KDE desktop. By means of an OpenGL injection library it also supports direct recording of OpenGL renders (read: games). That should produce superior videos compared to merely recording the desktop window (because that produces lower frame rate videos or lower quality).
Unfortunately it turned out that SimpleScreenRecorder was not capable of recording my Slackware desktop’s sound, and therefore game videos are silent.
That is a show stopper… apparently you need a sound server like PulseAudio in order to record the audio as well. I am not prepared to install PulseAudio on Slackware – as you are well aware, this is a personal issue I have with the PA author and the way he writes code. So I investigated further, and found out that the unreleased GIT sources of SimpleScreenRecorder support JACK as a new sound source next to ALSA (and PulseAudio). I built the program from its GIT sources and then went on to learn about JACK Audio Connection Kit. I knew that JACK is primarily used by audio professionals and musicians because of its low-latency core design. But as it goes with versatile programs, it is inherently difficult to grasp its concepts and complex to configure. But I persevered and ultimately found a way to configure JACK on my desktop, and reconfigure my ALSA setup so that all the programs that I use can still emit sound, and SimpleScreenRecorder is now capable of recording video and audio! I put a demo video online which I recorded for the intro sequence from the Metro: Last Light game.
As you can see, the game stutters a bit, but that is not caused by the recording software – it’s my desktop PC which is just not fast enough for the game.
My next post will be about how I built and configured JACK, and what I had to change in my ALSA configuration so that for instance Steam games (using SDL for audio) and MineCraft (using OpenAL for audio) would still make sounds.
In the meantime, if you want to try SimpleScreenRecorder, there’s a couple of dependencies you need to install as well. SimpleScreenRecorder was built against ffmpeg (version 2.1 to be precise – please note that upgrades of ffmpeg will usually break a lot of applications that depend on it due to a change in library versions). Also, the package which I released has been built against jack – even if you do not plan on using it, you’ll have to install it… or you can rebuild SimpleScreenRecorder yourself.
If you want to use SimpleScreenRecorder to record 32-bit OpenGL programs (Steam games, WINE based games) and are running a 64-bit Slackware, it will have to be a multilib system and you will have to use the “convertpkg-compat32″ script (part of my compat32-tools package) to convert and install the 32-bits “compat32” versions of the simplescreenrecorder, ffmpeg and jack packages as well as the 64-bit versions.
If you want to try and record a Steam game without the Steam windows being visible (those are also rendered in OpenGL), you’ll definitely have to read these instructions: http://www.maartenbaert.be/simplescreenrecorder/recording-steam-games/#native-steam-for-linux because currently it involves some manual tweaking to get this working (I expect that this will get easier in time). Judging by his Wiki, Maarten is responsive to the users of his program and is able to write meaningful documentation.
The release of SteamOS was right on time, as promised by Valve. SteamOS is an Operating System designed to play your (Steam) games on a TV. The accompanying “Steam Box“, which will be running the SteamOS and which is supposed to be a hardware platform as open as the Operating System designed for it, is still in Beta but 300 prototype devices (running the SteamOS) have been sent to eager testers together with a purpose-built Steam Controller.
Apparently the Steam Box will also allow you to play your games on your regular (Windows?) computer and “stream” the game’s display to the TV connected to the Steam Box (or any homebrew computer running SteamOS). I don’t know if that will deliver a perfect gaming experience (PC and TV must be close to each other) but I guess that this is how Windows users can still profit from the Steam Box (since it runs a Linux OS, Windows games are out of the question).
You can already download the slightly less than one gigabyte large archive of the OS. It is still a beta release, so not advised for “inexperienced Linux users”. Well, we Slackers do not fall into that category.
Q: What is SteamOS?
SteamOS is a fork (derivative) of Debian GNU/Linux. The first version (SteamOS 1.0) is called ‘alchemist’ and it is based on the Debian ‘wheezy’ (stable 7.1) distribution.
The major changes made in SteamOS are:
Backported eglibc 2.17 from Debian testing
Added various third-party drivers and updated graphics stack (Intel and AMD graphics support still being worked on)
Updated kernel tracking the 3.10 longterm branch (currently 3.10.11)
Custom graphics compositor designed to provide a seamless transition between Steam, its games and the SteamOS system overlay
Configured to auto-update from the Valve SteamOS repositories
I think it is a positive message to all Open Source fans that Debian has been chosen as the base for SteamOS and not Ubuntu, which was the initial target for the Linux Steam Client. I have been watching the threads discussing issues with Steam on Ubuntu and was always glad that running Steam on Slackware was so much easier 🙂
I downloaded the OS image and despite online warnings that the download server was overloaded, it arrived at 6.5 MB/sec which is the maximum bandwith of my own Internet link. I have not yet tried it, but somewhere this week I will certainly dress up a Virtual Machine to see what it looks like. I wonder what will happen, as SteamOS expects Nvidia graphics hardware to be present, although the FAQ mentions “(AMD and Intel graphics support coming soon)“.
Exciting times for Linux gamers. Ever since Gabe Newell’s public statement at LinuxCon 2013 that the future of gaming was on Linux, not on Windows, his company has been porting Steam games to Linux at a frantic pace, with other Open Source software profiting from their efforts (LLVM, X.Org drivers are examples). A year before that speech, Gabe Newell already called Windows 8 “a catastrophe” at a videogame conference in Seattle. Valve, a big thumbs up!
Yesterday was the 20th birthday of DOOM, the computer game which meant a paradigm shift to me way back when I got my hands on it.
It was 1993 and I worked at a CAD/CAM company with a Novell network (IPX protocolled, this was before the time of TCP/IP even). A collegue of mine had downloaded the shareware version of DOOM from a bulletin board and found out that it had multiplayer capabilities and could be played on an IPX network – like our company network. One-on-one play was also possible using direct modem connection (yes, this was before the advent of the public Internet) but IPX network setup meant 4-player deatchmatch. Nobody had ever played a 3D game on a network (Multi User Dungeons and the like are quite different) so this was exciting stuff.
I was the local sysadmin, and so they asked me if they could put up a copy of the game on the server so that people could install it and have a go at network play. Sure thing! I wanted to try this out myself of course. Early version of a BOFH 🙂
I wish I had gone ehard doing that… even though playing deathmatch was an ABSOLUTELY FANTASTIC experience. What happened? The first version of shareware DOOM had a serious flaw in the IPX network play, it used broadcast packets to communicate among the players of the game. Once we got a couple of foursomes playing the game, the network came to a complete standstill because of all the broadcast traffic.
Luckily the fix came fast, and the next update to the shareware version used unicast packets. That settled things 🙂
But by then I was hooked. I had never played a (semi-) 3D graphical game before at that time, the best I had done was Leisure Suit Larry and that was a different league altogether. I liked the Colossal Cave Adventure a lot better actually. You know that you can type “adventure” on your Slackware command prompt? You’ll probably not experience what I felt in 1983 when I first started it on the University’s mainframe computer… the first ever computer game I played. IT was right after we switched from teletypes and punch cards to VT100 terminals…
DOOM was so much different, it caused an adrenaline rush and we all got hooked at work. We had to declare our lunch breaks as exclusive frag time so that we could still get some work done in the remaining hours. DOOM’s IPX based network play was limited to isolated LANs because John Carmack was new to IPX, but we actually managed to battle our collegues in another office 100 kilometers away after I learnt enough of the IPX protocol to modify the ipxsetup source code and add routing capabilities (even then, idsoftware was ahead of everyone else in the field, not just by being the first company to give away parts of their game for free as “shareware” but also by making the source code of their network setup program available). Yes, those are some of my first USENET posts way back in 1995 and 1996 when we had finally had our own Internet subscription at work (connecting through a 1200 baud Hayes Smartmodem).
Not just the concept of network play, 3D gaming and freely sharing game data and source code was an eye opener to me, but also the concept of multimedia in computing. At the time, I did not even have a “real” DOS computer. I owned an Atari TT which I bought because Atari had promised to release a real UNIX OS for that machine. Unlike the Arari ST which was primarily meant for playing games, I was interested in programming, furthermore I had been a UNIX support person before I switched to Novell networks. It took Atari so long to deliver that I never actually got to install their brand of UNIX but got hooked on their TOS/GEM operating system instead, and actually wrote a couple of games (game clones to be precise) and utilities for the TT-GEM platform. But then DOOM came, and my girlfriend (now wife) had bought a computer to write her thesis. Of course I installed DOOM on it (my own Atari was useless) and she got hooked to the game as well 🙂
But, we kept getting stuck at a particular spot in the game and we did not know how to advance. There was no Internet remember… no Google to search for walkthroughs. So I decided to upgrade the computer with extra RAM and a soud card.
The first time I started DOOM after the sound card was installed, somewhere late at night in a darkened room, and some IMPs raised their gruesome voices, the hair on my head stood on end and I had goosebumps all over. This was scary stuff, o wow! It was my first truely immersive experience in computer gaming – 3D and sound. It defined my taste for computer games, and I still care for “idgames” style of shooters more than anything else.
And having the sounds meant we finally could progress in the game, because we heard a distant door open and close again, and we knew than that we had to run for that door. Something which we would not have discovered without a sound card.
At that time, I knew the computer industry was going to change. It was a game which made me decide to buy new hardware… that was a first for me. At work where I was the sysadmin I upgraded or replaced computers because the programmers would buy a new compiler or wrote more complex code. Games were not considered as relevant to computing. Hah!
A nice read, also called “Memories of Doom” (why did they nick my title!) is up on Kotaku where John Carmack and John Romero (former friends, now bitter rivals) reminisce about their creation. Oh, the good times.
Am I an old guy? Yes, that should be obvious by now. But I still play games. On Slackware Linux.
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!