Category Archives: gaming

DIY Handheld console – version 2

Although it was great to work on SuperGamePi-based DIY handheld console project, the device wasn’t that much fun to actually use and play. I wasn’t really thinking about it when I was building it – I assumed that fun from constructing & hacking around would be rewarding enough – yet I got nervous more than once when I actually tried to play longer than for a few minutes and there was always some inconvenience.

What went wrong?

Problem 1 was that my soldering work wasn’t perfect and I was having connection shortages which caused gamepad buttons not working or – actually worse – working when they shouldn’t. With a few iterations of desoldering and resoldering, I’ve managed to actually fix that issue.

Problem 2 was that after so many deconstructions and reconstructions of GamePi as project needed, screw holders eventually gave up. I’ve used super glue to fix them and it worked for a while, but not long enough. Still, that could be fixed, in worst scenario by reprinting GamePi case (which was a bit pricey).

Problem 3 was the one which eventually led me to go back to drawing board and redo the whole Pi-based handheld console project. Even though buttons worked, they haven’t really worked well. They were incosistent in tactile feeling plus amount of force needed to press each button differed. This wouldn’t be a problem in many projects – some house applications or soundboxes and such – but in gaming? It’s instant death because of jump which didn’t happen, loss of trial in Mario Kart, shooting failure in worst moment, even in turn-based jRPGs it was very irritating.

Handheld v2 – design!

I decided to completely change aproach and build modular system which would allow to swap components easily and to use already working gamepad part. Of course, it’s still possible to use  many other options: one can print 3D case which enables to hold SNES-like controller whole, gut Wii U “tablet” and insert Pi there or use smartphone bluetooth gamepad-case.

I’ve decided to go with last option, as BT gamepads are generally nicely recognized by Raspberry Pi/Retropie and their construction should enable flexibility in rebuilding later on. I didn’t like any option provided by popular company iPega, but found very promising photos & spec of joypad FlyDigiWee. It seemed rather unknown/untested in non-China world, yet I’ve liked it so much that I figured it’s worth trying out. Eventually I’ve had to order it twice and waited almost half a year for it (yeah…), but bad luck stopped there.

Building parts

In first version of handheld, I’ve used cheap 5″ GPS navigation screen plus not so cheap controller driver by Adafruit. Initially I wanted to use that for v2 as well, but unfortunately plastic holder for controller tape broke and I couldn’t find anywhere reasonably priced replacement. While thinking about about 3D printed replacement part, I eventually ordered another cheap 5″ screen with HDMI, designed for Raspberry Pi as it was accessible in my country.

There was an iussue with placement of GPIO block used for touch which I didn’t need and microUSB power port was put at right side of the screen – it collided with gamepad holder – so I removed both of them using as low force as I could and with help of my friend Ingvar I soldered 5V power plus ground instead.

Those changes made it really easy to use Raspberry Pi’s two GPIO ports to give power to the screen. Success!


Holding it together

While gamepad holder matched very well with screen (OK, after making stupid “backlight switch” smaller), I needed a way to hold RPi in place. Once more, first idea was to print 3D case for whole construction, but that would break modular approach so I decided that the simplest way is the best way – I ordered beautiful blue/clear case for RPi (with access to GPIO of course) and mounted it to gamepad with… cable holders. I can’t imagine more modular approach. ;)

Power over 9000!

While screen was nicely powered by RPi GPIO ports, Pi itself needed power. I’ve done another quick research and eventually reused Powerbank which I bought for v1. It has 6000 mAH capacity which is enough for a few hours of work (haven’t measured it exactly so it’s approximation) and 2.1A USB exit which is optimum for RPi 2 B. Potentially it could be not enough for RPI 3, but I use Pi I have (duh) and Pi 3, although has more power, has also higher needs – not only powerwise, but also regarding cooling necessarry for proper running.

Going back to powerbank – it’s quite heavy for such a small project (160g), yet comparing to other ones (eg. aluminium Xiaomi one which I use with smartphone & tablet) I can’t find better option which would still have nice capacity and amper outage. Also, it’s about the same size as RPi in case which is great, because if it was any longer it would be not comfortable to hold console in palms (which kinda is a goal here).

As you may imagine, I’ve used cable holders to put it all together. Glorious! :)


HDMI powered screen and longer (comparing to standard usecase) space between screen and RPi caused that I couldn’t use compact HDMI connector to hold it together. In result I have to to use standard HDMI cable. Well, perhaps not standard, because I’ve used as short one as I could’ve find – but it was still not perfect. Then my friend Dźwiedziu came with suggestion to… make it tangled like an old stationary phone cord. Perhaps it was crazy, but worked! When you can’t hide it, make it intentionally visible. Cool!


This hasn’t changed from version 1 – I still use RetroPie and it’s a great piece of work. It’s configured to support a lot of emulators, custom ports and such. RetroArch is running in backend which enables automatic configuration and mapping, is easy to use and has great EmulationStation UI. Only competition for RetroPie is RecalBox – designed for ease of use whuch leads to having less configuration options available. And I always prefer to have as vast selection as possible.

SNES, GB&GBA, PSX emulation works great; N64 is so-so. All ports I’ve tested so far work great – DOOM, Duke Nukem 3D, Quake 1 & 3(!), Minecraft Pi Edition (but not with gamepad), Stratagus for WarCraft II (same), Cave Story and more. Please let’s not discuss emulation legality here. I can also turn in into full LXDE/Pixel desktop, but it’s more of gimmick than real usecase. After all this 5″ screen has only 800×400 resolution.

First version, which used custom-build switches connected to Arduino Pro Micro hacked around to work like keyboard, was great because it allowed to use gamepad in places where it isn’t available normally – eg. for DOSBOX games. I lost that functionality in handheld v2 unfortunately. While DOSBOX has nice mapper for assigning joysticks/gamepads buttons to keyboard keys, it’s not working properly with my FlyDigiWee – all buttons, except arrows, are reported as one. Too bad. I’ve tried to register gamepad as keyboard+mouse using Xboxdrv driver, but it hasn’t worked in DOSBOX and Stratagus as well. Maybe there will be something better in future.

What does the future hold?

Project is cool and I’m already using it a lot, but it’s a bit too heavy to my liking. It’s caused by powerbank which is the first thing I’d like to replace (maybe aside of “speakers”) – when they’ll create something lighter with more capacity and outage. Other than that, I’m satisfied. I may change Pi 2 to another module in the future, but probably not to Pi 3 – its power is not that great and its needs are much higher.

Let’s play!

DIY: Raspberry Pi-based Retro Game Console

I got Raspberry Pi 2B for last Chrismas and decided I’d like to make a handheld. I didn’t have nearly any experiencence in making electronics, soldering, etc. before.


There are many similar projects like that in the web, so first I’ve decided to set my requirements (ease of use, RetroPie support, analog stick, and 5″ LCD screen) and found one great project at Adafruit… Which I later “disobeyed” many times – to support RPI2B (tutorial is made for RPI1) and mostly to use another parts – order from Adafruit store to Poland is unfortunatelly not reasonable in costs, so I’ve gathered my parts from stores in place… or Aliexpress. Mostly that.

I’ve decided to use same screen and screen controller board that Adafruit used (fortunatelly got both easily) to make sure it’s going to fit into 3D-printed enclosure (which was Adafruit one with bigger holes). It didn’t fit RPI2B easily, but good enough.

Biggest change was to not use SNES Controller board – I’ve changed it to external Arduino Pro Micro – which gave me built-in pull-up support and also was very nice to code.

I’ve used powerbank as battery.

Some cable soup, some broken analog-digital-converters (before I’ve switched to Arduino) and handheld gaming console is ready!

Triple monitor fun

I’ve finished another of my PC plans and upgraded to triple monitors. It was a big change for me – in the first few moments I wasn’t even sure if I’m going to get used to it, but soon I’ve started to love it. Much more (separated – and that’s good!) space for windows/terminals which I use a lot and a fantastic new way of more immersive gaming. It’s also much more appealing in terms of aesthetics. FYI I was using 2 24″ monitors before.

Obviously, my configuration couldn’t be standard, so let’s talk about quirks & tweaks.

I’m using 3 monitors with both Arch Linux host (GeForce 9800 GTX+) and Windows 7 gaming VM (GeForce GTX 960). To achieve comfortable change between those, I use HDMI switches placed under desk. Works great so far.

Monitors are mounted on a triple monitor stand. It was very difficult to find a good one. I was thinking about buying popular Ergotech one, but decided to try and buy less expensive (especially with shipping to Poland) and fairly new one from Duronic. I’m very happy with it in general, but it’s sturdy and hard to line up and level monitors perfectly, yet I’m almost there.

My 9800 GTX+ has only two outputs so to get all 3 screens working I need to use one output built-in onto motherboard GPU. Nvidia does all the rendering, Intel’s output is used only as transport route. I’ve needed to switch to Nouveau as it doesn’t work for me at all on Nvidia binary driver.

Script to turn on 3 monitors:

xrandr --setprovideroutputsource 1 0
xrandr --auto
xrandr --output HDMI3 --right-of DVI-I-1
xrandr --output DVI-I-2 --left-of DVI-I-1

I also utilize 3 monitors on Gaming VM – it’s working very well after enabling Surround in Nvidia GPU options. So far I’ve tested Witcher 3, Fallout New Vegas, Torchlight etc. and it’s marvelous!

There is also one non-trival advantage when using one system for 3-monitor-spanned gaming and another one for 3-monitor-no-spanned working. Switching between Surround/Eyefinity (spanning) would shuffle windows & icons when changed – doesn’t happen here.

Overall, it was new big thing for me and I’m very happy to have it. I’m definitely not crazy about ultra-wide monitors – these are too small for workplace (about size of 2 monitors) and would be very inefficient because of lack of angle if bigger, I hate the idea of curved ones, so there is really nothing better on market for me.

OQVEes5DaN-rMefsqEaIQg98eFXStf4zqTBouIhJArM=w1874-h928-noEdit: I forgot to add info about monitors used. So, there’s one BenQ G2450 in middle and BenQ GL2450 on sides (LED lighting). G2450 wasn’t accessible when I was ordering side monitors, so they have slightly different contrast/color, but are close enought to be good. These are nice for gaming (low/close to none input lag) and are *matte* which is omg-so big deal.

KVM/QEMU Gaming Machine

I’m using Linux as my main OS for some time now and I’m almost perfectly happy about it. Why almost? Because I’m a gamer and I don’t like compromises. So even if I totally support Linux-gaming revolution which Steam/Valve brought I won’t quit playing games which I’d like to play just because they don’t have Linux version. I was WINE using a lot, but it still didn’t support a lot of my games.

For some time I dual-booted with Windows. It was very irritating, because it forced me to close all my opened software, wait to shutdown first OS, wait to boot my computer and then start second OS… It was so irritating that when I bought notebook capable of ‘so-so’ running games, I connected it to the second input of my main monitor and played games like Diablo 3 on it (running Synergy for comfort).

That, of course, wasn’t best solution – two machines running instead of one and also my laptop’s GPU is way worse then my desktop one (no surprise). However I haven’t figured out better way until I found some info about VGA Passthrough.

That magic solution was my remaining piece – with help of KVM and Qemu, it allows to create virtual machine with its own, fully accessible graphic card. Passing CPU power and memory wasn’t problem for VMs for years but for PCI devices such as GPU it’s kinda revolution.

How does it work exactly? I’ve got two graphic cards, but I’m not using SLI neither Crossfire – my Arch Linux (primary OS) only sees GeForce 9800 GTX+ card and it’s using it exclusively. Second GPU – AMD Radeon 4850 in my case – is visible only for virtual machine with Windows and is available only for it – which means it’s properly detected by AMD drivers without any performance drops which happens when GPU’s emulated.

I’ve not actually ran any benchmarks, because it works just great. When I installed Diablo 3 and it just flew on high settings, I knew that’s exactly the solution I was looking for. Some other games I tested, like Disciples 3 or Assassin’s Creed 3 (which is rather GPU-heavy) also run with no difference than on the Windows-only system.

Instalation wasn’t pretty and it forced me to compile kernel with custom patches for Linux, add few kernel parameters into GRUB, some script-fiddling and also I was fighting for while to use nvidia proprietary driver instead of open-source one. On the other hand, I used virt-manager tool to configure VM and it was very nice and easy to use. Just set-up how much CPU cores and memory I want to add, create file image for disk, few more click to passthrough some devices like mouse, keyboard, integrated sound and GPU obviously – then it’s ready.

Zrzut ekranu z 2014-11-22 23:47:28The only really painful thing about this technology is required hardware. It requires VT-x (or AMD-V on AMD processors) which are quite common CPU extensions, but also VT-D (or IOMMU), which are not. It’s easy to check which Intel chips have them (sad thing for powergamers – almost none with overlocking abilities), but it’s very hard to find motherboards which must also support both of them. It’s so risky business that people are making lists of working hardware.

I went with AsRock Z77 Extreme4 motherboard and Core i5 3550 CPU, which both were confirmed few times to work with VGA Passthrough and I can say that it was very good decision. They aren’t so pricey, yet I like them both very much already. :) I gave 2 of 4 cores and 3 of my 8 GiBs RAM to VM, but I’m going to buy another 4 GiBs and give it exclusively for VM(s). I’m also going to change Radeon 4850 for some more powerful, eyefinity-capable GPU in next year. I’ll also setup “Lintendo” gaming VM (propably with SteamOS) so I don’t need to change both GPUs. ;)

What can I say more? I highly suggest all Linux-loving gamers to take a look at this technology and build it for yourself if you’re tech-savy enough – it took me about 1,5 days to set this up, but a lot of work was done thanks to excellent creators of guides which I link below.

Guides and other helpful links:

PCI passthrough via OVMF [Arch]

KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9 [Arch]

{Guide} Create a Gaming Virtual Machine [Fedora]

HOW-TO make dual-boot obsolete using XEN VGA passthrough [Linux Mint]

Network adapter configuration for KVM / Xen on Arch

VT-D How-To [Xen Wiki]

VFIO tips and tricks [excellent blog – start with their FAQ]

Some tips from me:

  • There’s big “battle” between Xen and KVM/Qemu – I was going to start with Xen, but it lost compatibility with Nvidia blob driver some time ago.
  • Don’t give up when Radeon GPU is passed through and it gives “Code 43” error with Microsoft’s default drivers – just install AMD one and you’re set! Lost some hours when trying to fix non-existing issue.
  • It’s rather obvious to me now, but it’s needed to use DKMS on self-compiled kernels for Nvidia driver.
  • Virt-manager has good VNC viewer built-in which is helpful especially when you’re configuring input devices.
  • Synergy’s great for optimising number of input devices in that setup, but it had some weird behaviour when cursor was passed from Linux host to Windows guest – now I passthrough USB mouse and KB, then I run Synergy server on virtual machine to control Linux on other then center monitors.
    Just use “relative mouse movement” and “lock cursor to screen” in Synergy, works excellent.

Wingamelauncher, czyli skrypty wspierające automatyczne uruchamianie gier Windows spod Linuksa

Pomiń gadaninę i przejdź do konkretów

Tak się złożyło, że kontynuuję temat zmian “systemowych” (poprzednio przechodziłem na niewspieranego przez Xperię X10 Android 4 ICS) – po raz kolejny w życiu próbuję przenieść cały swój “ekosystem” pod Linuksa.

Zawsze dużo korzystałem z Linuksów, a w ostatnim czasie stan ten osiągnął apogeum. Systemy uniksowe mają sensowną organizację, szybki i sprawny rozwój, wspaniałego basha i tuziny innych rozwiązań (repozytoria, żeby wspomnieć najbardziej bolesny chyba brak), które mnie zdecydowanie przekonują. Doszło do tego, że do większości operacji typu kopie zapasowe, synchronizacja danych, zacząłem pisać skrypty bashowe, uruchamiane w Cygwinie (upraszczając, jest to warstwa tłumacząca polecenia linuksowe na Windows).

Co kilka lat próbowałem przenosić swój ekosystem na Linuksa, ale koniec końców zawsze miałem jakiś krytyczny problem z obsługą swojego sprzętu i mówiłem sobie “kiedyś” – w końcu to “kiedyś” nadeszło.

Zawsze coś…

Nie chcę się skupiać na wszystkich narzędziach, z których korzystam – na to jeszcze będzie czas, próbuję dostosować jakieś IDE pod siebie, przenieść swoje prototypy gier na silniki OpenGL-owe, generalnie jest jeszcze za wcześnie.

Skoncentruję się za to na nieoczywistym rozwiązaniu, które sobie wprowadziłem – tytułowym zestawie skryptów do szybkiego przełączania się pod Windows i automatycznego uruchamiania gier wideo, klikając tylko na skrót w Linuksie.

Dlaczego w ogóle mam taką potrzebę? Nigdy nie jest idealnie – w PC mam kartę graficzną ATI Radeon HD 4850, która po przejęciu przez AMD jest niezbyt wspierana przez producenta, przez co sterowniki działają, powiedzmy, tak sobie – nie mogę grać poprzez WINE z wydajnością, która by mnie satysfakcjonowała.


Oczywistym jest więc, że przełączam się na Windows w celu rozrywki growej.

Uważam za skrajnie niewygodne konieczność opuszczenia systemu, następnie odczekania kilku minut na możliwość ledwo zalogowania się do Windows, odczekania kolejnej chwili na załadowanie się podstawowych usług, żeby w końcu móc włączyć – ręcznie – wybrany tytuł.

Moje rozwiązanie na pewno nie jest idealne, ale sprawia, że włączenie gry spod Linuksa to wybranie skrótu i odczekanie chwili, po której odpowiednia gra jest uruchomiona i czeka na użytkownika.

Część 1 – Rozbieranie Windows

Niezbędna jest pewna konfiguracja Windowsa – na moim PC stacjonuje Windows 8 z Classic Shell, który pomija ekran startowy.

1. Wyłączyłem konieczność logowania w Windows – niestety jest to niezbędne, aby rozwiązanie było wygodne.

* Wciskamy Win+R, żeby uruchomić menu uruchamiania, wpisujemy “control userpasswords2”;
* W wyświetlonym oknie odznaczamy opcję “Users must enter a user name and password to use this computer” (mam angielskiego windowsa, opcja po polsku opisana będzie podobnie do “użytkownicy musza podać nazwę użytkownika i hasła, by używać tego komputera”).

2. Utworzyłem plik skryptowy wingamelauncher.bat (treść na razie nie jest istotna, może być pusty), utworzyłem do niego skrót i umieściłem go w windowsowym autostarcie.

3. Utworzyłem w tej samej lokalizacji, co wingamelauncher.bat, drugi skrypt – “recreatewgl.bat” o takiej treści:

DEL H:\wingamelauncher.bat
ECHO start calc.exe>H:\wingamelauncher.bat

Oczywiście ścieżkę trzeba zmodyfikować pod swoją lokalizację. Skrypt ten będzie uruchamiany po włączeniu gry, modyfikując wingamelauncher.bat aby nie włączyła się automatycznie ponownie. Zamiast niej będzie odpalony kalkulator – takie tymczasowe rozwiązanie.

Część 2 – Ubieranie Linuksa

1. Tutaj było znacznie więcej zabawy. Zacząłem od zerknięcia do GRUBa, którym wpisem jest u mnie Windows, a którym Linuks – standardowo będzie to wpis trzeci i pierwszy.

Numery te trzeba podać w kolejności od zera – więc 2 i 0.

2. Edytowałem (jako root) plik /etc/default/grub, żeby ustalić zapisywanie ostatniej ładowanej pozycji – by móc je modyfikować z poziomu skryptów.

sudo gedit /etc/default/grub

Zakomentowałem linijkę:


I dodałem inną:


3. Uwaga, to nie jest ładne rozwiązanie – edytowałem pętle GRUBa 2, aby przywracać domyślne ustawienie po wybraniu innej opcji. Jeśli nie przeszkadza Ci fakt, że po uruchomieniu skryptu domyślnie będzie wybierany Windows, możesz tego rozwiązania nie stosować.

To rozwiązanie ma sporą wadę, dlatego, że będzie kasowane przez system przy każdej aktualizacji GRUBa – jeśli opracuję inną metodę, to oczywiście polecę.

Otworzyłem plik /boot/grub/grub.cfg:

sudo gedit /boot/grub/grub.cfg

Znalazłem wpisy dla moich systemów (rozpoczynają się od “menuentry”):

menuentry 'Linux Mint 14 Cinnamon 64-bit, 3.5.0-17-generic (/dev/sda8)' --class linuxmint --class gnu-linux --class gnu --class os {
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos8 --hint-efi=hd0,msdos8 --hint-baremetal=ahci0,msdos8 e3df731f-6c30-4b10-8088-e7d0311c4102
search --no-floppy --fs-uuid --set=root e3df731f-6c30-4b10-8088-e7d0311c4102
linux /boot/vmlinuz-3.5.0-17-generic root=UUID=e3df731f-6c30-4b10-8088-e7d0311c4102 ro quiet splash $vt_handoff
initrd /boot/initrd.img-3.5.0-17-generic


Dodałem polecenie “savedefault 0“, które sprawiło, że po wybraniu pozycji, ustawienie będzie zresetowane i następnym razem w GRUBie zostanie wybrana automatycznie pierwsza opcja (z indeksem 0).

menuentry 'Linux Mint 14 Cinnamon 64-bit, 3.5.0-17-generic (/dev/sda8)' --class linuxmint --class gnu-linux --class gnu --class os {
savedefault 0
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos8 --hint-efi=hd0,msdos8 --hint-baremetal=ahci0,msdos8 e3df731f-6c30-4b10-8088-e7d0311c4102
search --no-floppy --fs-uuid --set=root e3df731f-6c30-4b10-8088-e7d0311c4102
linux /boot/vmlinuz-3.5.0-17-generic root=UUID=e3df731f-6c30-4b10-8088-e7d0311c4102 ro quiet splash $vt_handoff
initrd /boot/initrd.img-3.5.0-17-generic


Analogiczną zmianę wykonałem dla wpisu Windows – powinien znajdować się jeden-dwa bloki niżej.

4. Edytowałem uprawnienia dla uruchamianie komend w pliku /etc/sudoers, żeby skrypty mogły uruchamiać się bez zapytania o hasło administratora:

sudo gedit /etc/sudoers

Na końcu pliku, przed komendą “#includedir /etc/sudoers.d”, dodałem następujące wiersze:

draiser ALL=(ALL)NOPASSWD:/usr/bin/wingamelauncher
draiser ALL=(ALL)NOPASSWD:/home/draiser/Skrypty/
draiser ALL=(ALL)NOPASSWD:/usr/sbin/grub-reboot
draiser ALL = NOPASSWD: /sbin/shutdown
draiser ALL=NOPASSWD: /usr/sbin/s2disk

Gdzie “draiser” to nazwa mojego użytkownika (można podać też “ALL” jako zamiennik dla wszystkich użytkowników), a skrypty podane po “NOPASSWD:” to moje lokalizacje skryptu, który zaraz będę prezentował, dodatkowo także odnośniki do systemowych funkcji rebootu ze zmianą kolejności w GRUB, wyłączania systemu i hibernacji.

5*. Krok opcjonalny – s2disk, czyli hibernacja przed ponownym uruchamianiem

Początkowo napisałem skrypt tak, aby po prostu restartował system, ale oczywiście zdecydowanie wygodniej jest, kiedy zapisuje stan pamięci na dysku, a następnie, już po ponownym włączeniu Linuksa, powraca do niego.

Do tego rozwiązania potrzebna jest partycja SWAP o rozmiarze zbliżonym do ilości pamięci RAM w PC, a także pakiet uswsusp, który instalujemy metodą:

sudo apt-get install uswsusp

Jest on konfigurowany po instalacji (wystarczy podać mu lokalizację partycji swap w formacie /dev/sdXY, np /dev/sda1) i następnie nadaje się do użytku.

6. Napisałem następnie właściwy skrypt, który miał za zadanie utworzyć plik wingamelauncher.bat (usuwając poprzednio istniejący) dla Windowsa, wybrać pozycję w GRUBie na Windows i wreszcie zrestartować system – albo korzystając z hibernacji (patrzy krok 5), albo standardowo.

#wingamelauncher - sh linux part
#by dRaiser
if [ -f /mnt/Multimedia/wingamelauncher.bat ]
rm /mnt/Multimedia/wingamelauncher.bat
echo "\"$1\"\r\nrecreatewgl.bat" > /mnt/Multimedia/wingamelauncher.bat
sudo grub-reboot 2
#sudo shutdown -r now
sudo s2disk -P 'shutdown method = reboot'

Potrzebne są w nim 3 modyfikacje – czyli podanie właściwej lokalizacji pliku wingamelauncher.bat z punktu widzenia Linuksa – u mnie to punkt montowania “/mnt/Multimedia”, a następnie, w zależności od wybranej metody rebootu:

1) Dla hibernacji przed rebootem, z użyciem pakietu uswsusp, pozostawienie bez zmian;
2) Dla rozwiązania bez hibernacji – usunięcie albo zakomentowanie znakiem “#” linijki “sudo s2disk(…)”, za to odkomentowanie (usunięcie znaku “#”) linijki “sudo shutdown -r now”.

7. Następnie umieściłem link symboliczny do skryptu w katalogu /usr/bin, żeby był wygodnie uruchamiany z dowolnego miejsca w systemie:

sudo ln -s /home/draiser/Skrypty/ /usr/bin/wingamelauncher

Gdzie “/home/draiser/Skrypty/” to oczywiście fizyczna lokalizacja zapisanego skryptu.

8. Pozostał w zasadzie tylko ostatni krok, tj. utworzenie aktywatora (skrótu) do uruchamiania konkretnej gry. W każdym środowisku graficznym tworzenie launchera wygląda podobnie, pozwolę sobie więc podać wyłącznie schemat polecenia aktywatora:

wingamelauncher "H:\Program Files\Diablo III\Diablo III\Diablo III.exe"

Gdzie ścieżka podana jako parametr polecenia to fizyczna lokalizacja pliku uruchomieniowego gry – widoczna dla Windows.

Na koniec

Jeśli wszystko poszło poprawnie, to uruchomienie skryptu powinno bezproblemowo zamknąć (albo zahibernować) Linuksa, wybrać w GRUB automatycznie Windows, uruchomić go, zalogować się, włączyć launcher Diablo 3. Słowem – wystarczy wyklikać skrót i zrobić sobie kilkuminutową przerwę, a następnie można już siekać bestie. :)

Niegłupim pomysłem jest odchudzenie Windowsa, żeby uruchamiał się możliwie najszybciej, powyłączanie zbędnych usług, et cetera.

Rozwiązanie powinno działać zarówno pod GRUB, jak i GRUB2; systemami debianopochodnymi, jak i resztą.

Zdaję sobie sprawę, że pewnie całą sprawę można rozwiązać lepiej/prościej – pisałem w bashu zawsze “przy okazji” i dopiero zaczynam bawić się weń na poważniej, ale nie znalazłem gotowego rozwiązania dla tego problemu – może komuś, poza mną, się ono przyda. Oczywiście można w ten sposób uruchomić cokolwiek, nie tylko gry. ;)

Grafika pochodzi z artykułu Blizzard sprawdzi się na Linuksie w 2013.

SteamBox – pomoże rynkowi gier?

O ile SteamBoksa sam raczej nie kupię, to uważam, że mógłby bardzo poprawić sytuację na rynku gier. Wszyscy producenci, którzy nie chcą produkować gier na PC z powodu ogromu konfiguracji, dostaliby jedną, łatwą do programowania platformę. A gracze pecetowi dostaliby dużo portów, które by się odpalało bez większych problemów na równie mocnych/lepszych konfiguracjach od SB.

Gabe Newell (Valve) o SteamBox

Post-pudełkowa nisza

Wraz z rozwojem rynku – w tym przypadku gier komputerowych – zdarza się, że tworzą się ciekawe i niekoniecznie zrozumiałe, na pierwszy rzut oka, nisze.

Gry komputerowe wyewoluowały i w przeciwieństwie do innych dóbr kultury, bezproblemowo rozwijają się na przestrzeni cyfrowej – jak należałoby tego oczekiwać od produktów, które są plikami wymagającymi komputera do zaprezentowania siebie.

Sprzedaż gier dystrybuowanych online na Steam, PSN, Xbox Live niesamowicie rośnie (tak samo na mniejszych serwisach, typu Green Man Gaming,, czy rodzimym, a co za tym idzie, procent ludzi kupujących gry fizyczne, w pudełkach, stopniowo maleje.

Pomimo to, na świecie, a zwłaszcza w Polsce, gracze mają sentyment do pięknych, nawet droższych wydań w kartonowym pudełku, które dumnie stoją na półce – fizyczne gadżety łechcą i wcale nie chcemy się ich pozbywać.

Nie mówię nawet o edycjach kolekcjonerskich, które nieodmiennie robią wrażenie i budzą podziw jakością wykonania.

W obliczu galopujących ofert promocyjnych w serwisach cyfrowych, przecen sięgających 90%-100%, nawet najbardziej nieprzekonani do cyfrowej dystrybucji gracze kupują swoje wyczekiwane tytuły… po czym dokupują do nich pudełka.

Brzmi egzotycznie? Jak najbardziej, może się to wydawać na pierwszy rzut oka przynajmniej dziwne, ale najlepiej swoje przywiązanie udowadniają ludzie, którzy zaczęli kupować puste pudełka po grach w serwisach aukcyjnych (pozostające np. ze sprzedaży samych kluczy rejestracyjnych). Ceny nie są wygórowane, na Allegro takie pudełka są wystawiane zazwyczaj poniżej 10 PLN. Sam już dwa razy skorzystałem z takiej oferty w przypadku świetnych tytułów z pakietem Steamworks (a więc uzależnionych od tej usługi), które kupiłem na „wyprzedaży”, aby następnie dokupić pudełka na półkę.

Powstała więc nisza. Teraz pytanie – jak szybko zacznie ona być wypełniana bardziej oficjalnie, niż na Allegro?

Sklepy (Ultima, nie mogą sobie pozwolić na sprzedawanie oddzielnych pudełek, nawet jeśli wyprzedają klucze – pytanie, czy coś się zacznie z tym dziać, należy więc do dystrybutorów. O ile GoGowi byłoby ciężko wysyłać pudełka całemu światu, to lokalny mógłby zaatakować.

Fascynaci będą usatysfakcjonowani, dystrybutorzy dostaliby dodatkowe źródła zarobku, rynek cyfrowy mógłby w ten sposób nawet przyspieszyć ekspansję.

Gry Infinity (Baldur’s Gate, Torment, Icewind Dale) na Windows 8

Windows 8 to bardzo dobry system – zwłaszcza, że dzięki promocji bardzo tani, a przy wykorzystaniu takich pożytecznych programów jak Classic Shell, czy Ribbon Disabler – oferujący więcej niż Win7, a także dzięki optymalizacji i dobrym rozwiązaniom (nowy Menedżer Zadań czy system kopiowania), sprawniejszy od poprzednika.

Jest też bardzo porządnym systemem do gier, niestety przez zmiany w obsłudze DirectDraw pojawiają się problemy z wydajnością z niektórymi starszymi tytułami, takimi jak gry na silniku Infinity (Baldur’s Gate, Planescape: Torment, Icewind Dale, etc.).

Szczęśliwie tym problemom da się łatwo zaradzić – wystarczy zmienić jedno ustawienie systemowe za pomocą programu DirectX Control Panel, który znajduje się w… DirectX SDK (żeby nie ściągać dużej paczki, mały mirror z samym programem). Mianowicie – należy odznaczyć opcję “Use Hardware Acceleration” w zakładce “DirectDraw”.

I już – śmiga!

(Uwaga – z kolei dla niektórych tytułów owa opcja musi być zaznaczona dla płynnego działania. Nie jest to więc bardzo wygodne rozwiązanie, bo trzeba o tym pamiętać, tym niemniej, długi sesje w staroszkolne cRPGi nie są bardzo utrudnione). ;-)


Diablo III będzie wymagać authenticatora – jak się z tym uporać BEZ Androida/iPhone’a?

Od premiery najnowszego hitu Blizzarda, Diablo III, deweloper (czy raczej dostawca usługi, patrząc na formę gry) nie może się odpędzić od problemów. A to pady, to przepełnienia serwerów, aż wreszcie – włamania na konta i kradzieże przedmiotów.

W związku z tym ostatnim problemem, Blizzard nie może sobie pozwolić na kolejne masowe włamy przy uruchamianiu Walutowego Domu Aukcyjnego (zakładam, że każdy wie, o czym mowa, ale jeśli nie – dom aukcyjny wewnątrz gry, pozwalający na zakup/sprzedaż przedmiotów, wkrótce także za prawdziwe pieniądze, a nie tylko growe sztabki złota).

W związku z tym, zgodnie z ostatnią aktualizacją polityki bezpieczeństwa battle.netu, już wkrótce jakiekolwiek operacje powiązane z płatnościami prawdziwą walutą, będą wymagały pełnego zabezpieczenia konta (czyli także D3), tj. podpięcia authenticatora.

Istnieją dwa rodzaje authenticatorów – jeden, fizyczny, który z oczywistych powodów trochę kosztuje; jak i drugi – mobilny – dostępny na smartfony (tj. telefony z systemem operacyjnym Android/iOS/BlackBerry/Windows Phone), a także parę starszych modeli telefonów.

Konieczność dodania nowego rodzaju zabezpieczenia jest dla co poniektórych problemem nie do przeskoczenia, czytam nawet sporo głosów, jak to Blizz naciąga na kolejne złotówki biednych Polaków. ;-)

Owym to graczom, nie posiadającym/nie chcącym posiadać ani smartfona, ani sprzętowego authenticatora, dedykuję niniejszy wpis – i dla Was jest rozwiązanie.

Dzięki otwartości paru przyjemnych platform, możliwe stało się napisanie swoistego “emulatora” androidowej aplikacji, dzięki czemu możliwe jest przypięcie “mobilnego” zabezpieczenia odpalonego na Windowsie. Wystarczy skorzystać z open-source’owej aplikacji WinAuth, hostowanej na GoogleCode – i podpiąć ją na battle.necie jako mobilny authenticator.

Program jest na tyle inteligentny, że przy pierwszym uruchomieniu sam proponuje i tworzy odpowiednie zabezpieczenie i pomaga w procesie dodania go do konta B.Net. Po dodaniu zaś, prezentuje w przyjazny sposób 30-sekundowe kody, które należy podać przy logowaniu się do gry/panelu zarządzania kontem – w 100% wygodnie, dzięki możliwości skopiowania kodu, jest nawet wygodniejszy od mobilnego, bo nie trzeba niczego przepisywać.

Gorąco polecam – to działa. :) Przestrzegam jedynie przed dwoma sprawami:

1) Trzymajmy na komputerze zainstalowany antywirus z odpowiednią ochroną przeciw spyware, aby przypadkiem jakiś keylogger nie przechwycił tego, co mamy w schowku;

2) Aplikacja jest open-source, dzięki czemu możemy sami sprawdzić jej kod i upewnić się, że na żadne bot-komputery nie wysyła wrażliwych danych. Jednakże to samo sprawia, że każdy mógłby zmodyfikować jej zawartość i przerobić na sprytnego wykradacza kodów; Dlatego też ściągajcie go wyłącznie z Google Code, a nie z żadnych pomocnych serwisów hostingowych, tak na wszelki wypadek.