Formati di file di Outpost 2 · bei.pm

I formati di dati utilizzati da Outpost 2 hanno una struttura simile a JFIF / PNG - i singoli blocchi di dati presentano sempre un'intestazione di 8 byte. Perciò eviterò di documentare le singole intestazioni nei luoghi specifici corrispondenti e documenterò solo le deviazioni.

Il formato è sempre il seguente; i dati utili sono quindi incorporati al suo interno:

I volumi sono dei contenitori di dati per il gioco, simili a un formato di archivio come ad esempio il Tarball. Almeno in Outpost 2, il formato riconosce solo file - nessuna cartella. Probabilmente, tuttavia, queste ultime potrebbero essere simulate attraverso nomi di file appropriati.

Un volume è composto dall'intestazione del volume e da diversi blocchi di volume, che corrispondono ai file concreti.

"I 'volumi'" sono i file con l'estensione 'vol' nella directory di gioco.

L'intestazione del volume non contiene alcun dato utile.
Essa funge unicamente da contenitore.

Le stringhe del volume dovrebbero trovarsi come prima informazione nell'intestazione del volume; a seguire ci sono le informazioni sul volume.

I Volume Strings sono un elenco di nomi di file che sono contenuti all'interno del volume.

Le informazioni sul volume contengono dettagli più specifici sui file. Si tratta in un certo senso di una sorta di voce di directory FAT (FAT = File Allocation Table).

Il numero di file si ottiene dividendo la dimensione del blocco per la lunghezza delle voci di directory - 14 byte.

I singoli elementi di directory hanno la seguente struttura:

Un volume-block è un contenitore che ospita file. Contiene soltanto - a causa del formato a blocchi - in modo ridondante la dimensione del file e successivamente seguono direttamente i dati utili.

I tiles sono un formato grafico bitmap specifico per Outpost-2. Si estendono su 13 tileset, chiamati "wells" (well0000.bmp fino a well0012.bmp), che si trovano all'interno del volume maps.vol.

I tileset / Wells contengono quanto segue:

È consigliabile per una realizzazione accurata non rendere in anticipo i tiles per metterli in cache, poiché i dati per il ciclo giorno/notte devono ancora essere elaborati - e ci sarebbero moltissimi dati.

I tiles sono grafica 8bpp con palette indicizzata, ciascuno con risoluzione 32x32 pixel, disposti tra di loro. In un tileset così creato, però, possono esserci molti più

Il contenitore principale è composto da 2 sezioni: head e data.

Secondo queste indicazioni, seguirà un file di palette in formato RIFF standardizzato. La specifica esatta si trova - poiché le palette compaiono anche altrove - sotto Palette.

Infine, seguono i dati dei pixel puri, riga per riga da sinistra in alto a destra in basso.
Il valore dei dati per le grafiche generalmente presenti come bitmap a 8bpp corrisponde all'indice del colore nella tavolozza.

Il motore di gioco disegna i tiles *probabilmente* su richiesta.
Questo sembra essere dovuto, tra l'altro, al ciclo giorno-notte che prevede 32 gradazioni di singoli tiles. Apparentemente, viene sottratto 'un po'' dal valore di luminosità. Valori precisi non sono ancora stati determinati, sto lavorando sulla base di calcolo

v *= (daylight / 48) + 0.25;

con i dati HSV dei pixel, dove daylight è un valore da 0-31 e v è un valore compreso tra 0-1. Inoltre, è da considerare che sulla mappa esiste un margine di 16 tiles a sinistra e a destra (che serve per la generazione invisibile delle unità).

In aggiunta, sembra che il ciclo giorno-notte aggiorni solo una colonna della mappa per ogni ciclo di gioco.
Un ciclo giorno-notte accelerato appare quindi come segue:

Cosa rappresenti esattamente PRT non è a me noto; potrebbe essere, ad esempio, 'Palette and Resource Table' - poiché questo file, che si trova come op2_art.prt in maps.vol, è proprio di questo tipo, o almeno questa descrizione ne riassumerebbe bene la funzione.

Il file contiene un elenco di palette, una tabella su tutte le bitmap utilizzate, tutte le definizioni delle animazioni e una serie di dati sconosciuti. Segue in modo vago il formato del contenitore precedente, poiché non tutti i record seguono questo schema.

La sezione CPAL (che probabilmente sta per contenitore di palette) racchiude solo i dati delle palette, specificando quanti dei soliti 1052 byte di palette a 8 bit sono presenti.

Il valore di 1052 byte non è da considerarsi vincolante, poiché il formato delle palette potrebbe prevedere dimensioni diverse. Si applica solo ai dati con cui viene distribuito Outpost 2.

Dopo l'elenco delle palette, segue immediatamente e senza un header introduttivo, l'elenco delle bitmap; subito dopo seguono le liste delle animazioni.
Entrambi sono introdotti da un uint(32) (o forse da uint24 + uint8 flags?), che contiene il numero di record.

Le informazioni sulle palette sono molto semplici da comprendere.
Esse consistono ciascuna in un'intestazione e in un segmento di dati.

La sezione dati raccoglie le singole voci delle palette. Il numero delle voci delle palette è dato dalla lunghezza del blocco / 4.

Gli singoli elementi hanno una struttura semplice come segue;

Per quanto riguarda le palette, c'è solo da dire che per le palette utilizzate nelle animazioni valgono le seguenti regole:

• Il primo colore è SEMPRE trasparente, indipendentemente dal valore specificato.
• Le voci delle palette da 1 a 24 devono essere considerate come colori dei giocatori nelle palette da 1 a 8.
  Non è chiaro da dove provengano esattamente i colori oltre al giocatore 1.
  Sospetto che i restanti colori siano hardcoded.

Questa struttura dati del file PRT indica come sono costruite le bitmap utilizzate per gli sprite. Queste bitmap fungono da singolo componente, da cui più elementi vengono assemblati per un frame di animazione di uno sprite.

I dati delle immagini concreti si trovano invece in op2_art.BMP nella directory di gioco.
Perché questo file bitmap abbia un'intestazione RIFF bitmap (per lo più corretta) non è chiaro. Probabilmente Outpost 2 utilizza API di sistema per caricare le grafiche, adottando temporaneamente questa intestazione e sovrascrivendo i campi corrispondenti e variabili.

I dati dei pixel si trovano nel file BMP nella posizione Offset + l'offset uint32, che si trova nel file BMP all'indirizzo 0x000A (offset dati RIFF bitmap), e corrispondono di nuovo all'ordinamento riga per riga dall'alto verso il basso e da sinistra a destra.

Grafiche monocromatiche 1bpp possono essere disegnate in modo tale che il colore 0 sia completamente trasparente, mentre il colore 1 è un nero/grigio semi-trasparente, poiché le grafiche monocrome vengono generalmente utilizzate per le ombre di veicoli e edifici nelle animazioni.

In questo modo si possono già assemblare molte grafiche.

Adesso arriviamo alla classe regina delle discipline all'interno dei formati dati di Outpost 2:
Le animazioni.

Le liste delle animazioni sono introdotte da un'intestazione globale, che serve principalmente alla verifica dei dati. Seguono quindi le specifiche delle animazioni concrete, che si suddividono in 3 livelli:

1. Animazione
   Un'animazione è l'istanza principale; rappresenta un'animazione di un'unità, di un edificio o di un 'animazione di particelle' (impatto di un cometa, meteo, esplosione) in una determinata situazione iniziale.
2. Frame
   Un frame è un'immagine singola all'interno di un'animazione. Un'animazione può contenere uno o più frame.
3. Subframe
   Un subframe è l'informazione riguardante il fatto che un determinato bitmap deve essere disegnato in una certa posizione di un frame secondo specifici criteri. Un frame può contenere uno o più subframe.

Segue quindi direttamente la definizione delle singole animazioni.

I dati del livello superiore, dell'animazione, sono principalmente dati di gestione - la Boundingbox indica le coordinate del contrassegno attorno al veicolo/edificio, quando esso è selezionato e indica anche quale area deve essere cliccabile.

L'offset determina principalmente il "punto zero"; il punto da sommare o sottrarre alle coordinate interne del gioco. Potremmo anche dire in termini matematici: l'offset indica qui l'origine delle coordinate.

Le finestre consistono, proprio come l'offset, in 4 valori uint(32) ciascuna (per finestra), che specificano un'area utilizzabile per singoli subframe. Fuori dalle finestre non è permesso realizzare disegni, a meno che non sia specificamente previsto per la bitmap.

Con questo possiamo ora assemblare singoli frame, così come animazioni complete; qui viene dimostrato, a titolo esemplificativo, con un'animazione più complessa, quella con l'indice 500.

L'animazione 500 mostra come un furgone Plymouth, caricato con materiale comune, venga scaricato. Si tratta di una delle poche animazioni che utilizza la funzionalità di Windowing.

In questo modo si può unire l'intera animazione.
Purtroppo c'è ancora un problema con il portellone superiore, poiché qui il bit corrispondente nelle informazioni sul tipo di grafica non è impostato.

Ecco alcuni altri bellissimi sprite animati dal gioco:

Manca ancora l'interfaccia utente del gioco, realizzata in uno stile metallo spazzolato.

Tuttavia, è evidente che Dynamix non ha dovuto reinventare la ruota; qui non vengono semplicemente utilizzate le API User32 e GDI32 fornite da Windows - in particolare, viene anche utilizzata la gestione delle risorse di User32.

Queste possono essere estratte, ad esempio, tramite programmi come il Resource Hacker sviluppato come freeware da Angus Johnson, oppure - se si teme di usare Wine su Linux / Mac OS - utilizzando wrestool incluso in icoutils.