Formats de fichiers Outpost 2 · bei.pm

Les formats de données utilisés par Outpost 2 ont une structure rappelant JFIF / PNG - chaque bloc de données comporte toujours un en-tête de 8 octets. C'est pourquoi je ne prends pas la peine de documenter les en-têtes individuels aux endroits spécifiques correspondants et je ne documente que les écarts.

Le format est toujours le suivant ; les données utiles y sont ensuite intégrées :

Les volumes sont des conteneurs de données pour le jeu, similaires à un format d'archive comme par exemple Tarball. Au moins dans Outpost 2, le format ne connaît que des fichiers - pas de dossiers. Il est probablement possible de simuler ces derniers à l'aide de noms de fichiers appropriés.

Un volume se compose de l'en-tête du volume ainsi que de plusieurs blocs de volume, qui correspondent aux fichiers concrets.

Les "volumes" sont les fichiers avec l'extension 'vol' dans le répertoire du jeu.

Le Volume Header ne contient aucune donnée utile.
Il sert uniquement de conteneur.

En premier lieu, on devrait trouver les chaînes de volume dans le Volume Header ; ensuite viennent les informations sur le volume.

Les chaînes de volume sont une liste de noms de fichiers qui sont contenus dans le volume.

Les informations sur le volume contiennent des informations plus détaillées sur les fichiers. Il s'agit en quelque sorte d'une sorte d'entrée de répertoire FAT (FAT = File Allocation Table)

Le nombre de fichiers est déterminé par la taille des blocs divisée par la longueur des entrées de répertoire - 14 octets.

Les entrées de répertoire individuelles ont chacune la structure suivante :

Un bloc de volume est un conteneur qui stocke des fichiers. Il contient simplement - en raison du format de bloc - une redondance de la taille du fichier, suivie directement des données utiles.

Les tiles sont un format graphique bitmap spécifique à Outpost-2. Ils s'étendent sur 13 ensembles de tiles, appelés "wells" (well0000.bmp à well0012.bmp), qui se trouvent dans le volume maps.vol.

Les ensembles de tiles / wells contiennent ce qui suit :

Il est fortement conseillé de ne pas rendre les tuiles à l'avance pour les mettre en cache, car les données pour le cycle jour/nuit doivent encore être traitées - et cela générerait une quantité énorme de données.

Les tuiles sont des graphiques 8bpp avec une palette indexée de 32x32 pixels de résolution, disposées les unes à côté des autres. Cependant, dans un ensemble de tuiles ainsi créé, il peut y en avoir bien plus.

Le conteneur principal se compose de 2 sections : head et data.

Après ces informations, un fichier de palette au format RIFF standardisé sera fourni. La spécification exacte se trouve - puisque les palettes apparaissent également ailleurs - sous Palettes.

Enfin, les données de pixels brutes suivent, ligne par ligne de haut à gauche vers bas à droite.
La valeur des données pour les graphiques, qui sont généralement au format bitmap 8bpp, correspond à l'index de la couleur dans la palette de couleurs.

Le moteur de jeu dessine les tuiles *probablement* à la demande.
Cela semble être en partie dû au cycle jour-nuit, qui connaît 32 nuances de tuiles individuelles. Il paraît qu'on soustrait à chaque fois 'un peu' de la valeur de luminosité. Des valeurs exactes n'ont pas encore pu être déterminées, je travaille sur la base de calcul suivante :

v *= (daylight / 48) + 0.25;

avec les données HSV des pixels, où daylight est une valeur de 0 à 31 et v est une valeur entre 0 et 1. De plus, il faut prendre en compte qu'il existe sur la carte une bordure de 16 tuiles à gauche et à droite (qui sert à faire apparaître des unités de manière invisible).

De plus, il semble que le cycle jour-nuit ne mette à jour qu'une colonne de la carte par cycle de jeu.
Un cycle jour-nuit accéléré se présente donc comme suit :

Je ne sais pas exactement ce que signifie PRT; il pourrait s'agir par exemple de 'Palette and Resource Table' - car ce fichier - trouvé sous le nom op2_art.prt dans maps.vol - en est un, ou cela décrirait bien sa fonction.

Ce fichier contient une liste de palettes, un tableau de toutes les bitmaps utilisées, toutes les définitions d'animations et encore un certain nombre de données inconnues. Il suit de manière assez lâche le format de conteneur précédent, car tous les enregistrements ne suivent pas ce schéma.

La section CPAL (qui signifie probablement conteneur de palettes) englobe uniquement les données de palette, en indiquant combien de palettes 8 bits de 1052 octets sont généralement présentes.

La mention de 1052 octets n'est pas considérée comme contraignante, car le format de palette pourrait prévoir des tailles de palette différentes. Cela s'applique uniquement aux données fournies avec Outpost 2.

Après la liste des palettes, vient immédiatement et sans en-tête introductif, la liste des bitmaps ; de la même manière, les listes d'animations suivent immédiatement.
Ces deux listes sont chacune introduites par un uint(32) (ou encore uint24 + uint8 flags ?) qui contient le nombre d'enregistrements.

Les informations sur les palettes sont très simples à lire.
Elles se composent chacune d'un en-tête et d'un segment de données.

La section de données contient les entrées individuelles des palettes. Le nombre d'entrées de palettes est calculé à partir de la longueur du bloc / 4.

Les entrées individuelles ont la structure simple suivante ;

Concernant les palettes, il convient d'ajouter que pour les palettes utilisées pour les animations, les règles suivantes s'appliquent :

• La première couleur est TOUJOURS transparente, peu importe la valeur qui y est indiquée.
• Les entrées de palette 1-24 sont considérées comme des couleurs de joueur dans les palettes 1-8.
  Il m'est peu clair d'où proviennent exactement les couleurs en dehors du joueur 1.
  Je suppose que les autres couleurs sont codées en dur.

Cette structure de données du fichier PRT indique comment les bitmaps utilisés pour les sprites sont construits. Ces bitmaps servent de composant individuel, dont plusieurs sont assemblés pour constituer une image d'animation d'un sprite.

Les données d'image concrètes se trouvent dans le op2_art.BMP dans le répertoire du jeu.
On ne sait pas pourquoi ce fichier bitmap possède un en-tête RIFF (principalement correct), mais il est probable qu'Outpost 2 utilise des API système pour charger les graphiques, en adoptant temporairement cet en-tête et en écrasant les champs correspondants et variables.

Les données de pixels se trouvent dans le fichier BMP à la Position Offset + l'offset uint32, qui se trouve à l'adresse 0x000A dans le fichier BMP (offset des données RIFF Bitmap), et correspondent à l'agencement ligne par ligne de gauche à droite et de haut en bas.

Les graphiques monochromes 1bpp peuvent être dessinés de manière à ce que la couleur 0 représente une transparence totale, tandis que la couleur 1 est un noir/gris semi-transparent, car les graphiques monochromes sont généralement utilisés pour les ombres des véhicules et des bâtiments dans les animations.

Ainsi, on peut déjà assembler de nombreux graphiques.

Maintenant, nous arrivons à la classe maîtresse des disciplines au sein des formats de données d'Outpost 2 :
Les animations.

Les listes d'animations commencent par un en-tête global, qui sert principalement à la vérification des données. S'ensuivent les définitions concrètes des animations, qui se divisent en 3 niveaux :

1. Animation
   Une animation est la plus haute instance ; elle représente une animation d'une unité, d'un bâtiment ou d'une 'animation de particules' (impact de comète, météo, explosion) dans une situation donnée.
2. Frame
   Une frame est une image unique au sein d'une animation. Une animation peut contenir une ou plusieurs frames.
3. Subframe
   Un subframe est l'information indiquant qu'une certaine bitmap doit être dessinée à une position spécifique d'une frame selon certains critères. Une frame peut contenir un ou plusieurs subframes.

Ensuite, suivent directement les définitions des animations individuelles.

Les données de la couche supérieure, de l'animation, sont principalement des données administratives - la Boundingbox désigne les coordonnées de la marque autour du véhicule/bâtiment, lorsque celui-ci est sélectionné, et indique également quelle zone doit être cliquable.

L'offset détermine principalement le "point zéro" ; le point à additionner ou à soustraire aux coordonnées internes du jeu. On pourrait également dire de manière mathématique : l'offset désigne ici l'origine des coordonnées.

Les fenêtres, tout comme l'offset, se composent chacune de 4 valeurs uint(32), qui définissent une zone considérée comme utilisable pour des sous-images individuelles. En dehors des fenêtres, il ne doit pas être dessiné, sauf si cela est prévu pour la bitmap.

Nous pouvons désormais assembler des cadres individuels ainsi que des animations complètes, comme démontré ici par un exemple d'une animation plus complexe, l'animation avec l'index 500.

L'animation 500 montre comment un fourgon Plymouth, chargé de minéraux ordinaires, est déchargé. C'est l'une des rares animations qui utilise la fonctionnalité de fenêtrage.

Voici comment l'ensemble de l'animation peut être assemblé.
Malheureusement, il y a encore un problème avec la trappe de chargement supérieure, car le bit correspondant dans les informations de type graphique n'est pas défini.

Voici quelques autres sprites magnifiquement animés du jeu :

Il ne reste plus qu'à finaliser l'interface utilisateur du jeu, qui est réalisée dans un style métal brossé.

Cependant, il est également évident que Dynamix n'a pas eu besoin de réinventer la roue ; ici, il ne s'agit pas seulement d'utiliser les API User32 et GDI32 fournies par Windows - en particulier, la gestion des ressources de User32 est également utilisée.

Celles-ci peuvent être extraites par des programmes comme le Resource Hacker, développé en tant que freeware par Angus Johnson, ou - si l'on hésite à utiliser Wine sous Linux / Mac OS - avec l'outil wrestool inclus dans icoutils.