Category Archives: Games

MS Windows on Linux: wine and MinGW-w64

 

I came across two separate discussions on LinuxQuestions.org that had a common root cause; a lack of Windows VST support in Carla and missing PE binary support in Wine causing Windows games to fail on Slackware.
They made me think about how I could help fix the core issue, which is that both SlackBuilds.org and Slackware 3rd party repositories (like mine) do not offer MinGW packages or scripts. To address the issue I needed to create a MinGW-w64 package, which is what I did. More on that, further down.

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.

Have fun with this! Eric

Note: I used one of Dave Gauer’s logos for MinGW-w64 to decorate this blog page.

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