Outpost 2 ꦢꦺꦠꦶꦭꦩꦠꦺ · bei.pm

ꦗꦮꦶꦱꦗꦶ
ꦢꦶꦱꦺꦴꦁ ꦠꦺꦱꦸꦏ꧀ ꦧꦼꦭꦶꦁ ꦲꦸꦔꦶꦁ ꦭꦶꦏꦼ ꦱꦸꦩ꧀ꦕꦠꦶꦁ OpenAI GPT-4o Mini.

Format file sing diterangake ing kaca iki adhedhasar analisis teknis babagan hak kekayaan intelektual saka Dynamix, Inc. lan Sierra Entertainment.
Hak kekayaan intelektual saiki dadi bagian saka Activision Publishing, Inc.- / Activision Blizzard, Inc.-massa lan saiki diduweni dening Microsoft Corp..

Informasi iki dikumpulake liwat Reverse Engineering lan Datenanalyse kanggo tujuan arsip lan interoperabilitas kanthi data sejarah.
Ora ana spesifikasi sing duwe hak utawa rahasia sing digunakake.

Gim iki saiki bisa dituku minangka unduhan ing gog.com.

Seni saka game

Rentetan artikel ing ngisor iki nyathet panemuku marang format data ing game strategi wektu nyata "Outpost 2: Divided Destiny", sing dirilis dening Sierra ing taun 1997 lan dikembangake dening Dynamix.

Aku wis fokus nganalisa data saka game iki - lan apa sing bisa ditindakake - kira-kira saka 01 November 2015 nganti 14 November 2015.

Miturut informasi sing bisa dakperoleh nganti saiki, Dynamix - kaya akeh perusahaan komersial liyane - ora ngembangake sawetara format data khusus kanggo Outpost 2, nanging uga digunakake ing pangembangan liyane kaya seri Mechwarrior (sing wis dimodifikasi).
Sanadyan mangkono, bisa dicathet manawa kekuatan inovasi format data iki sejatine winates lan asring adhedhasar konsep-konsep lawas saka format umum kaya JFIF lan RIFF.

kanggo interpretasi tabel lan format data, informasi liyane bisa ditemokake ing ꦱꦶꦠꦶꦤ꧀ ꦱꦶꦠꦶ? .
Data sing kasebut ing kene umume bisa dimangerteni minangka Little Endian.

Pungkasan, bisa dibilang yen reverse engineering iku banget nyenengake, sanajan ora lengkap.
Sajrone iku, aku uga nyaranake kanggo main game iki dhewe, amarga nawakake mekanika game sing menarik.

ꦲꦶꦏꦸꦁꦗꦺꦴ

Data format sing digunakake dening Outpost 2 nduweni struktur sing ngelingake marang JFIF / PNG - blok data sing saben-saben mesthi nduweni header 8 byte. Amarga iku, aku ora bakal nyatet header siji-siji ing panggonan sing cocog lan mung nyatet penyimpangan ing kono.

Format kasebut mesthi kaya ing ngisor iki; data sing bener-bener dienggo banjur dilebokake ing jerone:

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦶꦗꦶꦏ꧀ ꦧꦺꦴꦠꦺꦴꦱ

Nggawa informasi babagan apa sing diarepake ing blok data sabanjure.

Nilai-nilai sing dikenal:

  • 0x204C4F56 ('VOL '):
    Volume
  • 0x686C6F76 ('VOLH'):
    Header-Volume
  • 0x736C6F76 ('VOLS'):
    Strings-Volume
  • 0x696C6F76 ('VOLI'):
    Informasi-Volume
  • 0x4B4C4256 ('BLCK'):
    Block-Volume
  • 0x504D4250 ('PBMP'):
    Data-Grafik
  • 0x4C415050 ('PPAL'):
    Palet-Warna
  • 0x4C415043 ('CPAL'):
    Kontainer-Palet-Warna
  • 0x64616568 ('head'):
    Header
  • 0x61746164 ('data'):
    Data-Pengguna
0x0004 uint(24) ꦧꦭꦺꦴꦏ-ꦭꦺꦁꦏꦺ

Nduweni informasi babagan sepira gedhene (ing Byte) blok data ing ngisor iki.

Ing kene ateges data sing bener - 8 Header-Byte ora kalebu ing kono.
0x0007 uint(8) ꦗꦶꦏꦠ꧀?

Ora jelas, kanggo apa blok iki digunakake.

Ing Volume, nilai iki asring 0x80, ing file liyane asring 0x00. Iki nuduhake yen iki minangka set bendera.

ꦮꦺꦴꦭꦸꦤ꧀

Volume iku minangka wadah data kanggo game, padha karo format arsip kaya Tarball. Ing Outpost 2, format iki mung ngerti file - ora ana folder. Mungkin iki bisa disimulasikake liwat jeneng file sing cocog.

Sebuah Volume dumadi saka header Volume lan sawetara blok Volume, sing cocog karo file konkret.

"Volumes" iku file kanthi akhiran 'vol' ing direktori game.

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 56 4f 4c 20 -- -- -- -- -- -- -- -- -- -- -- -- V O L . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦺꦴꦏ꧀-ꦭꦺꦴꦁ
0x0007 uint(8) ꦥꦼꦭꦁ

Judhul Volume

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 76 6f 6c 68 -- -- -- -- -- -- -- -- -- -- -- -- v o l h . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦺꦴꦏ꧀-ꦭꦺꦴꦁ
0x0007 uint(8) ꦥꦼꦭꦁ

Header Volume ora ngemot data pangguna apa-apa.
Iku mung minangka wadah.

Dina pisanan ing Header Volume kudu ana Volume Strings; sawise iku banjur bakal ana informasi Volume.

Volume Strings

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 76 6f 6c 69 -- -- -- -- -- -- -- -- -- -- -- -- v o l i . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦺꦴꦏ꧀-ꦭꦺꦴꦁ
0x0007 uint(8) ꦥꦼꦭꦁ
ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 76 6f 6c 73 -- -- -- -- -- -- -- -- -- -- -- -- v o l s . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦺꦴꦏ꧀-ꦭꦺꦴꦁ
0x0007 uint(8) ꦥꦼꦭꦁ
0x0008 uint(32) ꦥꦺꦴꦭꦺꦴꦑ-ꦭꦺꦁꦒꦺ

Nyebutake pira byte saka data ing ngisor iki sing sejatine minangka data sing migunani.

Data liyane sing isih ana ing daftar volume-string katon dadi garbage.

Ing berkas-berkas sing duwe tanggal luwih anyar, 'data sing isih ana' iku 0x00, sing bisa nuduhake kekurangan ing toolchain nalika pangembangan game, yaiku, yen pangembang anyar ngurus inisialisasi buffer kanthi bener ing pungkasan, amarga ora ana pengaruh marang game apa data wis diinisialisasi utawa ora.
0x000c uint(8)[] ꦢꦺꦠꦶꦤꦩꦼꦤ-ꦭꦶꦱꦺ

Iki minangka dhaptar jeneng file sing dipungkasi 0-byte, sing - paling ora ing komponen data iki - mung ngarepake karakter ASCII.

Ora perlu, nalika ngurai data, kanggo ngetokake blok data iki luwih rinci, amarga ing informasi volume wis langsung dirujuk offset jeneng file.

VOLUME STRINGS iku sawijining dhaftar jeneng file sing kalebu ing sajroning volume kang ana.

Informasi Volume

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 76 6f 6c 69 -- -- -- -- -- -- -- -- -- -- -- -- v o l i . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦺꦴꦏ꧀-ꦭꦺꦴꦁ
0x0007 uint(8) ꦥꦼꦭꦁ

Informasi volume nyakup informasi luwih rinci kanggo file-file. Iki minangka sawijining jinis entri direktori FAT (FAT = File Allocation Table)

Jumlah file ditentokake saka ukuran blok dibagi dhuwure entri direktori - 14 Byte.

Entri direktori siji-sijine duwe susunan kaya ing ngisor iki:

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦢꦺꦠꦶꦤꦩꦼꦤ-ꦲꦺꦴꦤꦠ

Nyatakake ing ngendi offset (!) ing dhuwur dhaptar jeneng file (Volume-Strings) jeneng file saka file kasebut ditemokake.

Iki ngacu marang wiwitan blok data sing digunakake.
0x0004 uint(32) ꦢꦺꦠꦶꦱꦶ-ꦲꦺꦴꦥꦼꦠ

Nyatakake, ing endi offset ing sajroning file volume sing kabeh ana, file iki dumunung.
0x0008 uint(32) ꦢꦺꦠꦶ ꦏꦼꦏꦺ

Nyatakaké pira gedhene berkas ing Byte.
0x000c uint(16) 🏳️‍🌈?

Katone ana informasi tambahan babagan pengkodean file.

  • 0x03 wis disetel, yen file wis dikompres. Ing kene katon ana panggunaan pohon Huffman.
  • 0x80 katon mesthi disetel.

Blok Volume

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 56 42 4c 48 -- -- -- -- -- -- -- -- -- -- -- -- V B L H . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦺꦴꦏ꧀-ꦭꦺꦴꦁ
0x0007 uint(8) ꦥꦼꦭꦁ

Sak sawijining Volume-Block iku sawijining wadah, ing ngendi file-file disimpen. Iku mung ngemot - amarga format block - ukuran file sing redundant lan saiki langsung dilanjutake dening data sing digunakake.

ꦠꦶꦭꦼꦱ

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 50 42 4d 50 -- -- -- -- -- -- -- -- -- -- -- -- P B M P . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦶꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦫꦗꦶꦱꦺꦴ ꦭꦼꦔꦺ
0x0007 uint(8) ꦗꦗꦤꦶꦗꦶ

Tiles punika minangka format grafik Bitmap sing khusus kanggo Outpost-2. Padha nyebar ing 13 Tilesets, sing diarani "wells" (well0000.bmp nganti well0012.bmp), ingkang ana ing jero volume maps.vol.

Sajrone Tilesets / Wells ngemot ing ngendi:

Asma File Isi
well0000.bmp Grafik warna biru ukuran 32x32px - cocog kanggo nguji apa pemuat gambar sampeyan bisa digunakake
well0001.bmp Ngandung watu cerah, pegunungan ing watu cerah lan macem-macem variasi kawah tabrakan ing watu cerah
well0002.bmp Ngandung 'Doodads' watu cerah - yaiku unsur sing bisa dipasang kanggo ngurangi kekakuan (utawa kanthi sengaja minangka struktur, kaya tembok) ing watu cerah, kalebu vegetasi
well0003.bmp Ngandung struktur kaya kerak ing watu cerah
well0004.bmp Ngandung watu peteng, pegunungan ing watu peteng lan macem-macem variasi kawah tabrakan ing watu peteng
well0005.bmp Ngandung 'Doodads' watu peteng - yaiku unsur sing bisa dipasang kanggo ngurangi kekakuan (utawa kanthi sengaja minangka struktur, kaya tembok) ing watu peteng
well0006.bmp Ngandung struktur kaya kerak ing watu peteng, uga transisi antara watu cerah lan peteng
well0007.bmp Ngandung lava kalebu 4-5 bingkai animasi saka lava kasebut
well0008.bmp Ngandung pasir lan macem-macem variasi kawah tabrakan ing pasir
well0009.bmp Ngandung 'Doodads' pasir - yaiku unsur sing bisa dipasang kanggo ngurangi kekakuan (utawa kanthi sengaja minangka struktur, kaya tembok) ing pasir
well0010.bmp Ngandung 48 transisi saka pasir menyang watu cerah lan peteng
well0011.bmp Ngandung kutub peta, kanthi watu peteng minangka dasar
well0012.bmp Ngandung kutub peta, kanthi watu cerah minangka dasar

Iki dadi becik kanggo pelaksanaan sing akurat, ora ngasilake Tiles ing ngarep kanggo nyimpen, amarga data kanggo siklus dina/malam isih kudu diproses - lan bakal ana akeh banget data sing muncul.

Tiles yaiku grafik 8bpp karo palet terindeks kanthi resolusi 32x32 piksel, sing diatur siji sama liyane. Ing set Tiles sing wis digawe, bisa luwih akeh

Kontainer utama dumadi saka 2 bagian: head lan data.

Judhul Uga

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 68 65 61 64 -- -- -- -- -- -- -- -- -- -- -- -- h e a d . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦶꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦫꦗꦶꦱꦺꦴ ꦭꦼꦔꦺ
0x0007 uint(8) ꦗꦗꦤꦶꦗꦶ
0x0008 uint(32) Versi / Bendera?

Ing kene bisa dadi minangka indikasi versi saka format file; ing kabeh file sing ana ing tanganku, ana nilai 0x02
0x000c uint(32) ꦧꦼꦠꦼ (ꦲꦺꦴꦗꦺꦴꦭꦶꦤ꧀ ꦲꦺꦴꦤꦸꦠ꧀)

Nyatakaké pira amba file gambar (ing piksel).

Kanggo kabeh Wells saka Outpost 2, ing kene bakal ana nilai 0x20 utawa 32 sing diarepake.
0x0010 uint(32) ꦲꦺꦴꦶꦪꦺ (ꦮꦺꦫꦠꦶꦭꦺ ꦲꦺꦴꦗꦶꦭꦺ)

Nuduhake pinten dhuwuré file gambar (ing pixel).

Ing kabeh Wells saka Outpost 2, nilai 0x20 utawa 32 bakal diarep-arep.
0x0014 uint(32) ꦥꦶꦭꦸꦁꦠꦺꦧꦶ?

Arti saka nilai iki ora dikenal.

Amarga ana ing kabeh berkas sing dites ngemot nilai 8, bisa uga iki minangka informasi kedalaman warna.
0x0018 uint(32) ꦥꦶꦠꦼꦏꦺ 2?

Makna saka nilai iki ora dingerteni.

Mbok menawa iki minangka 'tujuan'-kandhane warna.

Sawise informasi iki, bakal ana berkas palet sing ana ing format RIFF standar. Spesifikasi sing tepat bisa ditemokake - amarga palet iki uga muncul ing panggonan liya - ing ꦥꦭꦼꦠꦼꦤ꧀.

Data Ubin

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 64 61 74 61 -- -- -- -- -- -- -- -- -- -- -- -- d a t a . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦶꦗꦶꦏ ꦧꦶꦠꦺꦱ
0x0004 uint(24) ꦧꦫꦗꦶꦱꦺꦴ ꦭꦼꦔꦺ
0x0007 uint(8) ꦗꦗꦤꦶꦗꦶ

Akhire, data piksel sing wis kosong iki muncul, saka kiwa-ndhuwur baris demi baris menyang kiwa-ngisor.
Nilai data ing gambar sing umume ana ing format 8bpp-Bitmap iki cocog karo indeks warna ing palet warna.

Data piksel diwiwiti saka ndhuwur kiwa lan rampung ing ngisor tengen.

Engine game nyathet Tiles kanthi *mungkin* on-demand.
Iki katon amarga siklus wengi-dinane, sing duwe 32 tingkat kanggo saben Tile. Ing kene, katon yen nilai padhang dijupuk 'sawetara' saka nilai kasebut. Nilai sing tepat durung bisa ditemtokake, aku kerja ing dasar perhitungan 

v *= (daylight / 48) + 0.25;

kanthi data HSV saka piksel, ing ngendi daylight minangka nilai saka 0-31 lan v minangka nilai antarane 0-1. Saliyane, kudu digatekake manawa ing peta ana pinggir 16 Tiles ing kiwa lan tengen (iki kanggo spawning unit sing ora katon).

Saliyane, siklus wengi-dinane katon nganyari mung siji kolom peta saben siklus game.
Siklus wengi-dinane sing dipercepat katon kaya ing ngisor iki:

Visualisasi siklus wengi-dinane

ꦥꦫꦶꦠ꧀

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 43 50 41 4c -- -- -- -- -- -- -- -- -- -- -- -- C P A L . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦺꦗꦶꦏ꧀ ꦧꦺꦪꦺꦴꦱ
0x0004 uint(24) ꦥꦭꦼꦠꦼꦤ꧀-ꦭꦼꦔꦺ

Ngandhut, mbalik marang format blok normal, jumlah palet sing bisa ditemokake ing file iki - ora dawa blok ing byte.
0x0007 uint(8) ꦥꦼꦩꦤ꧀

Kamungkinan, kaya biasane, Bendera.

Aku ora ngerti Bendera; amarga kabeh nilai sing dak ngerti cocog karo 0x00, bisa uga uga mungkin yèn jumlah Palet iku mung uint(32).

Apa sing diwakili dening PRT sejatine aku ora ngerti; nanging bisa wae contone 'Palette and Ressource Table' - amarga file iki - sing ditemokake minangka op2_art.prt ing maps.vol - nyatane minangka file kaya ngono, utawa iki bisa nerangake fungsi kasebut kanthi apik.

File iki ngemot dhaptar palet, tabel kabeh bitmap sing digunakake, kabeh definisi animasi, lan sawetara data sing durung dingerteni. File iki miturut format kontainer sing wis ana, nanging ora kabeh cathetan cocog karo skema iki.

Seksi CPAL (kamungkinan kanggo Paletten-Container) mung ngemot data palet, kanthi nyatakake pira saka palet ukuran 8-bit sing biasane 1052 byte sing ana.

Pernyataan 1052-byte iki ora dianggep wajib, amarga format palet bisa uga duwe ukuran palet sing beda-beda. Iki mung kanggo data sing dikirimake karo Outpost 2.

Sawise dhaptar palet, langsung lan tanpa header pambuka, wis ana dhaptar bitmap; lan langsung sawise iku ana dhaptar animasi.
Kedua dhaptar kasebut diwiwiti kanthi uint(32) (utawa maneh uint24+uint8 flag?) sing ngemot jumlah cathetan.

ꦥꦭꦼꦠꦼꦤ꧀

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 50 50 41 4c -- -- -- -- -- -- -- -- -- -- -- -- P P A L . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦼꦗꦶꦏ꧀ ꦧꦺꦠꦺꦱ
0x0004 uint(24) ꦥꦭꦺꦠꦺꦤ-ꦭꦺꦁꦒꦺ

Nggih, sabaliké format blok normal, nyatakaké jumlah palet ing berkas iki - dudu dawa blok ing byte.
0x0007 uint(8) ꦗꦶꦏꦗꦶ

Kamungkinan, kaya biasane, Flags.

Aku ora ngerti Flags; amarga kabeh nilai sing aku ngerti cocog karo 0x00, bisa uga jumlah palet iki mung sawijining uint(32).

Informasi palet gampang banget kanggo diwaca.
Iki dumadi saka header lan segmen data.

Judhul Palet

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 68 65 61 64 -- -- -- -- -- -- -- -- -- -- -- -- h e a d . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦼꦗꦶꦏ꧀ ꦧꦺꦠꦺꦱ
0x0004 uint(24) ꦥꦭꦺꦠꦺꦤ-ꦭꦺꦁꦒꦺ

Nggih, sabaliké format blok normal, nyatakaké jumlah palet ing berkas iki - dudu dawa blok ing byte.
0x0007 uint(8) ꦗꦶꦏꦗꦶ

Kamungkinan, kaya biasane, Flags.

Aku ora ngerti Flags; amarga kabeh nilai sing aku ngerti cocog karo 0x00, bisa uga jumlah palet iki mung sawijining uint(32).
0x0008 uint(32) ꦥꦭꦼꦠꦼꦤ꧀ꦥꦺꦴꦫꦺꦴꦤ꧀?

Mbokmenawa nemtokake, versi format palet endi sing dituturi dening palet.

Kabeh palet Outpost2 katon duwe versi 0x01.

Data Palet

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 64 61 74 61 -- -- -- -- -- -- -- -- -- -- -- -- d a t a . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦩꦼꦗꦶꦏ꧀ ꦧꦺꦠꦺꦱ
0x0004 uint(24) ꦧꦭꦗꦼꦭꦺꦴꦁ
0x0007 uint(8) ꦗꦶꦏꦗꦶ

Seksi data nampa entri palet siji-siji. Jumlah entri palet iku asale saka dawa blok / 4.

Entri siji-siji nduweni susunan sing prasaja kaya ing ngisor iki;

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- 04 -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(8) ꦫꦺꦴꦠ꧀-ꦏꦺꦴꦩ꧀ꦠꦺꦤ꧀

Nunjukaké pérangan Abang saka warna
0x0001 uint(8) ꦒꦿꦸꦤ꧀-ꦏꦼꦩ꧀ꦠꦸꦤꦺ

Nandhakake proporsi ijo saka warna
0x0002 uint(8) ꦧꦭꦸꦁ-ꦏꦺꦴꦩꦼꦤꦶ

Nuduhaké pérangan abang biru saka warna
0x0003 uint(8) ꦲꦸꦤ꧀ꦧꦼꦏꦤ - ꦥ꦳ꦺꦴꦏ꧀?

Ora cetha apa tegese nilai iki, amarga katon dhasar 0x04.

Kanggo palet, mung ana sing kudu diucapake, yen kanggo palet sing digunakake kanggo animasi kahanan ing ngisor iki berlaku:

  • Warna pisanan iku SALALAH transparan, ora preduli apa nilai sing kasebut ing kono.
  • Entri palet 1-24 dianggep minangka warna pemain ing palet 1-8.
    Ngendi warna-warna iki asalé saka pemain 1, aku ora ngerti.
    Aku ngira, warna-warna liyane iku wis hardcoded

Referensi Palet

ꦧꦶꦠꦩꦧꦱ

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦗꦺꦴꦧꦠꦶꦤ꧀ ꦏꦼꦠꦶꦱꦶ

Ngetokake lebar baris data piksel ing byte - amarga iki disusun miturut wates 4-byte.

Saiki gampang kanggo ngakses baris gambar tartamtu.

Kenapa nilai iki disimpen kanthi kapisah, sanajan bisa dihitung, durung cetha.
Mbok menawa iki minangka optimasi kanggo kode render.
0x0004 uint(32) ꦗꦶꦩꦶꦱꦶꦝꦶꦩꦸꦁ

Nunjukaké offset saka baris pisan ing bitmap
0x0008 uint(32) ꦲꦺꦴꦮꦺ

Ngandharake dhuwur gambar ing piksel
0x000c uint(32) ꦧꦿꦺꦴꦠꦺ

Ngetokake ambane gambar ing piksel
0x0010 uint(16) ꦠꦶꦥ꧀

Nyatakaké jinis gambar. Ing kéné katon manawa iki minangka bitmask:

  • 0x04 disetel, yen iki minangka grafik 1bpp.
  • 0x40 disetel, yen iki minangka grafik sing kudu ngetrapake windowing
0x0012 uint(16) ꦥꦭꦺꦠꦺ

Netepake, palet endi saka berkas PRT sing kudu digunakake

Struktur data saka file PRT iki nuduhake carane bitmap sing digunakake kanggo sprite disusun. Bitmap iki dadi siji komponen, sing sawetara digabungake dadi frame animasi saka sprite.

Data gambar sing konkret disimpen ing op2_art.BMP ing direktori game.
Kenapa file bitmap iki nduwe header RIFF-Bitmap (sing umume bener) ora cetha. Mungkin Outpost 2 nggunakake API sistem kanggo ngundhuh grafis, kanthi cara ngatur header iki sementara lan ngoverwrite bidang sing cocog lan bervariasi.

Data piksel ana ing file BMP ing Posisi Offset + uint32-Offset, ing file BMP bisa ditemokake ing alamat 0x000A (offset data RIFF-Bitmap), lan padha maneh karo susunan baris saka kiwa ndhuwur menyang tengen ngisor.

Grafis monochrome 1bpp bisa digambar kanthi cara kaya warna 0 dadi transparansi lengkap, lan warna 1 dadi setengah transparan ireng/abu-abu, amarga grafis monochrome umume digunakake kanggo bayangan kendaraan lan bangunan ing animasi.

Kanthi iki, sampeyan bisa nggabungake akeh grafis.

Modul papan perlindungan (Plymouth)

ꦄꦤꦶꦩꦸꦤꦶꦱꦺꦴ

Nalika iki kita bakal mlebu ing kelas raja saka disiplin ing sajrone format data Outpost 2:
Animasi.

Daftar animasi diwiwiti karo header global, sing utamane kanggo verifikasi data. Sawise iku, ana definisi animasi sing konkret, sing dipérang dadi 3 tingkat:

  1. Animasi
    Animasi iku instansi paling dhuwur; iku nglambangake animasi saka sawijining unit, bangunan utawa 'animasi partikel' (tabrakan komet, cuaca, ledakan) ing sawijining kondisi tartamtu.
  2. Frame
    Saben frame iku gambaran siji ing sajrone animasi. Siji animasi bisa ngemot siji utawa luwih frame.
  3. Subframe
    Saben subframe iku informasi babagan yen bitmap tartamtu kudu digambarake ing posisi tartamtu saka siji frame miturut kriteria tartamtu. Siji frame bisa ngemot siji utawa luwih subframe.

Sawise iku, langsung ana definisi-definisi animasi sing siji-siji.

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦏꦸꦭꦶꦁ ꦲꦶꦁꦏꦸꦭꦶꦤꦺꦴꦤꦺꦴ

Pira data animasi sing ana
0x0004 uint(32) ꦲꦤ꧀ꦗꦶꦱꦸꦤ꧀ ꦟꦼꦩꦺꦤꦶ

Pira jumlah frame sing kudu ana kabeh
0x0008 uint(32) ꦲꦤ꧀ꦗꦸꦁ ꦱꦸꦧꦫꦺꦴꦺꦤ꧀

Pira subframe sing sakabehe kudu ana
0x000c uint(32) ꦲꦤ꧀ꦗꦸꦁ ꦎꦲꦤꦸꦁ ꦲꦶꦪꦤ꧀

Pira "entri opsional" sing ana.

Animasi

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0020 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(32) ꦲꦸꦤꦼꦏꦸꦤ 1

Informasi sing ora dikenal
0x0004 uint(32) 𑑅𑑉𑑑𑑉𑑖𑑉𑑑𑑊: 𑑑𑑞𑑊𑑙𑑒𑑚𑑑𑑊

Marangke awalan kiwa (ing piksel) saka Bounding Box.
0x0008 uint(32) ꦧꦸꦤ꧀ꦠꦶꦁ ꦧꦺꦴꦁ: ꦲꦶꦁꦒꦼꦤ

Nandhani wiwitan ndhuwur (ing piksel) saka Bounding Box.
0x000c uint(32) ꦧꦸꦤꦺꦴꦠꦶꦁ ꦧꦺꦨꦸꦠ: ꦧꦿꦶꦠꦺ

Nampilake ambane (ing Pixel) saka Bounding Box.
0x0010 uint(32) ꦧꦸꦤ꧀ꦝꦶꦁ ꦧꦺꦴꦁ: ꦲꦺꦴꦭꦺ

Nunjukaké dhuwur (ing Piksel) saka Bounding Box.
0x0014 uint(32) Offset: X

Nunjukaké tengah horisontal saka animasi
0x0018 uint(32) Offset: Y

Nunjukaké tengah vertikal animasi
0x001c uint(32) ꦈꦤ꧀ꦧꦼꦏ꧀ꦤꦢꦶ 2

Informasi sing ora dikenal
0x0020 uint(32) ꦲꦤ꧀ꦗꦶꦱꦸꦤ꧀ ꦟꦼꦩꦺꦤꦶ

Nyatakaké pira jumlah bingkai animasi ing animasi iki
0x0024 uint(32) ꦲꦤ꧀ꦗꦺꦴꦤ꧀ Windows

Nunjukaké pira jendhela sing kudu digunakaké nalika nggambar

Data lapisan ndhuwur, animasi, utamane yaiku data administrasi - Boundingbox nuduhake koordhinat tandha ing sekitar kendaraan/gedhong, nalika dipilih lan uga nuduhake wilayah sing bisa diklik.

Offset utamane nemtokake "titik nol"; titik sing kudu dijumlahake utawa dikurangi menyang koordinat ing game. Ing istilah matematika, offset iki nuduhake asal koordhinat.

Ing Windows, kaya dene offset, ana (saben Windows) 4 nilai uint(32), ngendi iki nuduhake wilayah sing dianggep bisa digunakake kanggo subframe tunggal. Ing njaba Windows, yen wis disiapake kanggo bitmap, ora kena digambar.

Rangka

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(8) ꦱꦸꦧꦻꦭꦶꦗꦼꦁ-ꦲꦤ꧀ꦗꦱꦶꦭꦤꦶꦏ꧀ lan ꦠꦺꦴꦏꦼꦭ ꦏꦺꦴꦤꦶꦭ 1, 2

Nilai iki ngemot:

  • 0x7F (Bitmask): Jumlah subframe sing digunakake ing frame iki
  • 0x80: Informasi babagan ana ora'e Optional 1 lan 2
0x0001 uint(8) ꦲꦸꦤꦸꦁꦏꦶꦱꦺꦴ 1 lan Toggle kanggo Optional 3, 4

Nilai iki ngemot:

  • 0x7F (Bitmask): Ora dikenal - Aku curiga banget, iki minangka jumlah Gameticks sing bakal liwat, nganti frame sabanjure ditampilake
  • 0x80: Informasi babagan, apa Optional 3 lan 4 ana
0x0002 uint(8) Pilihan 1

Ora dikenal
0x0003 uint(8) Pilihan 2

Ora dikenal
0x0004 uint(8) ଓପସନାଲ 3

Ora dikenal
0x0005 uint(8) Optional 4

Ora dikenal

Subframe

ꦄꦢꦿ x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF ꦕꦗꦶ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ᮧᮞ᮪ᮕᮧᮒ ꦢꦠꦺꦤ꧀ꦠꦾꦺꦴ ꦧꦼꦱꦶꦗꦤ꧀ ꦲꦺꦴꦏꦼꦠꦶꦁ
0x0000 uint(16) ꦧꦶꦠꦩꦥ-ꦆꦶ

Nyatakan bitmap endi sing bakal digunakake kanggo subframe iki
0x0002 uint(8) ꦲꦸꦤꦼꦏꦸꦤ 1

Ora dikenal - nanging aku curiga banget, yen iki gegandhengan karo prioritas render (Z-Layer).
0x0003 uint(8) 𑀲𑀪𑀭𑀺𑀕𑀺-𑀅𑀢

Nunjukaké ing subframe endi kita saiki
0x0004 sint(16) ꦗꦸꦏꦼ - ꦲꦺꦴꦤꦶꦱꦶꦏꦼ

Nyatakaké ing endi ing jero Frame subframe kudu dipasang, utawa pira piksel bitmap kudu digeser sacara horisontal
0x0006 sint(16) ꦎꦺꦴꦧꦠ - ꦮꦼꦫꦶꦏꦭ

Nyatakna ngendi ing jero Frame subframe kudu dipasang, utawa pira pixel bitmap kudu dipindhah sacara vertikal

Mula kita saiki bisa nggabungake frame siji-siji, uga animasi lengkap, kaya ing ngendi dituduhake kanthi conto ing animasi sing luwih kompleks, animasi kanthi indeks 500.

Animasi 500

Animasi 500 nunjukaké, carané sawijining Plymouth-Transporter, sing kebak ore biasa, dipunsingkiraké. Iki minangka salah siji saka sawetara animasi, sing nggunakake fungsionalitas Windowing.

Lan mangkono, animasi lengkap bisa digabungaké.
Sayangé, isih ana masalah karo jendela muatan ndhuwur, amarga bit sing cocog ing informasi jinis grafik durung disetel.

Kene ana sawetara sprite liyane, sing kaendahané dianimasi saka game:

Panggambaran animasi 500 diilustrasikaké

Animasi 500 wis rampung digabung

Pabrik Gedung Plymouth

Pangkalan Angkasa Eden

Pusat Medis Eden

SCAT

Pangkalan Angkasa Plymouth

Easteregg:
Parade Natal

Easteregg:
Dog Dans

ꦱꦶꦗꦶꦪꦺꦴ ꦮꦶꦠꦶ

Saiki isih kurang antarmuka pangguna saka game kasebut, sing digawé kanthi gaya logam dipoles.

Nanging ing kene uga cetha, manawa Dynamix ora kudu nemokake roda maneh; ing kene ora mung nggunakake API User32 lan GDI32 sing disedhiyakake dening Windows - utamane uga nggunakake manajemen sumber daya saka User32.

Iki bisa diekstrak kanthi program kaya Angus Johnson sing dikembangaké minangka Freeware Resource Hacker, utawa - yen sampeyan isin nggunakake Wine ing Linux / Mac OS - nganggo wrestool sing kalebu ing icoutils.

Asma Berkas Isi
Outpost2.exe Nggawa mung ikon saka dolanan, sing nuduhake stasiun angkasa ing New Terra
op2shres.dll Nggawa sapanunggalane grafis kanggo unsur kendhali kaya wates, tombol, tombol radio, lan kothak centang uga latar dialog, gambar pendukung kanggo teks misi crita lan grafis latar menu utama
out2res.dll Nggawa dekorasi jendela inggame, ikon kanggo logam biasa lan khusus, layar muat, grafis kanggo dialog uga grafis kursor liyane, tambahan kanggo animasi ing direktori dolanan