Reverse Engineering gry - Nietypowa propozycja: Sonic Chronicles (2/3)

Oryginalny wpis: The Odd One Out: Sonic Chronicles (2/3) (napisany przez DrMcCoy).

---

Po wdrożeniu czytelników w temat popularnych formatów BioWare, zabieram się do omówienia formatów graficznych. Są one w większości zbudowane dla Nintendo DS, co oznacza że mogę pobawić się w detektywa ukrytej sceny moddingowej Nintendo. Chcę tutaj podziękować trzem osobom: Martin'owi Korth'owi, znanemu dzięki NO$GBA, którego dokumentacja GBATEK jest bezcenna przy mojej pracy, lowlines który powiedział nam wiele o szczegółowych detalach formatów i pleoNeX, którego licencjonowane narzędzia Tinke GPLv3 stanowiły fundament na którym przeprowadziłem wdrażanie mojego kodu.

"MAŁE"

Kiedy spojrzałem na pliki wewnątrz archiwów Sonic Chronicles, zauważyłem dziwną rzecz. Jest tam wiele plików o nazwach zakończonych na ".small". Podejrzewałem schemat kompresji, zwłaszcza po przeanalizowaniu plików w hexeditor. I rzeczywiście, jest kilka algorytmów kompresji przewidziane przez firmware Nintendo DS. Używany przez Sonic Chronicles jest wariant LZSS, który może być rozpakowany na licencji MIT przy użyciu narzędzia barubary na dsdecmp (GitHub). Wciągnąłem dekompresor do xoreos.

NSBTX

Pierwszym formatem graficznym Sonic Chronicles, który sprawdziłem był NSBTX. Pliki NSBTX są teksturami; czy raczej: Archiwa kilku faktur używanych przez jeden model. Realizacja odczytu była dość prosta i dodałem mały program do naszej kolekcji narzędzi, którym można "wydobyć" je do formatu TGA.

Hill, Boar, Tails

Następnie chciałem zobaczyć czcionki, NFTR, używane w grze. Są one czcionkami bitmapowymi, z każdym glyph'em jako obrazem. Obraz może być 1-bitowy czarno-biały, lub może być skali szarości dla antyaliasingu lub cieniowania. Dodatkowo, są tam tablice odwzorowań pozwalające przetłumaczyć każdy punkt kodu (UTF-16, UTF-32, CP1252 lub Shift-JIS) do indeksu gliyph'ów który reprezentuje.

Było trochę prób i błędów, dokumentacja istniejących projektów FLOSS do wyświetlania czcionki nie była całkiem poprawna w pewnych momentach (co może nie być nawet ich winą; Nintendo lubi wprowadzać subtelne zmiany formatów pomiędzy wersjami oprogramowania). Mimo to, po dłuższej chwili byłem w stanie wydrukować dowolne ciągi znaków, w tych czcionek w xoreos.

Test rysowania czcionek

NBFS / NBFP

Sonic Chronicles zawiera kilka plików NBFS, co jest prostym formatem RAW: 8-bit paleta danych obrazu (w 16-bitowych wartościach RGB555) w pliku NBFP o tej samej nazwie. Są one najczęściej stosowane do obrazów obejmujących cały ekran Nintendo DS.

Minimap / Conversional Card

NCGR / NCLR

Głównym format obrazu używany w Sonic Chronicles, którego wciąż brakuje: NCGR. Po wdrożeniu czytnika, dowiedziałem się niepokojących faktów:
Palety są w osobnych plikach NCLR które są dzielone pomiędzy NCGR.
Większość obrazów składa się z kilku plików NCGR rozmieszczonych na siatce.
Same dane obrazu NCGR składają się z płytek 8x8 pikseli
Obraz Sonic'a jest podzielony na tych zdjęciach:

Sonic / Komórki NCGR / Płytki NCGR

To wszystko sprawia, że po montażu ostateczny obraz jest trochę ... brzydki. Ale hej, sprawiłem przynajmniej że to działa.
... Z wyjątkiem jednej rzeczy: kilka plików NCGRć nie określa ich szerokości i wysokości. Po chwili zabawy z wartościami udało mi się znaleźć te wartości ręcznie, ale powstały obraz wygląda nieciekawie: to tak, jakby obraz miał się poprawić, ale potem różne części narysowane są w różnych miejscach. Każdy z tych plików ma również plik NCER o tej samej nazwie. Zakładam, że oznacza to iż informacje na temat jak wyciągnąć te NCGR są w NCER. Kolejna rzecz na stos rzeczy "do zrobienia".

NSBMD

Poszedłem w końcu do wielkiego zadania - formatu 3D: NSBMD. Wymagało to sporo zabawy, zgadywania metodą prób i błędów, a dokumentacja z tych formatów jest znikoma, a często niekompletna.
Koncepcyjnie, plik NSBMD składa się z następujących części:
-kości
-polecenia kości
-materiały
-wielokąty
-polecenia wielokątów
Kość składa się z nazwy i transformacji, że rozdziela ją od (tego właśnie nie wiadomo) głównej kości. Są one przechowywane w postaci płaskiej listy. Polecenia kości następnie określają, w jaki sposób połączyć je ze sobą. I dają każdej kości lokalizację w macierzy stosu Nintendo DS (listę macierzy transformacji zawierających wszystkie transformacje każdej kości w czasie renderingu).

Zepsuty szkielet dzika / Już prawie ... / Poprawnie działający szkielet dzika.

Materiał zawiera nazwę tekstury (co odwołuje się do tekstury wewnątrz NSBTX o tej samej nazwie co NSBMD) i kilka właściwości.
Każdy wielokąt może korzystać z jednego materiału i zawiera listę poleceń wielokąta. Te polecenia stoją za produkcją rzeczywistej geometrii. Określają one kolor, normalne i współrzędne tekstury i generowane wierzchołki. Manipulują również stosem matryc, a konkretnie wymianą matrycy pracy z matrycą z położenia stosu niektórych kości. W istocie opiera wierzchołki do położenia kości.

Ksenomorf / Dzik z dziurami / Dzik

Choć Nintendo DS interpretuje polecenia wielokątów "w locie" podczas renderowania i jednocześnie mogą być konwertowane niemal bezpośrednio do bloków OpenGL 1.2 [ glBegin () / glEnd () ], to nie jest naprawdę to co chcemy osiągnąć. Więc zamiast tego, podczas załadunku będziemy interpretować polecenia wielokątów do struktury pośredniej.

Sonic / Amy / Tails

Rezultatem jest stosunkowo masywna ładowarka dla tych plików, która jeszcze nie obejmuje wsparcia dla animacji.
Interesująca anegdota: Nintendo DS nie używa liczb zmiennoprzecinkowych do reprezentowania liczb rzeczywistych, ale różne formaty liczb stałoprzecinkowych. Są one często widywane w plikach NSBMD. Ale kiedy realizowałem wcześniej format GFF4 (patrz część 1 moich postępów), znalazłem w plikach GFF4 Sonic Chronicles typ pola nie opisany w zestawie narzędzi wiki Dragon Age. Okazuje się, że są to numery stałoprzecinkowe Nintendo DS!

CBGT / PAL i CDPTH

Po poprawce brzydkich modeli, byłem gotowy, aby pokazać obszary, prawda? Nieprawda. Jest jeszcze inny format graficzny w Sonic Chronicles : CBGT, używane do obrazów obszaru tła.

Jednak CBGT nie jest Formatem Nintendo. Nie, jest to jedna z kreacji BioWare. Ma jednak czerpać inspirację z formatów Nintendo DS. Składa się z bloków 64x64 pikseli, każdy skompresowany przy użyciu algorytmu LZSS (z plików .small), a każdy blok podzielony na płytki 8x8 pikseli. Pliki PAL o tej samej nazwie zawierają palety, z każdym CBGT będąc w stanie użyć innej palety w systemie PAL.
Ponieważ wiedziałem już jak złożyć razem te komórki i płytki z formatu NCGR, uzyskanie obrazu nie było problemem. Ale byłem w rozterce, nie wiedząc skąd uzyskać wymiary obrazu i jak do przenieść palety na komórki. Stworzyłem algorytm który pasował dla prawie wszystkich zdjęć, ale wciąż irytowały mnie odstające części. Wtedy do mnie dotarło: dla każdej pary CBGT / PAL, jest tam trzeci plik: 2DA. A ten zawiera informacje, które komórki stosują które palety, uporządkowane w tabeli 2D oraz jak są ułożone w końcowym obrazie. To oczywiście, wystarczy do obliczania ostatecznych wymiarów obrazu.

Zła dystrybucja palety / Poprawna dystrybucja palety

Znalazłem też czwarty plik dla prawie każdego CBGT / PAL / 2da: CDPTH. Umieszczone w podobny sposób do CBGT, zawiera 16-bitową informację głębokości dla każdego obszaru tła. Służy do tego by niektóre kawałki tła wyświetlać na modelach 3D w grze, kiedy te powinny pojawić się za czymś.

Głębokość

Teraz byłem gotowy do wdrożenia w Sonic Chronicles rzeczywiście istotnych rzeczy.