Kontroler do gier FPS 1. Wstęp 2. Koncepcja działania projektu

Kontroler do gier FPS
Adrian Chemicz
Wydział Inżynierii Mechanicznej i Informatyki
Kierunek informatyka, Rok III, Specjalność Programowanie Aplikacji Internetowych
Streszczenie
Tematem mojej pracy jest kontroler do gier typu FPS, który docelowo ma mieć postać kolimatora
do repliki broni. Celem tego kontrolera jest możliwie jak największe odwzorowanie ruchów gracza
na postać w grze. Urządzenie to wyświetla obraz na LCD od telefonu nokii pobrany z komputera,
który pracuje pod kontrolą systemu Windows.
1. Wstęp
Mój kontroler do gier został zbudowany z użyciem mikrokontrolera LPC1769 [1] z rdzeniem CortexM3. Kontroler ten do komunikacji z komputerem wykorzystuje wirtualny port com, który pracuje z
prędkością 6Mbaud/s. Urządzenie to wyświetla obraz na LCD od telefonu nokii pobrany z
komputera. Komputer użyty w projekcie korzysta z systemu Windows. Do detekcji ruchów gracza
zostały wykorzystane czujniki MEMS.
2. Koncepcja działania projektu
Kompletny projekt składa się z kontrolera i podestu. Kontroler w tym wszystkim jest najistotniejszy,
ponieważ właśnie to urządzenie odpowiada za komunikacje z komputerem. Zadaniem podestu jest
zbieranie informacji o ruchach nóg gracza i przekazywanie ich do kontrolera. Komunikacja między
kontrolerem a podestem odbywa się tylko w jednym kierunku(od podestu do urządzenia), a
korzysta z podczerwieni. Docelowo kontroler ma mieścić się w kolimatorze na replice.
Rys. 1: Elementy projektu.
3. Komunikacja między elementami systemu
Komunikacja między mikrokokontrolerem a komputerem korzysta z interfejsu RS485, który pracuje
z prędkością 6Mb/s. Do komunikacji z czujnikami MEMS(żyroskop i magnetometr) została
wykorzystana szyna I2C, która pracuje z częstotliwością 375 kHz. LCD od telefonu nokii jest
podpięty do szyny SPI i korzysta z maksymalnej częstotliwości 6MHz, która to jest podana w
dokumentacji do sterownika tego wyświetlacza (PCF8833) [2]. W projekcie została wykorzystana
także podczerwień, która wykorzystuje częstotliwość 36kHz, a do układu czujnik podczerwieni
TSOP31236 został podpięty do portu GPIO. Kontroler posiada także zwykłe przyciski podpięte
także do GPIO.
Rys. 2: Elementy kontrolera.
4. Wyświetlanie obrazu
Za wyświetlanie graczowi obrazu z gry komputerowej jest odpowiedzialny wyświetlacz od telefonu
nokii posiadający sterownik PCF8833 [2] lub podobny, dla którego maksymalna częstotliwość
pracy szyny danych SPI wynosi 6 MHz, co daje możliwość wyświetlania obrazu w przybliżeniu, w
30 klatkach na sekundę. Wyświetlacz użyty w projekcie posiada rozdzielczość 130x130 pikseli i
posiada dwunasto-bitową głębie kolorów. Szyna danych SPI dla tego wyświetlacza korzysta z
ramek składających się z 9 bitów. Taki format danych oznacza duże trudności, ponieważ nie
wszystkie układy mogą pracować z taką konfiguracją szyny SPI, a zazwyczaj dopuszczalna i
często jedyna długość ramki wynosi 8 bitów. W przypadku stosowania układu z takimi
ograniczeniami sposób obsługi wyświetlacza trzeba realizować w sposób programowy, co pociąga
za sobą straty w wydajności i komplikuje program. W przypadku układu użytego w projekcie takie
problemy nie występują, ponieważ SPI może pracować z ramką składającą się z od 4 do 16 bitów.
Dane wysyłane do wyświetlacza mogą być interpretowane jako dane lub komendy, a różnica
między nimi polega na stanie najstarszego bitu w ramce (jeśli jest ustawiony najstarszy bit oznacza
to dane). Format danych dla tego wyświetlacza w trybie 12 bitów na kolor przedstawia się
następująco: na każde dwa piksele przypadają trzy bajty (Rys. 3).
Rys. 3: Format danych dla sterownika PCF8833 w trybie 12 bitów na kolor. Puste kwadraty
oznaczają bity. Na tym rysunku zostały pominięte bity odpowiedzialne za tryb(komendy lub dane).
5. Czujniki MEMS
Za detekcje ruchów broni odpowiadają dwa czujniki: trzyosiowy żyroskop L3G4200D [6] firmy
STMicroelectronics i trzyosiowy magnetometr HMC5883L [5] firmy Honeywell. Żyroskop pobiera
wartość przyspieszenia kątowego z dwóch osi i przekazuje te wartości do PC, gdzie są one
zamieniane na ruchy myszki. Wartość przyspieszenia kątowego jest także wykorzystywana do
ustalania położenia kontrolera w przestrzeni. Wskutek niedoskonałości i wibracji żyroskopu
zachodzi konieczność korekcji pozycji kontrolera, do czego w projekcie wykorzystywany jest
magnetometr. Magnetometr jest używany do detekcji wartości maksymalnych pola magnetycznego
na poszczególnych osiach, co odpowiada możliwości detekcji czterech kierunków. Możliwości
magnetometru są znacznie większe, ale czujnik ten jest bardzo wrażliwy na zakłócenia
wywoływane przez linie zasilające i ferromagnetyki wskutek czego jakość pomiaru spada. W celu
polepszenia pomiarów należy możliwie jak najdalej odsunąć ten czujnik od źródeł zakłóceń.
6. Aplikacja po stronie Mikrokontrolera
Program na kontroler został napisany w asemblerze, ponieważ pierwotnie miał pracować na
jednym z najsłabszych układów, czyli na mikrokontrolerze LPC1111 z rdzeniem Cortex-M0, ale
wskutek komplikacji spowodowanych niewystarczającą częstotliwością taktowania peryferiów
zaszła konieczność przeniesienia projektu na inny, mocniejszy układ. Program składa się z części
inicjującej i pętli głównej. W części inicjującej są konfigurowane peryferia i czujniki, a w pętli
głównej dane z UART-u są przenoszone do LCD za pomocą SPI, lub w przypadku braku danych
dla wyświetlacza następuję odczyt danych z czujników w sposób nie blokujący.
7. Aplikacja po stronie PC
Kontroler od strony komputera jest widoczny jak zwykły port COM, ale w przeciwieństwie do
standardowego portu COM korzysta z niestandardowych wartości przesyłu danych, czyli 6
Mbaud/s. Do obsługi portu COM na komputerze zostało wykorzystane API dostępne w systemie
Windows [7] Aplikacja do obsługi tego urządzenia została napisana z wykorzystaniem
wielowątkowości jaką oferuje API systemu Windows, w celu uniknięcia blokad powstałych w
wyniku transmisji za pomocą portu COM. W programie wykorzystywane są dwa wątki. Wątek
pierwszy robi zrzuty ekranu, odbiera dane od urządzenia i aktualizuje tablice pikseli. Do zadań
wątku drugiego należy wysyłanie tablicy pikseli za pomocą portu COM w pętli, w której warunkiem
zakończenia jest ustawienie flagi końca. Dane otrzymane od urządzenia są zamieniane na
odpowiednie ruchy kursora w komputerze i zdarzenia od naciśniętych klawiszy klawiatury za
pomocą funkcji SendInput [8].
Rys. 4: Schemat blokowy algorytmu aplikacji po stronie komputera do obsługi urządzenia.
8. Transmisja danych z wykorzystaniem podczerwieni
W celu uniezależnienia elementu odpowiedzialnego za ruch repliki broni i ruch nóg gracza,
zastosowano transmisje z wykorzystaniem podczerwieni i pewien format ramki. Takie rozdzielenie
dwóch części projektu daje możliwość niezależnej rozbudowy dwóch elementów względem siebie,
a także tworzenie nowych modułów, które będą korzystały z wcześniej opracowanych rozwiązań.
Rolę odbiornika pełni czujnik TSOP31236 [4], a za wysyłanie odpowiada dioda podczerwona.
Format ramki użytej do transmisji z wykorzystaniem podczerwieni składa się z 8 bitów z czego na
dane jest przeznaczone tylko 6 bitów. Bity kodowane są przez zmianę stanu (bit zerowy – zmiana
z stanu niskiego na wysoki), co daje dodatkową opcje wykrywania błędów. Na każdy stan
przypada 16 błysków diody migającej z częstotliwością 36kHz, co stanowi optymalną wartość dla
czujnika podczerwieni.
Rys. 5: Ilustracja przykładowej ramki, w której pierwszy bit musi być równy 0, a ostatni równy 1.
9. Transmisja danych między PC a kontrolerem
Komunikacja między PC a kontrolerem odbywa się za pomocą interfejsu RS485, który pracuje z
prędkością 6Mbaud/s. W celu realizacji takich prędkości transmisji zastosowano w projekcie
konwerter FT232H, dla którego maksymalna prędkość wynosi 12Mbaud/s. Konwerter ten jest na
obecną chwilę najlepszym, dostępnym rozwiązaniem firmy FTDI. Komunikacja między
urządzeniami odbywa się z zastosowaniem full-duplexu, co oznacza konieczność zastosowania
czterech przewodów transmisyjnych. W kierunku kontrolera transmitowany jest obraz(bajt po
bajcie bez żadnych zabezpieczeń), a w kierunku PC specjalnie przygotowane ramki.
Rys.6: Format ramki wysyłanej do PC przez kontroler. W powyższej ramce pierwszy i ostatni bajt
są to wartości stałe, które umożliwiają dokonanie testu gdzie rozpoczyna się i kończy ramka. W tej
ramce są przetrzymywane dane odpowiedzialne za ruchy myszką i dane odpowiedzialne za ruch
postaci i atak.
10. Podsumowanie
Kontroler ten jest w pełni funkcjonalny, ale ma pewne braki które być może zostaną uzupełnione w
przyszłości. Wyświetlany obraz mimo niewielkiej rozdzielczości pozwala na w miarę płynną grę, a
ilość klatek jest na poziomie 23, co stanowi minimum do odczucia płynności obrazu. Do poprawy
komfortu grania brakuje akcelerometru, który dokonywałby dodatkowych korekt.
Literatura
[1] http://www.keil.com/dd/docs/datashts/philips/lpc17xx_um.pdf
[2]http://www.kamami.pl/dl/pcf8833_1.pdf
[3]http://www.kamami.pl/dl/kamodtft2.pdf
[4]http://www.vishay.com/docs/82492/tsop312.pdf
[5]http://www51.honeywell.com/aero/common/documents/myaerospacecatalogdocuments/Defense_Brochures-documents/HMC5883L_3-Axis_Digital_Compass_IC.pdf
[6]http://www.st.com/st-webui/static/active/en/resource/technical/document/datasheet/CD00265057.pdf
[7]http://msdn.microsoft.com/en-us/library/windows/desktop/aa363195%28v=vs.85%29.aspx
[8]http://msdn.microsoft.com/en-us/library/windows/desktop/aa363195%28v=vs.85%29.aspx