Jak tworzona jest grafika w Commodore i innych maszynach 8-bit?

W komputerach i konsolach 8-bitowych, tak samo jak zresztą w każdym innym komputerze do generacji grafiki potrzebujemy generalnie trzech rzeczy – procesora, który zarządza całym tym procesem, pamięci ekranu, gdzie przechowywane są dane tego, co ma zostać wyświetlone, oraz układu graficznego, który zajmuje się samą dynamiczną generacją obrazu na podstawie danych z pamięci.

[CPU] — [GPU] <– [SRAM]
|
\———–[RAM]

Rzecz jasna, to co właśnie powiedziałem, jest nie do końca prawdą, gdyż większość sprzętów 8-bitowych miała na tyle mało pamięci, że nie ekonomicznym byłoby ograniczanie dostępu do części z niej tylko dla grafiki, stąd większość współ-wykorzystywała normalną pamięć komputera, zwalniając ją do innych celów, gdy była niewykorzystywana. Stąd często np. w c64 widać na ekranie artefakty w trakcie startu programu, który mieli sobie w tym momencie akurat w pamięci przeznaczonej do wyświetlania np. znaków w trybie tekstowym.

[CPU] — [GPU]-VIDEO
| / |\
\———–[RAM]

W taki właśnie sposób obraz generowany jest przez np. C64 i Nintendo… ale czasami się, że konsola nie miała osobnego układu do generacji obrazu, a wykorzystywała do tego procesor. Tak robi na przykład komputer ZX81, czy konsola Atari 2600. Należy jednak wziąć pod uwagę, że wówczas większa część czasu procesora przeznaczana jest właśnie do tego celu i niewiele zostaje jej na obsługę programów czy gier.

[CPU] -VIDEO
/|\
\———–[RAM[VRAM]]

Czasami sprzęt ma tak mało pamięci, że w ogóle nie stać go na przechowywanie w niej kopii wyświetlanego obrazu… Wspomniane wcześniej Atari 2600 ma zaledwie 128 bajtów RAM nie ma więc szans na to by móc w nich zmieścić cały generowany przez nią obraz. Atari generuje więc obraz nigdzie nie zapisując jego zawartości, ma natomiast wiedzę o pozycji kilku elementów na nim – takich jak gracz, pociski, itp. To jednak temat dość trudny i zdecydowanie wymagałby osobnego filmiku

[CPU] -VIDEO

Wróćmy więc do najczęstszego przypadku, w którym mamy współdzieloną z resztą komputera pamięć ekranu i osobny układ generujący na jej podstawie obraz.
Zastanówmy się ile potrzebujemy pamięci by przedstawić obraz typowy dla 8-bitowego sprzętu

NES – 2KB RAM (+dodatkowy w kartridżach)
ZX-81 – 1-56KB RAM
VIC-20 – 5-64 KB RAM
C64 – 64 KB RAM
C16 – 16 KB

Powiedzmy, że będzie to obraz wielkości 320×200 pikseli. Dla jednego koloru potrzebujemy 1 bitu pamięci, by móc zapisać w nim informacje, czy dany pixel jest zapalny czy zgaszony. 320x200x1 to 64 000 bitów, czyli 8 000 bajtów. Dla 16 kolorów wymagamy 4 bitów na pixel – bo, jak z prostej matematyki wynika na 4 bitach można zapisać liczby od 0 do 15, czyli 16 stanów – co daje nam już 256 000 bitów, czyli 32 KB pamięci.

To już naprawdę dużo, gdyż komputery i konsole z lat 80’ miały zazwyczaj na swoim pokładzie od 1 do 64 KB pamięci RAM.

Do zapisania grafiki w 256 kolorach potrzeba nam już 64KB, a standardowej nowoczesnej 24-bitowej, operującej 1,6 milionami kolorów) już 192KB.

Konstruktorzy sprzętu musieli więc pójść na pewne kompromisy i spróbować zmniejszyć ilość wymaganej pamięci, tak by jednocześnie nie ograniczyć za mocno możliwości wyświetlania miłego dla oka obrazu.

Przykładowo komputer Commodore 64 posiada paletę 16 kolorów i rozdzielczość 320×200 pixeli, teoretycznie pamięć ekranu powinna wynosić 32 KB. Jednak dla podstawowego trybu bitmapowego, zwanego też często trybem wysokiej rozdzielczości zużywane jest tylko 9 KB.

Jak to możliwe?

W przypadku Commodore 64 postanowiono ograniczyć liczbę możliwych kolorów, jakie mogą znajdować się na obrazie, w bardzo sprytny sposób.

Dostępny obraz został podzielony na komórki, każda z nich o wielkości 8×8 pixeli. W każdej z tych komórek można używać tylko 2 dwóch kolorów na raz. Jeden używany jest jako tło, drugi jako kolor zapalonego pixela. Tak tworzona jest siatka 40 na 25 komórek.

Odpowiada im dodatkowe 40×20, czyli 1000 bajtów pamięci., każdy z nich zawiera informację o wybranym kolorze dla tła i zapalonych pixelów. Każdy bajt podzielony bowiem jest na dwa – po 4 bity, tzw. półbajty, a każdy z nich zawiera numer koloru od 0 do 15 – odpowiadający jednemu z kolorów z palety barw Commodre 64.

Spoglądając na przykładowy obrazek stworzony dla tego trybu, aż trudno uwierzyć, że mamy takie ograniczenie. Sprawdzając jednak dokładnie – każdą komórkę obrazu – potwierdzimy, że zawsze użyte są w niej tylko dwa kolory.

Utalentowany grafik dobierając do sąsiadujących komórek podobne kolory, może sprawić tutaj cuda.

Bądźmy jednak szczerzy, dwa kolory w komórce to jednak dość duże ograniczenia, szczególnie w przypadku produkcji gier, gdzie nie ma czasu i możliwości na tak mozolne dobieranie grafiki, bo musi ona spełniać też funkcję użytkową – umożliwiać wygodne granie, a nie tylko ładnie wyglądać. Często ma się jednak wrażenie, że grafikom się po prostu nie chciało.

Commodore dało więc im jeszcze jedną możliwość – tryb multikolor, w którym liczba możliwych do użycia w komórce kolorów wzrasta do 4. Jak pamiętacie z początku filmiku – 4 kolory to 2 bity, a co za tym idzie teoretycznie do zapisu danych o obrazie potrzebujemy 16KB pamięci.

Troszkę dużo.

Co zrobiło więc commodore? Zmniejszyło rozdzielczość poziomą z 320 do 160 pixeli.

Straciliśmy troszkę rozdzielczości, ale za to zyskaliśmy dodatkowy bit potrzebny do określenia koloru.

Każdy pixel na ekranie jest teraz związany z parą bitów, która może przyjmować teraz cztery wartości 00, 01, 10 i 11.

01 i 10 – to kolory, których możemy używać – tak jak w trybie wysokiej rozdzielczości, znajdują się one w 1KB pamięci obrazu, tak jak wspominałem przed chwilą.

00 – to pierwszy dodatkowy kolor – kolor wspólnego tła, wybieramy jeden dla całego obrazu, mamy tu więc trochę mniejszą dowolność, za to zużywamy tylko pół bajtu pamięci na zapisanie sobie z boku, jaki kolor chcemy wyświetlać..

11 – to drugi dodatkowy kolor dobierany również osobno dla każdej komórki osobno – commodore przeznacza na to dodatkowo kolejne 1000 bajtów, zwanych pamięcią koloru.

Pewnie zwrócicie mi uwagę, że w 1000 bajtów powinno się zmieścić 1000 informacji nie o jednym, a o dwóch kolorach. Teoretycznie tak, lecz praktycznie pod uwagę brana jest tylko jedna połowa z każdego bajtu – druga po prostu się marnuje. Szkoda.

Tak, czy owak – zamiast 32 KB pamięci, tryb multikolor poświęcając trochę rozdzielczości i ograniczając wolność w doborze kolorów komórkach – zajmuje 10 KB.

A jakie są efekty? Znowu wygląda to bardzo dobrze.

Obrazki wyglądają niesamowicie. Po powiększeniu i narzuceniu siatki z zarysem komórek – widać, jak dobrze należy dobrać kolory w sąsiadujących obszarach, by uzyskać taki efekt.

Multikolor i highres to jedyne dwa bitmapowe tryby graficzne, jakie oferuje Commodore 64. Jedyne dwa oficjalne. O tych nieoficjalnych być może opowiemy w innym filmiku.

Często jednak generowanie grafiki nie kończy się na generowaniu bitmap, choć w przypadku komputerów takich jak ZX Spectrum i Commodore 16, tak niestety jest.

Wiele maszyn opracowywanych szczególnie jako maszyny do grania wspiera sprzętowo jeden dodatkowy potężny mechanizm – sprajty, czyli duszki.

Duszki to obiekty wyświetlane zupełnie niezależnie od tła – czy to od grafiki bitmapowej, czy tekstowej. W przypadku Commodore 64 mają on rozdzielczość 24 na 21 pixeli i można wyświetlić ich na ekranie na raz 8. Jak zwykle bywa w przypadku tego komputera, liczba nieoficjalna jest znacznie większa.

Każdy duszek może mieć inny kolor i być umiejscowiony w innym miejscu na ekranie, a nawet poza nim – tak by móc wyłonić się zza ramki. Duszki mają też tą fajną właściwość, iż są częściowo przezroczyste – nie mają bowiem żadnego ustalonego koloru tła.

Sprajty wyświetlane są standardowo na grafice, nic nie stoi jednak na przeszkodzie by ukrywały się częściowo za nią. Same duszki również mają ustaloną kolejność – każdy kolejny z ośmiu przesłania poprzedni. Dzięki temu można uzyskać efekt głębi, czy paralaksy.

W pamięci komputera duszek, a właściwie bajty danych opisujące jego wygląd, moga znajdować się w kilku miejscach – można więc zapisać w RAMie animacje duszka, a następnie przełączać wygląd duszka w prosty sposób, zmieniając tylko informacje, z którego miejsca ma być on załadowany.

Jeśli rozmiar 24×21 wydaje się być dla nas za mały, duszka można sprzętowo powiększyć dwa razy zarówno w pionie, jak i w poziomie. Nie zmienia się jednak tutaj rozdzielczość, a tylko fizyczny rozmiar na ekranie.

Podobnie, jak w przypadku grafiki tła – commodore oferuje jeszcze możliwość dodatkowego pokolorowania duszka. Zmniejszając jego rozdzielczość do 12 na 21 pixeli – możemy skorzystać z dodatkowych 2 kolorów – wspólnych dla wszystkich duszków. Mamy więc przeźroczyste tło, kolor konkretnego duszka i 2 kolory współdzielone.

Dobrą informacją jest to, że opcje takie, jak rozmiar i wielokolorowość, można ustawiać dla każdego sprajta osobno – co daje programistą dużą dowolność.

Sprajty są wykorzystywana zazwyczaj, jak reprezentacja ruchomych obiektów – postaci gracza, przeciwników, pocisków. Układ graficzny commodore vic-ii dodatkowo informuje o kolizji, czyli nachodzeniu duszków na siebie inną grafike, co znacznie ułatwia programowanie.

Niezależnie od tego – duszki są ważnym elementem grafiki – szczególnie tej dynamicznej.

O ile stworzenie za pomocą BASICa jakiegoś sensownego rysunku jest dość skomplikowane z uwagi podział pamięci ekranu na bloki 8×8 pixeli, to duszkami bawił się każdy szanujący się fan commodore. Zamiana projektu graficznego jednokolorowego sprajta na ciąg bajtów, które trzeba wpisać do pamięci – to kwestia prostej zamiany liczby dwójkowej na dziesiętną.

Reszta obsługi sprajta jest równie prosta. Dane wystarczy wczytać do pamięci i gotowe.

Ostatnią ciekawostką dotyczącą grafiki na commodre, o której chciałbym wspomnieć jest możliwość sprzętowego scrollowania ekranu , wykorzystywana w wszelakich grach platformowych. Układ graficzny pozwala na przesuwanie ekranu o 1 do 8 pixeli zarówno w pionie, jak i poziomie – dzięki temu możliwe jest bezproblemowe płynne przewijanie ekranu w grach takich, jak chociażby Giana SIsters. To niby oczywista oczywistość, ale np. takie 16-bitowe Atari ST tego nie potrafiło.