Outpost 2 Format Fail · bei.pm

Format data yang digunakan oleh Outpost 2 mempunyai struktur yang mengingatkan kepada JFIF / PNG - setiap blok data sentiasa mempunyai header 8 Byte. Oleh itu, saya tidak akan mendokumentasikan setiap header di lokasi tertentu dan hanya akan mendokumentasikan penyimpangan di sana.

Formatnya sentiasa seperti berikut; data sebenar kemudiannya disisipkan di dalamnya:

Volume adalah sebuah kontainer data untuk permainan, mirip dengan format arkib seperti Tarball. Setidaknya dalam Outpost 2, format ini hanya mengenal fail - tiada folder. Mungkin, ini boleh disimulasikan melalui nama fail yang sesuai.

Sebuah volume terdiri daripada header volume serta beberapa blok volume yang sepadan dengan fail-fail tertentu.

"Volumes" adalah fail dengan sambungan 'vol' dalam direktori permainan.

Header Volume tidak mengandungi sebarang data berguna.
Ia hanya berfungsi sebagai bekas.

Dalam header Volume, yang pertama sekali seharusnya terdapat string Volume; diikuti dengan maklumat Volume.

Volume Strings adalah senarai nama fail yang terdapat dalam volume tersebut.

Informasi volume mengambil maklumat yang lebih terperinci berkenaan fail. Ini boleh dianggap sebagai sejenis entri direktori FAT (FAT = Jadual Pengagihan Fail)

Jumlah fail diperoleh daripada saiz blok dibahagi dengan panjang entri direktori - 14 bait.

Setiap entri direktori mempunyai struktur berikut:

Blok volume adalah sebuah kontena, yang menyimpan fail. Ia hanya mengandungi sekali lagi - berdasarkan format blok - saiz fail secara redundan dan seterusnya diikuti terus oleh data yang digunakan.

Tile adalah format grafik bitmap yang khusus untuk Outpost-2. Ia terdiri daripada 13 set tile, yang dipanggil "wells" (well0000.bmp hingga well0012.bmp), yang terletak di dalam volume maps.vol.

Set tile / Wells mengandungi yang berikut:

Adalah disarankan untuk melaksanakan dengan tepat, untuk tidak merender Tiles terlebih dahulu untuk menyimpannya dalam cache, kerana data untuk kitaran siang/malam masih perlu diproses - dan akan menghasilkan banyak data.

Tiles adalah grafik 8bpp dengan palet terindeks dengan resolusi 32x32 piksel, yang disusun secara berurutan. Dalam satu set Tiles yang dihasilkan, boleh terdapat jauh lebih banyak.

Kontainer utama terdiri daripada 2 bahagian: head dan data.

Setelah maklumat ini, akan ada juga fail palet yang berada dalam format RIFF yang standard. Spesifikasi yang tepat boleh didapati - kerana palet juga muncul di tempat lain - di bawah Palet.

Akhirnya, data piksel yang jelas mengikuti, dari kiri-atas secara baris ke kanan-bawah.
Nilai data dalam grafik yang biasanya dalam format bitmap 8bpp sepadan dengan indeks warna dalam palet warna.

Enjin permainan ini nampaknya *mungkin* menggambar Tiles secara on-demand.
Ini mungkin disebabkan oleh kitaran siang-malam, yang mempunyai 32 tahap bagi setiap Tile. Nampaknya, nilai kecerahan akan dikurangkan 'sedikit' setiap kali. Nilai yang tepat masih belum dapat ditentukan, saya bekerja berdasarkan pengiraan

v *= (daylight / 48) + 0.25;

dengan data HSV bagi pixel, di mana daylight adalah nilai antara 0-31 dan v adalah nilai antara 0-1. Selain itu, perlu diambil kira bahawa peta juga mempunyai sempadan 16 Tiles di kiri dan kanan (yang berfungsi untuk spawnen unit secara tidak terlihat).

Selain itu, nampaknya kitaran siang-malam hanya mengemas kini satu lajur peta setiap kitaran permainan.
Kitaran siang-malam yang dipercepat adalah seperti berikut:

Saya tidak tahu dengan tepat apa yang dimaksudkan dengan PRT; mungkin ia bermaksud 'Palette dan Resource Table' - kerana fail ini - yang boleh didapati sebagai op2_art.prt dalam maps.vol - adalah sejenisnya, atau ini mungkin menggambarkan fungsinya dengan baik.

Fail ini mengandungi senarai palet, jadual untuk semua bitmap yang digunakan, semua definisi animasi dan beberapa data yang tidak diketahui. Ia mengikuti format kontena sebelum ini secara longgar, kerana tidak semua rekod mengikuti skema ini.

Seksi CPAL (mungkin bermaksud kontena palet) hanya merangkumi data palet, dengan menunjukkan berapa banyak palet 8-bit yang biasanya berukuran 1052 byte yang ada.

Pernyataan 1052-byte tidak dianggap sebagai wajib, kerana format palet mungkin mempunyai saiz palet yang berbeza. Ia hanya terpakai untuk data yang disertakan bersama Outpost 2.

Setelah senarai palet, senarai bitmap akan diikuti secara langsung dan tanpa header pengenalan; begitu juga senarai animasi akan mengikuti dengan segera.
Kedua-duanya dimulakan dengan uint(32) (atau sekali lagi uint24+uint8 bendera?) yang menunjukkan jumlah rekod yang ada.

Informasi palet sangat mudah untuk dibaca.
ianya terdiri daripada satu header dan satu segmen data.

Bahagian data mengambil entri palet yang berasingan. Jumlah entri palet adalah berdasarkan panjang blok / 4.

Setiap entri mempunyai struktur yang ringkas seperti berikut;

Berkaitan dengan palet, hanya ada satu lagi yang perlu dikatakan, iaitu untuk palet yang digunakan untuk animasi, aturan berikut terpakai:

• Warna pertama SENTIASA transparan, tidak kira apa nilai yang diberikan di situ.
• Entiti palet 1-24 dianggap sebagai warna pemain dalam palet 1-8.
  Apa yang menjadikan warna selain daripada pemain 1 tidak jelas bagi saya.
  Saya mengesyaki bahawa warna yang lain adalah hardcoded.

Struktur data PRT ini menunjukkan bagaimana bitmap yang digunakan untuk sprite dibentuk. Bitmap ini berfungsi sebagai komponen tunggal, di mana beberapa disusun menjadi satu bingkai animasi sprite.

Data gambar yang konkret tersembunyi dalam op2_art.BMP di direktori permainan.
Sebab mengapa fail bitmap ini mempunyai header RIFF-bitmap (yang kebanyakannya betul) tidak jelas. Mungkin Outpost 2 menggunakan API sistem untuk memuat grafik, dengan mengambil alih header ini secara sementara dan menimpa medan yang berkaitan dan berbeza.

Data piksel boleh ditemui dalam fail BMP pada Posisi Offset + uint32-Offset, yang boleh dijumpai dalam fail BMP pada alamat 0x000A (offset data RIFF-bitmap), dan sekali lagi menyusunnya baris demi baris dari atas kiri ke bawah kanan.

Grafik monokrom 1bpp boleh dilukis sedemikian rupa, di mana warna 0 adalah ketelusan penuh, dan warna 1 adalah hitam/kelabu separuh telus, kerana grafik monokrom biasanya digunakan untuk bayangan kenderaan dan bangunan dalam animasi.

Dengan itu, banyak grafik dapat disusun.

Sekarang kita masuk ke kelas utama disiplin dalam format data Outpost 2:
Animasi.

Senarai animasi dimulakan dengan header global yang berfungsi terutamanya untuk pengesahan data. Seterusnya adalah definisi animasi yang terperinci, yang dibahagikan kepada 3 tahap:

1. Animasi
   Satu animasi adalah instans tertinggi; ia menggambarkan animasi bagi satu unit, bangunan, atau 'animasi partikel' (kejadian meteor, cuaca, letupan) dalam keadaan tertentu.
2. Frame
   Satu frame adalah satu gambar dalam satu animasi. Satu animasi boleh mengandungi satu atau lebih frame.
3. Subframe
   Satu subframe adalah maklumat yang menunjukkan bahawa bitmap tertentu harus dilukis pada posisi tertentu dalam satu frame berdasarkan kriteria tertentu. Satu frame boleh mengandungi satu atau lebih subframe.

Seterusnya adalah definisi animasi yang spesifik.

Data daripada lapisan teratas, animasi, adalah terutamanya data pengurusan - Boundingbox merujuk kepada koordinat tanda di sekitar kenderaan/bangunan, apabila ia dipilih dan juga menunjukkan kawasan yang boleh diklik.

Offset menentukan terutamanya "titik null"; titik yang perlu diselaraskan atau ditolak daripada koordinat dalaman permainan. Kita juga boleh katakan secara matematik: offset merujuk kepada asal koordinat di sini.

Bagi tingkap, sama seperti offset, terdapat 4 nilai uint(32) bagi setiap tingkap, yang menunjukkan kawasan yang boleh digunakan untuk subframe tertentu. Di luar tingkap, sepanjang ia diperuntukkan untuk bitmap, tidak boleh dilukis.

Dengan ini, kita kini boleh menggabungkan bingkai individu serta animasi lengkap, di sini sebagai contoh pada animasi yang lebih kompleks, animasi dengan indeks 500, didemonstrasikan

Animasi 500 menunjukkan bagaimana sebuah Plymouth-transport yang dipenuhi dengan bahan mentah biasa sedang dibongkar. Ini adalah salah satu dari sedikit animasi yang menggunakan fungsi pengendalian tetingkap.

Dan dengan itu, animasi lengkap dapat disatukan.
Malangnya, masih ada masalah dengan pintu muatan atas, kerana bit yang berkaitan dalam maklumat jenis grafik tidak ditetapkan.

Sini ada beberapa sprite lain yang dianimasikan dengan indah dari permainan:

Sekarang hanya tinggal antaramuka pengguna permainan yang mempunyai rupa logam berus.

Tetapi di sini juga jelas bahawa Dynamix tidak perlu mencipta semula roda; di sini bukan sahaja menggunakan API User32 dan GDI32 yang disediakan oleh Windows - khususnya juga pengurusan sumber dari User32 digunakan.

Ini boleh diekstrak menggunakan program seperti Resource Hacker yang dibangunkan oleh Angus Johnson sebagai perisian percuma, atau - jika anda menghindari penggunaan Wine di Linux / Mac OS - dengan menggunakan wrestool yang terdapat dalam icoutils.