sobota, 12 września 2020

Stawiamy serwer Unreal (OldUnreal 227i/j patch) na linuksie

Słowem wstępu

Gra wydana w 1998 roku z silnikiem obecnie rozwijanym przez społeczność portalu oldunreal.com.

Opiszę tutaj procedurę dla sytuacji gdy serwer znajduje się na maszynie do której nie macie fizycznego dostępu czyli logujecie się przez ssh i w taki sposób wszystkim zarządzacie.

Wymagania podstawowe

Przede wszystkim musimy mieć grę, i tutaj możemy mieć albo wersję Gold albo zwykłą - tj. bez dodatku Return to Na Pali. Jeśli macie golda będzie łatwiej bo wersja w której wyszedł Gold od razu nadaje się do nałożenia łatki ze strony oldunreal.com. Jeśli macie wersję bazową będziecie musieli nałożyć kilka łatek zanim łatka na 227i pozwoli się zainstalować.

Obecnie oficjalnie dostępnym patchem jest 227i - a co za tym idzie musicie upewnić się, że macie zainstalowane paczki pozwalające uruchamiać programy skompilowane dla architektury x86 bowiem tylko pod tą architekturę są skompilowane pliki wykonywalne w tej wersji. Jako osoba zaznajomiona z Unrealową społecznością korzystam z łatki 227j v47, która ma już binarki dla systemów 64-bitowych. Także gdy będziecie mieli publiczny dostęp do wersji 227j nie będzie trzeba się już o to martwić.

Zaczynamy stawiać serwer

Przyjmę, że pliki gry/serwera są już na maszynie na której będziecie wszystko budować. W katalogu z grą i podkatalogu System(lub System64 dla wersji 227j i dalszych) macie plik UCCLinux.bin, któremu musimy nadać prawa wykonywania:

chmod +x System/UCCLinux.bin

Ten plik pozwala nam na uruchomienie serwera, natomiast całkiem fajnie zrobić sobie prosty skrypt w bashu, który od ponownie uruchomi serwer w przypadku awarii. Skorzystamy tutaj z tego co mówi nam wiki OldUnreal. Ja tworzę go w głównym katalogu gry i zapisuję jako prosty skrypt basha:

#!/bin/sh

until ./System/UCCLinux.bin server DMDeck16?Game=Unrealshare.Deathmatchgame; do
        echo "Server 'UCCLinux.bin' crashed with exit code $?. Respawning.." >&2
        sleep 1
   done

I nadajemy mu prawa wykonywania za pomocą:

chmod +x nazwa_waszego_skryptu

 Teraz zadbajmy aby nasz serwer mógł być widoczny z poziomu gry, w tym celu musimy zaktualizować odniesienia do masterserwerów gry. Szukamy analogicznych wpisów do tych poniżej w pliku System/UnrealLinux.ini i je aktualizujemy:

ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.oldunreal.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.hlkclan.net MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.333networks.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.hypercoop.tk MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.newbiesplayground.net MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.errorist.tk MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.qtracker.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master2.oldunreal.com MasterServerPort=27900

Dla systemów linuksowych należy jeszcze włączyć UpLink serwera, ten sam plik:

[IpServer.UdpServerUplink]
DoUplink=True

I teraz drobne niedociągnięcie ze strony developerów(a raczej, dewelopera - no niestety), otóż plik konfiguracyjny UnrealLinux.ini nie posiada wszystkich wpisów, które posiada Unreal.ini. I tak oto, aby nadać nazwę naszemu serwerowi i poprawnie wyświetlać MOTD musimy przekopiować z Unreal.ini do UnrealLinux.ini(może być na końcu pliku) następujące linijki:

[Engine.GameReplicationInfo]
Region=0
ServerName=                       
ShortName=Unreal Server
AdminName=
AdminEmail=
MOTDLine1=
MOTDLine2=
MOTDLine3=
MOTDLine4=
ShowMOTD=False

I uzupełnić wedle własnych upodobań. Jeszcze należy oczywiście ustalić hasło administratora coby wszyscy nie mogli się bezkarnie panoszyć:

[Engine.GameInfo]
AdminPassword=twoje_haslo_adminstratora

Polecam jeszcze przypisać sobie klawisz do wywołujący menu administracyjne. Szukacie pliku System/User.ini (ew. System64/User.ini) i dokonujecie odpowiednich zmian, ja przypisalem np. do klawisza F8:

F8=UShowAdminMenu

Ostatnia rzecz na wstępie - dla własnej wygody warto zbindować sobie łączenie się z własnym serwerem z uprawnieniami administratora. Ja podpiąłem to pod klawisz F10:

F10=open adres_ip_waszego_serwera?password=wasze_haslo_administratora

Jako ze wersja 227 jest ciagle rozwijana na swoim serwerze odpuscilem sobie Enchanced DeathMatch(w skrócie EDM) jako, że ostatnia wersja jest dość stara; natomiast nad oficjalną wersją gry ciągle się pracuje. Podobnie ma się sprawa z anty-cheatem.

Ważne dodatki - mutatory

Tutaj jest panie i panowie sajgon jak diabli :/. No niestety, jeśli nie siedzicie w społeczności Unreala 1 będziecie mieć nie lada problemy ze znalezieniem pasujących paczek. A to nie ma nowszej wersji ogólnie dostępnej, a to jest na jakiejś stronie którą znają głównie ludzie ze społczności czy też plik README do mutatora ma literówkę przez co nie będzie poprawnie wywoływany. Ale, po kolei.

UMapVote(raczej słabe rozwiązanie, polecam przejść sekcję niżej, do EDM)

Bardzo istotny dodatek, odpowiadający za możliwość głosowania na mapy i tryby gry dostępne na serwerze. Należy go samemu skonfigurować a pliki mutatora - podobnie jak w przypadku każdego innego mutatora wrzucamy do katalogu System(lub System64). Oto mój konfig(plik UMamVote.ini) jakby ktoś miał problemy ze składnią:

[UMapVoteServer.VotingHandler]
MinVoters=1
RequiredMapsBeEnable=0
VotingTime=40
MapChangePrc=0.750000
MidGamePrc=0.510000
bBeginEndGameVotingOnEndGame=False)
bBeginEndGameVotingOnEndGame=False)
bBeginEndGameVotingOnEndGame=False
bAutoMaps=False
bDisplayVoteItem=True
Maps=(MapName="DmDeck16",GameIndex=-1)
Maps=(MapName="DmCurse",GameIndex=-1)
Maps=(MapName="DmDeathFan",GameIndex=-1)
Maps=(MapName="DmElsinore",GameIndex=-1)
Maps=(MapName="DmFith",GameIndex=-1)
Maps=(MapName="DmHealPod",GameIndex=-1)
Maps=(MapName="DmMorbias",GameIndex=-1)
Maps=(MapName="DmTundra",GameIndex=-1)
GameModes=(GameName="Vanilla|DeathMatch",ShortGameName="V_DeathMatch",GamePrefix="DM",GameTypeClass="UnrealShare.DeathMatchGame",Mutators="",AddedCmdLine="",Packages="",bKeepInventory=False)
GameModes=(GameName="Relics|DeathMatch",ShortGameName="R_DeathMatch",GamePrefix="DM",GameTypeClass="UnrealShare.DeathMatchGame",Mutators="Relics.RelicMutator2",AddedCmdLine="",Packages="",bKeepInventory=False)
GameModes=(GameName="Instagib|DeathMatch",ShortGameName="IGIB_DeathMatch",GamePrefix="DM",GameTypeClass="UnrealShare.DeathMatchGame",Mutators="UTWeapons.Instagib",AddedCmdLine="",Packages="",bKeepInventory=False)
GameModes=(GameName="LowGravity.Instagib|DeathMatch",ShortGameName="LG.IGIB_DeathMatch",GamePrefix="DM",GameTypeClass="UnrealShare.DeathMatchGame",Mutators="UTWeapons.Instagib,LowGrav.LowGrav",AddedCmdLine="",Packages="",bKeepInventory=False)

Teraz tak, jeśli stawiać będziecie server na wersji 227j koniecznie popytajcie o najnowszą wersję, gdyż w moim przypadku wersje 1.4 i 1.6 rozwalały interfejs gry; a raczej - czyniły go niefunkcjonalnym. Odsyłam też do pliku tekstowego dołączonego do mutatora, żebyście wiedzieli co wpisać w pliku UnrealLinux.ini jako ServerActors oraz Serverpackages. Pamiętajcie też aby wywołać mutator w poleceniu którym uruchamiacie sam server, jako że będzie on niezależny od wybranego trybu gry - pisze o wszystkim w pliku tesktowym dołączonym do mutatora.

Zasada jest generalnie taka, że każdy mutator z którego planujecie korzystać na serwerze dodajecie do ServerPackages. Tj. jeśli ma on plik np. zdzisiek1.u to dorzucacie ServerPackages=zdzisiek1 w odpowiedznim miejscu.

Przykładowo moja sekcja odpowiadająca za te wpisy z tego samego serwera z którego pochodzi plik UMapVote.ini:

[Engine.GameEngine]
CacheSizeMegs=8
UseSound=True
bServerSaveInventory=False
ServerActors=IpDrv.UdpBeacon
ServerActors=IpServer.UdpServerQuery
ServerActors=UBrowser.UBrowserUplink
;ServerActors=UWebAdmin.WebAdminManager
; Oldstyle way. If you dislike auto updates, then simply comment ServerActors=UBrowser.UBrowserUplink and uncomment below.
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.oldunreal.com MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.hlkclan.net MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master2.oldunreal.com MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.hypercoop.tk MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.newbiesplayground.net MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.errorist.tk MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.noccer.de MasterServerPort=27900
;ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.qtracker.com MasterServerPort=27900
ServerPackages=Female1skins
ServerPackages=Female2skins
ServerPackages=Male1skins
ServerPackages=Male2skins
ServerPackages=Male3skins
ServerPackages=SkTrooperskins
ServerPackages=UnrealIntegrity
ServerPackages=UMapVote
ServerPackages=UTWeapons
ServerPackages=Relics

Podałem wam w zasadzie tylko mutator do głosowania bo nie jestem, w stanie przewidzieć co będziecie chcieli konkretnie mieć na waszych serwerach - ten natomiast był moim pierwszym wyborem - który ujdzie, ale zdecydowanie bardziej polecam EDM - omówiony później.

Aha, jakbyście szukali mutatora do trybu InstaGib - jest częścią paczki UTWeapons albo w EDM(zdecydowanie polecam to drugie rozwiązanie).

Optymalizacja serwera aby zmniejszyć lagi

Ponownie odnosimy się do pliku UnrealLinux.ini, z tym że interesuje nas sekcja:

[IpDrv.TcpNetDriver]

W niej natomiast pozycje MaxClientRate i NetServerMaxTickRate. Z tego co udało mi się dowiedzieć to klan DOG, za którym osobiście nie przepadam - używa takich wartości tych zmiennych:
 
MaxClientRate=100000
NetServerMaxTickRate=65
 
Przy czym weźcie pod uwagę, że zależą one od mocy maszyny i połączenia sieciowego z serwerem - także testujcie różne wartości drogą prób i błędów. Doradzam też zmienić szybkość w konfiguracji klienta na LAN - proste ale to najbardziej popularna porada jaka krąży po sieci - i chyba faktycznie działa.

EDM - Enchanced DeathMatch - dla mnie najlepszy mutator do votingu i wszystkiego na początek


Przed napisaniem tej części miałem już sprawdzone UMapVote, które jest bardzo średnie natomiast na początek daje radę, fajna jest też możliwość stworzenia sobie "własnych gamemodów" łącząc okreśłony tryb z wybranymi przez nas mutatorami. Później sprawdziłem UTeamFix, jeśli mnie pamięć nie myli - wersję 10H. Niby ok, ale jak dla mnie manual jest napisany tak czytelnie jak groch z kapustą. Jeśli jednak to wybierzecie(a jeśli stawiacie serwer na tryby Cooperative czy drużynowe może to nie być taki zły pomysł) zajrzyjcie sobie do pliku UTeamFix.int - od razu domyślicie się do jakiej sekcji w pliku UnrealLinux.ini co wpisywać - ja zanim tam zajrzałem długo nie wiedziałem gdzie np. ustawić hasło administratora - a moim skromnym zdaniem manual ma nas w tym przypadku w dupie.

Później przyszedł czas na EDM - i tu, dla mnie - stawiającego serwer DeathMatch'owy; pojawiło się autentyczne wytchnienie. Od pobrania paczki z EDM do uruchomienia bazowo skonfigurowanego pod niego serwera minęła niecała godzina. Dzięki przejrzystemu manualowi czułem się tak konfortowo, że praktycznie wszystkich zmian dokonałem jednym rzutem - później tylko start, test; wszystko działa - ok.

No ale po kolei. Instalacja jest prosta. Pobieracie sobie najnowszą wersję, tzn. z 2009 roku - witajcie w świecie retro - z tego miejsca. Interesuje was "Enhanced Deathmatch 6.0 (July 15th, 2009)". Powinniście otrzymać plik EDM6_PUBLIC-7-15-09.zip. U mnie poszła podstawa i dodatkowe mutator tj. z katalogu "Necessart Files" wszystko z "System" leci do "System64"(lub System), a z "Textures" do "Textures"(wow). Z "Extra Files" wszystko z "Mutators" też do "System64".

Rozpakowujecie też sobie ten plik u siebie na dysku i czytacie manual - krótki i czytelny. Na start serwera jako tryb gry wywołujecie "EDM6_Client.EnhancedDM".

Wszystko w zasadzie macie w manualu. Ale po krótce - mapki na które idzie głosować wpisujecie sobie do "EDMMAPS.ini", a główną konfigurację mutatora macie w "EnhancedDM.ini" - tam też macie odpowiednio sekcje do wpisania mutatorów, które będą zawsze ładowane z serwerem oraz te, na które mogą głosować gracze.

Dodatek, kolorowanie nazwy naszego serwera

Najlepiej poszukajcie sobie programiku UT2K4 Message Colourizer, ustawcie sobie wszystko co chcecie, tzn. nazwę waszego serwera z dopisanymi kolorami w odpowiednich miejscach i wklejcie jako nazwę serwera w pliku UnrealLinux.ini.

Osobiście jednak odradzam tego typu zabawy; sam skończyłem z plikiem którego ani notatnik(xed) ani Libre Office Writer nie mogło ruszyć - poradził sobie z tym natomiast jak podejrzewałem notatnik dostarczany z WINE(dodając spację po każdym znaku, ale chociaż treść została). Dla mnie natomiast dużo ważniejsza jest możliwość edycji konfiguracji na serwerze z poziomu terminala - nie polecam.

Zakończenie

Podziękowania dla Smirftsch, Dots, x21-(DOG)- oraz strategy-(DOG)-, ISV-GamesHarder, którzy niezwykle pomogli mi w znalezieniu potrzebnych plików oraz służyli wiedzą gdy jej potrzebowałem.

czwartek, 3 września 2020

JoeQuake jednak natywnie na linuksie? Nareszcie - wersja 0.16.2(rev.6567)

Po zasięgnięciu języka na discordzie i kontakcie z deweloperami JoeQuake, okazało się, że możliwe jest skompilowanie silnika na systemach linuksowych. Oto prosta instrukcja co należy zrobić. Dodam, że sprawdzone na systemie Linux Mint 20, coby jakieś odniesienie było o jakich czasach w ogóle mowa.

Zależności

Po pierwsze, zależności. Jeśli o mnie chodzi o to co musiałem doinstalować aby pomyślnie skompilować źródła:

sudo apt install gcc-multilib libjpeg9-dev:i386 libxxf86dga-dev:i386 libxxf86vm-dev:i386 libgl-dev:i386 libpng-dev:i386 libsdl2-dev:i386

Na logikę, jeśli ktoś wam skompiluje binarkę, aby ją uruchomić musicie zainstalować:

sudo apt install libjpeg9:i386 libxxf86dga1:i386 libxxf86vm1:i386 libgl1:i386 libpng16-16:i386 libsdl2:i386

W przypadku mojej dystrybucji paczka libjpeg9-dev:i386 wymagała usunięcia libjpeg-turbo8-dev:amd64 jako, że oba pakiety dostarczały ten sam plik.

Pobranie źródeł

Zródła pobieracie stąd:

https://github.com/kugelrund/JoeQuake/archive/linux.zip

Co da wam plik JoeQuake-linux.zip

Kompilacja źródeł

Możecie sobie to puścić nawet jako skrypt, uruchamiany w katalogu z plikiem https://github.com/kugelrund/JoeQuake/archive/linux.zip:

#!/bin/sh

unzip JoeQuake-linux.zip -d JOELINUX
cd JOELINUX/JoeQuake-linux
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make

Plik wykonywalny znajdował się będzie w katalogu:

JOELINUX/JoeQuake-linux/build/trunk/joequake-gl

I w sumie tyle, macie łatwo bo Sphere już dodał́ niedawno obsługę pulseaudio, ja 4 dni szukałem rozwiązania jak silnik wspierał jeszcze dźwięk z OSS - uwierzcie, nic nie działało. Teraz jest gitara, wszystko gra.

Wchodzimy w świat Quake 1 w 2020 roku. Czyli - jak zacząć?

Zacznijmy od tego, że podobnie jak w przypadku wielu leciwych gier tak samo w przypadku Quake'a 1 wydanego w 1996 roku podejście do samej gry uległo znacznej zmianie po 24 latach. Mam tutaj na myśli sposoby uruchamiania gry oraz społeczność i wyznaczone przez nią standardy zarówno w przypadku rozgrywki sieciowej, jak i single-player.

Na wstępie należy zaznaczyć, że chociaż Q1 ma silnik z otwartym kodem źródłowym, a co z tym idzie dostępnych jest wiele jego interpretacji i portów tutaj nie wystarczy, że wybierzemy ten najbardziej nam odpowiadający i posłuży on nam do wszystkiego. Trochę lipa, ale tak już jest. W skrócie powiem tak:

  • Quakespasm - do grania single-player w czystego Quake'a albo do prymitywnego grania w sieci(tj. bez wyszukiwarki serwerów czy po sieci LAN)
  • EzQuake - współczesne granie sieciowe bazujące na kulturze Quake World
  • Joe/NeaQuake - speedrunning

Ważne jest tutaj to, że JoeQuake oraz NeaQuake posiadają fizykę oryginału, natomiast Quakespasm oraz EzQuake ją modufikują.

Quakespasm

Tutaj sytuacja jest prosta, instalujemy z repo i mamy spokój. W moim przypadku na Linux Mint 20 wystarczy:

sudo apt install quakespasm

Po czym jak już mamy silnik tworzymy sobie katalog, wrzucamy do niego chociażby plik katalog id1 z wersji shareware lub pełnej gry. Silnik uruchamiamy poleceniem:

quakespasm -basedir ścieżka_do_tego_folderu/z_katalogiem_id1

EzQuake(przygotowanie silnika gry)

Tutaj są dwie szkoły, pierwsza to pobranie binarnej wersji pod linuksa ze strony projektu. Przy czym w moim przypadku wiązało się to z większym bólem głowy gdyż miałem problemy z bibliotekami.

Najpierw system skarżył się na brak pliku libpng12.so.0 co rozwiązujemy czysto instalując np. ten pakiet w zależności od posiadanej architektury:

Instalujemy standardowo tj. np.:

sudo dpkg -i libpng12-0_1.2.54-1ubuntu1.1_i386.deb

Kolejny problem jaki mi wyskoczył wyglądał następująco:

./ezquake-linux-x86_64: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./ezquake-linux-x86_64)

Po kilku nieudanych próbach rozwiązania problemu dałem spokój i postanowiłem samodzielnie skompilować ten silnik gdyż na logikę wszystko co było potrzebne już miałem w systemie. Wystarczyły do tego trzy polecenia:

git clone https://github.com/ezQuake/ezquake-source.git

cd ezquake-source 

sh build-linux.sh

I teraz tak, co dokładnie robi linux-build.sh? Sprawdza naszą dystrybucie, instaluje niezbędne pakiety potrzebne do zbudowania silnika i kompiluje go pomijając make install - więc spokojnie. Prawa roota są mu potrzebne tylko do zainstalowania niezbędnych zależności. Szkoda, że standardowo nie pokazuje co instaluje ale końcem końców silnik jest zbudowany.

Pisząc to zauważyłem, że autorzy logi z budowania(więc może i informacje o instalowanych pakietach)  piszą do:

/tmp/ezquake-build.log

Także jakbyście byli ciekawi zajrzyjcie tam w razie wątpliwości.

EzQuake(zdobycie plików niezbędnych do grania w sieci)

I tu jest prosto, nie musimy nawet mieć Quake'a. Wystarczy że wejdziemy na stronę nquake - tam pobieramy paczkę dla linuksa o nazwie nquake_installer-linux-latest.tar.gz, wypakowywujemy i uruchamiamy plik install_nquake.sh. Installer zapyta nas gdzie chcemy mieć nquake - domyślnie ~/.nquake przy czym pojawi się również folder ~/nquake. Opcje przy instalacji mogą być domyślne, są zupełnie ok.

Pozostaje tylko przekopiować poprzednio przez nas skompilowany plik binarny silnika ezquake(w moim przypadku ezquake-linux-x86_64,  do ~/nquake; uruchomić - i grać.

Joe/NeaQuake(droga porażek)

I tutaj właśnie, speedrunning. Jeśli ktoś chciałby np. wziąć udział w speedrunowaniu E1M1 albo całej gry musicie zaopatrzyć się w jeden z tych silników - przy czym NeaQuake to po prostu drobna modyfikacja JoeQuake. Najpopularniejszy jest JoeQuake, natomiast paczka binarna niestety jest dość stara i  wywala mi te same błędy przy próbie uruchomienia jak w przypadku gotowej binarki EzQuake.

I tak gwoli wyjaśnienia, oczywiście, że możecie sobie speedrunować na Quakespasm czy EzQuake ale nikt tych waszych dokonań pod uwagę w poważnych rankingach nie weźmie gdyż oba silniki mają zmienioną fizykę w stosunku do oryginału o czym już wspomniałem. Jak powiedział mi jeden użytkownik discorda:

(...)noone stops you from playing on those engines ofc, but you wont be able to submit to the leaderboards

Ja poległem przy próbie kompilacji tych silników ale trochę informacji dla Was mam, jeśli chcecie szaleć z JoeQuake, źródła pobieracie tym poleceniem:

git clone https://github.com/j0zzz/JoeQuake.git

Natomiast w przypadku NeaQuake tym:

git clone https://github.com/crashfort/NEAQUAKE.git

NeaQuake ma taką przewagę, że ma od razu linuksowy makefile, do którego odwołujecie się wydając to polecenie w katalogu ze źródłami:

make -f Makefile.linux

Z tego co patrzyłem program próbuje skompilować się pod i386 i tam odpuściłem bo aż tak mi nie zależy, po skomentowaniu linijek odpowiedzialnych za architekturę - gdy już miało lecieć pod x86_64 wywaliło mi taki błąd:

cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: ‘-fcf-protection=full’ is not supported for this target
make: *** [Makefile.linux:102: release_glx/cd_linux.o] Error 1

I tutaj ponownie z pomocą przychodzi ekipa speedrunowania Q1 z discorda. Otóż tutaj znajdziecie różne poprawki do budowania na linuksach:

https://github.com/kugelrund/JoeQuake/tree/linux

Ale podobno i tak silnik będzie działał bez dźwięku, i średnio sprawnie. Dlatego ja uznałem biorąc pod uwagę wszystkie problemy, że po prostu nie warto. Ale jeśli chcecie, droga wolna.

JoeQuake(droga zwycięstwa)

No tak, ale podszedłem do sprawy od drugiej strony - tj. wersji windowsowej silnika i wine 5.0. I tutaj wszystko działa, mniej więcej - otóż w wersji 0.16.2(build 6454) z którą dostarczana jest tylko wersja ze wsparciem dla akceleracji graficznej. I tutaj musimy emulować wirtualny pulpit z poziomu wine(inaczej silnik nie uruchomi się) oraz wykluczyć w opjach wine zarządzanie oknami i dekorowanie ich przy użyciu systemowego window managera(u mnie window manager MATE - podejrzewam, że Marco) - w przeciwnym razie myszka będzie centrowała do środka tj. nie będziecie za jej pomocą w stanie się np. obracać. 

I tutaj z pomocą przychodzi wersja 0.15(build 3798) - obie pobierzecie z oficjalnej strony projektu. Wersja z akceleracją również nie uruchamiała się na pełnym ekranie, toteż od razu ją odpuściłem. Natomiast wersja software'owa działa wspaniale, nie zapamiętuje tylko rozdzielczości i kilku poleceń. To i tak nadal dużo lepsze niż kompilowanie wersji linuksowej na siłę.

 ________

Na zakończenie dodam, że udało się w końcu po wielu próbach skompilować linuksową wersję JoeQuake, konkretnie 0.16.2(rev.6567) - dokładną instrukcję co konkretnie należy zrobić znajdziecie w tym poście.

Kompilacja Fluxbox 1.3.7 kompilatorem C++ 17 (GCC 11)

Po aktualizacji systemu jakiś czas temu okazało się, że posiadając nową wersję gcc w systemie nie byłem w stanie poprawnie skompilować Fluxb...