Outpost 2 Obrazci datotek · bei.pm

Podatkovni formati, ki jih uporablja Outpost 2, imajo strukturo, ki spominja na JFIF / PNG - posamezni podatkovni bloki vedno vsebujejo 8-bajtni glavo. Zato se odločim, da ne bom dokumentiral posameznih glav na ustreznih specifičnih mestih, temveč bom tam dokumentiral le odstopanja.

Format je vedno naslednji; dejanski uporabni podatki so nato v njem vgrajeni:

Volumi so podatkovni kontejner za igro, podoben arhivskemu formatu, kot je na primer Tarball. V Outpost 2 to format pozna le datoteke - brez map. Vendar bi jih verjetno lahko simulirali s ustreznimi imeni datotek.

Volumen je sestavljen iz volumske glave in več volumski blokov, ki ustrezajo konkretnim datotekam.

"Volumi" so datoteke z končnico 'vol' v imeniku igre.

Glava volumna ne vsebuje nobenih uporabnih podatkov.
Uporablja se le kot kontejner.

Prvi podatki v glavi volumna bi morali biti nizi volumna; za njimi sledijo informacije o volumnu.

Volume Strings so seznam imen datotek, ki so vključene v volumen.

Informacije o volumnu zajemajo podrobnejše informacije o datotekah. Gre nekako za vrsto vnosa v FAT imeniku (FAT = tabela dodelitve datotek).

Število datotek izhaja iz velikosti bloka, deljene z dolžino vnosov v imeniku - 14 bajtov.

Posamezni vnosi v imeniku imajo naslednjo strukturo:

Volume blok je kontejner, ki shranjuje datoteke. Vsebuje še enkrat - zaradi bloka formata - odvečno velikost datoteke, nato pa sledijo neposredno uporabniški podatki.

Tiles predstavljajo specifičen format bitmap grafike za Outpost-2. Raztezajo se čez 13 Tilesetov, imenovanih "wells" (well0000.bmp do well0012.bmp), ki se nahajajo znotraj volumna maps.vol.

Tileseti / Wells vsebujejo naslednje:

Priporočljivo je, da se ploščice ne upodabljajo vnaprej za shranjevanje v predpomnilnik, saj je potrebno še obdelati podatke za dan/noč ciklus – in bi nastalo zelo, zelo veliko podatkov.

Ploščice so 8bpp grafike z indeksirano paleto, vsaka z ločljivostjo 32x32 pikslov, ki so razporejene med seboj. V tako nastalem nizu ploščic pa je lahko še veliko več.

Glavni vsebinski blok je sestavljen iz dveh sekcij: head in data.

Na podlagi teh podatkov sledi še datoteka palete v standardiziranem formatu RIFF. Natančna specifikacija se nahaja - saj se palete pojavljajo tudi drugje - pod Palete.

Nakonec sledijo še surove podatke o pikselih, ki so razporejeni od zgoraj levo do spodaj desno, vrstično.
Vrednost podatka pri grafiki, ki je ponavadi predstavljena kot 8bpp-bitmapi, ustreza indeksu barve v barvni paleti.

Igračna enačba verjetno *na zahtevo* nariše ploščice.
Zdi se, da je to deloma posledica cikla dneva in noči, ki pozna 32 stopenj posameznih ploščic. Pri tem se očitno od vrednosti svetlosti 'malo' odšteje. Natančne vrednosti še niso bile določene, delam na osnovi izračuna

v *= (daylight / 48) + 0.25;

s podacimi HSV pik, pri čemer je daylight vrednost od 0 do 31, v pa vrednost med 0 in 1. Dodatno je treba upoštevati, da na zemljevidu obstaja še rob 16 ploščic levo in desno (to služi za nevidno pojavljanje enot).

Dodatno se zdi, da cikel dneva in noči na vsakem ciklu igre posodobi le en stolpec zemljevida.
Pospešen cikel dneva in noči je zato videti takole:

Za kaj točno PRT stoji, mi ni znano; mogoče bi lahko pomenilo 'Tabela palet in virov' - saj ta datoteka, ki jo najdemo kot op2_art.prt v maps.vol, dejansko predstavlja takšno, oziroma bi to funkcijo dobro opisalo.

Ta datoteka vsebuje seznam palet, tabelo vseh uporabljenih bitmapov, vse definicije animacij in še vrsto neznanih podatkov. Sledi do sedaj uporabljeni obliki kontejnerja le ohlapno, saj vsi zapisi ne sledijo temu shemi.

Odsek CPAL (verjetno pomeni kontejner palet) zajema le podatke o paletah, tako da navaja, koliko običajno 1052 bajtov velikih 8-bitnih palet je prisotnih.

Davčna oznaka 1052 bajtov ni obvezna, saj bi oblikovanje palet potencialno predvidevalo različne velikosti palet. Velja le za podatkovni sklop, s katerim je Outpost 2 dostavljen.

Po seznamu palet sledi takoj, brez uvodnega glave, seznam bitmapov; takoj za tem sledijo še seznami animacij.
Oba se začenjata z uint(32) (ali spet uint24+uint8 zastavice?), ki vsebuje število zapisov.

Informacije o paletah so zelo enostavne za branje.
Sestavljene so iz naslova in podatkovnega segmenta.

Podatkovni odsek zajema posamezne vnose palet. Število vnosov palet se izračuna iz dolžine bloka / 4.

Posamezni vnosi imajo preprosto strukturo;

O paletah pa lahko še rečem, da pri paletah, ki se uporabljajo za animacije, veljajo naslednja pravila:

• Prva barva je Vedno prozorna, ne glede na to, kakšna vrednost je tam navedena.
• Vnosi palete 1-24 se v paletah 1-8 štejejo kot barva igralca.
  Kje točno prihajajo barve izven igralca 1, mi ni jasno.
  Sumim, da so preostale barve hardcoded.

Ta podatkovna struktura PRT-datoteke določa, kako so zasnovani bitmapi, ki se uporabljajo za sprite. Ti bitmapi služijo kot posamezna komponenta, iz katere se sestavi več delov za animacijski okvir sprite.

Končni slikovni podatki so shranjeni v op2_art.BMP v igri.
Zakaj ta datoteka bitmape vsebuje (pretežno pravilno) RIFF-bitmap glavo, ni jasno. Verjetno Outpost 2 uporablja sistemske API-je za nalaganje grafike, pri čemer se ta glava začasno prevzame in ustrezna, spremenljiva polja prepišejo.

Piksli so v BMP-datoteki na položaju Offset + uint32-Offset, ki ga najdemo v BMP-datoteki na naslovu 0x000A (RIFF-bitmap-datotečni offset) - in ponovno ustrezajo vrstičnemu razporedu od zgoraj levo proti desno spodaj.

Monokromatske 1bpp grafike so lahko narisane tako, da barva 0 predstavlja popolno prosojnost, medtem ko barva 1 je polprosojna črna/siva, saj se monokromatske grafike ponavadi uporabljajo za sence vozil in zgradb v animacijah.

Tako lahko že sestavimo mnoge grafike.

Zdaj pridemo do kraljevske discipline znotraj formatov podatkov Outpost 2:
Do animacij.

Seznami animacij se začnejo z globalno glavo, ki služi predvsem za verifikacijo podatkov. Nato sledijo konkretne definicije animacij, ki so razdeljene v 3 ravni:

1. Animacija
   Animacija je najvišja instanca; predstavlja animacijo enote, stavbe ali 'delčne animacije' (kometski udar, vreme, eksplozija) v določenem izhodišču.
2. Frame
   Frame je posamezna slika znotraj animacije. Animacija lahko vsebuje enega ali več frame-ov.
3. Subframe
   Subframe je informacija, da naj se določena bitmapa pod določenimi kriteriji nariše na določeno mesto frame-a. Frame lahko vsebuje enega ali več subframe-ov.

Nato sledijo posamezne definicije animacij.

Podatki zgornje plasti animacije so predvsem upravljalski podatki - Boundingbox označuje koordinate oznake okoli vozila/poslopja, kadar je to izbrano, in hkrati označuje, kateri del je mogoče klikniti.

Offset predvsem določa "ničelno točko"; točko, ki se mora seštevati ali odštevati od notranjih koordinat igre. Matematično bi lahko rekli: offset tukaj označuje koordinatno izhodišče.

Oken je, prav tako kot offset, vsak (na okno) sestavljen iz 4 uint(32) vrednosti, ki določajo območje, ki velja za posamezne subframe. Zunaj oken se, če to ni predvideno za bitmaps, ne sme risati.

Tako lahko zdaj sestavljamo posamezne okvire, pa tudi celotne animacije, tukaj pa to ob demonstraciji bolj kompleksne animacije, animacije z indeksom 500.

Animacija 500 prikazuje, kako se Plymouth transporter, naložen z običajnimi minerali, raztovarja. To je ena redkih animacij, ki uporablja funkcionalnost oken.

In tako lahko sestavimo celotno animacijo.
Žal pa obstaja še en problem z zgornjim tovorom, saj tukaj ustrezni bit v informacijah o grafični vrsti ni nastavljen.

Tukaj je še nekaj drugih, čudovito animiranih sprite-ov iz igre:

Zdaj še manjka uporabniški vmesnik igre, ki je zasnovan v brušeni kovini.

Vendar pa je tudi tukaj očitno, da Dynamix ni bilo treba ponovno izumiti kolesa; tukaj ne izkoriščajo le preprosto API-jev User32 in GDI32, ki jih zagotavlja Windows - še posebej se uporablja upravljanje virov User32.

Ti se lahko na primer izvlečejo s programi, kot je Resource Hacker, ki ga je kot freeware razvil Angus Johnson, ali - če se pod Linuxom / Mac OS izogibate uporabi Wine - s pomočjo wrestool, ki je vključen v icoutils.