Outpost 2 파일 형식 · bei.pm

Outpost 2에서 사용되는 데이터 형식은 JFIF / PNG를 연상시키는 구조를 가지고 있으며, 각 데이터 블록은 항상 8 바이트 헤더를 포함하고 있습니다. 따라서 각 헤더를 해당 특정 위치에 문서화하는 것은 생략하고, 그곳에서는 오직 차이점만 문서화합니다.

형식은 항상 다음과 같으며, 실제 데이터는 그 안에 포함되어 있습니다:

볼륨은 게임을 위한 데이터 컨테이너로, Tarball과 같은 아카이브 형식과 유사합니다. 최소한 Outpost 2에서는 이 형식이 파일만 포함하고 있으며 - 폴더는 없습니다. 하지만 적절한 파일 이름을 통해 이러한 폴더를 시뮬레이션할 수 있을 것입니다.

볼륨은 볼륨 헤더와 여러 개의 볼륨 블록으로 구성되며, 이 블록은 구체적인 파일에 해당합니다.

"Volumes"는 게임 디렉토리 내에서 'vol' 확장자를 가진 파일입니다.

볼륨 헤더에는 사용 데이터가 포함되어 있지 않습니다.
그것은 단순히 컨테이너 역할을 합니다.

볼륨 헤더의 첫 번째 데이터는 볼륨 문자열이어야 하며, 그 다음에 볼륨 정보가 이어집니다.

볼륨 문자열은 볼륨 내에 포함된 파일 이름 목록입니다.

볼륨 정보는 파일에 대한 자세한 정보를 포함합니다. 이는 어떤 면에서 FAT 디렉토리 항목의 일종입니다 (FAT = 파일 할당 테이블).

파일의 수는 블록 크기를 디렉토리 항목의 길이로 나눈 값에서 14 바이트를 뺀 값으로 계산됩니다.

각각의 디렉토리 항목은 다음과 같은 구조를 가지고 있습니다:

볼륨 블록은 파일을 수용하는 컨테이너입니다. 블록 형식 때문에 파일 크기를 중복해서 포함하고 있으며, 그 다음에는 바로 유용한 데이터가 옵니다.

타일은 아웃포스트-2 특정 비트맵 그래픽 포맷입니다. 이는 13개의 타일셋으로 구성되어 있으며, "우물"이라고 불립니다 (well0000.bmp부터 well0012.bmp까지), 이들은 볼륨 maps.vol 내에 위치하고 있습니다.

타일셋 / 우물에는 다음 내용이 포함되어 있습니다:

정확한 구현을 위해 타일을 미리 렌더링하여 캐시하는 것은 권장하지 않습니다. 왜냐하면 주/야 주기에 대한 데이터는 아직 처리해야 하며, 매우 많은 데이터가 발생할 수 있기 때문입니다.

타일은 각각 32x32 픽셀 해상도의 인덱스 팔레트를 가진 8bpp 그래픽으로 서로 배열되어 있습니다. 이렇게 생성된 타일셋에는 훨씬 더 많은

주 컨테이너는 두 개의 섹션으로 구성되어 있습니다: head와 data.

이 정보에 따라 표준화된 RIFF 형식의 팔레트 파일이 추가로 제공됩니다. 팔레트가 다른 곳에서도 등장하기 때문에 정확한 사양은 팔레트에서 확인할 수 있습니다.

마지막으로 왼쪽 상단에서 오른쪽 하단으로 줄 단위로 나열된 원시 픽셀 데이터가 이어집니다.
일반적으로 8bpp 비트맵 형식인 그래픽의 데이터 값은 색상 팔레트에서 색상의 인덱스에 해당합니다.

게임 엔진은 타일을 *아마도* 필요에 따라 그립니다.
이는 32단계의 개별 타일을 가진 낮과 밤의 주기 때문인 것 같습니다. 이때 밝기 값에서 '조금씩' 차감되는 것으로 보입니다. 정확한 값은 아직 확인되지 않았으며, 저는 계산 기준으로 작업하고 있습니다.

v *= (daylight / 48) + 0.25;

픽셀의 HSV 데이터를 사용하여, 여기서 daylight는 0-31의 값이고 v는 0-1 사이의 값입니다. 또한 맵에는 각각 왼쪽과 오른쪽으로 16개의 타일의 경계가 존재한다는 점을 고려해야 합니다 (이는 유닛의 보이지 않는 스폰을 위해 필요합니다).

추가로, 낮과 밤의 주기는 게임 사이클당 맵의 한 열만 업데이트하는 것 같습니다.
가속화된 낮과 밤의 주기는 다음과 같이 보입니다:

PRT가 정확히 무엇을 의미하는지는 잘 모르겠지만, 예를 들어 '팔레트 및 리소스 테이블'일 가능성이 있습니다. 이 파일은 op2_art.prt로 maps.vol에 존재하며, 실제로 그러한 내용을 담고 있거나 이 기능을 잘 설명할 수 있습니다.

이 파일에는 팔레트 목록, 사용된 모든 비트맵에 대한 테이블, 모든 애니메이션 정의 및 여러 가지 미지의 데이터가 포함되어 있습니다. 기존의 컨테이너 형식을 느슨하게 따르지만, 모든 데이터 레코드가 이 형식을 따르는 것은 아닙니다.

CPAL 섹션(팔레트 컨테이너를 의미할 가능성이 높음)은 팔레트 데이터만 포함하며, 일반적으로 1052 바이트 크기의 8비트 팔레트가 몇 개 존재하는지를 나타냅니다.

1052 바이트의 표기는 의무사항으로 간주되지 않으며, 팔레트 형식이 잠재적으로 다양한 팔레트 크기를 가질 수 있음을 의미합니다. 이는 Outpost 2와 함께 제공되는 데이터 세트에만 해당됩니다.

팔레트 목록 다음에는 별도의 헤더 없이 바로 비트맵 목록이 나옵니다; 그 다음에는 애니메이션 목록이 뒤따릅니다.
두 목록 모두 각각 uint(32) (또는 다시 uint24+uint8 플래그?)로 시작하여 데이터 레코드 수를 포함합니다.

팔레트 정보는 매우 쉽게 읽을 수 있습니다.
각각 헤더와 데이터 세그먼트로 구성되어 있습니다.

데이터 섹션은 개별 팔레트 항목을 포함합니다. 팔레트 항목의 수는 블록 길이 / 4에 따라 결정됩니다.

각 항목은 다음과 같은 간단한 구조를 가지고 있습니다;

팔레트에 대해 추가로 말씀드리자면, 애니메이션에 사용되는 팔레트에는 다음과 같은 규칙이 적용됩니다:

• 첫 번째 색상은 항상 투명하며, 그곳에 어떤 값이 입력되어 있든 관계 없습니다.
• 팔레트 항목 1-24는 팔레트 1-8에서 플레이어 색상으로 간주됩니다.
  플레이어 1을 제외한 색상이 정확히 어디서 오는지는 저도 잘 모르겠습니다.
  남은 색상은 하드코딩되어 있다고 추측합니다.

PRT 파일의 이 데이터 구조는 스프라이트에 사용되는 비트맵이 어떻게 구성되어 있는지를 나타냅니다. 이 비트맵은 개별 구성 요소로 사용되며, 여러 개가 스프라이트의 애니메이션 프레임으로 조합됩니다.

구체적인 이미지 데이터는 게임 디렉토리에 있는 op2_art.BMP에 숨겨져 있습니다.
이 비트맵 파일이 (대부분 올바른) RIFF 비트맵 헤더를 가지고 있는 이유는 불분명합니다. 아마도 Outpost 2는 그래픽을 로드하기 위해 시스템 API를 사용하여 이 헤더를 일시적으로 사용하고 해당 변동 필드를 덮어쓰는 방식으로 작동할 것입니다.

픽셀 데이터는 BMP 파일에서 오프셋 + uint32 오프셋 위치에 있으며, 이 값은 BMP 파일의 주소 0x000A에서 찾을 수 있습니다 (RIFF 비트맵 데이터 오프셋). 데이터는 다시 위에서 왼쪽에서 오른쪽으로 아래로의 행 단위로 배열됩니다.

모노크롬 1bpp 그래픽은 색상 0이 완전한 투명성, 색상 1이 반투명한 검정/회색으로 그려질 수 있습니다. 왜냐하면 모노크롬 그래픽은 일반적으로 애니메이션에서 차량 및 건물의 그림자에 사용되기 때문입니다.

따라서 이미 많은 그래픽을 조합할 수 있습니다.

이제 Outpost 2 데이터 형식 내의 분야 중 최상급인 애니메이션에 대해 알아보겠습니다.
애니메이션입니다.

애니메이션 목록은 주로 데이터 검증을 위한 글로벌 헤더로 시작됩니다. 그 다음에는 3단계로 구성된 구체적인 애니메이션 정의가 이어집니다:

1. 애니메이션
   애니메이션은 최상위 인스턴스입니다; 이는 특정 상황에서 단위, 건물 또는 '입자 애니메이션'(유성 충돌, 날씨, 폭발)의 애니메이션을 나타냅니다.
2. 프레임
   프레임은 애니메이션 내의 단일 이미지입니다. 애니메이션은 하나 이상의 프레임을 포함할 수 있습니다.
3. 서브프레임
   서브프레임은 특정 비트맵이 특정 기준 하에 프레임의 특정 위치에 그려져야 한다는 정보를 의미합니다. 하나의 프레임은 하나 이상의 서브프레임을 포함할 수 있습니다.

이후에는 각 애니메이션 정의가 바로 이어집니다.

최상위 레이어의 데이터인 애니메이션은 주로 관리 데이터로 구성되어 있습니다 - Boundingbox는 차량/건물 주변의 마킹 좌표를 나타내며, 해당 항목이 선택되었을 때 클릭 가능한 영역을 동시에 표시합니다.

오프셋은 주로 "제로 포인트"를 결정합니다; 게임 내부 좌표에 더하거나 빼야 할 점입니다. 수학적으로 말하자면, 오프셋은 여기서 좌표 원점을 나타냅니다.

윈도우는 오프셋과 마찬가지로 각각 (윈도우당) 4개의 uint(32) 값으로 구성되어 있으며, 이는 개별 서브프레임에 사용할 수 있는 영역을 지정합니다. 비트맵에 적절히 지정된 경우, 윈도우 밖에서는 그려서는 안 됩니다.

이를 통해 우리는 개별 프레임뿐만 아니라 전체 애니메이션을 적절하게 조합할 수 있습니다. 여기서는 인덱스 500의 복잡한 애니메이션을 예로 들어 설명합니다.

애니메이션 500은 일반 광석이 실린 플리머스 화물차가 하역되는 모습을 보여줍니다. 이는 창 관리 기능을 활용하는 몇 안 되는 애니메이션 중 하나입니다.

이렇게 전체 애니메이션을 조합할 수 있습니다.
안타깝게도 상단 적재구에 문제가 있는데, 여기서 그래픽 유형 정보의 해당 비트가 설정되지 않았습니다.

게임에서의 아름답게 애니메이션된 스프라이트 몇 개를 더 소개합니다:

이제 게임의 사용자 인터페이스가 남았으며, 이는 브러시드 메탈 느낌으로 디자인되었습니다.

하지만 여기서도 Dynamix가 새로운 바퀴를 발명할 필요는 없었습니다; 여기서는 Windows에서 제공하는 User32 및 GDI32 API를 단순히 사용하는 것이 아니라, 특히 User32의 리소스 관리도 활용되고 있습니다.

예를 들어, Angus Johnson이 무료 소프트웨어로 개발한 Resource Hacker와 같은 프로그램을 통해 추출할 수 있으며, Linux / Mac OS에서 Wine 사용을 꺼리는 경우에는 icoutils에 포함된 wrestool을 사용할 수 있습니다.