Outpost 2 fájlformátumok · bei.pm

Az Outpost 2 által használt adatformátumok a JFIF / PNG struktúrájára emlékeztetnek - az egyes adatblokkok mindig 8 byte-os fejlécet tartalmaznak. Ezért nem dokumentálom az egyes fejléceket a megfelelő specifikus helyeken, csak az eltéréseket jegyzem fel.

A formátum mindig a következő; a tényleges hasznos adatok pedig ebben vannak beágyazva:

A Volumek adatkonténerek a játékhoz, hasonlóan egy archiváló formátumhoz, mint például a Tarball. Legalábbis az Outpost 2-ben a formátum csupán fájlokat ismer - mappákat nem. Valószínűleg ezeket azonban megfelelő fájlnevekkel lehetne szimulálni.

Egy Volume a Volume-fejlécből és több Volume blokkból áll, amelyek a konkrét fájloknak felelnek meg.

A "Volumes" azok a fájlok, amelyek végződnek 'vol' a játék könyvtárában.

A Volume Header önmagában nem tartalmaz felhasználói adatokat.
Csupán tárolóként szolgál.

A Volume Header elsődleges adatai a Volume Stringek; ezt követik a Volume információk.

A Volume Strings egy fájlnév lista, amely a kötetben található.

A kötetinformációk részletesebb információkat tartalmaznak a fájlokról. Ez bizonyos szempontból hasonlít egy FAT könyvtári bejegyzéshez (FAT = File Allocation Table).

A fájlok száma a blokk méretének és a könyvtári bejegyzések hosszának (14 byte) hányadosából adódik.

A különböző könyvtári bejegyzések felépítése a következő:

A Volume-blokk egy olyan tároló, amely fájlokat tartalmaz. Csak még egyszer - a blokkformátum miatt - redundánsan tartalmazza a fájlméretet, majd közvetlenül ezután következnek a hasznos adatok.

A Tiles-ök egy Outpost-2-specifikus bitmap grafikai formátum. 13 Tileset-re terjednek ki, "well" néven (well0000.bmp-tól well0012.bmp-ig), melyek a maps.vol kötetben találhatók.

A Tilesetek / Wells a következőket tartalmazzák:

Javasolt, hogy a pontos megvalósítás érdekében ne rendereljük előre a lapkákat a gyorsítótárazás érdekében, mivel az adatok a nappali/éjjeli ciklushoz még feldolgozásra várnak - és nagyon-nagyon sok adat keletkezne.

A lapkák 8bpp grafikák indexelt palettával, mindegyik 32x32 pixel felbontású, amelyek egymás mellett helyezkednek el. Az így létrejött lapkakészlet azonban sokkal több

A fő konténer 2 szekcióból áll: head és data.

Ezeket az adatok után egy standardizált RIFF-formátumban lévő palettafájl következik. A pontos specifikációt - mivel a paletták máshol is előfordulnak - a Paletták alatt található.

Végül következnek a nyers pixeldatok, balról fentről lefelé, soronként jobbra.
A 8bpp-bitképként megjelenő grafikák adatértéke a színindexet jelenti a színpalettán.

A játékmotor a csempéket *valószínűleg* igény szerint rajzolja meg.
Ennek egyik oka valószínűleg a nap-éj ciklus, amely 32 fokozatot ismer az egyes csempék számára. Úgy tűnik, hogy a fényesség értékéből 'egy kicsit' levonnak. Pontos értékeket még nem sikerült meghatározni, a számítási alapot a következő képlettel dolgozom ki:

v *= (daylight / 48) + 0.25;

a pixel HSV-adatai alapján, ahol a daylight egy 0-31 közötti érték, és v egy 0-1 közötti érték. Továbbá figyelembe kell venni, hogy a térképen balra és jobbra is van egy 16 csempéből álló szegély (ez az egységek láthatatlan spawnálására szolgál).

Továbbá úgy tűnik, hogy a nap-éj ciklus játékciklusonként csak egy oszlopot frissít a térképen.
Egy felgyorsított nap-éj ciklus tehát a következőképpen néz ki:

A PRT pontos jelentése számomra nem ismert; elképzelhető például, hogy a 'Paletta és Erőforrás Tábla' - mivel ez a fájl - amely a op2_art.prt néven található a maps.vol-ban - valóban egy ilyen fájlt jelent, vagy akár jól is leírhatja a funkcióját.

Ez a fájl tartalmaz egy paletták listáját, egy táblázatot az összes használt bitmapról, az összes animációs definíciót és számos ismeretlen adatot. A korábbi konténerformát követi, de laza összefüggésben, mivel nem minden rekord követi ezt a sémát.

A CPAL szekció (valószínűleg a paletták konténerét jelenti) csupán a palettadatokat öleli fel, megadva, hogy hány db a jellemzően 1052 byte méretű 8-bites palettákból van jelen.

A 1052-byte méret nem tekinthető kötelezőnek, mivel a palettaformátum potenciálisan eltérő palettaméreteket is megengedhet. Ez csupán azokra az adatokra vonatkozik, amelyekkel az Outpost 2 kiadásra került.

A paletták listája után közvetlenül és bevezető fejléc nélkül következik a bitmapelemek listája; ugyanígy az animációs listák is közvetlenül következnek.
Ezek mindegyike egy uint(32) (vagy esetleg uint24 + uint8 flag?) bevezetésével kezdődik, amely tartalmazza a rekordok számát.

A raklap-információk nagyon egyszerűen olvashatók.
Egy fejlécből és egy adat-szegmensből állnak.

A adat szekció tartalmazza az egyes raklap-bejegyzéseket. A raklap-bejegyzések száma a blokk hosszának / 4-ből adódik.

Az egyes bejegyzések egyszerű felépítése a következő;

A palettákkal kapcsolatban annyit kell még mondani, hogy az animációkhoz használt palettákra a következő szabályok vonatkoznak:

• A legelső szín MINDIG átlátszó, függetlenül attól, hogy milyen értéket adtak meg.
• A paletta bejegyzések 1-24 a 1-8. palettákban játékos színként értendők.
  Hogy a színek honnan származnak az 1-es játékoson kívül, azt nem tudom.
  Feltételezem, hogy a többi szín hardcoded.

A PRT-fájl adatszerkezete megmutatja, hogyan épülnek fel a spritekhez használt bitmapok. Ezek a bitmapok egy-egy alkotóelemként szolgálnak, amelyből több darabot összeállítanak egy sprite animációs keretéhez.

A konkrét képadatok a játék mappájában található op2_art.BMP fájlban rejtőznek.
Hogy miért rendelkezik ez a bitmap fájl egy (többnyire helyes) RIFF-bitmap fejlécsel, az nem világos. Valószínű, hogy az Outpost 2 rendszer-API-kat használ a grafikák betöltésére, ideiglenesen átvéve ezt a fejlécet, és felülírva a megfelelő, változó mezőket.

A pixeldatok a BMP fájlban az Offset + uint32-Offset pozíción találhatók, mely a BMP fájlban a 0x000A címen érhető el (RIFF-bitmap adatok offsetje), és ismét a bal felső saroktól jobbra lefelé haladó soros elrendezést követi.

A monokróm 1bpp grafikák úgy is megrajzolhatók, hogy a 0 szín teljes átlátszóságot, míg az 1 szín félig átlátszó fekete/szürke, mivel a monokróm grafikákat jellemzően jármű- és épületsötétekhez használják az animációkban.

Ily módon már sok grafikát össze lehet állítani.

Most már a legmagasabb szintű diszciplínákra térünk át az Outpost 2 adatformátumok között:
Az animációkra.

Az animációs listák egy globális fejlécsel kezdődnek, amely elsődlegesen az adatok ellenőrzésére szolgál. Ezt követik a konkrét animációs definíciók, amelyek 3 szintre oszlanak:

1. Animáció
   Egy animáció a legfelsőbb szint; egy egység, egy épület vagy egy 'reszkető animáció' (üstökös becsapódás, időjárás, robbanás) animációját ábrázolja egy adott kiindulási helyzetben.
2. Kép
   Egy kép egyetlen kép az animáción belül. Egy animáció tartalmazhat egy vagy több képet.
3. Alkép
   Egy alkép az információ arról, hogy egy adott bitmapot bizonyos kritériumok alapján egy adott helyre kell rajzolni egy képen. Egy kép tartalmazhat egy vagy több alképet.

Ezt követően közvetlenül az egyes animációs definíciók következnek.

A legfelső réteg, az animáció adatai elsősorban adminisztrációs adatok - a Boundingbox a jármű/épület körüli jelölés koordinátáit jelöli, mikor az ki van választva, és egyúttal azt is megadja, hogy melyik terület legyen kattintható.

Az offset elsősorban a "nullpontot" határozza meg; azt a pontot, amelyet a játékbeli koordinátákhoz hozzá kell adni, vagy el kell vonni. Matematikai értelemben az offset itt a koordináták eredetét jelenti.

A windows esetében, akárcsak az offsetnél, minden egyes (ablak) 4 uint(32) értéket tartalmaz, amelyek egy területet határoznak meg, ami egyes alkeretek számára felhasználható. Az ablakokon kívül, ha azt a bitmap megfelelően megengedi, nem szabad rajzolni.

Ezzel most már egyes kereteket, valamint teljes animációkat is össze tudunk állítani, itt egy összetettebb animáció példáján, az 500 indexű animáción demonstrálva

A 500-as animáció bemutatja, hogyan ürítik ki a Plymouth teherautót, amelyet hagyományos érccel rakodtak meg. Ez az egyik kevés animáció, amely kihasználja az ablakkezelési funkciót.

Így a teljes animáció összerakható.
Sajnos van még egy probléma a felső rakodónyílással, mivel itt a megfelelő bit nincs beállítva a grafikai típus információjában.

Itt van még néhány gyönyörűen animált sprite a játékból:

Még hiányzik a játék felhasználói felülete, amely fémes, kefélt megjelenésű.

De itt is észlelhető, hogy Dynamix nem kellett, hogy újra feltalálja a kereket; itt nemcsak a Windows által biztosított User32 és GDI32 API-kat használják - különösen a User32 erőforrás-kezelését is alkalmazzák.

Ezek például programokkal, mint az Angus Johnson által ingyenes szoftverként kifejlesztett Resource Hacker, vagy - ha valaki Linux / Mac OS alatt kerüli a Wine használatát - az icoutils-ban található wrestool segítségével is ki tudja nyerni.