Formate de fișier Outpost 2 · bei.pm

Formatele de date utilizate de Outpost 2 au o structură care amintește de JFIF / PNG - blocurile de date individuale au întotdeauna un header de 8 Bytes. Prin urmare, nu voi documenta fiecare header în locurile specifice corespunzătoare, ci voi documenta doar abaterile.

Formatul este întotdeauna următorul; datele propriu-zise sunt încorporate în acesta:

Volițele sunt un container de date pentru joc, asemănător cu un format de arhivă, cum ar fi Tarball. În cel puțin Outpost 2, formatul cunoaște doar fișiere - fără foldere. Cel mai probabil, acestea ar putea fi simulate prin denumiri corespunzătoare ale fișierelor.

Un volum constă din antetul volumului, precum și din mai multe blocuri de volum, care corespund fișierelor concrete.

"Volumele" sunt fișierele cu extensia 'vol' din directorul jocului.

Antetul volumului nu conține date utile.
Acesta servește doar ca un container.

Primul element în antetul volumului ar trebui să fie șirurile volumului; urmate apoi de informațiile despre volum.

Volume Strings reprezintă o listă de nume de fișiere care sunt incluse în volum.

Informațiile despre volum conțin detalii mai aprofundate despre fișiere. Acestea reprezintă, într-un fel, un fel de înregistrare în director FAT (FAT = File Allocation Table)

Numărul de fișiere rezultă din dimensiunea blocului împărțită la lungimea înregistrărilor din director - 14 octeți.

Fiecare înregistrare din director are următoarea structură:

Un volum-block este un container care găzduiește fișiere. Acesta conține doar din nou - datorită formatului block - redundant dimensiunea fișierului, iar apoi urmează direct datele utilizatorului.

Tile-urile sunt un format grafic bitmap specific pentru Outpost-2. Acestea se extind pe 13 seturi de tile-uri, numite "wells" (well0000.bmp până la well0012.bmp), ce se află în interiorul volumului maps.vol.

În cadrul seturilor de tile-uri / Wells se regăsesc următoarele:

Este recomandat pentru o implementare precisă să nu se redea în avans tile-urile pentru a le salva în cache, deoarece datele pentru ciclul zi/noapte trebuie să fie încă procesate - și ar genera foarte, foarte multe date.

Tile-urile sunt grafice 8bpp cu paletă indexată, fiecare având o rezoluție de 32x32 pixeli, aranjate unele peste altele. Într-un astfel de set de tile-uri pot exista însă mult mai multe

Containerul principal este format din 2 secțiuni: head și data.

În urma acestor informații, va urma un fișier de paletă în format RIFF standardizat. Specificația exactă se găsește - deoarece paletele apar și în alte locuri - sub Palete.

În cele din urmă, urmează datele pixelilor brute, de sus în stânga, pe rând, spre jos dreapta.
Valoarea datelor pentru graficele care sunt de obicei prezentate ca bitmap-uri 8bpp corespunde indexului culorii în paleta de culori.

Engine-ul de joc desenează tile-urile *probabil* la cerere.
Asta pare să se datoreze, printre altele, ciclului zi-noapte, care cunoaște 32 de nuanțe ale tile-urilor individuale. Se pare că de fiecare dată se scade 'puțin' din valoarea de luminozitate. Valorile exacte nu au fost încă stabilite, lucrez pe baza calculelor

v *= (daylight / 48) + 0.25;

cu datele HSV ale pixelilor, unde daylight este o valoare de 0-31 iar v este o valoare între 0-1. În plus, trebuie să se țină cont că pe hartă există câte un margine de 16 tile-uri pe stânga și pe dreapta (acesta servește pentru spawn-ul invizibil al unităților).

În plus, ciclul zi-noapte pare să actualizeze doar o coloană a hărții pentru fiecare ciclu de joc.
Un ciclu zi-noapte accelerat arată astfel:

Ce înseamnă exact PRT nu știu; o posibilitate ar fi, de exemplu, 'Palette and Resource Table' - deoarece acest fișier - găsit sub numele op2_art.prt în maps.vol - este unul de acest tip, sau aceasta ar descrie destul de bine funcția sa.

Această fișier conține o listă de palete, o tabelă cu toate bitmap-urile utilizate, toate definițiile animațiilor și o serie de date necunoscute. Urmează în mod liber formatul de container precedent, deoarece nu toate înregistrările respectă acest schema.

Secțiunea CPAL (probabil pentru container de palete) cuprinde doar datele paletei, specificând câte dintre paletele de 8 biți, fiecare având de obicei 1052 de octeți, sunt prezente.

Mențiunea de 1052 de octeți nu este considerată obligatorie, deoarece formatul paletei ar putea prevedea dimensiuni diferite ale paletelor. Aceasta se aplică doar pentru setul de date cu care este livrat Outpost 2.

După listele de palete urmează imediat, fără un antet introductiv, lista de bitmap-uri; imediat după acestea urmează listele de animații.
Ambele sunt inițiate cu un uint(32) (sau din nou uint24+uint8 steaguri?) care conține numărul de înregistrări.

Informațiile despre palete sunt foarte ușor de citit.
Acestea constau fiecare dintr-un antet și un segment de date.

Sețiunea de date conține înregistrările individuale ale paletelor. Numărul de înregistrări ale paletelor rezultă din lungimea blocului / 4.

Înregistrările individuale au următoarea structură simplă;

În legătură cu paletele, mai trebuie spus că pentru paletele utilizate în animații, se aplică următoarele reguli:

• Prima culoare este ÎNTOTDEAUNA transparentă, indiferent de valoarea specificată acolo.
• Intrările din palete 1-24 sunt considerate ca fiind culorile jucătorilor în paletele 1-8.
  De unde provin culorile în afara de jucătorul 1, nu este clar pentru mine.
  Presupun că celelalte culori sunt hardcoded.

Structura de date a fișierului PRT indică modul în care sunt construite bitmap-urile folosite pentru sprite-uri. Aceste bitmap-uri servesc ca elemente individuale, din care mai multe sunt asamblate într-un cadru de animație al unui sprite.

Datele specifice ale imaginii se ascund în op2_art.BMP din directorul jocului.
Motivul pentru care acest fișier bitmap are un antet RIFF (preponderent corect) este neclar. Probabil că Outpost 2 folosește API-uri de sistem pentru a încărca grafica, preluând temporar acest antet și suprascriend câmpurile corespunzătoare, variabile.

Datele pixelilor se găsesc în fișierul BMP la poziția Offset + offset uint32, ceea ce se găsește în fișierul BMP la adresa 0x000A (offset-ul datelor RIFF-Bitmap), și corespund din nou aranjării pe linii de sus în stânga spre dreapta jos.

Graficile monocrome 1bpp pot fi desenate astfel încât culoarea 0 să fie complet transparentă, iar culoarea 1 să fie un negru/gri semi-transparent, deoarece graficele monocrome sunt de obicei utilizate pentru umbrele vehiculelor și clădirilor în animații.

Astfel, se pot asambla deja multe grafice.

Acum ajungem la clasa regală a disciplinelor din formatele de date Outpost 2:
Animatiile.

Listelor de animație le precede un header global, care servește în principal pentru verificarea datelor. Apoi urmează definițiile concrete ale animațiilor, care se împart în 3 niveluri:

1. Animație
   O animație este cea mai înaltă instanță; ea reprezintă o animație a unei unități, a unei clădiri sau a unei 'animații de particule' (impact de cometă, vreme, explozie) într-o anumită situație inițială.
2. Cadru
   Un cadru este o imagine unică în cadrul unei animații. O animație poate conține unul sau mai multe cadre.
3. Subcadru
   Un subcadru reprezintă informația că o anumită bitmap trebuie desenată într-o anumită poziție a unui cadru, conform unor criterii specifice. Un cadru poate conține unul sau mai multe subcadre.

Apoi urmează direct definițiile individuale ale animațiilor.

Datele stratului superior, al animației, sunt în principal date administrative - Boundingbox se referă la coordonatele marcajului din jurul vehiculului/clădirii, atunci când acesta este selectat și indică, de asemenea, care zonă poate fi clicată.

Offset-ul determină în principal „punctul zero”; punctul care trebuie adunat sau scăzut în coordonatele interne ale jocului. Pot să spun și mai matematic: offset-ul se referă aici la originea coordonatelor.

Windows-urile sunt, la fel ca offset-ul, formate din câte 4 valori uint(32) fiecare, ce indică o zonă care este considerată utilizabilă pentru subframe-uri individuale. În afara Windows-urilor, nu se poate desena, cu condiția ca acest lucru să fie prevăzut pentru bitmap.

Astfel putem acum să combinăm cadre individuale, precum și animații complete, demonstrând aici, exemplificativ, o animație mai complexă, animația cu indexul 500

Animatia 500 arată cum un transportor Plymouth, încărcat cu minereu obișnuit, este descărcat. Aceasta este una dintre puținele animații care utilizează funcționalitatea de feronerie.

Și astfel se poate asambla întreaga animație.
Din păcate, există încă o problemă cu hubloul superior, deoarece bitul corespunzător din informațiile despre tipul grafic nu este setat.

Iată câteva alte sprite-uri frumos animate din joc:

Acum lipsește doar interfața utilizatorului jocului, care este realizată într-un aspect de metal periat.

Cu toate acestea, este clar că Dynamix nu a fost nevoit să reinventeze roata; aici nu sunt utilizate doar simplu API-urile User32 și GDI32 furnizate de Windows - în special este folosit și managementul resurselor din User32.

Aceasta poate fi extrasă, de exemplu, prin programe precum Resource Hacker, dezvoltat ca software gratuit de Angus Johnson, sau - dacă se evită utilizarea Wine pe Linux / Mac OS - cu ajutorul wrestool inclus în icoutils.