Outpost 2 Tiedostomuodot · bei.pm

Outpost 2:n käyttämät tiedostomuodot muistuttavat rakenteeltaan JFIF / PNG:ta - yksittäisillä tietolohkoilla on aina 8 tavun otsikko. Siksi jätän yksittäisten otsikoiden dokumentoinnin asianmukaisiin erityiskohtiin ja dokumentoin vain poikkeamat.

Muoto on aina seuraava; varsinaiset hyötydatat on sitten upotettu siihen:

Volyymit ovat pelin tietokontteja, jotka ovat samanlaisia kuin arkistomuodot, kuten esimerkiksi Tarball. Ainakin Outpost 2:ssa muoto tuntee vain tiedostoja - ei kansioita. Todennäköisesti nämä voitaisiin kuitenkin simuloida vastaavilla tiedostonimillä.

Volume koostuu volume-otsikosta sekä useista volume-lohkoista, jotka vastaavat konkreettisia tiedostoja.

"Volumes" ovat tiedostoja, joiden pääte on 'vol' pelin hakemistossa.

Volyymin otsikko itsessään ei sisällä mitään hyötydataa.
Sen ainoa tarkoitus on toimia säiliönä.

Volyymin otsikon ensimmäisenä tietona tulisi olla volyymin merkkijonot; niiden jälkeen seuraavat volyymin tiedot.

Volume Stringit ovat lista tiedostonimistä, jotka sisältyvät volyymiin.

Volumetiedot sisältävät tarkempia tietoja tiedostoista. Ne ovat eräänlainen FAT-hakemistorivi (FAT = File Allocation Table).

Tiedostojen määrä saadaan jakamalla lohkokoko hakemistotietueiden pituudella - 14 tavua.

Yksittäisten hakemistotietueiden rakenne on seuraavanlainen:

Volume-lohko on säiliö, joka sisältää tiedostoja. Se sisältää vain uudelleen - lohkomuodon vuoksi - redundanteisti tiedoston koon, ja sen jälkeen seuraavat suoraan käyttödatat.

Tiles ovat Outpost-2:een liittyvä bitmapsovelluksen grafiikkamuoto. Ne kattavat 13 Tilesettiä, "kaivoiksi" kutsuttua (well0000.bmp:sta well0012.bmp:een), jotka sijaitsevat maps.vol -tiedostossa.

Tileseteissä / Kaivoissa on seuraavaa:

On suositeltavaa, että tarkka toteutus ei renderöi laattoja etukäteen välimuistia varten, koska päivän/yön syklin tiedot täytyy vielä käsitellä - ja dataa syntyy todella paljon.

Laatoissa on 8bpp-grafiikka indeksoidulla väriavaruudella, jokainen 32x32 pikselin resoluutiolla, ja ne on järjestetty toistensa viereen. Tällaisessa laattaasetelmassa voi kuitenkin olla huomattavasti enemmän

Pääsäiliö koostuu kahdesta osiosta: head ja data.

Tämän tiedon perusteella seuraa vielä yksi standardoidussa RIFF-muodossa oleva palettitiedosto. Tarkka erittely löytyy - koska paletit esiintyvät muuallakin - kohdasta Väripaletit.

Lopuksi seuraavat puhtaat pikselidatat, vasemmasta yläkulmasta riveittäin oikeaan alakulmaan.
Datan arvo, joka yleensä vastaa 8bpp-bitmapeissa olevia grafiikoita, vastaa värin indeksiä väripalettissa.

Pelimoottori piirtää laatat *todennäköisesti* kysynnän mukaan.
Tämä näyttää johtuvan muun muassa päivä- ja yösyklistä, jossa on 32 asteikkoa yksittäisille laatoille. Ilmeisesti kirkkausarvosta vähennetään aina 'hieman'. Tarkkoja arvoja ei ole vielä pystytty määrittämään, työskentelen laskentaperustalla

v *= (daylight / 48) + 0.25;

HSV-tietojen avulla pikseleistä, missä daylight on arvo 0-31 ja v on arvo välillä 0-1. Lisäksi on otettava huomioon, että kartalla on kummallakin puolella vielä 16 laatan reunus (joka palvelee yksiköiden näkymättömän ilmestyksen tarkoitusta).

Lisäksi päivä- ja yösykli näyttää päivittävän vain yhden sarakkeen kartasta jokaisen pelisykli aikana.
Vauhdikkaampi päivä- ja yösykli näyttää näin ollen seuraavalta:

Mitä PRT tarkalleen ottaen tarkoittaa, ei ole minulle selvää; mahdollinen merkitys voisi olla esimerkiksi 'Palette and Resource Table' - koska tämä tiedosto, joka löytyy nimellä op2_art.prt maps.vol -kansiossa, liittyy tällaiseen, tai tämä kuvaa toimintoa varsin hyvin.

Tämä tiedosto sisältää luettelon paleteista, taulukon kaikista käytetyistä bitmap-kuvista, kaikki animaatiomääritelmät ja joukon tuntemattomia tietoja. Se noudattaa suurin piirtein aiempaa säilömuotoa, sillä kaikki tietueet eivät noudata tätä kaavaa.

CPAL-osio (todennäköisesti tarkoittaa palettisäilöä) kattaa vain palettitiedot ilmoittamalla, kuinka monta tavallisesti 1052 tavun kokoista 8-bittistä palettia on olemassa.

1052 tavun ilmoitusta ei pidetä sitovana, sillä palettimuoto voi periaatteessa sisältää erilaisia palettikokoja. Se koskee vain tietojoukkoa, joka on mukana Outpost 2:ssa.

Palettien luettelon jälkeen seuraa välittömästi ja ilman johdanto-otsikkoa bitmap-luettelo; samoin seuraavat animaatiolistat.
Molemmat aloitetaan kukin uint(32):lla (tai taas uint24+uint8 liput?) joka sisältää tietueiden määrän.

Paletteinformaatio on erittäin helppolukuista.
Se koostuu aina otsikosta ja datasegmentistä.

Datan osio sisältää yksittäiset laatikkotiedot. Laatikkotietojen määrä saadaan lohkon pituudesta / 4.

Yksittäisillä tiedoilla on seuraava yksinkertainen rakenne;

Paleteista on vielä sanottava, että animaatioissa käytettävien palettien osalta käytetään seuraavia sääntöjä:

• Ensimmäinen väri on AINA läpinäkyvä, riippumatta siitä, mikä arvo siellä on.
• Palettien merkinnät 1-24 lasketaan pelaajaväreiksi paleteissa 1-8.
  Mistä värit pelaaja 1:n ulkopuolella tarkalleen ottaen tulevat, ei ole minulle selvää.
  Arvelen, että loput värit ovat hardcoded.

Tämä PRT-tiedoston tietorakenne ilmoittaa, kuinka spriteille käytetyt bitmapit on rakennettu. Nämä bitmapit toimivat yksittäisinä osina, joista useita yhdistetään spriten animaatiokehyksessä.

Konkreettiset kuvadata piileksivät kuitenkin pelin hakemistossa op2_art.BMP:ssä.
Miksi tämä bitmap-tiedosto sisältää (enimmäkseen oikein) RIFF-bitmap-otsikon, on epäselvää. Todennäköisesti Outpost 2 käyttää järjestelmän API:ita grafiikoiden lataamiseen, ottamalla tämän otsikon tilapäisesti käyttöön ja ylittämällä vastaavat, vaihtelevat kentät.

Pikselidataa löytyy BMP-tiedostosta Offset + uint32-offset -sijainnista, joka löytyy BMP-tiedostosta osoitteesta 0x000A (RIFF-bitmap-datan offset), ja se vastaa jälleen ylhäältä alas oikealle suuntautuvaa rivijärjestystä.

Monokromaattisia 1bpp-grafiikoita voidaan piirtää siten, että väri 0 on täysin läpinäkyvä, ja väri 1 on puoliksi läpinäkyvä musta/harmaa, koska monokromaattisia grafiikoita käytetään yleisesti ajoneuvojen ja rakennusten varjoissa animaatioissa.

Tällä tavoin voi jo koota monia grafiikoita.

Nyt siirrymme Outpost 2 -tiedostomuotojen huipputason kurinalaisuuksiin:
Animaatioihin.

Animaatioruettelot alkavat globaalilla otsikolla, joka palvelee ensisijaisesti tietojen varmennusta. Tämän jälkeen seuraavat varsinaiset animaatiomääritelmät, jotka jakautuvat kolmeen tasoon:

1. Animaatio
   Animaatio on korkein taso; se esittää animaatiota yksiköstä, rakennuksesta tai 'hiukkasanimaatiosta' (komettakolari, sää, räjähdys) tietyssä lähtötilanteessa.
2. Kehys
   Kehys on yksi kuva animaatiossa. Animaatio voi sisältää yhden tai useamman kehyksen.
3. Alakehys
   Alakehys on tieto siitä, että tietty bitmap on piirrettävä tiettyyn kehykseen tietyillä kriteereillä. Kehys voi sisältää yhden tai useamman alakehyksen.

Sitten seuraavat suoraan yksittäiset animaatiomääritelmät.

Ylimmän tason, animaation, tiedot ovat ensisijaisesti hallintotietoja - Boundingbox tarkoittaa auton/rakennuksen ympärillä olevia koordinaatteja, kun se on valittuna, ja se myös osoittaa, mikä alue on klikattavissa.

Offset määrittää ensisijaisesti "nollapisteen"; pisteen, jota pelin sisäisiin koordinaatteihin kuuluu lisätä tai vähentää. Voisi myös sanoa matemaattisesti: offset tarkoittaa tässä koordinaattien alkuperää.

Ikkunoissa on, aivan kuten offsetissa, kullekin ikkunalle 4 uint(32) -arvoa, jotka määrittävät alueen, joka on käytettävissä yksittäisille alarunkoille. Ikkunoiden ulkopuolella ei saa piirtää, ellei bitmapille ole erikseen varattu tilaa.

Nyt voimme koota yksittäisiä kehyksiä sekä kokonaisia animaatioita. Tässä esimerkkinä monimutkaisemmasta animaatiosta, animaatiosta, jonka indeksi on 500, demonstroidaan.

Animaatio 500 näyttää, kuinka Plymouth-kuljetusauto, joka on tavallisilla mineraaleilla kuormattu, puretaan. Tämä on yksi harvoista animaatioista, jotka hyödyntävät ikkunointitoimintoa.

Niinpä koko animaatio voidaan yhdistää.
Valitettavasti yläkuormausluukun kanssa on edelleen ongelma, sillä vastaavaa bittiä grafiikkatyyppitiedossa ei ole asetettu.

Tässä vielä muutamia kauniisti animoituja spritejä pelistä:

Nyt puuttuu vielä pelin käyttöliittymä, joka on toteutettu harjatun metallin ilmeellä.

Kuitenkin on myös selvää, että Dynamix ei tarvinnut keksiä pyörää uudelleen; tässä ei vain yksinkertaisesti käytetä Windowsin tarjoamia User32- ja GDI32-API:ita - erityisesti myös User32:n resurssienhallintaa hyödynnetään.

Näitä voidaan esimerkiksi purkaa ohjelmilla, kuten Angus Johnsonin ilmaisohjelmalla Resource Hacker, tai - jos Linuxilla / Mac OS:lla vältetään Winen käyttöä - apuna voidaan käyttää icoutilsin mukana tulevaa wrestoolia.