Moze juz ktos z Was zastanawial sie jak NES wyswietla grafike.
Postaram sie chyba najbardziej lopatologicznie to wytlumaczyc...
Uwierzcie na slowo - to co napisze na dole jest napisane BARDZO prosto...
Ok. Jadziem.
Grajac w gry widzimy mase roznych obiektow - jedne skacza, inne stoja
w miejscu i nic nie robia, a jeszcze inne powoduja u nas atak nerwicy
i automatyczny odruch rzucenia padem o glebe...
Te wszystkie obiekty
sa poskladane z mniejszych, cos na podobe klockow lego. Tyle, ze tutaj,
kazdy klocek jest tej samej wielkosci, jedynie kolory inne.
Grafika w grach na NES jest podzielona na tzw. TILES'y - takie male obrazki,
co maja maksymalnie 4 kolory i 8x8 pixeli. Wszelka grafika zapisana jest
na karcie w ukladzie ROM nazwanym CHR ROM'em (
CHa
Racter),
czasami wgrana jest w PRG ROM, z ktorego potem wczytywana jest do pamieci
CHR RAM (VRAM), ktora powiedzmy zastepuje pamiec CHR ROM.
NES zostal tak ciekawie zrobiony, ze dane PRoGramu (PRG) sa w pewnym sensie
niezalezne od danych CHaRakterow (CHR). NES ma dwa procesory w sobie,
czyli CPU (procesor) oraz PPU (chip graficzny) i kazdy z nich ma swoje,
tylko dla siebie kosci pamieci RAM - CPU ma 2KB PRG RAMU a PPU ma swoje 2KB VRAMU.
Jak ktos chce zrobic maly eksperyment, niech wywali ze swojej konsoli NES
lub Pegasus chip graficzny i odpali jakies gry - beda one dzialac,
jednak grafika bedzie tzw. "kaszaniasta". Cos takiego jest takze w kartridzach
z grami - jest PRG ROM i CHR ROM, jak wywalimy z karta CHROM, to bedzie ten
sam efekt co w przypadku wylutowania z konsoli chipa graficznego (lub jego pamieci).
Pewnie juz nie raz ktos z Was posiadal gre na pegasusa, ktora wyswietlala
ta slynna "kaszaniasta" grafike, natomiast sama gra, muzyka itd dzialala
- to wlasnie wina uszkodzonego CHR ROMU...
Oki...
Gdyby odczytac dane CHR z karta gry, to zobaczymy cos takiego:
(jako obiekt prezentacji uzyje gry "Super Mario Bros")
Czyl maaasa roznych TILES'ow, ktore maja dziwne kolory i sa strasznie
balaganiarsko poukladane. Jeden wielki syf...
Wlasnie przypomina to worek z klockami, z ktorego bedziemy brac interesujace
nas klocki i budowac co tam sie podoba..
Kolory sa dziwne, bo i tak ukladamy sobie oddzielne palety kolorow,
ktore sa przypisywane potem do odpowiednich TILE'sow.
Oto bohater!:
To wlasnie TILE'S - z nich trzeba poskladac cala grafike w NES'owych grach...
Ma on dokladnie 8x8 pixeli, posiada 4 kolory - TYLKO cztery! Nie moze byc
mniej i wiecej. Ino cztyry. Jednak aby nie bylo zbyt kolorowo, widoczne sa
tylko trzy... Bo kolor 0 (zero) jest kolorem PRZEZROCZYSTYM, tzn. niewazne
jaki kolor tam wstawimy, to on i tak zostanie "przykryty" tłem. Chodzi o to,
ze jak narysujemy w literke A to dzieki temu sama literka A bedzie
widoczna, a wypelnienie tilesa (reszta z 8x8pixeli) bedzie przezroczyste... Chyba wiadomo
o co biega.... Oczywiscie moga istniec jakies programowe triki, co zmieniaja
te wlasciwosci i tiles caly wyswietli sie w 4kolorach. Ale nie o to tu chodzi.
Paleta TILES'a. Pewnie ktos sie zdziwil czytajac tylko o 4 kolorach, skoro NES
potrafi wyswietlic jednoczesnie 16 kolorow na ekranie (czepiajac sie to bedzie w sumie 12 tylko...)
Sprawa jest taka, ze do kazdego tilesa mozna przypisac jego WLASNA palete
kolorow. (Ogolnie powiedzmy, bo pomijam cos, co sie nazywa SQUARE w Attribute
Table. To ma byc ogolny opis, wiec pomijam).
TILES sam nie posiada kolorow, ma on tylko DANE informujace o roznicy
w zawartych pixelach. Potem kolory z wszelkich palet sa przypisywane
do danych w tilesie (hehe - kolorowane sa).
Jak widac pobralem z danych CHR jeden TILES, ktory przedstawia "ognik" wystrzeliwany
przez duzego maria (ktory zebral kwiatek). W grze ten "ognik" jest animowany
i ma az dwie klatki animacji, dzieki ktorym obiekt sie "kreci"
w powietrzu (widac je w PIC nr1) i dwie klatki animacji gdy w cos uderza.
Czyli piszemy kod w assemlberze, pobieramy adresy odpowadajace za umiejscowienie
TILES'ow tego obiektu, pobieramy kolorki z palety i robimy "animacje"
lub tworzymy jeden obiekt w grze np. Grzybka:
Jeszcze jedna sprawa: Wszystko to dzieli sie na dane "duszkow" (SPRITE)
i dane tla (BACKGROUND). Poza pewnymi innymi sprawami, ktore je dziela podczas
kodowania gry, "zasada TILES'a" jest identyczna w obu przypadkach.
No... Jeszcze czesto sam uklad w danych CHR jest podzielony (nie zawsze, ale mowa
o NROM'ie bez dodatkowych mapperow) np. pierwsze 4KB danych w CHR ROM to sprire'y,
a kolejne 4KB to tla. NROM posiada lacznie MAX 8KB danych CHR... Czyli....
Na grafike mamy TYLKO 8KB!
Dzielac to na ilosc TILES'ow, ktory to ma
zawsze 16bajtow wielkosci wychodzi nam maksymalnie 512 sztuk TILES'ow w jednej grze
NROM... Wydaje sie malo, jednak mozna cuda robic uzywajac takiej ilosci.
Jak juz napisalem - jeden 8x8 pixeli i 4-kolorowy TILES zawsze zajmuje 16 bajtow
w pliku CHR. Czyli w 8KB mamy 512 sztuk, bo 8KB to 8192 bajty, ktore dzielimy na 16
i mamy 512 (Caly czas mowa o NROM'ie).
Gdyby plik CHR otworzyc HEX edytorem to zobaczymy cos takiego:
16 bajtow to akurat jedna pozioma "linijka" hex'ow:
Ok... Wszystko jak widac wyliczone co do bajta i... bita.
Kiedys tak bylo, kazdy bajt czy bit byl na wage zlota, nie to co dzisiaj, gdzie gry
zaczynaja wychodzic na plytach BLU-RAY 50GB....
Postaram sie wyjasnic graficznie jak wyglada TILES' z innej strony...
Kazdy bajt TILES'a to 8 bitow - czyli osiem ZER lub JEDYNEK,
ktore potem sa przeliczane na bajty..
Przyklad - Jak "narysowac" literke X w roznych kolorach:
WAZNE!! Napisalem wyzej "Jak "narysowac" literke X w roznych kolorach"
- niech nikt nie odbiera tego tak, ze ten schemat pokazuje jak
ustawiac kolory np. czerwony, zielony czy niebieski.
Jesli bedziemy mieli np. po lewej BIT1 i po prawej BIT1, to nie oznacza
to wcale koloru CZERWONEGO... Obsolutnie NIE!. Kolory definiujemy w paletach,
tutaj pojecia "KOLOR 0, 1, 2 i 3" to tylko informacjami potrzebnymi do przypisywania pixelom kolorow z palety.
Kazdy jego bajt, czyli te 8-bitow to jedna linia pozioma o rozmiarze 8pixeli.
Jest ich 8 - czyli akurat 8x8pixeli. Ale zaraz! Przeciez to razem wychodzi
8bajtow, wiec TILES' ma rozmiar 8-mio, a nie 16 bajtowy?! Hehe Mozna by tak to odebrac,
lecz jest zupelnie inaczej. Przeciez bity sa dwa - ZERO i JEDEN,wiec
gdyby TILES mial wielkosc 8bajtow, to mozna by w nim tylko uzywac
dwoch kolorow - koloru 0 i koloru 1, a przeciez ma 4 kolory.
W tych 16bajtach zawarte sa jakby dwa te same obrazki, kazdy wypelniony
tylko zerami albo jedynkami. Dzieki temu, ze sa dwa takie "klony" TILES'a
mozna mieszac wartosci. Np. Jesli w jednym "Klonie" mamy w lewym gornym
pixelu 0, a w tym samym miejscu ale w drugim "klonie" tez bedzie zero,
to wychodzi lacznie, ze tutaj pixel ma kolor ZERO - czyli ten co pisalem,
ktory jest "przezroczysty". A jesli np. w pierwszym klonie bedzie pixel oznaczony
jedynka, a w drugim tez bedzie jedynka, to w ich polaczeniu wychodzi nam kolor 3...
Dzieki temu mozna wyodrebnic 4 kolorki, wiecej sie nie da.
Wszystkie cztery kombinacje widzimy na obrazku wyzej.
Ekran NES'a ma 256x240 pixeli w trybie PAL i 256x224 w trybie NTSC.
Na ekranie w trybie PAL wlezie dokladnie 32x30 TILES'ow czyli 960 sztuk,
natomiast w trybie NTSC 32x28 czyli 896 sztuk. Zwyczajnie w NTSC
obcinana jest gorne 8pixeli oraz dolne 8pixeli. Piszac cokolwiek w asemblerze
NES'a czesto uzywa sie Tablic Nazw (Name Tables), czyli taka mapa ekranu,
z zaznaczonymi gdzie maja byc wyswietlone TILESy, ktore beda skladac
sie na tlo.
Koniec. Ktos zalapal o co biega?
:D
WSZYSTKO OPISANE BARDZO OGOLNIE, BO TEMAT DOSYC ROZBUDOWANY.
Jednak zalezalo mi na w miare jak najprostszym jego przedstawieniu,
jak ktos chce cos wiecej sie dowiedziec, niech pisze na dole tematu