Formats de fitxer d'Outpost 2 · bei.pm

Els formats de dades utilitzats per Outpost 2 tenen una estructura que recorda a JFIF / PNG - els blocs de dades individuals sempre tenen un capçal de 8 bytes. Per tant, m'estalvio documentar els caps individuals als llocs específics corresponents i només documentaré les desviacions.

El format és sempre el següent; les dades útils reals estan incrustades dins d'ell:

Els volums són un contenidor de dades per al joc, similar a un format d'arxiu com ara Tarball. Almenys a Outpost 2, el format només reconeix fitxers - no carpetes. Probablement, però, es podrien simular aquestes últimes mitjançant noms de fitxer adequats.

Un volum consta del capçalera del volum així com de diversos blocs de volum que corresponen als fitxers concrets.

"Volums" són els fitxers amb l'extensió 'vol' a la carpeta del joc.

El volum header no conté cap dada útil.
Només serveix com a contenidor.

Com a primera dada al volum header s'han de trobar les cadenes del volum; a continuació hi ha les informacions del volum.

Les cadenes de volum són una llista de noms de fitxers que es troben dins del volum.

La informació de volum conté detalls més específics relacionats amb els fitxers. D'alguna manera, és una mena d'entrada de directori FAT (FAT = File Allocation Table).

El nombre de fitxers es calcula dividint la mida del bloc per la longitud de les entrades del directori - 14 bytes.

Les entrades de directori individuals tenen l'estructura següent:

Un volum de bloc és un contenidor que allotja fitxers. Conté només una vegada més - a causa del format del bloc - la mida del fitxer, i després segueixen directament les dades útils.

Les fitxes són un format gràfic de bitmap específic d'Outpost-2. S'estenen a través de 13 conjunts de fitxes, anomenats "wells" (well0000.bmp fins well0012.bmp), que es troben dins del volum maps.vol.

Així, els conjunts de fitxes / wells contenen el següent:

És molt recomanable per a una implementació acurada no renderitzar les fitxes amb antelació per tal de fer-ne la memòria cau, ja que les dades per al cicle de dia/nit encara s'han de processar - i s'acumularien moltes dades.

Les fitxes són gràfics de 8bpp amb paleta indexada de 32x32 píxels de resolució, que estan disposades de manera col·locada. En un conjunt de fitxes així creat, però, es poden obtenir moltes més

El contenidor principal consta de 2 seccions: head i data.

Després d'aquests detalls, es presentarà un fitxer de paleta en format RIFF estàndard. La especificació exacta es pot trobar - ja que les paletes apareixen en altres llocs - a Paletes.

Finalment, segueixen les dades de píxels en brut, de dalt a l'esquerra a baix a la dreta, línia per línia.
El valor de les dades en les gràfiques que normalment es presenten com a imatges de 8bpp correspon a l'índex del color a la paleta de colors.

El motor del joc dibuixa els tiles *probablement* sota demanda.
Això sembla ser degut, entre altres coses, al cicle dia-nit, que coneix 32 graduacions de tiles individuals. Sembla que es resta 'una mica' del valor de brillantor. Encara no s'han pogut determinar els valors exactes, estic treballant sobre la base de càlcul

v *= (daylight / 48) + 0.25;

amb les dades HSV dels píxels, on daylight és un valor de 0-31 i v és un valor entre 0-1. A més, cal tenir en compte que al mapa hi ha un marge de 16 tiles cap a l'esquerra i cap a la dreta (que serveix per aparèixer unitats de manera invisible).

A més, sembla que el cicle dia-nit actualitza només una columna del mapa per cada cicle del joc.
Un cicle dia-nit accelerat és, per tant, així:

No sé exactament què significa PRT; una possibilitat podria ser 'Palette and Resource Table' - ja que aquest fitxer - que es troba com a op2_art.prt dins de maps.vol - és un d'aquest tipus, o això descriuria força bé la seva funció.

Aquest fitxer conté una llista de paletes, una taula sobre totes les imatges de mapa utilitzades, totes les definicions d'animació i una sèrie de dades desconegudes. Segueix de manera laxa el format de contenidor anterior, ja que no tots els registres segueixen aquest esquema.

La secció CPAL (que probablement significa contenidor de paletes) només envolta les dades de paleta, especificant quantes de les habituals paletes de 8 bits de 1052 bytes hi ha disponibles.

La indicació de 1052 bytes no es considera vinculant, ja que el format de paleta podria preveure diferents mides de paleta. Només s'aplica al conjunt de dades amb el qual es lliura Outpost 2.

Després de les llistes de paletes, segueix immediatament i sense un encapçalament introductori, la llista d'imatges de mapa; igualment, immediatament segueixen les llistes d'animacions.
Ambdues s'inicien amb un uint(32) (o de nou uint24 + uint8 flags?) que conté el nombre de registres.

La informació de les palets és molt fàcil de llegir.
Consisteix en un encapçalament i un segment de dades.

La secció de dades inclou les entrades de palets individuals. El nombre d'entrades de palets es calcula a partir de la longitud del bloc / 4.

Les entrades individuals tenen l'estructura següent, senzilla;

Respecte a les paletes, només cal dir que per a les paletes que s'utilitzaran en les animacions, s'apliquen les següents normes:

• El primer color és SEMPRE transparent, independentment del valor que s'hi indiqui.
• Les entrades de paleta 1-24 es consideren com a color del jugador en les paletes 1-8.
  On proven exactament els colors fora del jugador 1, no ho sé.
  Sospito que els colors restants estan codificats de manera fixa.

Estructura de dades d'arxiu PRT que indica com estan formats els bitmaps que s'utilitzen per als sprites. Aquests bitmaps serveixen com un component individual, del qual es munten diversos en un fotograma d'animació d'un sprite.

Les dades d'imatge concretes es troben a la op2_art.BMP a la carpeta del joc.
Per què aquest arxiu bitmap té un capçalera RIFF (en la seva majoria correcta) és desconegut. Probablement Outpost 2 utilitza API de sistema per carregar les gràfiques, agafant temporalment aquest capçalera i sobreescrivint els camps corresponents i variables.

Les dades de píxels es troben a l'arxiu BMP en la posició Offset + l'offset uint32, que es pot localitzar a l'arxiu BMP a l'adreça 0x000A (offset de dades RIFF-Bitmap), i corresponen de nou a l'organització fila per fila d'esquerra a dreta i de dalt a baix.

Gràfics monocroms de 1bpp es poden dibuixar de tal manera que el color 0 sigui totalment transparent, així com el color 1 sigui un negre/gris semi-transparent, ja que els gràfics monocroms s'utilitzen habitualment per a ombres de vehicles i edificis en les animacions.

Així es poden combinar ja moltes gràfiques.

Ara arribem a la classe reina de les disciplines dins dels formats de dades d'Outpost 2:
Les animacions.

Les llistes d'animacions s'inicien amb un encapçalament global, que serveix principalment per a la verificació de dades. A continuació, seguixen les definicions concretes d'animacions, que es divideixen en 3 nivells:

1. Animació
   Una animació és la instància més alta; representa l'animació d'una unitat, d'un edifici o d'una 'animació de partícules' (impacte de cometes, temps, explosió) en una situació inicial determinada.
2. Fotograma
   Un fotograma és una imatge única dins d'una animació. Una animació pot incloure un o més fotogrames.
3. Subfotograma
   Un subfotograma és la informació sobre que una determinada imatge bitmap s'ha de dibuixar en una posició específica d'un fotograma segons uns criteris determinats. Un fotograma pot incloure un o més subfotogrames.

A continuació, es presenten directament les definicions d'animacions individuals.

Les dades de la capa superior, de l'animació, són principalment dades de gestió - la Boundingbox indica les coordenades de la marca al voltant del vehicle/edifici, quan aquest està seleccionat i també indica quina àrea ha de ser clicable.

El desfasament determina principalment el "punt zero"; el punt que s'ha de sumar o restar a les coordenades internes del joc. Es podria dir també de manera més matemàtica: el desfasament indica aquí l' origen de les coordenades.

En les finestres, igual que en el desfasament, hi ha respectivament (per finestra) 4 valors uint(32), que indiquen una àrea que es considera utilitzable per a submarcs individuals. Fora de les finestres no es pot, sempre que estigui destinat per a la bitmap, dibuixar.

Així podem ara muntar frames individuals, així com animacions completes, aquí es mostra un exemple d'una animació més complexa, l'animació amb l'índex 500.

La animació 500 mostra com es descarrega un transportador Plymouth carregat amb mineral comú. Es tracta d'una de les poques animacions que utilitza la funcionalitat de finestres.

Així és com es pot combinar tota l'animació.
Desafortunadament, hi ha un problema amb la tapa de càrrega superior, ja que aquí el bit corresponent a la informació del tipus de gràfic no està establert.

Aquí teniu alguns altres sprites animats magnífics del joc:

Només falta la interfície d'usuari del joc, que té un aspecte de metall polit.

Però aquí també és evident que Dynamix no va haver de reinventar la roda; aquí no només s'utilitzen simplement les API User32 i GDI32 proporcionades per Windows, sinó que també s'aplica la gestió de recursos de User32.

Aquests es poden extreure, per exemple, mitjançant programes com el Resource Hacker, que va desenvolupar Angus Johnson com a programari gratuït, o - si es té por d'utilitzar Wine sota Linux / Mac OS - amb l'ajuda de wrestool que es troba dins icoutils.