Szybka Grafika na Wyświetlaczach RGB

[deshipu]

Oprócz szerokiej gamy monochromatycznych wyświetlaczy OLED, e-ink i LCD, na rynku znaleźć też można wyświetlacze kolorowe, czy to LCD czy OLED, nierzadko nawet w postaci gotowych modułów. Ze względu na ilość danych, jakie do nich trzeba przesłać, wyświetlacze te zazwyczaj używają protokołu SPI z dodatkowym pinem (same wyświetlacze często obsługują także kilka trybów równoległych, ale nie widziałem jeszcze gotowego modułu, który by udostępniał odpowiednie wyprowadzenia). Dość często są one nawet wyposażone w panel dotykowy. Kusi zatem ich użycie w naszych projektach do wyświetlania interfejsu użytkownika.

Niestety, gdy tylko spróbujemy użyć jednej z gotowych bibliotek na Arduino, przekonamy się, że są one panicznie wolne. Odświeżenie ekranu potrafi nawet zająć kilka sekund — używanie takiego  interfejsu użytkownika to mordęga. Czy to zatem wina wyświetlacza? Ale jeśli podłączymy go do RaspberryPi i ustawimy odpowiedni sterownik w jądrze, to ten sam wyświetlacz działa relatywnie szybko — da się nawet na nim grać w gry komputerowe? Co jest zatem nie tak? Czy to wina samego Arduino?

Okazuje się, że częściowo winę ponosi dosyć wolne taktowanie SPI w Arduino, ale większym problemem jest sposób, w jaki te biblioteki wysyłają dane. Generalnie spotkać można dwa podejścia, oba dosyć wolne:

Bufor Ramki

Pierwszym podejściem jest użycie bufora — wielkości całego ekranu, lub, jeśli brakuje nam na to pamięci — części ekranu. Wszystkie operacje graficzne skutkują w zmianach w tym buforze — wobec czego są relatywnie szybkie. Na koniec, cały bufor jest wysyłany do wyświetlacza. Jeśli bufor zajmował tylko część ekranu, to wszystkie operacje graficzne są powtarzane dla poszczególnych fragmentów ekranu, aż cały ekran nie zostanie odświeżony. Podejście takie ma tą zaletę, że nawet jeśli wiele naszych operacji graficznych dotyka tych samych pikseli, to na koniec każdy z nich wysłany jest tylko raz — zatem nie "boli" tak bardzo na przykład rysowanie pogrubionego prostokąta przez narysowanie najpierw większego prostokąta, a potem mniejszego wewnątrz, w kolorze tła.

Poniższy rysunek ilustruje tą ideę:

Niestety podejście to ma dwie duże wady: po pierwsze, wymaga gigantycznych, jak na możliwości mikrokontrolerów, ilości pamięci RAM, a po drugie, niepotrzebnie wysyła co klatkę te wszystkie piksele, które się wcale nie zmieniły.

Ten drugi problem można rozwiązać przynajmniej częściowo, kosztem dodatkowej pamięci, zapamiętując po prostu które piksele się zmieniły i wysyłając do wyświetlacza obszar lub obszary które je zawierają. Najprościej jest to zrobić po prostu trzymając w pamięci listę tak zwanych "brudnych prostokątów" (dirty blocks). Jest tu niezłe pole do popisu dla miłośników algorytmów, bo te prostokąty można ze sobą scalać w jeden lub dzielić na kilka, optymalizując transfer. Niestety, większość dostępnych bibliotek nic takiego nie robi.

Bezpośrednie Rysowanie

Drugim popularnym podejściem jest wysyłanie do wyświetlacza piksela natychmiast gdy tylko jakaś operacja graficzna go modyfikuje. Niewątpliwą zaletą takiego podejścia jest znacznie mniejsze zapotrzebowanie na pamięć, a także fakt, że wynik takiej operacji jest widoczny od razu, bez konieczności odświeżania. Wadą jest to, że na każdy piksel przypada teraz 8-10 bajtów, zamiast 2, oraz to, że widać wykonywanie się każdej operacji graficznej, zatem jeśli się nakładają, to będzie widać migotanie.

Tryb Tekstowy

A może da się to zrobić inaczej? Być może moglibyśmy się nauczyć czegoś z tego, jak robiły to stare ośmiobitowe komputery? Albo nawet nie takie stare pecety. Otóż zamiast trzymać stan wszystkich pikseli w pamięci RAM, możemy zamiast tego mieć w pamięci ROM wszystkie kombinacje, jakie potrzebujemy, dla fragmentów ekranu, a w pamięci RAM tylko pamiętać który kawałek używa której kombinacji. To szczególnie dobrze sprawdza się do wyświetlania tekstu, gdy w pamięci ROM mamy wzory wszystkich znaków, a w RAM tylko informację o tym jaki znak i w jakim kolorze jest w danym miejscu.

Mamy wówczas tylko jedną operację graficzną, jaką jest zmiana pojedynczego znaku. Używamy wówczas małego bufora — takiej wielkości, w jakiej mają się nam na ekranie wyświetlać znaki — do którego kopiujemy z pamięci ROM grafikę nowego znaku, zmieniając odpowiednio kolory. Następnie wysyłamy ten bufor do wyświetlacza. W ten sposób mamy relatywnie mały narzut, zmienia się cały znak na raz i nie zużywamy dużo pamięci.

Oczywiście technikę tę można stosować nie tylko do tekstu. Nasze "znaki" mogą być tak naprawdę całymi fragmentami interfejsu użytkownika — ramkami, przyciskami, lampkami, etc. — trochę to przypomina interfejs Norton Commandera, ale przecież nasze kafelki mogą być większe i w wielu kolorach. Co więcej, możemy je łączyć z pozostałymi dwoma strategiami — na przykład mieć na ekranie miejsce, w którym piksel po pikselu będzie rysowany jakiś wykres, obszar, w którym wyświetlany będzie tekst (z małymi kafelkami) i resztę ekranu, gdzie wyświetlimy resztę interfejsu (z dużymi kolorowymi kafelkami). Tak długo, jak obszary nie będą się nakładać, wszystko będzie działać dobrze.

Sprite-y

No dobrze, ale co w przypadku gdy chcemy mieć jakieś płynnie przemieszczające się elementy, na przykład kursor myszy? Albo bohatera gry komputerowej? Okazuje się, że nadal możemy to zrobić dość wydajnie, jeśli tylko połączymy w jedną całość wszystkie dotychczas wspomniane pomysły:

Powyższa ilustracja pokazuje jak może wyglądać taki system. W pamięci ROM mamy grafiki dla naszych kafelków (na przykład części mapy) oraz duszków (postaci gracza, wrogów, pocisków, etc.). W pamięci RAM trzymamy mapę, która mówi jaki kafelek jest w danym miejscu ekranu, oraz obiekty reprezentujące duszki (zawierającą ich pozycję i wskaźnik do grafiki).

Mamy dwie możliwości operacji graficznych: zmiana zawartości kafelka, lub zmiana zawartości lub położenia duszka. W pierwszym przypadku, brudnym blokiem jest obszar zajmowany przez kafelek, w drugim — obszar zajmowany poprzednio przez duszka, połączony z obszarem zajmowanym przez jego nową pozycję.

W każdym z tych przypadków, tworzymy w pamięci bufor wielkości naszego brudnego prostokąta i wypełniamy go odpowiednią grafiką. Mamy tutaj dwie możliwości, które mogą działać lepiej lub gorzej w zależności od specyfiki systemu.

Albo rysujemy każdy z kafelków, których dotyka nasz brudny blok, a następnie na tym rysujemy każdego duszka, który ma choć jeden piksel w środku bloku (kolejność rysowania duszków jest istotna).

Albo iterujemy po pikselach naszego bufora sprawdzając najpierw wszystkie duszki a na końcu kafelek, aż nie znajdziemy elementu, który jest w tym miejscu widoczny. Wtedy sprawdzamy jaki kolor ma mieć ten piksel i przechodzimy dalej.

Pierwsze podejście sprawdza się przy pojedynczej warstwie kafelków i małej liczbie duszków. Drugie podejście jest lepsze kiedy mamy kilka warstw kafelków (z przezroczystością), albo na przykład duże kafelki i mały tekst, oraz większą liczbę duszków.

Jak szybko to działa? Zależy oczywiście od ilości zmian, ale jest to wystarczająco szybkie, aby pisać gry komputerowe w MicroPythonie:

Edytowano Styczeń 29, 2019 przez deshipu

[msalamon]

Znasz jakiś dobry przykład implementacji Sprite'a? Chodzi mi o kod źródłowy oczywiście

[Ogyb]

Szukałem, nie ma;-P W stm z użyciem DMA takie duszki mogłyby świetnie działać. Ogólnie biblioteki na arduino są napisane strasznie wolno, gdyż muszą poprawiać "programistę" oraz być bardzo uniwersalne. Np takie Adafruit GFX wyciąga abs() z uint_16t - co niby ma dac ta funkcja na takiej zmiennej?  Spodziewają się ujemnej wartości w uint? Dodatkowo nie używają funkcji wyświetlacza tylko liczą wszystko wewnętrznie, zmieniając co chwile pozycję kursora itd. 

Jest dużo modułów z 8 bitowa, oraz nawet 16 bitowa szyna. 4" ips wyświetlacze na ali np.

Edytowano Grudzień 1, 2019 przez Ogyb

[Zealota]

Dnia 29.01.2019 o 21:40, msalamon napisał:

Znasz jakiś dobry przykład implementacji Sprite'a? Chodzi mi o kod źródłowy oczywiście

Może to będzie odpowiednie:

 

 

[RFM]

Dnia 29.01.2019 o 12:42, deshipu napisał:

Okazuje się, że częściowo winę ponosi dosyć wolne taktowanie SPI w Arduino

Częściowe? Realna przepływność SPI przy taktowaniu 8MHz to ok 4MHz. W uC z wykorzystaniem DMA, nie ma problemu aby "wycisnąć" max możliwości SPI sterownika wyświetlacza, przeważnie 15MHz czyli prawie 4 razy szybciej niż na AVR.

 

Dnia 29.01.2019 o 12:42, deshipu napisał:

Pierwszym podejściem jest użycie bufora — wielkości całego ekranu, lub, jeśli brakuje nam na to pamięci — części ekranu. ...)

Niestety podejście to ma dwie duże wady: po pierwsze, wymaga gigantycznych, jak na możliwości mikrokontrolerów, ilości pamięci RAM

Mikrokontrolery z kilkuset kB RAM nie są rzadkością a i 1M jest osiągalny.

 

Dnia 29.01.2019 o 12:42, deshipu napisał:

Mamy dwie możliwości operacji graficznych: zmiana zawartości kafelka, lub zmiana zawartości lub położenia duszka. W pierwszym przypadku, brudnym blokiem jest obszar zajmowany przez kafelek, w drugim — obszar zajmowany poprzednio przez duszka, połączony z obszarem zajmowanym przez jego nową pozycję.

W każdym z tych przypadków, tworzymy w pamięci bufor wielkości naszego brudnego prostokąta i wypełniamy go odpowiednią grafiką. Mamy tutaj dwie możliwości, które mogą działać lepiej lub gorzej w zależności od specyfiki systemu.

Po co kombinować gdy można użyć sterownika FT8xx? Dla wyświetlaczy ze sterownikiem też jest rozwiązanie https://forum.elportal.pl/viewtopic.php?f=62&t=14998 gdzie bez problemu można obsłużyć duszki.

2 godziny temu, Zealota napisał:

Może to będzie odpowiednie:

W porównaniu do Adafruit rewelacja ale widać, że AVR ledwo dyszy (mała płynność animacji) i 100% mocy przeznacza na grafikę. Co z resztą zadań gdy 100% zużywa grafika?

Do tego co można osiągnąć na FT8xx daleka droga i nie oszukujmy się, AVR nie ma szansy aby zbliżyć się do rozwiązań z DMA i dużym buforem RAM. To jest nawet osiągalne dla Xmega ale cenowo wyjdzie pewnie 2 razy drożej niż ARM (w Xmega najczęściej wymagany zewnętrzny RAM).

[Ogyb]

Od ft8xx dużo taniej i sprawniej wyjdzie np jakiś stm32h7 czy coś podobnego (do kupienia za 30zł 1M RAM + akceleracja 2D i 400 MHz rdzenia + fpu). Xmega ma jakąś przewagę nad ARM? Cokolwiek? Ani to podobne w programowaniu do Atmega ani tanie... Przy wykorzystaniu paru % rdzenia można animować Chrom-ART daje nam mieszanie obrazów itd. DMA2D wysyła bufor, sprzętowe dekodowanie JPEG. 

[RFM]

5 minut temu, Ogyb napisał:

Od ft8xx dużo taniej i sprawniej wyjdzie np jakiś stm32h7 czy coś podobnego

Naturalnie ale w wątku jest mowa o Arduino co najczęściej jest rozumiane jak AVR. Nawet jak nie AVR to Arduino libs. Znasz biblioteki dla Arduino, które obsłużą DMA2D czy choćby DMA do transferu danych do sterownika wyświetlacza z wykorzystaniem FCM albo wbudowany sterownik wyświetlacza np w F429? Ja nie znam i nigdy o czymś takim nie słyszałem natomiast dla FT8xx EVE wygeneruje kod dla Arduino.

[BlackJack]

Największym bólem większości jeżeli nie wszystkich wyświetlaczy z interfejsem szeregowym, jest brak wyprowadzenia sygnału RF sterownika LCD, co uniemożliwia synchronizację zapisu do bufora, z "powrotem pionowym".
Tak czy siak pisanie gier, to swego rodzaju "sztuka oszukiwania", aby omijać pewne ograniczenia sprzętowe i programowe w sumie też.