Formatos de archivo de Outpost 2 · bei.pm

Los formatos de datos utilizados por Outpost 2 tienen una estructura similar a JFIF / PNG; cada bloque de datos siempre tiene un encabezado de 8 bytes. Por lo tanto, omito documentar los encabezados individuales en los lugares específicos correspondientes y solo documentaré las desviaciones.

El formato es siempre el siguiente; los datos útiles reales están incrustados en él:

Los volúmenes son un contenedor de datos para el juego, similar a un formato de archivo como, por ejemplo, Tarball. Al menos en Outpost 2, el formato solo reconoce archivos, no carpetas. Probablemente, sin embargo, estos podrían simularse a través de nombres de archivo correspondientes.

Un volumen consiste en el encabezado del volumen y varios bloques de volumen que corresponden a los archivos concretos.

"Volúmenes" son los archivos con la extensión 'vol' en el directorio del juego.

El encabezado del volumen no contiene datos útiles.
Sirve únicamente como contenedor.

Como primera fecha en el encabezado del volumen deberían encontrarse las cadenas del volumen; a continuación siguen las informaciones del volumen.

Los Volume Strings son una lista de nombres de archivos que se encuentran dentro del volumen.

La información de volumen contiene detalles más específicos sobre los archivos. De alguna manera, se trata de una especie de entrada de directorio FAT (FAT = Tabla de Asignación de Archivos).

La cantidad de archivos se obtiene al dividir el tamaño del bloque por la longitud de las entradas del directorio - 14 bytes.

Cada entrada de directorio tiene la siguiente estructura:

Un bloque de volumen es un contenedor que almacena archivos. Contiene, debido al formato del bloque, de manera redundante, el tamaño del archivo y a continuación siguen directamente los datos útiles.

Los tiles son un formato gráfico en bitmap específico de Outpost-2. Se extienden a través de 13 conjuntos de tiles, llamados "wells" (well0000.bmp hasta well0012.bmp), que se encuentran dentro del volumen maps.vol.

Los conjuntos de tiles / Wells contienen lo siguiente:

Es recomendable para una implementación precisa no renderizar las baldosas de antemano para poder almacenarlas en caché, ya que los datos del ciclo día/noche aún deben procesarse, y se generarían muchos datos.

Las baldosas son gráficos de 8bpp con paletas indexadas de 32x32 píxeles de resolución, dispuestas en fila. Sin embargo, en un conjunto de baldosas así creado se pueden tener muchas más.

El contenedor principal consiste en 2 secciones: head y data.

Después de esta información, se proporcionará un archivo de paleta en formato RIFF estandarizado. La especificación exacta se puede encontrar - dado que las paletas también aparecen en otros lugares - en Paletas.

Finalmente, llegan los datos de píxeles en bruto, de arriba a la izquierda hacia abajo a la derecha, línea por línea.
El valor de los datos en las gráficas que generalmente están en formato de 8bpp-Bitmaps corresponde al índice del color en la paleta de colores.

El motor del juego probablemente dibuja los tiles *a demanda*.
Esto parece deberse, entre otras cosas, al ciclo de día y noche, que conoce 32 niveles diferentes de los tiles individuales. Al parecer, se reduce 'un poco' el valor de luminosidad. Aún no se han podido determinar valores exactos, estoy trabajando sobre la base de cálculo

v *= (daylight / 48) + 0.25;

con los datos HSV de los píxeles, donde daylight es un valor de 0-31 y v es un valor entre 0-1. Además, hay que tener en cuenta que en el mapa existe un borde de 16 tiles a la izquierda y a la derecha (que sirve para el spawn invisible de unidades).

Además, parece que el ciclo de día y noche actualiza solo una columna del mapa por ciclo de juego.
Un ciclo de día y noche acelerado se ve de la siguiente manera:

No estoy seguro de lo que significa exactamente PRT; podría ser, por ejemplo, 'Tabla de Paletas y Recursos' - ya que este archivo, que se encuentra como op2_art.prt en maps.vol, es de este tipo, o al menos esa descripción podría reflejar bien su función.

Este archivo contiene una lista de paletas, una tabla de todos los bitmaps utilizados, todas las definiciones de animaciones y una serie de datos desconocidos. Se adhiere de manera laxa al formato de contenedor anterior, ya que no todos los registros siguen este esquema.

La sección CPAL (que probablemente significa contenedor de paletas) solo abarca los datos de la paleta, indicando cuántas de las paletas de 8 bits, que normalmente son de 1052 bytes, están presentes.

La especificación de 1052 bytes no se considera vinculante, ya que el formato de la paleta podría prever diferentes tamaños de paleta. Solo se aplica al conjunto de datos con el que se entrega Outpost 2.

Después de las listas de paletas, sigue inmediatamente y sin un encabezado introductorio, la lista de bitmaps; de la misma manera, las listas de animaciones siguen de inmediato.
Cada una de ellas se inicia con un uint(32) (¿o nuevamente uint24+uint8 flags?) que contiene la cantidad de registros.

La información de las paletas es muy fácil de leer.
Consiste en un encabezado y un segmento de datos.

La sección de datos incluye las entradas individuales de palets. La cantidad de entradas de palets se calcula a partir de la longitud del bloque / 4.

Las entradas individuales tienen la siguiente estructura simple;

En cuanto a las paletas, solo cabe mencionar que para las paletas que se utilizan en animaciones, las siguientes reglas son aplicables:

• El primer color es SIEMPRE transparente, sin importar el valor que se indique allí.
• Las entradas de la paleta 1-24 se consideran como color de jugador en las paletas 1-8.
  No tengo claro de dónde provienen exactamente los colores fuera del jugador 1.
  Sospecho que los colores restantes están codificados de forma fija.

Estructura de datos del archivo PRT que indica cómo están construidos los bitmaps utilizados para los sprites. Estos bitmaps sirven como un componente individual, de los cuales varios se ensamblan en un marco de animación de un sprite.

Los datos de imagen concretos se encuentran en op2_art.BMP en el directorio del juego.
Por qué este archivo de bitmap tiene un encabezado de bitmap RIFF (en su mayoría correcto) es incierto. Probablemente Outpost 2 utiliza APIs del sistema para cargar los gráficos, adoptando temporalmente este encabezado y sobrescribiendo los campos correspondientes y variables.

Los datos de píxeles se encuentran en el archivo BMP en la posición Offset + el offset uint32, que se puede encontrar en la dirección 0x000A del archivo BMP (offset de datos del bitmap RIFF), y corresponden nuevamente a la disposición fila por fila de arriba a izquierda a derecha y abajo.

Gráficos monocromos de 1bpp pueden dibujarse de tal manera, que el color 0 sea completamente transparente, y el color 1 sea un negro/gris semi-transparente, ya que los gráficos monocromos se utilizan comúnmente para sombras de vehículos y edificios en las animaciones.

Con esto ya se pueden ensamblar muchas gráficas.

Ahora pasamos a la clase maestra de las disciplinas dentro de los formatos de datos de Outpost 2:
Las animaciones.

Las listas de animación comienzan con un encabezado global, que sirve principalmente para la verificación de datos. A continuación, siguen las definiciones concretas de animación, que se dividen en 3 niveles:

1. Animación
   Una animación es la instancia superior; representa una animación de una unidad, un edificio o una 'animación de partículas' (impacto de cometas, clima, explosiones) en una situación inicial determinada.
2. Fotograma
   Un fotograma es una imagen única dentro de una animación. Una animación puede incluir uno o varios fotogramas.
3. Subfotograma
   Un subfotograma es la información sobre que un determinado bitmap debe ser dibujado en una posición específica de un fotograma bajo ciertos criterios. Un fotograma puede incluir uno o varios subfotogramas.

A continuación, ya vienen directamente las definiciones individuales de animación.

Los datos de la capa superior, de la animación, son principalmente datos administrativos - la Boundingbox se refiere a las coordenadas de la marca alrededor del vehículo/edificio, cuando este ha sido seleccionado y también indica qué área debería ser clickable.

El offset determina principalmente el "punto cero"; el punto que debe ser sumado o restado a las coordenadas internas del juego. Se podría decir de manera más matemática: el offset se refiere aquí al origen de coordenadas.

En las ventanas, al igual que con el offset, hay 4 valores uint(32) por cada ventana, que indican un área que es considerada utilizable para submarcos individuales. Fuera de las ventanas, a menos que esté destinado a la bitmap correspondiente, no se puede dibujar.

Con esto, ahora podemos ensamblar tanto cuadros individuales como animaciones completas; aquí se demuestra con un ejemplo de una animación más compleja, la animación con el índice 500.

La animación 500 muestra cómo se descarga un transportador Plymouth cargado con mineral común. Esta es una de las pocas animaciones que utiliza la funcionalidad de ventanas.

Así es como se puede ensamblar la animación completa.
Desafortunadamente, todavía hay un problema con la escotilla superior, ya que el bit correspondiente en la información del tipo de gráfico no está configurado.

Aquí hay algunos otros sprites maravillosamente animados del juego:

Aún falta la interfaz de usuario del juego, que tiene un aspecto de metal cepillado.

Pero aquí también es evidente que Dynamix no tuvo que reinventar la rueda; aquí no solo se utilizan simplemente las APIs User32 y GDI32 proporcionadas por Windows, sino que también se emplea la gestión de recursos de User32.

Estas se pueden extraer, por ejemplo, mediante programas como Resource Hacker, desarrollado como software gratuito por Angus Johnson, o - si se teme usar Wine en Linux / Mac OS - utilizando wrestool que se incluye en icoutils.