LinkedIn YouTube Facebook
Szukaj

Newsletter

Proszę czekać.

Dziękujemy za zgłoszenie!

Wstecz
SoM / SBC

[UPGRADE!] Pierwsze kroki z Raspberry Pi: RPi jako konsola do gier czyli Quake II i Quake III na platformie Raspberry

Następnie za pomocą narzędzia git pobieramy kod źródłowy silnika gry:

git clone https://github.com/raspberrypi/quake3.git
cd quake3

W celu uproszczenia etapu kompilacji do minimum, wraz z kodem źródłowym silnika udostępniony został skrypt build.sh realizujący cały proces konfiguracji i budowania plików wynikowych. Sam skrypt przystosowany jest do potrzeb cross-kompilacji, natomiast my przeprowadzimy kompilację natywną (bezpośrednio na zestawie Raspberry Pi). Z tego też powodu musimy dokonać niewielkiej modyfikacji skryptu. Linię 8 tego skryptu zastępujemy ciągiem:

ARM_LIBS=/opt/vc/lib

W linii 16:

INCLUDES="-I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads"

W ostatnim kroku usuwamy (lub komentujemy) linię 19:

#CROSS_COMPILE=bcm2708-

Po zapisaniu zmian w pliku build.sh, możemy już uruchomić kompilację:

./build.sh

Kompilacja silnika gry trwa około jedną godzinę. Możemy więc ten czas poświęcić na przygotowanie plików PK3. Czym są pliki PK3?

Jak wspomniałem silnik gry Quake III dostępny jest na licencji Open Source, nie oznacza to jednak, że gra Quake III Arena jest otwarta i darmowa. Do uruchomienia gry potrzebujemy jeszcze plików *.pk3, będące niczym innym jak zaszyfrowanym archiwum ZIP. Pliki PK3 zawierają opisy map, modeli, tekstur czy dźwięków dostępnych w grze, ich szyfrowanie ma natomiast uniemożliwić swobodną edycję modeli czy tekstur, a także tworzenie dodatkowych map. Jak możemy się łatwo domyślić, pliki PK3 nie są darmowe (nie potrzebowalibyśmy wówczas nic więcej by uruchomić pełną wersję gry). Do prezentacji możliwości wykorzystamy więc pliki *.pk3 dostępne w oficjalnej wersji demo (udostępniającej cztery w pełni grywalne mapy) – posiadacze pełnych wersji gry mogą wykorzystać własne pliki. Aby skrócić czas poszukiwań, wszystkie wymagane pliki pak0.pk3…pak8.pk3 zostały udostępnione jako „Załącznik 1„. Pobrane pliki umieszczamy w katalogu $HOME/quake3_src/quake3/build/release-linux-arm/baseq3 utworzonym po zakończeniu procesu kompilacji.

Jeżeli cały proces przebiegł poprawnie możemy już uruchomić grę i ucieszyć oko wysoką wydajnością rozgrywki (ok. 45 FPS):

cd $HOME/quake3_src/quake3/build/release-linux-arm
sudo ./ioquake3.arm

Efekt końcowy jest niesamowity, jak widać to na filmie

Gra Quake II

Cofnijmy się teraz w historii gier komputerowych i chronologii serii Quake niemal dokładnie o dwa lata, bo właśnie tyle czasu dzieli wydania drugiej i trzeciej części gier Quake. W tym podrozdziale zajmiemy się kompilacją i uruchomieniem Quake II na platformie Raspberry Pi, a ściślej ujmując jej portu Yamagi Quake 2 przystosowanego do wymagań API OpenGL ES. Projekt Yamagi Quake 2 wystartował w roku 2009 i jest wciąż rozwijany i udostępniany na wiele platform sprzętowych. Podobnie jak w poprzednim podrozdziale, dla Czytelników chcących pominąć etap kompilacji silnika gry, udostępniony został plik binarny wraz z niezbędnymi plikami do szybkiego uruchomienia gry. Warto jednak i tym razem poświęcić chwilę czasu na samodzielną kompilację…

 

 

Przykładowe widoki ekranu z grą QUAKE II na platformie Raspberry Pi

 

Pierwszym krokiem jest utworzenie nowego katalogu i pobranie źródeł z repozytorium GIT:

mkdir $HOME/quake2_src
cd $HOME/quake2_src
git clone https://github.com/reefab/yquake2.git

Tym razem nie musimy dokonywać żadnych zmian w skryptach budujących i możemy bezpośrednio wywołać polecenie make:

cd yquake2
make

Podobnie jak w poprzednim przypadku kompilacja źródeł jest dość czasochłonna. Po pomyślnym zakończeniu procesu, do katalogu $HOME/quake2_src/yquake/release/baseq2 kopiujemy plik pak0.pak oraz katalog players dostępne do pobrania jako „Załącznik 3„. Tym samym możemy już uruchomić właściwą rozgrywkę:

cd $HOME/quake2_src/yquake/release 
sudo ./quake2

Jak zapewne większość Czytelników doświadczalnie zauważy, jakość i wydajność rozgrywki Quake II jest nieporównywalnie niższa niż w serii III. Problemem jest tutaj sama optymalizacja silnika, jednak miejmy nadzieję, że dzięki wielu deweloperom/hobbystom sytuacja ta w najbliższym czasie ulegnie poprawie (wzrost wydajności możemy uzyskać poprzez wyłączenie dźwięku – najszybszym sposobem realizacji tego zadania jest przekopiowanie domyślnego pliku konfiguracyjnego yq2.cfg z folderu stuff do katalogu release/baseq2).

 

Łukasz Skalski - absolwent Politechniki Gdańskiej, miłośnik FLOSS, autor książki "Linux. Podstawy i aplikacje dla systemów embedded" oraz szeregu artykułów dotyczących programowania systemów wbudowanych. Zawodowo związany z firmą Samsung. Wszystkie wolne chwile poświęca projektowaniu i programowaniu urządzeń wyposażonych w mikroprocesory 8-/16- i 32-bitowe. Szczególnym zainteresowaniem obejmuje tematykę systemu Linux w aplikacjach na urządzenia embedded.