Outpost 2 skráarsnið · bei.pm

Þau gagnasnið sem Outpost 2 notar hafa uppbyggingu sem minnir á JFIF / PNG - einstaka gagnablökin hafa alltaf 8 bita fyrirsagnir. Þess vegna sleppi ég því að skrá fyrirsagnirnar á tilgreindum stöðum og skrá aðeins frávik þar.

Sniðið er alltaf eftirfarandi; raunverulegu gagnin eru þá innbyggð í því:

Volumes eru gögnagámar fyrir leikinn, svipað og skjalasnið eins og Tarball. Að minnsta kosti í Outpost 2 þekkir sniðið aðeins skjal - engar möppur. Líklegt er að hægt væri að herma þetta með viðeigandi skjalanafni.

Ein Volume samanstendur af Volume-fyrirsagninni auk nokkurra Volume blokkra sem samsvara tilteknum skrám.

"Volumes" eru skjalin með endingunni 'vol' í leikaskránni.

Volume hausamurinn inniheldur sjálfur engin notkunargögn.
Hann þjónar aðeins sem gáma.

Þeir Volume strengir ættu að vera fyrsta dagsetningin í Volume hausamurnum; síðan fylgja upplýsingarnar um Volume.

Volume strengjarnir eru lista yfir skráarnafn sem eru innifalin í volume-inu.

Volume-upplýsingarnar innihalda ítarlegri upplýsingar um skrárnar. Þessar upplýsingar eru í vissum skilningi svona eins og FAT-skráning (FAT = File Allocation Table)

Fjöldi skrár kemur fram með því að deila blokkastærð með length á skrárskrám - 14 bætum.

Hver skrárskrá hefur eftirfarandi uppbyggingu:

Volume-blokk er í rauninni gáma, sem tekur við skrám. Hann inniheldur aðeins einu sinni til viðbótar - vegna blokkarsniðsins - auka skráarstærðina og síðan koma beint á eftir notendagögnin.

Hér er um að ræða sérstakt bitmap-grafíkerfnisform fyrir Outpost-2. Þeir ná yfir 13 flísasett, kallaðir "wells" (well0000.bmp til well0012.bmp), sem eru innan rúmsins maps.vol.

Flísasettin / Wells innihalda eftirfarandi:

Það er ráðlagt að framkvæma nákvæmlega, að rendera flísarnar ekki fyrirfram til að geyma þær, þar sem gögnin fyrir dag/nótt hringrásina þurfa enn að vinna - og mjög, mjög mikil gögn myndu safnast.

Flísarnar eru 8bpp grafík með indexaðri palettu á 32x32 pixla upplausn, sem raðað er saman. Í slíkum flísasafni er hins vegar hægt að hafa miklu fleiri

Aðal gáminn samanstendur af 2 sektionum: head og data.

Eftir þessar upplýsingar kemur enn ein palettuskrá í staðlaða RIFF-sniði. Nákvæm sérsniðin er að finna - þar sem palettur koma einnig fram á öðrum stöðum - undir Palettur.

Að lokum fylgja hreinu pixeldatarnir, frá vinstri efst raðað eftir röð niður í hægra horn.
Verdid í gögnunum sem venjulega koma fram sem 8bpp-bitmaps samsvarar vísinum á litnum í litapalettunni.

Leikjaforritið teiknar flísarnar *sennilega* eftir þörfum.
Þetta virðist meðal annars vera vegna dags- og næturhringsins, sem þekkir 32 stig af einstökum flísum. Í því ferli er greinilega 'lítið' dregið frá birtumætinu. Nákvæm gildi hafa ekki verið ákveðin enn, ég vinn út frá útreikningum

v *= (daylight / 48) + 0.25;

með HSV-gögnum pixla, þar sem daylight er gildi á bilinu 0-31 og v er gildi á bilinu 0-1. Auk þess þarf að hafa í huga að á kortinu er einnig til 16 flísar rúm á vinstri og hægri hlið (sem þjónar til ósýnilegs spawns eininga).

Auk þess virðist dags- og næturhringurinn aðeins uppfæra eina súlu á kortinu í hverju leiktímabili.
Hratt dags- og næturhringur lítur því út eins og hér segir:

Hvað PRT stendur nákvæmlega fyrir er mér ekki kunnugt; hugsanlegt væri til dæmis 'Palette and Resource Table' - þar sem þessi skrá - að finna sem op2_art.prt í maps.vol - er af þeirri gerð, eða þetta myndi lýsa virkni hennar frekar vel.

Þessi skrá inniheldur lista af paletum, töflu um allar notaðar bitamyndir, allar skilgreiningar á hreyfingum og einnig fjölda óþekktra gagna. Hún fylgir lauslega fyrra skáldformi, þar sem ekki allar skráð gögn fylgja þessu mynstur.

CPAL-hlutinn (sem líklega stendur fyrir paletuhaldara) umlykur aðeins paletugögnin, með því að tilgreina hversu margar af venjulegu 1052 bita stórum 8-bita paletum eru til staðar.

1052-bita tilgreiningin er ekki talin bindandi, þar sem paletufræðin gæti hugsanlega haft mismunandi paletustærðir. Hún gildir aðeins fyrir gögnin sem Outpost 2 er afhent með.

Eftir paletulistana fylgir strax og án forskriftar, listi yfir bitamyndir; og þar á eftir fylgja hreyfingalistarnir strax.
Báðir eru hver um sig hafnir með uint(32) (eða aftur uint24+uint8 merki?) sem inniheldur fjölda skráðra gagna.

Upplýsingarnar um pallana eru mjög auðvelt að lesa.
Þær samanstanda af fyrirsagnarpunkti og gögnunum.

Datasamningurinn tekur við einstökum pallettuinnskotum. Fjöldi pallettuinnskota kemur fram úr blokkarlengd / 4.

Einstök innskot hafa einfaldan uppbyggingu eins og hér segir;

Um palettunum er aðeins að segja, að fyrir palettur sem notaðar eru í animationum gilda eftirfarandi reglur:

• Þriðja liturinn er ALLTAF gegnsær, sama hvað gildi er gefið.
• Palettueinleggin 1-24 teljast sem leikmannalitur í palettum 1-8.
  Hvar litirnir, aðrir en leikmaður 1, koma nákvæmlega frá er mér óljóst.
  Ég geri ráð fyrir að hinir litirnir séu hardcoded.

Þetta gögnaskipulag PRT-skrárinnar vísar til þess hvernig bitmap-áskriftirnar sem notaðar eru fyrir spriturnar eru byggðar. Þessar bitmap-áskriftir þjóna sem einstök eining, þar sem margar eru settar saman í animasjonsramma fyrir sprit.

Þau ákveðnu myndgögn eru aftur á móti falin í op2_art.BMP í leikjaskránni.
Hvers vegna þessi bitmap-skrá hefur RIFF-bitmaphaus (að mestu leyti rétt), er óljóst. Væntanlega notar Outpost 2 kerfis-API til að hlaða grafík, með því að taka tímabundið við þessum haus og skrifa yfir viðeigandi, breytilegu reitina.

Pixlagögnin eru í BMP-skránni á stöðu Offset + uint32-Offset, sem er að finna í BMP-skránni á adresu 0x000A (RIFF-bitmap-gagnastöð), og samsvarar aftur línulegri uppsetningu frá efst til vinstri niður til hægri.

Einlit 1bpp grafík getur verið teiknuð þannig að litur 0 sé algjörlega gegnsær, og litur 1 verði hálfgegnsætt svart/svartan, þar sem einlita grafík er venjulega notuð fyrir skugga farartækja og bygginga í animasjónunum.

Þannig er hægt að setja saman margar grafík.

Nú förum við í konungsklassa greina innan Outpost 2 gagnasniðanna:
Þeirra sem snerta á animations.

Animationslistarnir byrja með alheimsheiti sem þjónar fyrst og fremst til gagnavottunar. Því næst koma tilteknar animationsskilgreiningar sem skiptast í 3 stig:

1. Animation
   Animation er efsta einingin; hún sýnir animation fyrir einingu, byggingu eða 'partikla-animation' (kometáfall, veður, sprenging) í ákveðnu upphafi.
2. Frame
   Frame er einstakt mynd í animation. Animation getur innihaldið eitt eða fleiri frames.
3. Subframe
   Subframe er upplýsingarnar um að ákveðin bitmap eigi að teiknast á ákveðna staðsetningu á frame undir ákveðnum skilyrðum. Frame getur innihaldið eitt eða fleiri subframes.

Því næst koma strax einstakar animationsskilgreiningar.

Gögnin í efstu lögun, sem tengjast animation, eru fyrst og fremst stjórnunargögn - Boundingbox vísar hér til hnitanna sem umlykur farartækið/bygginguna, þegar það er valið og gefur jafnframt til kynna hvaða svæði á að vera smellanlegt.

Offset-ið ákveður fyrst og fremst "núllpunktinn"; punktinn sem á að reikna á móti eða draga frá innanhúss hnitum. Það má einnig segja á stærðfræðilegan hátt: offset-ið vísar hér til hitnagrunns.

Í Windows er um að ræða, eins og við offset-ið, 4 uint(32)-gildi fyrir hvert Window, sem gefa til kynna svæði sem telst nothæft fyrir einstaka subframes. Utan Windows má ekki, svo framarlega sem það sé ekki tilgreint fyrir bitmap-ið, teikna.

Með þessu getum við nú sameinað einstaka ramma, sem og heilar hreyfimyndir, hér er sýnt sem dæmi á flóknari hreyfimynd, hreyfimyndinni með index 500.

Animation 500 sýnir hvernig Plymouth-flutningabíll, sem er fullur af venjulegu málmi, er tæmdur. Þetta er ein af fáum teiknimyndum sem notar gluggastjórnunar virkni.

Þannig má sameina alla teiknimyndina.
Því miður er enn eitt vandamál með efri hleðslulúguna, þar sem viðkomandi bit í grafíkgerðarupplýsingunum er ekki stillt.

Hér eru nokkrir aðrir, fallega teiknaðar sprit úr leiknum:

Nú vantar enn notendaviðmót leiksins, sem er í burstaðri málm-útliti.

En einnig hér sést að Dynamix þurfti ekki að enduruppgötva hjólið; hér eru ekki bara einfaldlega notaðar User32- og GDI32-API sem Windows býður upp á - sérstaklega er einnig notað auðlindastjórnun frá User32.

Þetta má til dæmis vinna úr með forritum eins og Resource Hacker, sem Angus Johnson þróaði sem fríforrit, eða - ef maður óttast að nota Wine á Linux / Mac OS - með hjálp wrestool sem er innifalið í icoutils.