Outpost 2 Dátufyrimyndir · bei.pm

Dati, sum verður brúkt í Outpost 2, hava eina uppbygging, sum minnir um JFIF / PNG - deildirnar hava altíð eina 8 byte hedar. Tí spari eg meg fyri at dokumentera einstøku heðarnar á teimum serligu støðunum og dokumentera bert avvik.

Formatin er altíð hesin; søguligu nyttudaturnar eru so innbýttar í tað:

Volumini eru ein dátupakk fyri spelet, líkt einum arkivformat, so sum Tarball. Í minsta lagi í Outpost 2 kennir formatini bert til dátufailar - eingi mappar. Sannlíkt ber til at simulera hetta við at brúka svarandi datunøtt.

Eitt volume består av volume-headerinum og fleiri volume blokkum, sum svara til serligu dátufailarnar.

"Volumes" eru dátufailarnar við endingini 'vol' í speletmyndini.

Volume Header'in einki nýtsluupplýsingar í sær.
Hann tænir bert sum ein íløgukassi.

Fyrsta dátan í Volume Header'in eru Volume Strings; eftir tað koma so Volume-upplýsingarnar.

Í Volume Strings er talan um ein lista av fílunøttum, sum eru við í volume.

Volume-upplýsingarnar taka við fleiri ítøkiligum upplýsingum um skrárnar. Hetta er á ein hátt ein slags FAT-skráseting (FAT = File Allocation Table).

Útrokningin av skránum kemur frá blokkstørrelsen deilt við lengdin av skrársetingunum - 14 byte.

Hver einstaka skrárseting hevur hendan uppbygning:

Ein volumeblokkur er ein kassi, sum tekur móti skrám. Hann inniheldur bara einaferð til - vegna blokkformatin - avskipaða skrásstøddina, og síðani fylgja beinleiðis brúkaradatar.

Tile-ini eru eitt serligt Bitmap-grafikformat fyri Outpost-2. Teir strika seg yvir 13 tilesets, kallað "wells" (well0000.bmp til well0012.bmp), sum eru inni í volumini maps.vol.

Tilesets / Wells innihalda hetta:

Hetta er ráðiligt fyri eina nákvæma framleiðslu, at tiles ikki verða rendrað áðrenn, fyri at kunna cache'a teir, tí at dátan fyri dag/náttarlagið má enn verða bearbeidd - og tað vil skapa nógv nógv data.

Tile'ini eru 8bpp-grafikkur við indexeraðari palettu, hvør við 32x32 pikslar uppløtt, sum standa saman. Í einum so framkomnum tileset kunnu tó nógv meira

Høvuðskontainarin er bygdur upp av 2 seksjónum: head og data.

Afturat hesum upplýsingum fer ein pallfíl við standardiseruðum RIFF-formati. Náttúran av spesifikasjónini kann finnast - tí pallarnir eisini eru aðrastaðni - á Pallir.

Aftur fylgir tað beinleiðis pixeldaturnar, frá vinstru-uppi línuliga móti høgru-neðri.
Datavirðið hjá teimum grafikkunum, sum vanliga eru 8bpp-bitmaps, svarar til indeksin av litinum í litpalettuni.

Spil-Engine'in málar Tiles *kanska* on-demand.
Hetta tykist millum annað at vera tengt til dag-náttarsyklusin, sum hevur 32 stig av einstøkum Tiles. Her verður greitt frá, at eitt 'lítið' verður dregið frá ljósverdi. Nákvæmar virði eru framvegis ikki komin fram, eg arbeiði útfrá útreikningargrunni

v *= (daylight / 48) + 0.25;

við HSV-datum av pikslar, har daylight er eitt virði frá 0-31, og v er eitt virði millum 0-1. Afturat hesum er at taka í mánað, at á kortinum eru enn 16 Tiles til vinstru og høgru (hesi tæna til ósjónliga spawning av einingum).

Afturat hesum tykist dag-náttarsyklusin bert at uppdatera eina kolonu á kortinum hvørja ferð í einum gamecycle.
Ein skundaður dag-náttarsyklus sær tí út soleiðis út:

Hvat PRT nøyaktiliga stendur fyri, er mær ikki kunnugt; hugsaði um til dømis 'Palette and Resource Table' - tí tað snýr seg um hesa filina - at finna sum op2_art.prt í maps.vol - sum er ein slíkur, ella hetta kundi lýst funktiónina væl.

Henda filin inniheldur eina lista av palettum, eina tabellu yvir allar brúktar bitmap-ar, allar animatiónsdefineringar og enn eina røð av ókendum upplýsingum. Hon fylgir fram til núverandi containerformatinum leyst, tí ikki allar dataskrivi fylgja hesum skemanu.

CPAL-sektionen (stendur kanska fyri palettukontainer) umfatttur bert palettudatuna, við at vísa, hvussu mong av teimum vanligu 1052 byte stórum 8-bit palettum eru til staðar.

1052-byte angivin verður ikki mettað sum bindandi, tí palettuformatini kunnu potensielt hava ymiskar palettustøddir. Hon er bert galdandi fyri datalagerið, sum Outpost 2 verður útgivin við.

Eftir palettulistarnar fylgir beint og uttan inntøkuheader, longu listin av bitmap-ar; líka so beint fylgja so animatiónslistarnar.
Bæði verða byrjað við einum uint(32) (ella aftur uint24+uint8 flagg?) sum inniheldur talvuna av dataskrivum.

Palettupplýsingarnar eru very einfaldar at lesa.
Teir eru gjørdir av einum header og einum data-segmenti.

Datasektionen taka ímóti einstøku pallhúsini. Talvan av pallhúsum kemur fram úr blokk-longdini / 4.

Einstøku innlættini hava hesa, einfaldan uppbygning;

Til palettarnar er bert at siga, at fyri animationir brúktar palettir gilda hesar reglur:

• Fyrsta liturin er ALTID transparent, óansæð hvørjin verdi er givin har.
• Palett-innskot 1-24 skulu metast sum spælaralitir í palettum 1-8.
  Hvar litirnir koma frá uttan frá spælara 1 er mær ógreitt.
  Eg ætla, at restin av litunum er hardcoded.

Henda data-strukturin í PRT-failinum vísar til, hvussu bitmappirnir, sum verða nýttir til sprites, eru bygdir. Hesir bitmappir eru einliðandi partur, har fleiri verða samansett til ein animaferð í einum sprite.

Teir konkretu mynddata eru afturímóti at finna í op2_art.BMP í spælinum mappa.
Hví henda bitmap-failin hevur ein (fyrr mest rættan) RIFF-bitmap-header, er ógreitt. Kanska brúkar Outpost 2 system-API'ir at hlaða grafikkarnar, har hesin header verður temporært ílagdur og viðkomandi, breytandi felti verða yvirskrivað.

Pixeldaturnar eru í BMP-failinum á tilfari Offset + uint32-Offset, sum er at finna í BMP-failinum á adresu 0x000A (RIFF-bitmap-data offset), til finna - og svarar aftur til línuliga uppsetningin frá vinstra aftur til høgru niðri.

Monokrome 1bpp-grafikkir kunnu verða málaðar, soleiðis at litur 0 er fullkomin transparens, meðan litur 1 er hálvtransparantur svart/grátt, tí monokromu grafikkirnar vanliga verða nýttar til kjøretøyi og bygningaskuggar í animatiónunum.

Hetta ger, at man longu kann seta nógv grafikkir saman.

Nú koma vit til kongaklassan í disiplinunum innan Outpost 2 dataformata:
Animationirnar.

Animationslistarnar byrja við einum globalum header, sum fyrst og fremst tænir til dátuverifikation. Eftir fylgja tær konkrettu animationsdefinitiónirnar, sum eru uppbygd í 3 stig:

1. Animation
   Ein animation er hægsta instans; hon vísir eina animation av einari eining, einari bygning ella einari 'partikulanimation' (kometaskot, veður, eksplosjón) í einum ávísum útgangsstøðu.
2. Frame
   Eitt frame er eitt einstakt mynd innan eina animation. Ein animation kann hava eitt ella fleiri frames.
3. Subframe
   Eitt subframe er upplýsing um, at ein ávís bitmap skal verða málað undir ávísum dømum á eina ávíst støðu av einari frame. Ein frame kann hava eitt ella fleiri subframes.

Eftir hetta koma tær serligu animationsdefinitiónirnar beint eftir.

Upplýsingarnar í ovasta lagnum, animatiónini, eru fyrst og fremst stjórnarupplýsingar - Boundingbox vísir til koordinaturnar hjá merkinum rundan um bil/bygning, nær tað er valt, og gevur eisini vísing til, hvørjar økir skulu vera klikkbar.

Offsetið avger fyrst og fremst "nullpunktið"; punktin, sum skal leggjast at, ella dragast frá spølini-internu koordinatum. Man kundi eisini sagt matematiskt: offsetið vísir her til koordinatursupruni.

Her eru vindeytini, eins og við offsetinum, 4 uint(32)-virði fyri hvørt vindeyti, som vísa eina øki, sum er brúkt fyri einstakar subframes. Uttan fyri vindeytini, so leingi sum tað er ætlað fyri bitmapina, má ikki málast.

Vit kunnu nú seta saman einstaka frames, so væl sum fullar animationer, her vísast ein dømi av eini meira komplisert animation, animationina við index 500.

Animation 500 vísir, hvussu ein Plymouth-transportør, sum er læddur við vanligum malm, verður leyslagdur. Hetta er ein av fáu animationunum, sum nýtir vinduvirkna.

Soleiðis kann man samanseta alla animationina.
Óheppiliga er tað enn eitt trupulleiki við ovastu lastlúkuna, tí at her er tað svarandi bit í grafikktypupplýsingunum ikki sett.

Her eru eisini nakrar aðrar, vøttandisliga animeraðar sprites úr spølunum:

Nú manglar enn brúkaragrunnin til spelet, sum er hildin í einum børstaðum metal-útbúgving.

Men eisini her er greitt, at Dynamix ikki mátti uppfinna hjólið aftur; her verða ekki bara beinleiðis nýtt API'ini frá Windows, User32 og GDI32 - serliga verður eisini ressursumanagementið hjá User32 brúkt.

Hetta kann til dømis útvørðast við hjálp av programum sum tað frá Angus Johnson, sum er frítt tilfar, Resource Hacker, ella - um tú skalt brúka Linux / Mac OS og einki ynskir at brúka Wine - við hjálp av wrestool, sum er í icoutils.