Category Archives: Games

A journey into recording sound & video in Slackware

ssr 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.

ssr_qtui

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.

Get packages (and sources) here:

Have fun! Eric

SteamOS is out – based on Debian, not Ubuntu

steamos

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.

From the SteamOS FAQ:

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!

Eric

Memories of Doom

doom_boxcoverYesterday 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.

Man…

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.

SteamOS coming to your living room

steamos

Today, Valve Software has announced their next move in bringing the Steam content delivery (read: gaming) platform to the masses. The developer is going to wrap Steam into its own in-house developed Linux Operating System!

The SteamOS is meant to be installed onto living room devices (your TV, multimedia streaming box, and probably onto a SteamBox eventually).

It was already clear that Valve was sort-of preparing for a customization layer on top of a Linux OS; the http://repo.steampowered.com/hometest/pool/steam/ directories show some interesting tidbits. But rather than building the Steam binaries with Ubuntu Linux as the OS target, like they have done until now, Valve have come up with a whole Operating System of their own.

The good news is that this will be a Linux OS and it will be free to use by gamers as well as manufacturers. It will probably not be based on Slackware – their loss… but hey, they can always hire me. Keeping Steam supported in Slackware will not be a daunting task, because I am willing to bet a few dimes that the SteamOS will be yet another Ubuntu derivative or at least a Debian derivative.

Let’s hope that there will be a real Steam Box in the end. Having a SteamOS firmware for multimedia devices and smart TV’s will at least keep some of you busy. Interesting enough, Valve released a couple of teasers in the past week, hinting for interesting announcements. Well, this was the first of three. The next one can be expected on Wednesday 25 september. To shorten the wait, you may want to check out a review of the keynote speech at LinuxCon 2013 by Valve’s head honcho Gabe Newell. His thoughts shed more light on what we may expect from Valve in the near future.

steamos_back_buttonHave fun! Eric

Half-Life Dedicated Server

half-life-logo I have written down how I configured my Half-Life Dedicated Server (HLDS) in a new Slackware Documentation article. You can find the article here: http://docs.slackware.com/howtos:software:halflife_dedicated_server

The reason why I felt compelled to write this, was that the information you can find using Google, and the information on Valve’s own developer Wiki, is not 100% accurate or even outdated.

Writing an article also allowed me to add some tips, like starting the game server in “screen”, and explaining how you can auto-start the game server when your Slackware server boots, and keep the game files updated using a daily cron job.

I hope that the new SlackDocs article will trigger fellow Slackers to create their own HLDS server, and invite each other for some fragging. Hint: you can use the Slackware SteamCommunity group to schedule events like these.

Next on the TODO list is documenting how I created the “minimal Slackware” 32-bits virtual machine (less than 500 MB of Slackware installation footprint) which I use to run my own HLDS at home.

And after that, I still have to document how I setup a TeamSpeak server on the same virtual machine, which can be used for quality in-game voice chat. Lots left to do when I get bored again…

Cheers, Eric