Formatos de Arquivo do Outpost 2 · bei.pm

Os formatos de dados usados pelo Outpost 2 têm uma estrutura semelhante à do JFIF / PNG - os blocos de dados individuais sempre possuem um cabeçalho de 8 bytes. Portanto, não vou me dar ao trabalho de documentar os cabeçalhos individuais nos locais específicos correspondentes e apenas documentarei as divergências.

O formato é sempre o seguinte; os dados úteis reais estão então incorporados nele:

Os volumes são um contêiner de dados para o jogo, semelhante a um formato de arquivo como, por exemplo, Tarball. Pelo menos em Outpost 2, o formato reconhece apenas arquivos - sem pastas. Provavelmente, essas poderiam ser simuladas por meio de nomes de arquivos apropriados.

Um volume consiste no cabeçalho do volume e em vários blocos de volume, que correspondem aos arquivos concretos.

"Volumes" são os arquivos com a extensão 'vol' no diretório do jogo.

O cabeçalho do volume não contém dados úteis.
Ele serve apenas como um contêiner.

Como primeira informação no cabeçalho do volume, devem estar as strings do volume; em seguida, vêm as informações do volume.

Os Volume Strings são uma lista de nomes de arquivos que estão contidos dentro do volume.

As informações de volume contêm detalhes adicionais sobre os arquivos. De certa forma, isso é uma espécie de entrada de diretório FAT (FAT = Tabela de Alocação de Arquivos).

O número de arquivos é determinado pelo tamanho do bloco dividido pelo comprimento das entradas de diretório - 14 bytes.

Cada uma das entradas de diretório tem a seguinte estrutura:

Um bloco de volume é um contêiner que armazena arquivos. Ele contém apenas mais uma vez - devido ao formato do bloco - a redundância do tamanho do arquivo e, em seguida, seguem-se diretamente os dados úteis.

Os Tiles são um formato de gráfico bitmap específico do Outpost-2. Eles se estendem por 13 conjuntos de tiles, chamados de "wells" (well0000.bmp até well0012.bmp), que estão dentro do volume maps.vol.

Os conjuntos de tiles / wells contêm o seguinte:

É altamente recomendável, para uma implementação precisa, não renderizar os tiles antecipadamente para que possam ser armazenados em cache, pois os dados para o ciclo dia/noite ainda precisam ser processados - e haveria uma quantidade muito grande de dados.

Os tiles são gráficos 8bpp com paleta indexada, cada um com resolução de 32x32 pixels, dispostos entre si. Em um tileset assim formado, no entanto, pode haver muito mais.

O contêiner principal é composto por 2 seções: head e data.

Após essas informações, haverá ainda um arquivo de paleta disponível no formato RIFF padronizado. A especificação exata pode ser encontrada - uma vez que as paletas também aparecem em outros lugares - em Paletas.

Finalmente, seguem os dados de pixel brutos, da esquerda para cima, linha por linha, até a parte inferior direita.
O valor dos dados nas gráficos, que geralmente estão na forma de bitmaps 8bpp, corresponde ao índice da cor na paleta de cores.

A engine de jogo provavelmente desenha os tiles *sob demanda*.
Isso parece ser devido ao ciclo dia-noite, que conhece 32 graduações de tiles individuais. Aparentemente, o valor de luminosidade é diminuído 'um pouco' a cada vez. Valores exatos ainda não foram determinados, estou trabalhando com a base de cálculo

v *= (daylight / 48) + 0.25;

usando os dados HSV dos pixels, onde daylight é um valor de 0-31 e v é um valor entre 0-1. Além disso, é importante considerar que no mapa ainda existem bordas de 16 tiles à esquerda e à direita (que servem para o aparecimento invisível de unidades).

Além disso, o ciclo dia-noite parece atualizar apenas uma coluna do mapa a cada ciclo de jogo.
Um ciclo dia-noite acelerado se parece com o seguinte:

Não sei exatamente o que significa PRT; uma possibilidade poderia ser 'Tabela de Paletas e Recursos' - já que este arquivo - encontrado como op2_art.prt no maps.vol - é realmente uma tabela desse tipo, ou isso descreveria bem a sua função.

Este arquivo contém uma lista de paletas, uma tabela de todos os bitmaps utilizados, todas as definições de animação e uma série de dados desconhecidos. Ele segue de forma solta o formato de contêiner anterior, pois nem todos os registros seguem esse esquema.

A seção CPAL (provavelmente significa Contêiner de Paletas) envolve apenas os dados das paletas, indicando quantas das paletas de 8 bits, que geralmente têm 1052 bytes, estão presentes.

A especificação de 1052 bytes não é considerada obrigatória, pois o formato da paleta pode potencialmente prever tamanhos de paletas diferentes. Ela se aplica apenas ao conjunto de dados com o qual o Outpost 2 é fornecido.

Após as listas de paletas, segue imediatamente e sem um cabeçalho introdutório, a lista de bitmaps; e logo após, as listas de animação.
Ambas são iniciadas com um uint(32) (ou novamente uint24+uint8 flags?) que contém a quantidade de registros.

As informações das paletes são muito fáceis de ler.
Elas consistem em um cabeçalho e um segmento de dados.

A seção de dados contém as entradas individuais das paletes. A quantidade de entradas de paletes é determinada pelo comprimento do bloco / 4.

As entradas individuais têm a seguinte estrutura simples;

Quanto às paletas, só resta dizer que para as paletas a serem usadas em animações, as seguintes regras se aplicam:

• A primeira cor é SEMPRE transparente, não importa qual valor esteja indicado.
• As entradas da paleta 1-24 são consideradas como cores do jogador nas paletas 1-8.
  Não está claro de onde vêm as cores além do jogador 1.
  Suspeito que as outras cores sejam hardcoded.

Estrutura de dados do arquivo PRT indica como os bitmaps usados para os sprites são organizados. Esses bitmaps servem como um único componente, dos quais vários são montados em um quadro de animação de um sprite.

Os dados de imagem concretos estão, por outro lado, no op2_art.BMP no diretório do jogo.
Por que esse arquivo bitmap possui um cabeçalho RIFF (predominantemente correto) não está claro. Provavelmente, o Outpost 2 usa APIs do sistema para carregar os gráficos, adotando temporariamente esse cabeçalho e sobrescrevendo os campos correspondentes e variáveis.

Os dados de pixel estão localizados no arquivo BMP na posição Offset + o uint32-Offset, encontrado no arquivo BMP no endereço 0x000A (offset de dados RIFF-Bitmap), e correspondem novamente à disposição linha a linha de cima para baixo, da esquerda para a direita.

Gráficos monocromáticos 1bpp podem ser desenhados de forma que a cor 0 represente transparência total, enquanto a cor 1 seja um preto/cinza semitransparente, já que os gráficos monocromáticos são geralmente usados para sombras de veículos e edifícios nas animações.

Dessa forma, já é possível montar muitas graficias.

Agora chegamos à classe principal das disciplinas dentro dos formatos de dados do Outpost 2:
As animações.

As listas de animação começam com um cabeçalho global, que serve principalmente para a verificação de dados. Em seguida, seguem as definições concretas de animação, que se dividem em 3 níveis:

1. Animação
   Uma animação é a instância superior; ela representa uma animação de uma unidade, de um edifício ou de uma 'animação de partículas' (impacto de cometas, clima, explosão) em uma determinada situação inicial.
2. Quadro
   Um quadro é uma única imagem dentro de uma animação. Uma animação pode conter um ou mais quadros.
3. Subquadro
   Um subquadro é a informação de que uma determinada bitmap deve ser desenhada em uma determinada posição de um quadro sob certos critérios. Um quadro pode conter um ou mais subquadros.

Em seguida, já seguem as definições individuais de animação.

Os dados da camada superior, da animação, são prioritariamente dados administrativos - a Boundingbox refere-se às coordenadas da marcação em torno do veículo/edifício, quando este está selecionado e também indica qual área deve ser clicável.

O offset determina prioritariamente o "ponto zero"; o ponto que deve ser adicionado ou subtraído às coordenadas internas do jogo. Poderíamos dizer de forma mais matemática: o offset aqui indica a origem das coordenadas.

As janelas (Windows) são, assim como o offset, compostas por 4 valores uint(32) cada, que indicam uma área que é considerada utilizável para subquadros individuais. Fora das janelas, desde que seja apropriado para o bitmap, não se deve desenhar.

Com isso, agora podemos montar frames individuais, bem como animações completas, demonstrado aqui como exemplo em uma animação mais complexa, a animação com o índice 500.

A animação 500 mostra como um transporte Plymouth, carregado com minério comum, é descarregado. Esta é uma das poucas animações que utiliza a funcionalidade de janelas.

E assim, a animação completa pode ser montada.
Infelizmente, ainda há um problema com a escotilha superior, pois o bit correspondente nas informações do tipo de gráfico não está definido.

Aqui estão mais alguns sprites lindamente animados do jogo:

Agora falta apenas a interface do usuário do jogo, que é feita em um estilo de metal escovado.

Mas também aqui é evidente que Dynamix não precisou reinventar a roda; aqui não são apenas utilizadas as APIs User32 e GDI32 fornecidas pelo Windows - em particular, também é gerenciado o uso de recursos do User32.

Esses recursos podem ser extraídos, por exemplo, por programas como o Resource Hacker, desenvolvido como freeware por Angus Johnson, ou - caso você evite usar Wine no Linux / Mac OS - com a ajuda do wrestool incluído no icoutils.