torstai 27. kesäkuuta 2019

How I got S.T.A.L.K.E.R.: Clear Sky and Call of Pripyat to work on Devuan Linux

Introduction

This is a very short guide on how I got S.T.A.L.K.E.R.: Clear Sky and Call of Pripyat to work on my Linux computer. I had bought them on Steam earlier, and thanks to Steam Play and Proton, it was very easy even though the game did not work out of the box.

Steam settings

Like in the previous post, it is necessary to enable Steam Play for all titles so that S.T.A.L.K.E.R. can be installed on Linux. It is simply a check box in Steam preferences, follow e.g. this guide.

After that the game can be installed, but it did not launch properly but crashed; A BugTrap window appeared with some magic numbers in it.

In this case the solution was simple. In the WineHQ AppDB page, there is some mentions about DX10 not being tested/not working, and the solution is to use DX9.

In the bottom of the README.md in Proton Github page, environment variables are listed. There is variables to disable D3D11 and D3D10. The game works perfectly with Proton (4.0 I think currently) as soon as those two are disabled. So add the following to the startup parameters of the games in Steam:
PROTON_NO_D3D11=1 PROTON_NO_D3D10=1 %command%

You can see the parameters in screenshot below:






After using these parameters, the game can be launched from Steam and works just fine (though I have not yet played very long...)

EDIT 7/2021: After two years I got back to this game and since then Proton has been updated many times. Latest version is 6.3-5 and the game did not launch with that. Changing Proton version for these games to 4.11-13 made the game lauch fine and it works properly. I only tried Clear Sky again so far.

Also I'm not sure whether ProtonDB existed when I wrote this article. The game pages for Clear Sky and Call of Pripyat have probably more information on how to get the games run and with which Proton versions and settings.

How I got Watch_dogs 2 to run on Devuan Linux

Introduction

I played through Watch_dogs on my laptop few years ago, and I really liked the game even though I found some aspectes of it stupid (e.g. missions where it was necessary to kill everyone instead of sneaking around). My laptop just barely run the game but it was fun nonetheless.

I bought Watch_dogs 2 also (from Steam), and while it launched on the laptop the framerate was so low that the game was unplayable.

Now that I got my new computer, I decided to try the game again. This time, however, I had Linux which made things a bit more complicated.

As I mentioned in the previous post, I use Devuan Linux with the Beowulf (testing) branch, because only that has decent enough AMD graphics (and Vulkan) drivers for many games.

Installation from Steam

Originally I bought the game from Steam. The game is also visible on Uplay, but I decided to try installing the game from Steam first. This might have made things a bit more complicated in the end...

To install the (Windows) game from Steam I first had to enable the Steam Play compatibility layer for all games. I did it according to e.g. this guide. After that I could install the game.

Watch_dogs 2 requires Uplay (Ubisoft game launcher/store) to work, so when launching the game for the first time, it installed Uplay and some DirectX libraries and whatnot.

Running with Steam Play

After installation through Steam I tried to play the game. Sometimes it got stuck on the splash screen, other times I got it to launch Uplay only, and from tere I could try to start the game but it would just get stuck on the splash screen.

Some sources told to try giving a parameter -eac_launcher to run the game, but it didn't really help. So in the end I gave up trying to run Watch_dogs 2 with Steam Play and Proton (I think the version was 4.0.something) and try manually with Wine.

I already had the game downloaded by Steam, and I used winecfg to add a drive so that it would include the Steam directory with the game. However I didn't know where Uplay was installed and it was not visible in the default wineprefix, so I decided to download it and install with Wine. It installed fine, but did not launch due to some errors.

Wine version

The current Wine version in Devuan Beowulf is 4.0. However it didn't work any better than Steam Play, maybe even worse, didn't launch Uplay nor the game. So I decided to update Wine.

The current development version of Wine, is 4.11, I decided to try that. I followed the Debian guide on Wine homepage and it seemed to work fine with Devuan. I.e. I added
deb https://dl.winehq.org/wine-builds/debian/ stretch main
to sources.list. I assumed that Debian strect would be close to Devuan Beowulf. I then installed the winehq-devel package. This installed the 4.11 development version.

This, however, did not work. I don't remember the errors I got anymore, but I could not get the game to run, probably because Uplay would not launch. I found similar results in the WineHQ AppDB for Uplay, wine version 4.11 was given garbage rating.

There was promising result for version 4.8 though, everything should work. So I decided to give it a try. First I removed (apt-get remove ...) everything wine related, and then installed the wine-development 4.8 for Debian stretch:
apt-get install winehq-devel=4.8~stretch
 if I remember correctly. I might check the actual package names later.

Note: Since my installation a new test with wine 4.11-staging shows gold results if corefonts (maybe same as arial, see below) is installed with winetricks. So it might not be necessary to downgrade the wine version.

Install dxvk

Dxvk is open source Vulkan implementation of Direct3D 11/10. It is necessary to run these games, so I installed that one; version 0.96 (which i think is the latest) is already in Devuan Beowulf, so following command was enough:
apt-get install dxvk dxvk-wine64-development

Winetricks

I think with wine 4.8 Uplay launched a bit longer, but still crashed. I went to check what the Lutris installation script for Uplay did and saw that it does call winetricks with arial, win7 and d3dcompiler_43. In my case the last one failed to install, but doing
winetricks arial
winetricks win7
to install arial font and change default windows version to 7 did the trick and Uplay started just fine.

Uplay options

I multiple places it is preferred to set startup parameters for Watch_dogs 2 in Uplay to include
-eac_launcher
which disables the Easy AntiCheat, and also disables multiplayer, I think. I added this. I also disabled the Uplay overlay in Uplay preferences after one crash, as was suggested somewhere. After that I've only crashed the game once and it was when I was exiting the game. So I recommend disabling the overlay.

Install wine steam

At this point I had Uplay running but of course the game was not visible in it since it was installed with Steam. So I launched the game from the steam installation directory with wine. It launched but it wanted to install Steam again... Probably the wine version cannot directly communicate with Linux Steam. After a few tries I decided to go ahead and install the windows version of Steam with wine (clicking ok when the game prompted to install).

After Wine Steam was installed, it wanted to re-download Watch_dogs 2, since the game was not in the default library. Since I had already mapped the Linux Steam library in a wine drive, I added it to Wine Steam. Now Wine Steam saw that I had the game already.

I added the same -eac_launcher command line in Steam as well.

Note: It is VERY bad idea to use same library for Linux and Windows Steam. The Wine client tried to update all Linux games instantly to their Windows counterparts... See below how I fixed this.

Trying it out

At this point I can launch the game from Steam. Launching it brings up Uplay, and after first start the game is also visible in Uplay and can be launched from there as well. It works perfecly (as far as I can tell). I'm not interested in the multiplayer, so it does not matter if it does not work (though the game suggest online missions still... dunno what's the deal).

So, it was quite an adventure to get the game to work and I think I did it the hard way, but in the end I can play the game! I'm not going to touch the setup until I've finished the game, then I can try if it is easier to just install the game from Uplay or something.

About the steam library

As I mentioned, it was a bad idea to share the steam library between Linux and Windows client. Since I had already installed the game with Steam Linux (SteamPlay), I had to move it. I created a new directory, and made the .../Steam/steamapps/common/ tree there. I moved the Watch_dogs 2 directory from the Linux tree to there, as well as the appmanifest file under .../Steam/steamapps/. The manifest is just text, I looked into all of them until I found the correct one.

I changed the winecfg drive mapping so that the old path in wine would now end up in the new directory with only Watch_dogs 2 in it. After restarting Steam(s), the Linux client no longer sees Watch_dogs 2 as installed, and the Wine Steam sees only that, no other games. Now it works just fine.

Conclusion

So in the end I think the relevant parts could be:
  • Install latest wine-devel (I used 4.8 but I think the latest could also work)
  • winetricks arial
  • winetricks win7
  • Install latest dxvk and dxvk-wine64-development
  • Install Uplay
  • Install windows Steam client with Wine
  • Install Watch_dogs 2 with the Wine Steam client (or directly from Uplay?)
  • Disable Uplay overlay
  • Add -eac_launcher parameter in Uplay and in Steam for the game
  • Launch the game from Uplay or Steam and enjoy!

keskiviikko 26. kesäkuuta 2019

How I got DOOM (2016) to run on Devuan Linux

Introduction

I bough the "new" (2016 version) DOOM some years ago on Steam, but back then my computer was not powerful enough to run it, and it wasn't even 64 bit. So I never got around to play the game. Now I finally decided to update my computer to a basic gaming machine which should be good enough to run these few years old games (DOOM, Watch_dogs 2, Deus Ex: Mankind Divided etc).

With my old computer I had some version of Windows 7. Now I did not have the license anymore, nor did I want to spend over hundred euros for a new one. So I decided to first start with Linux and try to get my games to run on that. And Steam promises that DOOM would run with their Proton compatibility layer.

I decided to install Devuan Linux, since I wanted a distribution without SystemD. I wont go into details why, and in the end it should not make much difference anyways. The current stable version of Devuan is Ascii, so I installed that one. It worked very well out of the box, and I installed the Linux Steam client and DOOM without issues.

First issue: nothing happens

After installing DOOM I wanted to test it. I pressed the play button on Steam and... nothing happens. No splash screen, no errors, nothing... I also tried Deus Ex: Manking Divided (which has native Linux version) and it worked fine (though giving a warning about nonsupported distribution), so graphics etc. seemed to work just fine. Something else was going on.

I started searching the internet about similar issues and didn't seem to find anything relevant. Finally, after a long search I came across this thread. It caught my attention because I was using my old storage disc which was used with Windows before, which I checked to be formatted as NTFS. Even though I had read/write/execute permissions on the disc, it was owned by root.

I checked my user id and group id with id -u [username] and id -g [username]. I added those ids (1000 and 1000) to my /etc/fstab parameters for the partition with uid=1000,gid=1000 like was instructed in a post in the thread linked above. Then I remounted the drive and tried again. Now the game seemed to launch.

I did not know about Steam logs which could have revealed the issue right away... Oh well...

Second issue: fatal error on startup

Now the game seemed to be starting, but quite quickly died to a fatal error:

FATAL ERROR: wglCreateContextAttribsARB failed
 Again, furious searching lead me to this bug report. I tried to enter the +r_renderapi 1 to the game's launch options but it didn't really make a difference.

In the bug report there is a mention that mesa needs to be a recent version. The versions listed in the post are:
  • client glx vendor string: Mesa Project and SGI
  • OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.5
  • OpenGL version string: 3.1 Mesa 18.1.5
  • OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.5
In Devuan Ascii, the mesa-glx package is 13.0.6 so it was too old. However, it seemed that ascii-backports repository had 18.2.8, so I decided to try that.

Updating mesa

So I added the ascii-backports repository (with main, contrib and non-free portions) to /etc/apt/sources.list and did the normal apt-get update. Then I manually installed what I thought I needed: mesa-vulkan-drivers, libgl1-mesa-glx, libglx-mesa-0, libdrm-amdgpu and maybe some other. Then I rebooted to be sure the new drivers are loaded.

Boot texts rolling and... blank screen. Keyboard not working, cannot change to text-only terminal, cannot reboot with keyboard.... Luckily power button did trigger a shutdown. So, I clearly forgot some packages and broke the Xorg.

From GRUB I booted to single user mode and wondered how I would go about fixing this. I tried installing some more packages from the ascii-backports, like xserver-xorg-???, but I could not get X to start. I decided to switch to Devuan Beowulf (testing) version, since it had the mesa-vulkan drivers version 18.3.6.

So change ascii to beowulf in sources.list, and apt-get update && apt-get dist-upgrade. After a while it was done and I rebooted. Fingers crossed... and it works. Perfect.

Now it was time to test DOOM again with newer drivers. Launching steam and pressing play on DOOM, and now it works flawlessy! Perfect.

So in the end I got DOOM to work, but seems like the Devuan Ascii is a bit outdated, and it is necessary to have more recent drivers. I stick with Devuan Beowulf now because with the new drivers most games seem to work fine.

torstai 23. toukokuuta 2019

Stereo FM receiving with RTL-SDR and Gnuradio - part 3

This is third part of the stereo FM broadcast demodulation using rtl-sdr and GnuRadio Companion. In this part I describe another method for doing the stereo demodulation.

  • Part 1 shows how the mono signal is received and how the stereo signal is modulated.
  • Part 2 shows how I implemented a stereo demodulator.

Introduction

While investigating how to receive the stereo FM broadcast, I came across this document, which describes an FPGA implementation of a stereo receiver. Interesting part of it was how to demodulate the stereo signal.

According to the document, stereo signal can be just sampled at the positive and negative peaks of the 38 kHz carrier and then hold until next peak. Low-pass filtering this should provide the original stereo signal.

I wondered if this really was possible on night when I couldnt sleep, and came to conclusion that it is indeed possible. Considering the equation for streo modulation

Streo FM broadcast modulation


and forgetting about the 19 kHz pilot for now, we can see that when the 38 kHz carrier () is at positive peak (1.0), then the signal is 0.5*(A+B)+0.5*(A-B)=A i.e. the left channel. When the carrier is at negative peak (-1.0) the signal is 0.5*(A+B)-0.5*(A-B)=B i.e. the right channel.

I also wrote a python script to show this graphically:
Sampling the signal to regenerate left and right signals

In the figure the 38 kHz carrier is shown with cyan and the FM baseband signal in black. Blue line shows the original left channel data and red shows the original right channel data. Blue dots show signal sampling points in positive peak of the carrier and red dots at negative peak.

The figure clearly shows that the sampling indeed does recreate the original waveforms.

GRC implementation

I implemented the sampling method in GRC. Following figure shows how the demodulator looks. It is very similar to the previous method (e.g. 38 kHz carrier recovery etc), but maybe a bit simpler looking.

Sampling type stereo FM demodulator

 I also uplodaded the GRC file to GitHub.

Once again I used the python script to generate ramp signals and wav file source to test the demodulator. The "received" signals look correct with this method also.

Demodulated left and right test signals with sampling method