Formatet e skedarëve të Outpost 2 · bei.pm

Formatet e të dhënave të përdorura nga Outpost 2 kanë një strukturë që i ngjan JFIF / PNG - blloqet e ndryshme të të dhënave gjithmonë kanë një header prej 8 byte. Për këtë arsye, nuk e shoh të nevojshme të dokumentoj header-at e veçantë në vendet përkatëse specifike, por do të dokumentoj vetëm devijimet atje.

Formati është gjithmonë si më poshtë; të dhënat e vërteta janë të futur brenda tij:

Volumet janë një enë të dhënash për lojën, të ngjashme me një format arkivi si p.sh. Tarball. Pak a shumë në Outpost 2, formati njeh vetëm skedarët - jo dosjet. Probabilisht këto mund të simulojnë përmes emrave të skedarëve përkatës.

Një volum përbëhet nga titulli i volumit, si dhe nga disa blloqe volumesh që përkojnë me skedarët konkretë.

"Volumet" janë skedarët me përfundimin 'vol' në drejtorinë e lojës.

Koka e volumit nuk përmban asnjë të dhënë të dobishme.
Ajo shërben vetëm si një konteiner.

Si data e parë në kokën e volumit duhet të ndodhen vargjet e volumit; më pas vijnë informacionet mbi volumet.

Volume Strings janë një listë emrash dosjesh që janë të përfshira brenda volumit.

Informacionet e volumit përmbajnë informacione më të detajuara rreth skedarëve. Ato përfaqësojnë në njëfarë mënyre një lloj ndryshimi të regjistrit të FAT (FAT = Tabela e Alokimit të Skedarëve).

Numri i skedarëve llogaritet duke ndarë madhësinë e bllokut me gjatësinë e regjistrave të direktorëve - 14 byte.

Regjistrat individualë të direktorëve kanë secili këtë strukturë:

Në një volum-blok, kemi të bëjmë me një kontejner, i cili përmban skedarë. Ai përmban vetëm një herë - për shkak të formatit të blokut - në mënyrë të tepërt madhësinë e skedarit dhe pas saj vijnë menjëherë të dhënat e përdorimit.

Tiles janë një format specifik grafik Bitmap për Outpost-2. Ato shtrihen mbi 13 sets të tilesh, të quajtur "wells" (well0000.bmp deri në well0012.bmp), që ndodhen brenda volumit maps.vol.

Përveç kësaj, sets e tilesh / Wells përmbajnë sa vijon:

Është e rekomandueshme për një implementim të saktë që Tiles të mos renderohen paraprakisht për t'i ruajtur ato në cache, pasi të dhënat për ciklin ditë/natë ende duhet të përpunohen - dhe do të krijoheshin shumë shumë të dhëna.

Tile-t janë grafika 8bpp me paletë të indeksuar me rezolucion 32x32 piksel, të cilat janë të rregulluara njëra mbi tjetrën. Në një set të tillë Tile-esh megjithatë mund të ketë shumë më tepër

Kontaineri kryesor përbëhet nga 2 seksione: head dhe data.

Pas këtyre të dhënave, do të ketë gjithashtu një skedë palete në formatin e standardizuar RIFF. Specifikimi i saktë mund të gjendet - duke qenë se paletat shfaqen edhe në vende të tjera - nën Paletat.

Fundamentalisht, ndjekin të dhënat e pastra të pikselëve, nga majtas-lart rresht pas rreshti drejt poshtë-djathtas.
Vlera e të dhënave në grafikat që zakonisht janë në formën e 8bpp-Bitmaps i korrespondon indeksit të ngjyrës në paletën e ngjyrave.

Engjina e lojës regjistron Tiles *mendohet* on-demand.
Kjo duket se është për shkak të ciklit ditë-natë, i cili njeh 32 nivele të ndryshme të Tiles. Duket se për vlerën e ndriçimit hiqet 'pak' nga ajo. Vlerat e sakta ende nuk janë përcaktuar, unë po punoj mbi bazën e llogaritjeve

v *= (daylight / 48) + 0.25;

me të dhënat HSV të pikselëve, ku daylight është një vlerë nga 0-31 dhe v është një vlerë midis 0-1. Përveç kësaj, duhet të merret parasysh se në hartë ekziston gjithashtu një kufi prej 16 Tiles majtas dhe djathtas (që shërben për spavimin e padukshëm të njësive).

Përveç kësaj, cikli ditë-natë për çdo cikël loje, duket se përditëson vetëm një kolonë të hartës.
Një cikël ditë-natë i përshpejtuar duket kështu:

Për çfarë qëllimi që qëndron PRT saktësisht nuk e di; një mundësi mund të ishte 'Tabela e Paletave dhe Burimeve' - pasi që kjo skedar - e gjetur si op2_art.prt në maps.vol - është një e tillë, dhe kjo do ta përshkruante mjaft mirë funksionin e saj.

Ky skedar përmban një listë paletash, një tabelë mbi të gjitha bitmapet e përdorura, të gjitha definicionet e animacioneve dhe një sërë të dhënash të panjohura. Ai ndjek formatin e deritanishëm të kontejnerit në mënyrë të lirë, pasi jo të gjitha regjistrat i përmbahen këtij skeme.

Seksioni CPAL (ndoshta që do të thotë kontejner paletesh) përfshin vetëm të dhënat e paletave, duke treguar se sa prej paletave 8-bit, zakonisht me madhësi 1052 byte, janë të pranishme.

Përsa i përket madhësisë 1052 byte, ajo nuk konsiderohet e detyrueshme, pasi formati i paletave mund të parashikojë madhësi të ndryshme paletash. Ajo vlen vetëm për fondin e të dhënave me të cilin dorëzohet Outpost 2.

Pas listave të paletave, menjëherë dhe pa një header fillestar, vjen lista e bitmap-eve; po ashtu, menjëherë pas saj ndjekin listat e animacioneve.
Të dyja fillojnë secila me një uint(32) (ose përsëri uint24+uint8 flamuj?) që përmban numrin e regjistrave.

Informacionet mbi paletat janë shumë të lehta për t'u lexuar.
Ato përbëhen secila nga një header dhe një segment të dhënash.

Seksioni i të dhënave përfshin hyrjet individuale të paletave. Numri i hyrjeve të paletave llogaritet nga gjatësia e bllokut / 4.

Hyrjet individuale kanë këtë ndërtim të thjeshtë;

Për paletat, mund të themi se për paletat që përdoren për animacione, vlen rregulli si më poshtë:

• Ngjyra e parë është GJITHMONË transparente, pavarësisht se çfarë vlere është dhënë atje.
• Përcaktimet e paletave 1-24 konsiderohen si ngjyra lojtari në paletat 1-8.
  Ku vijnë ngjyrat përveç lojtarit 1, nuk më është e qartë.
  Unë mendoj se ngjyrat e tjera janë hardcoded.

Kjo strukturë të dhënash e skedarit PRT tregon se si janë ndërtuar bitmapet e përdorura për spritet. Këto bitmapet shërbejnë si një komponent i vetëm, nga i cili shumë janë bashkuar për të formuar një kornizë animacioni të një sprite.

Të dhënat specifike të imazhit fshihen në op2_art.BMP në direktorinë e lojës.
Pse ky skedar bitmap ka një (në tërësi të saktë) header RIFF-Bitmap, nuk është e qartë. Ndoshta Outpost 2 përdor API-të e sistemit për të ngarkuar grafikët, duke e marrë përkohësisht këtë header dhe duke e mbishkruar fushat përkatëse, të ndryshme.

Të dhënat e pikselëve ndodhen në skedarin BMP në pozitën Offset + uint32-Offset, e cila mund të gjendet në skedarin BMP në adresën 0x000A (offseti i të dhënave RIFF-Bitmap), dhe përsëri përputhen me renditjen rresht pas rreshti nga maja e majtë në të poshtme të djathtë.

Grafikat monochrome 1bpp mund të vizatohen në mënyrë që ngjyra 0 të jetë transparencë e plotë, ndërsa ngjyra 1 të jetë një e zezë/gri gjysmë transparente, pasi grafikat monochrome përdoren zakonisht për hijet e automjeteve dhe ndërtesave në animacione.

Kështu, mund të përbëhen shumë grafika.

Tani po kalojmë në klasën mbretërore të disiplinave brenda formateve të të dhënave të Outpost 2:
Animacionet.

Listat e animacioneve fillojnë me një header global, i cili shërben kryesisht për verifikimin e të dhënave. Pas tij vijnë definicionet konkrete të animacioneve, të cilat ndahen në 3 nivele:

1. Animacioni
   Një animacion është instanca kryesore; ai paraqet një animacion të një njësie, një ndërtese ose një 'animacion partikulesh' (rënia e kometave, moti, shpërthimi) në një situatë të caktuar.
2. Frame
   Një frame është një imazh i vetëm brenda një animacioni. Një animacion mund të përmbajë një ose më shumë frame.
3. Subframe
   Një subframe është informacioni që tregon se një bitmap e caktuar duhet të tërhiqet në një pozicion të caktuar të një frame nën kritere të caktuara. Një frame mund të përmbajë një ose më shumë subframe.

Pas kësaj, ndjekin direkt definicionet e veçanta të animacioneve.

Të dhënat e shtresës së sipërme, të animacionit, janë kryesisht të dhëna administrative - Boundingbox përfaqëson koordinatat e shenjës rreth automjetit/ndërtesës, kwhen e njëjta është e zgjedhur dhe gjithashtu tregon se cili rajon duhet të jetë i klikueshëm.

Offset-i përcakton kryesisht "pikën zero"; pikën, e cila duhet të llogaritet ose të hiqet nga koordinatat e brendshme të lojës. Mund të thuhet gjithashtu në mënyrë matematikore: offset-i përfaqëson këtu origjinën e koordinatave.

Windows-t janë, ashtu si offset-i, çdo herë (për secilën window) 4 vlera uint(32), të cilat tregojnë një rajon të cilin e konsiderojmë të përdorshëm për subframe të veçanta. Jashtë Windows-ve, nuk lejohet, përveç nëse është e parashikuar për Bitmap-in, të bëhet vizatim.

Kështu mund të përbëjmë tani korniza të veçanta, si dhe animacione të plota, këtu një shembull në një animacion më kompleks, animacioni me indeks 500, demonstruar

Animacioni 500 tregon si një transportues Plymouth, i ngarkuar me mineral të zakonshëm, shkarkohet. Kjo është një nga animacionet e pakta që përdor funksionalitetin e Windowing.

Dhe kështu mund të bashkohen të gjithë animacionet.
Për fat të keq, ka ende një problem me hapjen e sipërme të ngarkesës, pasi këtu biti përkatës në informacionin e llojit të grafikës nuk është vendosur.

Këtu ka disa sprite të tjera, të animuara mrekullisht nga loja:

Tani na mungon ndërfaqja e përdoruesit të lojës, e cila është në një stil metali të fërkuar.

Por gjithashtu këtu është e dukshme se Dynamix nuk kishte nevojë ta shpikë përsëri rrotën; këtu nuk përdoren thjesht API-të User32 dhe GDI32 të ofruara nga Windows - veçanërisht përdoret edhe menaxhimi i burimeve nga User32.

Këto mund të nxirren, për shembull, përmes programeve si Resource Hacker, e zhvilluar si freeware nga Angus Johnson, ose - nëse dikush heziton të përdorë Wine në Linux / Mac OS - me ndihmën e wrestool, e përfshirë në icoutils.