Outpost 2 Format File · bei.pm

Format data yang digunakan oleh Outpost 2 memiliki struktur yang mirip dengan JFIF / PNG - setiap blok data selalu dilengkapi dengan header 8 byte. Oleh karena itu, saya tidak akan mendokumentasikan setiap header di tempat yang sesuai dan hanya mendokumentasikan penyimpangan.

Formatnya selalu seperti berikut; data yang sebenarnya kemudian tersemat di dalamnya:

Volume adalah sebuah wadah data untuk permainan, mirip dengan format arsip seperti Tarball. Setidaknya di Outpost 2, format ini hanya mengenal file - tidak ada folder. Mungkin saja folder tersebut dapat disimulasikan melalui nama file yang sesuai.

Sebuah Volume terdiri dari header Volume serta beberapa blok Volume yang sesuai dengan file-file konkret.

"Volumes" adalah file dengan akhiran 'vol' di direktori permainan.

Header Volume tidak mengandung data berguna apapun.
Ia hanya berfungsi sebagai wadah.

Tanggal pertama dalam Header Volume seharusnya berisi string Volume; diikuti oleh informasi Volume.

Volume Strings adalah daftar nama file yang terdapat dalam volume tersebut.

Informasi volume mencakup informasi yang lebih rinci tentang file-file. Ini dapat dianggap sebagai semacam entri direktori FAT (FAT = Tabel Alokasi File).

Jumlah file diperoleh dari ukuran blok dibagi dengan panjang entrinya direktori - 14 byte.

Setiap entri direktori memiliki struktur sebagai berikut:

Sebuah Volume-Block adalah sebuah wadah yang menyimpan file. Ia hanya mengandung sekali lagi - karena format blok - ukuran file secara redundan dan setelah itu langsung diikuti oleh data yang digunakan.

Tiles adalah format grafik bitmap yang spesifik untuk Outpost-2. Mereka terdiri dari 13 set tiles, yang disebut "wells" (well0000.bmp hingga well0012.bmp), yang berada di dalam volume maps.vol.

Set tiles / Wells ini berisi hal-hal berikut:

Sangat disarankan untuk pelaksanaan yang akurat, agar tidak merender Tiles sebelumnya untuk di-cache, karena data untuk siklus siang/malam masih harus diproses - dan akan ada sangat banyak data yang dihasilkan.

Tiles adalah grafik 8bpp dengan palet terindeks dengan resolusi 32x32 piksel, yang disusun satu sama lain. Dalam sebuah tileset yang dihasilkan, namun bisa jauh lebih banyak

Kontainer utama terdiri dari 2 seksi: head dan data.

Setelah informasi ini, akan ada file palet yang tersedia dalam format RIFF yang distandarisasi. Spesifikasi yang tepat dapat ditemukan - karena palet tersebut juga muncul di tempat lain - di Palet.

Akhirnya, data piksel mentah mengikuti, dari kiri atas ke kanan bawah secara baris.
Nilai data pada grafik yang biasanya berupa bitmap 8bpp ini sesuai dengan indeks warna dalam palet warna.

Engine permainan menggambar Tiles *kemungkinan* sesuai permintaan.
Ini tampaknya terkait dengan siklus siang-malam, yang memiliki 32 tingkatan untuk setiap Tile. Tampaknya, setiap kali nilai kecerahan 'sedikit' dikurangi. Nilai yang tepat masih belum dapat ditentukan, saya bekerja berdasarkan perhitungan

v *= (daylight / 48) + 0.25;

dari data HSV piksel, di mana daylight adalah nilai dari 0-31 dan v adalah nilai antara 0-1. Selain itu, perlu diperhatikan bahwa di peta terdapat batas masing-masing 16 Tile di kiri dan kanan (yang digunakan untuk pemunculan unit secara tak terlihat).

Selain itu, siklus siang-malam sepertinya hanya memperbarui satu kolom peta per siklus permainan.
Siklus siang-malam yang dipercepat terlihat seperti berikut:

Saya tidak tahu apa sebenarnya yang dimaksud dengan PRT; bisa jadi itu berarti 'Palette dan Resource Table' - karena file ini - yang dapat ditemukan sebagai op2_art.prt di dalam maps.vol - adalah seperti itu, atau ini bisa menggambarkan fungsinya dengan cukup baik.

File ini berisi daftar palet, tabel tentang semua bitmap yang digunakan, semua definisi animasi, dan sejumlah data yang tidak diketahui. File ini mengikuti format kontainer yang ada sebelumnya secara longgar, karena tidak semua catatan mengikuti skema ini.

Seksi CPAL (yang mungkin berarti Paletten-Container) hanya mencakup data palet dengan menyatakan berapa banyak dari palet 8-bit yang biasanya berukuran 1052 byte yang ada.

Pernyataan ukuran 1052 byte ini tidak dianggap wajib, karena format palet dapat memungkinkan ukuran palet yang berbeda. Ini hanya berlaku untuk data yang disertakan dengan Outpost 2.

Setelah daftar palet, diikuti langsung dan tanpa header pengantar, adalah daftar bitmap; begitu juga, daftar animasi mengikuti dengan segera.
Keduanya masing-masing diawali dengan uint(32) (atau mungkin uint24+uint8 flags?) yang berisi jumlah catatan.

Informasi palet sangat mudah dibaca.
Mereka terdiri dari header dan segmen data.

Seksi data mencakup setiap entri palet. Jumlah entri palet diperoleh dari panjang blok / 4.

Setiap entri memiliki struktur sederhana sebagai berikut;

Tentang palet, hanya bisa dikatakan bahwa untuk palet yang digunakan untuk animasi, aturan berikut berlaku:

• Warna pertama SELALU transparan, terlepas dari nilai apa yang diberikan di sana.
• Entri palet 1-24 dianggap sebagai warna pemain dalam palet 1-8.
  Asal warna di luar pemain 1 saya tidak tahu.
  Saya menduga warna-warna lainnya sudah di-hardcode.

Struktur data dari file PRT ini menunjukkan bagaimana bitmap yang digunakan untuk sprite dibangun. Bitmap ini berfungsi sebagai komponen tunggal, yang beberapa di antaranya dirakit menjadi satu frame animasi dari sprite.

Data gambar konkret terdapat dalam op2_art.BMP di direktori game.
Alasan mengapa file bitmap ini memiliki header RIFF-Bitmap (yang sebagian besar benar) masih belum jelas. Mungkin Outpost 2 menggunakan API sistem untuk memuat grafik, dengan cara sementara mengambil header ini dan menimpa bidang yang sesuai dan bervariasi.

Data piksel dapat ditemukan di dalam file BMP pada posisi Offset + uint32-Offset, yang dapat ditemukan di alamat 0x000A dalam file BMP (offset data RIFF-Bitmap), dan kembali sesuai dengan pengaturan per baris dari kiri atas ke kanan bawah.

Grafik monokrom 1bpp dapat digambar sedemikian rupa, hingga warna 0 mewakili transparansi penuh, sedangkan warna 1 adalah hitam/abu-abu setengah transparan, karena grafik monokrom biasanya digunakan untuk bayangan kendaraan dan bangunan dalam animasi.

Dengan demikian, banyak grafik sudah dapat dirakit.

Sekarang kita sampai pada kelas utama disiplin dalam format data Outpost 2:
Animasi.

Daftar animasi dimulai dengan header global yang terutama digunakan untuk verifikasi data. Selanjutnya adalah definisi animasi konkret yang dibagi menjadi 3 tingkatan:

1. Animasi
   Sebuah animasi adalah instansi tertinggi; ia mewakili animasi dari sebuah unit, bangunan, atau 'animasi partikel' (benturan komet, cuaca, ledakan) dalam keadaan tertentu.
2. Frame
   Sebuah frame adalah satu gambar tunggal dalam sebuah animasi. Sebuah animasi dapat terdiri dari satu atau lebih frame.
3. Subframe
   Sebuah subframe adalah informasi tentang bahwa bitmap tertentu harus digambar pada posisi tertentu dari sebuah frame berdasarkan kriteria tertentu. Sebuah frame dapat terdiri dari satu atau lebih subframe.

Selanjutnya adalah definisi animasi yang spesifik.

Data dari lapisan tertinggi, yaitu animasi, terutama adalah data administratif - Boundingbox merujuk pada koordinat penanda di sekitar kendaraan/bangunan, kapan pun itu dipilih dan juga menunjukkan area mana yang dapat diklik.

Offset terutama menentukan "titik nol"; titik yang harus ditambahkan atau dikurangkan pada koordinat internal permainan. Dapat juga dikatakan secara matematis: offset di sini merujuk pada asal koordinat.

Windows terdiri dari 4 nilai uint(32) untuk setiap window, yang menunjukkan area yang dianggap dapat digunakan untuk subframe tertentu. Di luar windows, tidak boleh digambar, jika tidak ditentukan untuk bitmap tersebut.

Dengan ini, kita sekarang dapat menyusun frame individu maupun animasi lengkap, di sini sebagai contoh pada animasi yang lebih kompleks, animasi dengan indeks 500, diperagakan

Animasi 500 menunjukkan bagaimana sebuah Plymouth-Transporter, yang dimuat dengan bijih biasa, dibongkar. Ini adalah salah satu dari sedikit animasi yang memanfaatkan fungsionalitas windowing.

Dan inilah cara untuk menyatukan seluruh animasi.
Sayangnya, masih ada masalah dengan pintu atas, karena bit yang sesuai dalam informasi jenis grafik tidak diatur.

Ini beberapa sprite yang sangat indah dan dianimasikan dari permainan:

Sekarang masih perlu antarmuka pengguna dari permainan, yang memiliki tampilan logam yang disikat.

Tetapi di sini juga terlihat bahwa Dynamix tidak perlu menciptakan kembali roda; di sini tidak hanya menggunakan secara sederhana API User32 dan GDI32 yang disediakan oleh Windows - terutama juga menggunakan manajemen sumber daya dari User32.

Ini dapat diekstraksi menggunakan program seperti Resource Hacker yang dikembangkan oleh Angus Johnson sebagai perangkat lunak gratis, atau - jika Anda menghindari penggunaan Wine di Linux / Mac OS - dengan bantuan wrestool yang terdapat dalam icoutils.