Định dạng tệp Outpost 2 · bei.pm

Các định dạng dữ liệu được sử dụng bởi Outpost 2 có cấu trúc giống như JFIF / PNG - các khối dữ liệu riêng lẻ luôn có một tiêu đề 8 byte. Vì vậy, tôi sẽ không ghi chép lại từng tiêu đề ở các vị trí cụ thể tương ứng mà chỉ ghi chép các điểm khác biệt.

Định dạng luôn là như sau; các dữ liệu thực tế sau đó được nhúng vào bên trong:

Các Volume là một container dữ liệu cho trò chơi, tương tự như một định dạng lưu trữ như Tarball. Ít nhất trong Outpost 2, định dạng này chỉ biết đến các tệp - không có thư mục. Có lẽ chúng có thể được mô phỏng thông qua tên tệp tương ứng.

Một Volume bao gồm tiêu đề Volume và nhiều khối Volume, mà tương ứng với các tệp cụ thể.

"Volumes" là các tệp có đuôi 'vol' trong thư mục trò chơi.

Header khối chứa không có dữ liệu hữu ích nào.
Nó chỉ đơn giản là một bộ chứa.

Dữ liệu đầu tiên trong Header khối nên là các chuỗi Volume; tiếp theo là thông tin về Volume.

Các Volume Strings là một danh sách tên tệp nằm trong volume này.

Thông tin Volume chứa các thông tin chi tiết về các tệp. Điều này có thể được coi là một loại mục nhập thư mục FAT (FAT = Bảng phân bổ tệp).

Số lượng tệp được tính bằng kích thước khối chia cho độ dài của mục nhập thư mục - 14 byte.

Các mục nhập thư mục riêng lẻ có cấu trúc như sau:

Một khối Volume là một container, có nhiệm vụ chứa các tệp tin. Nó chỉ bao gồm một lần nữa - do định dạng khối - thông tin kích thước tệp tin và sau đó là ngay lập tức dữ liệu sử dụng.

Các Tiles là định dạng đồ họa Bitmap đặc thù của Outpost-2. Chúng trải dài qua 13 Tilesets, được gọi là "wells" (well0000.bmp đến well0012.bmp), nằm trong khối maps.vol.

Các Tilesets / Wells chứa những nội dung sau:

Thật sự khuyên rằng nên thực hiện một cách chính xác, không nên render các ô (tiles) trước để lưu vào bộ nhớ cache, vì dữ liệu cho chu kỳ ngày/đêm vẫn cần phải được xử lý - và sẽ có rất nhiều dữ liệu phát sinh.

Các ô là hình ảnh 8bpp với bảng màu chỉ mục có độ phân giải 32x32 pixel, được sắp xếp theo chiều dọc. Trong một bộ ô (tileset) như vậy, có thể có nhiều hơn nữa.

Container chính bao gồm 2 phần: head và data.

Theo những thông tin này, còn có một tệp bảng màu ở định dạng RIFF chuẩn. Thông số kỹ thuật chính xác có thể tìm thấy - vì các bảng màu cũng xuất hiện ở nơi khác - tại Bảng màu.

Cuối cùng, dữ liệu pixel đã được hiển thị, từ góc trên bên trái theo hàng đến góc dưới bên phải.
Giá trị dữ liệu đối với các hình ảnh thường được trình bày dưới dạng bitmap 8bpp tương ứng với chỉ số của màu trong bảng màu.

Động cơ trò chơi vẽ các ô *có khả năng* theo yêu cầu.
Điều này dường như liên quan đến chu kỳ ngày-đêm, với 32 cấp độ của từng ô. Trong đó, có vẻ như giá trị độ sáng được trừ đi 'một chút'. Các giá trị chính xác vẫn chưa được xác định, tôi đang làm việc dựa trên cơ sở tính toán

v *= (daylight / 48) + 0.25;

với dữ liệu HSV của các pixel, trong đó daylight là một giá trị từ 0-31 và v là một giá trị từ 0-1. Hơn nữa, cần lưu ý rằng trên bản đồ vẫn còn một dải 16 ô ở bên trái và bên phải (để tạo ra các đơn vị không nhìn thấy).

Bên cạnh đó, chu kỳ ngày-đêm dường như chỉ cập nhật một cột của bản đồ cho mỗi chu kỳ trò chơi.
Một chu kỳ ngày-đêm được tăng tốc sẽ trông như sau:

Tôi không biết chính xác PRT đại diện cho điều gì; có thể là 'Bảng Palettes và Tài nguyên' - vì đây là một tệp - được tìm thấy với tên op2_art.prt trong maps.vol - liên quan đến điều đó, hoặc điều này sẽ mô tả chức năng khá tốt.

Tệp này chứa danh sách các palette, một bảng về tất cả các bitmap đã sử dụng, tất cả các định nghĩa animation và một loạt dữ liệu chưa biết. Nó tuân theo định dạng container trước đó một cách lỏng lẻo, vì không phải tất cả các bản ghi đều theo mô hình này.

Phần CPAL (có khả năng đại diện cho Container Palette) chỉ bao gồm dữ liệu palette, bằng cách chỉ ra số lượng palette 8-bit có kích thước 1052 byte thông thường.

Sự chỉ định 1052 byte không được coi là bắt buộc, vì định dạng palette có thể cho phép kích thước palette khác nhau. Nó chỉ áp dụng cho tập dữ liệu mà Outpost 2 được phát hành.

Sau danh sách palette ngay lập tức và không có tiêu đề mở đầu, là danh sách bitmap; ngay sau đó là danh sách animation.
Cả hai đều được bắt đầu bằng một uint(32) (hoặc lại là uint24 + uint8 flags?) chứa số lượng bản ghi.

Thông tin về pallet rất dễ dàng để đọc.
Nó bao gồm một tiêu đề và một đoạn dữ liệu.

Phần dữ liệu bao gồm các mục pallet riêng lẻ. Số lượng mục pallet được xác định bởi độ dài của khối / 4.

Các mục riêng lẻ có cấu trúc đơn giản như sau;

Về các bảng màu, chỉ có thể nói rằng, các quy tắc sau áp dụng cho các bảng màu được sử dụng cho hoạt hình:

• Màu đầu tiên LUÔN LUÔN là trong suốt, bất kể giá trị nào được chỉ định ở đó.
• Các mục bảng màu 1-24 được coi là màu của người chơi trong các bảng màu 1-8.
  Tôi không rõ màu sắc từ người chơi 1 và các màu sắc khác đến từ đâu.
  Tôi nghi ngờ rằng các màu còn lại được mã hóa cứng.

Cấu trúc dữ liệu của tệp PRT này chỉ ra cách mà các bitmap được sử dụng cho các sprite được xây dựng. Những bitmap này đóng vai trò là thành phần riêng lẻ, từ đó nhiều cái được ghép lại thành một khung hình hoạt hình của một sprite.

Dữ liệu hình ảnh cụ thể thì ẩn chứa trong op2_art.BMP trong thư mục trò chơi.
Nguyên nhân tại sao tệp bitmap này có một tiêu đề RIFF bitmap (chủ yếu là chính xác) vẫn chưa rõ. Có thể Outpost 2 sử dụng các API hệ thống để tải đồ họa, bằng cách tạm thời sử dụng tiêu đề này và ghi đè lên các trường tương ứng, có sự thay đổi.

Dữ liệu pixel được tìm thấy trong tệp BMP tại vị trí Offset + uint32-Offset, mà có thể tìm thấy ở địa chỉ 0x000A trong tệp BMP (điểm dữ liệu RIFF-Bitmap), và lại tương ứng với cách sắp xếp theo dòng từ trên xuống dưới bên trái sang phải.

Đồ họa đơn sắc 1bpp có thể được vẽ sao cho màu 0 hoàn toàn trong suốt, trong khi màu 1 là một màu đen/xám bán trong suốt, vì đồ họa đơn sắc thường được sử dụng cho bóng của phương tiện và tòa nhà trong các hoạt hình.

Với điều này, người ta có thể ghép nhiều đồ họa lại với nhau.

Bây giờ chúng ta đến với lớp cao nhất của các chuyên ngành trong định dạng dữ liệu Outpost 2:
Các hình ảnh động.

Các danh sách hình ảnh động được bắt đầu bằng một tiêu đề toàn cầu, chủ yếu phục vụ cho việc xác minh dữ liệu. Sau đó là các định nghĩa hình ảnh động cụ thể, được chia thành 3 cấp độ:

1. Hình ảnh động
   Một hình ảnh động là thực thể cao nhất; nó đại diện cho một hình ảnh động của một đơn vị, một tòa nhà hoặc một 'hình ảnh động hạt' (va chạm sao chổi, thời tiết, nổ) trong một tình huống nhất định.
2. Khung hình
   Một khung hình là một hình ảnh đơn lẻ trong một hình ảnh động. Một hình ảnh động có thể chứa một hoặc nhiều khung hình.
3. Khung phụ
   Một khung phụ là thông tin về việc một bitmap nhất định sẽ được vẽ ở một vị trí nhất định của một khung hình dưới các tiêu chí nhất định. Một khung hình có thể chứa một hoặc nhiều khung phụ.

Sau đó sẽ là các định nghĩa hình ảnh động cụ thể.

Dữ liệu của lớp trên cùng, của hoạt ảnh, chủ yếu là dữ liệu quản lý - Boundingbox chỉ định tọa độ của điểm đánh dấu quanh phương tiện/công trình, khi nó được chọn và cũng đồng thời xác định khu vực nào có thể nhấp vào.

Offset chủ yếu xác định "điểm gốc"; điểm mà cần phải tính toán hoặc trừ trên tọa độ trong trò chơi. Có thể nói một cách toán học: offset ở đây chỉ định gốc tọa độ.

Các cửa sổ cũng giống như offset, bao gồm (cho mỗi cửa sổ) 4 giá trị uint(32), chỉ định một khu vực có thể sử dụng cho các khung con riêng lẻ. Bên ngoài các cửa sổ, nếu không được chỉ định cho bitmap, không được phép vẽ.

Với điều này, chúng ta có thể ghép nối các khung hình riêng lẻ cũng như các hoạt ảnh hoàn chỉnh, ở đây sẽ được minh họa bằng một hoạt ảnh phức tạp hơn, hoạt ảnh có chỉ số 500.

Animation 500 cho thấy cách một chiếc xe tải Plymouth, được chở đầy quặng thông thường, được dỡ hàng. Đây là một trong số ít các animation sử dụng chức năng Windowing.

Và đây là cách ghép nối toàn bộ animation lại với nhau.
Thật không may, vẫn còn một vấn đề với cửa tải phía trên, vì bit tương ứng trong thông tin loại đồ họa chưa được thiết lập.

Dưới đây là một số sprite được hoạt hình rất đẹp khác từ trò chơi:

Bây giờ còn thiếu giao diện người dùng của trò chơi, được thiết kế với phong cách kim loại chải.

Nhưng ở đây cũng có thể thấy rằng Dynamix không cần phải phát minh lại bánh xe; ở đây không chỉ đơn giản là sử dụng các API User32 và GDI32 mà Windows cung cấp - đặc biệt là quản lý tài nguyên từ User32 cũng được sử dụng.

Các tài nguyên này có thể được trích xuất bằng các chương trình như Resource Hacker, được phát triển như phần mềm miễn phí bởi Angus Johnson, hoặc - nếu bạn ngại sử dụng Wine trên Linux / Mac OS - bằng cách sử dụng wrestool có trong icoutils.