Przeciwnicy
Każda gra wymaga jakichś przeciwników, których nasz bohater musi unikać, poruszając się po świecie. Jak w tradycyjnych platformówkach dodałem przeciwników, którzy chodzą w przód i w tył po platformach. Idea jest taka, że bohater ma ich unikać, przeskakując ich w odpowiednich momentach.
Obrazek przedstawia pierwszych 6 spośród 12 klatek animacji jednego z przeciwników. Różowe tło (255, 0, 255) jest zakodowane w FPGA jako przezroczysty kolor – jakikolwiek piksel narysowany wcześniej w tym punkcie pozostanie widoczny.
W grze wykorzystałem klasę Actor, aby zrealizować przemieszczenie postaci wzdłuż ciągu ścieżek. Ruch postaci jest wygładzany za pomocą funkcji wygładzającej. Mam do wyboru funkcje, które przyspieszają i hamują ruch z różną prędkością, a także wywołują ruch oscylacyjny.
Te funkcje matematyczne są umieszczone w przestrzeni nazw stm32plus fx. Aby zapewnić ich działanie w rozsądnym czasie (16,2 ms odstępu między ramkami), potrzebna jest jednostka zmiennoprzecinkowa (FPU) wbudowana w mikrokontroler F4. Mnożenie i dodawanie liczb zmiennoprzecinkowych przechowywanych w wewnętrznych rejestrach zabiera jeden cykl zegara, podobnie jak zamiana z liczby zmiennoprzecinkowej na całkowitą i na odwrót. Oczywiście animacje nie są przeznaczone tylko dla przeciwników. Każda prawdziwa platformówka zawiera mnóstwo obiektów, takich jak windy i statyczne, lecz animowane dekoracje, na przykład oświetlenie. Zaimplementowałem kilka z nich, aby pokazać, jak można to zrobić.
W mojej implementacji demo animuję cały świat, ale nie dodałem bohatera, którym można byłoby sterować. Stworzenie logiki gry, która obejmowałaby podstawową fizykę i wykrywanie kolizji zajęłoby więcej czasu, niż mam do dyspozycji. Zapewniłem jedynie możliwość przewijania świata za pomocą poleceń góra / dół / lewo / prawo przy użyciu podłączonych przycisków lub joysticka.
Logika tego dema obejmuje aktualizację pozycji w świecie, animację bitmap i przesłanie tych danych do FPGA. To wszystko musi się zmieścić w maksymalnym limicie 32 ms, z czego zmienną część stanowi bezpieczne okno na wgranie nowych bitmap do FPGA. W trybie debug cała logika dema (bez optymalizacji) wykonuje się w ciągu 1 ms. To bardzo krótko i pozostawia dużo czasu na dodanie dodatkowej logiki obsługującej głównego bohatera gry. Wykorzystanie zasobów mikrokontrolera widać poniżej (opcja optymalizacji -Os).
text data bss dec hex filename
86500 2128 1116 89744 15e90 manic_knights.elf
Czas na wideo
Wgrałem krótki filmik demonstrujący działanie gry. Najlepiej jest obejrzeć go w wysokiej jakości na Youtube.
Integralność sygnałowa
Integralność sygnałowa zawsze stanowiła problem w przypadku dwuwarstwowej płytki, która zawiera nie tylko złożony i wymagający układ FPGA, ale też zaawansowany mikrokontroler Cortex-M4. Zbadałem niektóre sygnały pod oscyloskopem, aby zobaczyć, jak bardzo są w rzeczywistości zniekształcone. Poniżej widać sygnał na wyjściu oscylatora 40 MHz po zaprogramowaniu FPGA i uruchomieniu gry:
Nie jest to zły sygnał jak na oscylator. Widać pewne tętnienia na dole i na górze, ale są one zbyt słabe, aby powodować problemy – nie zauważyłem żadnych zaburzeń.
Teraz przyjrzyjmy się sygnałowi WR płynącemu od mikrokontrolera do FPGA. Mój oscyloskop jest wystarczająco szybki, aby odtworzyć szczegóły tego sygnału:
Tutaj widać nieco inną sytuację. W dolnej części sygnału jest przestrzał, który przekracza poziom masy. Widać również dzwonienie za narastającym zboczem. Nie są to jednak tak poważne problemy, aby spowodować błędne wykrycie zbocza.
Projekt pracował całkowicie poprawnie podczas okresu, w którym go uruchamiałem. Sądzę jednak, że to zasługa dużego marginesu bezpieczeństwa między poziomami logicznymi w standardzie LVCMOS 3,3 V. Gdyby projekt miał pracować przy coraz popularniejszych napięciach 2,5 lub 1,8 V, ten margines bezpieczeństwa spadłby do wartości, która już nie chroni przed wystąpieniem zaburzeń.
Bardzo przydatną funkcją dostępną w nowszych układach FPGA firmy Xilinx jest impedancja kontrolowana cyfrowo (DCI). Pozwala ona automatycznie załączyć rezystancję terminującą dopasowaną do podłączonej ścieżki. Z pewnością skorzystałbym z tej funkcji, gdyby była dostępna w używanym przeze mnie modelu.
Wnioski
W takim dużym projekcie, jak ten, zawsze pozostaje miejsce na poprawki. Mimo to podczas testów płytka okazała się działać niezawodnie przy zasilaniu z zewnętrznego źródła napięcia od 4,6 do 5 V. Poniżej przedstawiam pomysły na udoskonalenie całego systemu.
- Odprowadzanie ciepła wokół zasilacza AMS1117 w obudowie SOT-223 zasilanego napięciem 3,3 V nie jest wystarczające. Powinienem zwiększyć rozmiar pola, do którego jest przylutowana powierzchnia odprowadzająca ciepło, a także zdublować to pole po drugiej stronie płytki, łącząc oba siecią przelotek.
- Brakuje obsługi audio. Było to celowe założenie w pierwszej części projektu. Skoro wiem już, że projekt działa, mógłbym dodać kilka przetworników cyfrowo-analogowych i wzmacniacz słuchawkowy, aby zapewnić obsługę audio.
- Integralność sygnałowa. To zawsze jest problem w przypadku płytki dwuwarstwowej. Z pewnością można by wprowadzić pewne zmiany w projekcie płytki, aby zoptymalizować ścieżki prądu powrotnego i poprawić integralność sygnałową. Planuję publikację oddzielnego artykułu, w którym przedstawię swoje odkrycia dotyczące kształtu i jakości sygnałów w różnych miejscach płytki.
- Mikrokontroler STM32F429 okazał się zbyt mocny (zgodnie z przewidywaniami), a stanowi najdroższy element na płytce. Podejrzewam, że dobrym wyborem byłby model F401 taktowany zegarem 84 MHz, który zachowuje ważny układ peryferyjny SDIO i jednostkę zmiennoprzecinkową. Pracuje wystarczająco szybko, aby obsłużyć logikę gry i jednocześnie jest o połowę tańszy od F429.
Słowo końcowe
Aby zrealizować kompletny, sensownie działający projekt, poświęciłem miesiące, pracując wieczorami i w weekendy. Jednak projekt okazał się sukcesem i uważam, że był wart tego wysiłku.
Kody źródłowe dla mikrokontrolera/FPGA są dostępne na Githubie. Natomiast na mojej stronie downloads można pobrać też pliki gerbera dla samej płytki PCB.
Andy Brown
