Formaty plików Outpost 2 · bei.pm

Dane formaty używane przez Outpost 2 mają strukturę przypominającą JFIF / PNG - poszczególne bloki danych zawsze mają nagłówek o długości 8 bajtów. W związku z tym oszczędzam sobie dokumentowania poszczególnych nagłówków w odpowiednich specyficznych miejscach i dokumentuję tylko odchylenia.

Format jest zawsze następujący; właściwe dane użytkowe są w nim osadzone:

Volume to kontener danych dla gry, podobny do formatu archiwum, takiego jak Tarball. Przynajmniej w Outpost 2 format ten zna jedynie pliki - bez folderów. Prawdopodobnie jednak można by je zasymulować za pomocą odpowiednich nazw plików.

Volume składa się z nagłówka Volume oraz z kilku bloków Volume, które odpowiadają konkretnym plikom.

"Volumes" to pliki z rozszerzeniem 'vol' w katalogu gry.

Nagłówek wolumenu sam w sobie nie zawiera żadnych danych użytkowych.
Jest jedynie kontenerem.

Pierwszymi danymi w nagłówku wolumenu powinny być ciągi wolumenu; następnie pojawiają się informacje o wolumenie.

Volume Strings to lista nazw plików, które znajdują się w obrębie woluminu.

Informacje o woluminie zawierają bardziej szczegółowe dane na temat plików. W pewnym sensie jest to rodzaj wpisu w katalogu FAT (FAT = Tablica Przydziału Plików).

Liczba plików wynika z wielkości bloku podzielonej przez długość wpisów katalogowych - 14 bajtów.

Pojedyncze wpisy katalogowe mają następującą strukturę:

Blok woluminu to kontener, który przechowuje pliki. Zawiera on jedynie - ze względu na format bloku - redundantnie rozmiar pliku, a następnie bezpośrednio następują dane użytkowe.

Tiles to specyficzny format grafiki bitmapowej dla Outpost-2. Obejmuje 13 zestawów tiles, zwanych "studniami" (well0000.bmp do well0012.bmp), które znajdują się w woluminie maps.vol.

Zestawy tiles / studnie zawierają następujące elementy:

Jest to zalecane dla dokładnej realizacji, aby nie renderować kafli z wyprzedzeniem w celu ich buforowania, ponieważ dane dotyczące cyklu dnia/nocy muszą być jeszcze przetworzone - a danych byłoby naprawdę bardzo dużo.

Kafle to grafiki 8bpp z paletą indeksowaną o rozdzielczości 32x32 pikseli, które są ułożone w stos. W tak powstałym zestawie kafli może być jednak znacznie więcej

Główny kontener składa się z 2 sekcji: head i data.

Zgodnie z tymi danymi, następnie dostępny będzie plik palety w standardowym formacie RIFF. Dokładna specyfikacja znajduje się - ponieważ palety pojawiają się także w innych miejscach - pod Palety.

W końcu następują surowe dane pikseli, od lewego górnego rogu, wierszami do prawego dolnego rogu.
Wartość danych w grafikach, które zazwyczaj występują jako bitmapy 8bpp, odpowiada indeksowi koloru w palecie kolorów.

Silnik gry prawdopodobnie rysuje kafelki *na żądanie*.
Wydaje się to być związane z cyklem dnia i nocy, który zna 32 stopnie poszczególnych kafelków. Wygląda na to, że od wartości jasności odejmowane jest 'trochę'. Dokładne wartości nie zostały jeszcze ustalone, pracuję na podstawie obliczeń

v *= (daylight / 48) + 0.25;

za pomocą danych HSV pikseli, gdzie daylight to wartość od 0 do 31, a v to wartość między 0 a 1. Należy również wziąć pod uwagę, że na mapie istnieje dodatkowo margines 16 kafelków po lewej i prawej stronie (służy to niewidzialnemu pojawianiu się jednostek).

Dodatkowo wydaje się, że cykl dnia i nocy aktualizuje tylko jedną kolumnę mapy w każdym cyklu gry.
Przyspieszony cykl dnia i nocy wygląda zatem następująco:

Za co dokładnie odpowiada PRT, nie jest mi znane; możliwe, że chodzi o 'Tabela Palet i Zasobów' - ponieważ ten plik - znajdowany jako op2_art.prt w maps.vol - jest takim plikiem, a ta nazwa dobrze opisuje jego funkcję.

Ten plik zawiera listę palet, tabelę wszystkich używanych bitmap, wszystkie definicje animacji oraz szereg nieznanych danych. Luźno podąża za dotychczasowym formatem kontenera, ponieważ nie wszystkie rekordy są zgodne z tym schematem.

Sekcja CPAL (prawdopodobnie oznaczająca kontener palet) obejmuje jedynie dane palet, wskazując, ile z typowo 1052-bajtowych 8-bitowych palet jest dostępnych.

Podana wartość 1052 bajtów nie jest wiążąca, ponieważ format palet potencjalnie przewiduje różne rozmiary palet. Dotyczy to jedynie zbioru danych, z którym dostarczany jest Outpost 2.

Bezpośrednio po liście palet, i to bez wstępnego nagłówka, następuje lista bitmap; natychmiast po niej pojawiają się listy animacji.
Obie zaczynają się odpowiednio od uint(32) (lub znowu uint24+uint8 flagi?), które zawierają liczbę rekordów.

Informacje o paletach są bardzo łatwe do odczytania.
Składają się z nagłówka i segmentu danych.

Sekcja danych zawiera poszczególne wpisy palet. Liczba wpisów palet wynika z długości bloku / 4.

Pojedyncze wpisy mają następującą, prostą strukturę;

O paletach można dodać tylko tyle, że dla palet używanych w animacjach obowiązują następujące zasady:

• Pierwszy kolor jest ZAWSZE przezroczysty, niezależnie od podanej wartości.
• Pozycje palet 1-24 są traktowane jako kolory graczy w paletach 1-8.
  Gdzie dokładnie pochodzą kolory poza kolorem gracza 1, nie jest dla mnie jasne.
  Podejrzewam, że pozostałe kolory są zakodowane na stałe.

Struktura danych pliku PRT określa, jak są zbudowane bitmapy używane dla sprite'ów. Bitmapy te służą jako pojedynczy element, z którego wiele łączy się w klatkę animacji sprite'a.

Konkretnych danych obrazowych można znaleźć w op2_art.BMP w katalogu gry.
Jest niejasne, dlaczego ten plik bitmapowy posiada (przeważnie poprawny) nagłówek RIFF-Bitmap, ale prawdopodobnie Outpost 2 wykorzystuje systemowe API do ładowania grafik, tymczasowo przejmując ten nagłówek i nadpisując odpowiednie, zmienne pola.

Dane pikseli znajdują się w pliku BMP na pozycji Offset + uint32-Offset, który znajduje się w pliku BMP pod adresem 0x000A (offset danych RIFF-Bitmap) i odpowiada ponownie liniowemu układowi od góry do dołu, z lewej do prawej.

Grafiki monochromatyczne 1bpp mogą być rysowane w sposób, że kolor 0 oznacza pełną przezroczystość, a kolor 1 to półprzezroczysty czarny/szary, ponieważ monochromatyczne grafiki są zwykle używane do cieni pojazdów i budynków w animacjach.

Dzięki temu można już złożyć wiele grafik.

Teraz przechodzimy do królewskiej klasy dyscyplin w formatach danych Outpost 2:
Do animacji.

Listy animacji rozpoczynają się od globalnego nagłówka, który służy głównie do weryfikacji danych. Następnie pojawiają się konkretne definicje animacji, które dzielą się na 3 poziomy:

1. Animacja
   Animacja to najwyższa instancja; przedstawia animację jednostki, budynku lub 'animacji cząsteczkowej' (uderzenie komety, pogoda, wybuch) w określonej sytuacji początkowej.
2. Klucz
   Klucz to pojedynczy obrazek w ramach animacji. Animacja może zawierać jeden lub więcej kluczy.
3. Podklucz
   Podklucz to informacja o tym, że określona bitmapa ma być rysowana w określonej pozycji klucza według określonych kryteriów. Klucz może zawierać jeden lub więcej podkluczy.

Następnie pojawiają się już bezpośrednio poszczególne definicje animacji.

Dane najwyższej warstwy animacji to przede wszystkim dane administracyjne - Boundingbox oznacza współrzędne oznaczenia wokół pojazdu/budynku, kiedy jest on wybrany, i jednocześnie wskazuje, który obszar powinien być klikalny.

Offset przede wszystkim określa "punkt zerowy"; punkt, który należy dodać lub odjąć od współrzędnych wewnętrznych gry. Można to również ująć matematycznie: offset tutaj oznacza oryginał współrzędnych.

W przypadku okien, podobnie jak w przypadku offsetu, mamy do czynienia z 4 wartościami uint(32) dla każdego okna, które określają obszar uznawany za użyteczny dla poszczególnych subframe'ów. Poza oknami nie wolno rysować, o ile nie jest to odpowiednio przewidziane dla bitmapy.

Dzięki temu możemy teraz łączyć pojedyncze klatki oraz całe animacje, co zostało zaprezentowane na przykładzie bardziej złożonej animacji o indeksie 500.

Animacja 500 pokazuje, jak transportowiec Plymouth, załadowany standardowym rudzikiem, jest rozładowywany. Jest to jedna z niewielu animacji, która wykorzystuje funkcjonalność okienkową.

I tak można połączyć całą animację.
Niestety, wciąż istnieje problem z górnym włazem ładunkowym, ponieważ odpowiedni bit w informacji o typie grafiki nie jest ustawiony.

Oto jeszcze kilka innych, pięknie animowanych sprite'ów z gry:

Teraz brakuje jeszcze interfejsu użytkownika gry, który utrzymany jest w stylu szczotkowanego metalu.

Ale także tutaj widać, że Dynamix nie musiało wynajdywać koła na nowo; nie tylko prosto korzystają z API User32 i GDI32 dostarczonych przez Windows - szczególnie wykorzystywane jest także zarządzanie zasobami z User32.

Można je na przykład wyodrębnić za pomocą programów takich jak Resource Hacker, opracowanego przez Angusa Johnsona jako oprogramowanie freeware, lub - jeśli ktoś unika używania Wine na Linuxie / Mac OS - przy pomocy wrestool, które jest częścią icoutils.