Outpost 2 รูปแบบไฟล์ · bei.pm

ไทย
ข้อความนี้ได้รับการแปลโดยอัตโนมัติผ่าน OpenAI GPT-4o Mini

รูปแบบไฟล์ที่อธิบายไว้ในหน้านี้อิงจากการวิเคราะห์ทางเทคนิคของทรัพย์สินทางปัญญาจาก Dynamix, Inc. และ Sierra Entertainment.
ทรัพย์สินทางปัญญาในปัจจุบันเป็นส่วนหนึ่งของกลุ่ม Activision Publishing, Inc. / Activision Blizzard, Inc. และในขณะนี้เป็นของ Microsoft Corp..

ข้อมูลเหล่านี้ถูกรวบรวมผ่าน การวิศวกรรมย้อนกลับ และ การวิเคราะห์ข้อมูล เพื่อวัตถุประสงค์ในการจัดเก็บข้อมูลและความสามารถในการทำงานร่วมกันกับข้อมูลประวัติศาสตร์.
ไม่มีสเปคที่เป็นกรรมสิทธิ์หรือเป็นความลับถูกใช้.

เกมนี้สามารถซื้อได้ในราคาเป็นดาวน์โหลดที่ gog.com.

ศิลปะของเกม

บทความชุดต่อไปนี้เป็นการบันทึกความรู้ของฉันเกี่ยวกับรูปแบบข้อมูลในเกมวางแผนแบบเรียลไทม์ "Outpost 2: Divided Destiny" ซึ่งเผยแพร่โดย Sierra ในปี 1997 และพัฒนาโดย Dynamix

ฉันได้ทำการวิเคราะห์ข้อมูลของเกมนี้ตั้งแต่ประมาณวันที่ 1 พฤศจิกายน 2015 ถึง 14 พฤศจิกายน 2015

จากข้อมูลที่ฉันสามารถรวบรวมได้ จนถึงปัจจุบัน Dynamix - เช่นเดียวกับบริษัทเชิงพาณิชย์หลายแห่ง - ไม่ได้พัฒนารูปแบบข้อมูลบางประเภทเฉพาะสำหรับ Outpost 2 แต่ได้ใช้งานในโครงการอื่น ๆ เช่นซีรีส์ Mechwarrior (ที่ปรับเปลี่ยน)
ไม่ว่าในกรณีใดก็ตาม ยังสามารถสังเกตได้ว่าความคิดสร้างสรรค์ในรูปแบบข้อมูลนั้นมีขอบเขตจำกัดและมักจะอิงจากแนวคิดที่มีอยู่เดิมจากรูปแบบทั่วไป เช่น JFIF และ RIFF

สำหรับการตีความตารางและรูปแบบข้อมูลข้อมูลเพิ่มเติมสามารถดูได้ที่ อะไรคืออะไร?
ข้อมูลที่ระบุในที่นี้โดยทั่วไปถือว่าเป็น Little Endian

สรุปได้ว่าการวิศวกรรมย้อนกลับนั้นสนุกมาก แม้ว่าจะยังไม่สมบูรณ์
แน่นอนว่าฉันขอแนะนำให้เล่นเกมนี้ด้วย เพราะมันมีกลไกการเล่นที่น่าสนใจ

บทนำ

รูปแบบข้อมูลที่ใช้ใน Outpost 2 มีโครงสร้างที่คล้ายคลึงกับ JFIF / PNG - บล็อกข้อมูลแต่ละบล็อกจะมีส่วนหัวขนาด 8 ไบต์เสมอ ดังนั้นฉันจึงขอข้ามการบันทึกส่วนหัวแต่ละส่วนที่ตำแหน่งเฉพาะและจะบันทึกเฉพาะความเบี่ยงเบนเท่านั้น

รูปแบบจะเป็นดังนี้เสมอ; ข้อมูลที่ใช้งานจริงจะถูกฝังอยู่ในนั้น:

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(32) ไบต์มหัศจรรย์

ประกอบด้วยข้อมูลเกี่ยวกับสิ่งที่คาดว่าจะเกิดขึ้นในบล็อกข้อมูลถัดไป

ค่าที่รู้จัก:

  • 0x204C4F56 ('VOL '):
    ปริมาณ
  • 0x686C6F76 ('VOLH'):
    ส่วนหัวของปริมาณ
  • 0x736C6F76 ('VOLS'):
    สตริงปริมาณ
  • 0x696C6F76 ('VOLI'):
    ข้อมูลปริมาณ
  • 0x4B4C4256 ('BLCK'):
    บล็อกปริมาณ
  • 0x504D4250 ('PBMP'):
    ข้อมูลกราฟิก
  • 0x4C415050 ('PPAL'):
    แผนภูมิสี
  • 0x4C415043 ('CPAL'):
    คอนเทนเนอร์แผนภูมิสี
  • 0x64616568 ('head'):
    ส่วนหัว
  • 0x61746164 ('data'):
    ข้อมูลที่ใช้
0x0004 uint(24) ความยาวบล็อก

ข้อมูลเกี่ยวกับขนาด (เป็นไบต์) ของข้อมูลบล็อกด้านล่างนี้

ซึ่งหมายถึงข้อมูลที่ใช้งานจริง - 8 ไบต์ของหัวเรื่องจะไม่รวมอยู่ในนี้
0x0007 uint(8) ธง?

ยังไม่ทราบแน่ชัดว่า Block นี้มีวัตถุประสงค์อะไร

ใน Volumes ค่านี้มักจะเป็น 0x80 ส่วนในไฟล์อื่น ๆ มักจะเป็น 0x00 ซึ่งบ่งชี้ว่าอาจจะเป็นการตั้งค่าสถานะ (Flag-Set)

ปริมาณ

Volume เป็นตัวเก็บข้อมูลสำหรับเกม คล้ายกับรูปแบบไฟล์เก็บข้อมูล เช่น Tarball อย่างน้อยใน Outpost 2 รูปแบบนี้มีเพียงไฟล์ - ไม่มีโฟลเดอร์ อาจเป็นไปได้ว่าเราสามารถจำลองโฟลเดอร์เหล่านี้ได้โดยใช้ชื่อไฟล์ที่เหมาะสม

Volume ประกอบด้วย Volume-Header และ Volume Blocks หลายตัวที่ตรงกับไฟล์ที่แท้จริง

"Volumes" คือไฟล์ที่มีนามสกุล 'vol' ในไดเรกทอรีเกม

Adr 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) ธง

ส่วนหัวของปริมาตร

Adr 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) ธง

ส่วนหัวของ Volume ไม่มีข้อมูลการใช้งานใด ๆ
มันมีไว้เพียงเพื่อเป็นที่เก็บข้อมูลเท่านั้น

ข้อมูลแรกในส่วนหัวของ Volume ควรเป็น Volume Strings; หลังจากนั้นจะเป็นข้อมูลเกี่ยวกับ Volume

สายเสียง

Adr 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) ธง
Adr 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) ความยาวของ Payload

ระบุจำนวนไบต์ของข้อมูลต่อไปนี้ที่เป็นข้อมูลที่ใช้งานได้จริง

ข้อมูลที่เหลืออยู่ในรายการวอลุ่มสตริงนั้นชัดเจนว่าต้องถูกมองว่าเป็น ขยะ

ในไฟล์ที่มีวันที่ใหม่กว่า ข้อมูล 'ที่เหลือ' จะเป็น 0x00 ซึ่งอาจบ่งบอกถึงความไม่เพียงพอของเครื่องมือในระหว่างการพัฒนาเกม กล่าวคือ นักพัฒนาเพิ่งมาดูแลการเริ่มต้นที่ถูกต้องของบัฟเฟอร์ในภายหลัง เพราะมันไม่มีผลต่อเกมว่าข้อมูลนั้นได้รับการเริ่มต้นหรือไม่
0x000c uint(8)[] รายการชื่อไฟล์

นี่คือรายการชื่อไฟล์ที่ถูกจำกัดด้วย 0-Byte ซึ่ง - อย่างน้อยในส่วนข้อมูลที่นำเสนอ - คาดว่าจะมีเพียงอักขระ ASCII เท่านั้น

ไม่จำเป็นต้องประเมินข้อมูลบล็อกนี้อย่างละเอียดเมื่อทำการประมวลผลข้อมูล เนื่องจากในข้อมูล Volume จะมีการอ้างอิงตำแหน่งของชื่อไฟล์โดยตรงอยู่แล้ว

Volume Strings คือรายการชื่อไฟล์ที่อยู่ภายใน Volume

ข้อมูลเกี่ยวกับปริมาตร

Adr 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) ธง

ข้อมูลเกี่ยวกับ Volume จะบันทึกรายละเอียดเพิ่มเติมเกี่ยวกับไฟล์ โดยจะมีลักษณะคล้ายกับรายการใน FAT (FAT = File Allocation Table)

จำนวนไฟล์จะคำนวณจากขนาดของบล็อกหารด้วยความยาวของรายการในไดเรกทอรี - 14 ไบต์

รายการในไดเรกทอรีแต่ละรายการมีโครงสร้างดังนี้:

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(32) ออฟเซ็ตชื่อไฟล์

ระบุว่าชื่อไฟล์ของไฟล์นั้นอยู่ที่ออฟเซ็ต (!) ใดในรายการชื่อไฟล์ (Volume-Strings)

โดยอิงจากจุดเริ่มต้นของบล็อกข้อมูลที่ใช้งาน
0x0004 uint(32) ออฟเซ็ตไฟล์

ระบุว่าไฟล์อยู่ที่ตำแหน่งใดภายในไฟล์ Volume ทั้งหมด
0x0008 uint(32) ขนาดไฟล์

ระบุขนาดของไฟล์เป็นไบต์
0x000c uint(16) ธง?

ดูเหมือนว่าจะมีข้อมูลเพิ่มเติมเกี่ยวกับการเข้ารหัสไฟล์

  • 0x03 จะถูกตั้งค่าเมื่อไฟล์ถูกบีบอัด โดยมีการใช้ต้นไม้ฮัฟฟ์แมนในที่นี้
  • 0x80 ดูเหมือนว่าจะถูกตั้งค่าเสมอ

บล็อกปริมาตร

Adr 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) ธง

บล็อกวอลลุ่มคือคอนเทนเนอร์ที่ใช้เก็บไฟล์ ซึ่งจะมีขนาดไฟล์ซ้ำอีกครั้งหนึ่ง - เนื่องจากรูปแบบของบล็อก - และหลังจากนั้นจะตามมาด้วยข้อมูลที่ใช้งานได้ทันที

กระเบื้อง

Adr 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) ธง

Tile เป็นรูปแบบกราฟิก Bitmap ที่เฉพาะเจาะจงสำหรับ Outpost-2 ซึ่งมีทั้งหมด 13 Tilesets เรียกว่า "wells" (well0000.bmp ถึง well0012.bmp) ซึ่งอยู่ภายใน Volume maps.vol

โดย Tilesets / Wells จะมีเนื้อหาดังต่อไปนี้:

ชื่อไฟล์ เนื้อหา
well0000.bmp กราฟิกขนาด 32x32 พิกเซล สีฟ้า - เหมาะสำหรับทดสอบว่า Image-Loader ทำงานได้หรือไม่
well0001.bmp ประกอบด้วยหินสีอ่อน เทือกเขาบนหินสีอ่อน และหลากหลายรูปแบบของหลุมอุกกาบาตในหินสีอ่อน
well0002.bmp ประกอบด้วย 'Doodads' บนหินสีอ่อน - ซึ่งเป็นองค์ประกอบที่สามารถวางเพื่อสร้างความหลากหลาย (หรือวางเป็นโครงสร้าง เช่น กำแพง) บนหินสีอ่อน รวมถึงพืชพรรณด้วย
well0003.bmp ประกอบด้วยโครงสร้างแบบเปลือกบนหินสีอ่อน
well0004.bmp ประกอบด้วยหินสีเข้ม เทือกเขาบนหินสีเข้ม และหลากหลายรูปแบบของหลุมอุกกาบาตในหินสีเข้ม
well0005.bmp ประกอบด้วย 'Doodads' บนหินสีเข้ม - ซึ่งเป็นองค์ประกอบที่สามารถวางเพื่อสร้างความหลากหลาย (หรือวางเป็นโครงสร้าง เช่น กำแพง) บนหินสีเข้ม
well0006.bmp ประกอบด้วยโครงสร้างแบบเปลือกบนหินสีเข้ม รวมถึงการเปลี่ยนผ่านระหว่างหินสีอ่อนและหินสีเข้ม
well0007.bmp ประกอบด้วยลาวา รวมถึงเฟรมอนิเมชัน 4-5 เฟรมของลาวา
well0008.bmp ประกอบด้วยทรายและหลากหลายรูปแบบของหลุมอุกกาบาตในทราย
well0009.bmp ประกอบด้วย 'Doodads' บนทราย - ซึ่งเป็นองค์ประกอบที่สามารถวางเพื่อสร้างความหลากหลาย (หรือวางเป็นโครงสร้าง เช่น กำแพง) บนทราย
well0010.bmp ประกอบด้วยการเปลี่ยนผ่าน 48 ครั้งจากทรายไปยังหินสีอ่อนและหินสีเข้ม
well0011.bmp ประกอบด้วยขั้วโลกของแผนที่ โดยมีหินสีเข้มเป็นพื้นฐาน
well0012.bmp ประกอบด้วยขั้วโลกของแผนที่ โดยมีหินสีอ่อนเป็นพื้นฐาน

แนะนำให้ไม่เรนเดอร์ Tiles ล่วงหน้าเพื่อเก็บข้อมูลในแคช เพราะข้อมูลสำหรับวงจรวัน/คืนยังต้องได้รับการประมวลผล - และจะมีข้อมูลจำนวนมากเกิดขึ้น

Tiles เป็นกราฟิกแบบ 8bpp ที่มีพาเลตต์แบบดัชนี ขนาด 32x32 พิกเซล ซึ่งจัดเรียงอยู่ในแนวตั้ง ใน Tileset ที่เกิดขึ้นสามารถมีมากกว่านั้นได้

คอนเทนเนอร์หลักประกอบด้วย 2 ส่วน: head และ data.

หัวข้อกระเบื้อง

Adr 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) เวอร์ชัน / ธง?

นี่อาจเป็นการระบุเวอร์ชันของรูปแบบไฟล์; ในไฟล์ทั้งหมดที่ฉันมีอยู่ค่านี้คือ 0x02
0x000c uint(32) ความกว้าง (ความละเอียดแนวนอน)

ระบุความกว้างของไฟล์ภาพ (เป็นพิกเซล).

สำหรับทุกบ่อใน Outpost 2 ค่าที่คาดว่าจะได้รับที่นี่คือ 0x20 หรือ 32.
0x0010 uint(32) ความสูง (ความละเอียดในแนวตั้ง)

ระบุความสูงของไฟล์ภาพ (เป็นพิกเซล).

สำหรับทุกบ่อใน Outpost 2 ค่าที่คาดว่าจะได้ที่นี่คือ 0x20 หรือ 32.
0x0014 uint(32) ความลึกของสี?

ความหมายของค่าตัวนี้ยังไม่เป็นที่ทราบ

เนื่องจากมันปรากฏในไฟล์ที่ตรวจสอบทั้งหมดว่าเป็นค่า 8 อาจจะเป็นการระบุความลึกของสี
0x0018 uint(32) ความลึกสี 2?

ความหมายของค่านี้ไม่เป็นที่รู้จัก

อาจเป็น 'เป้าหมาย' ความลึกของสี

จากข้อมูลเหล่านี้จะมีไฟล์พาเลตต์ที่อยู่ในรูปแบบ RIFF ที่ได้มาตรฐานเพิ่มเติม ไฟล์สเปคที่แน่นอนสามารถพบได้ - เนื่องจากพาเลตต์ปรากฏที่อื่นด้วย - ที่ พาเลตต์.

ข้อมูลกระเบื้อง

Adr 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) ธง

สุดท้ายนี้ข้อมูลพิกเซลที่เปลือยเปล่าจะถูกจัดเรียงจากมุมซ้ายบนไปยังมุมขวาล่างตามแถว
ค่าข้อมูลในกราฟิกที่โดยทั่วไปมีรูปแบบเป็น 8bpp-Bitmaps จะตรงกับดัชนีของสีในพาเลตสี

ข้อมูลพิกเซลเริ่มต้นจากมุมซ้ายบนและสิ้นสุดที่มุมขวาล่าง

เอนจินเกมจะทำการวาด Tiles ในแบบ *ตามความต้องการ*.
สิ่งนี้ดูเหมือนจะเกี่ยวข้องกับวงจรวัน-คืน ซึ่งมีการแบ่งระดับของ Tiles ออกเป็น 32 ระดับ โดยจะมีการลดค่าความสว่างลง 'เล็กน้อย' ในแต่ละครั้ง ค่าที่แน่นอนยังไม่สามารถกำหนดได้ ฉันกำลังทำงานบนพื้นฐานการคำนวณ 

v *= (daylight / 48) + 0.25;

โดยใช้ข้อมูล HSV ของพิกเซล โดยที่ daylight เป็นค่าระหว่าง 0-31 และ v เป็นค่าระหว่าง 0-1. านอกจากนี้ต้องคำนึงว่าบนแผนที่ยังมีขอบ 16 Tiles ทั้งทางซ้ายและขวา (ซึ่งใช้สำหรับการเกิดหน่วยที่มองไม่เห็น).

เพิ่มเติมคือ วงจรวัน-คืนจะอัปเดตเฉพาะหนึ่งคอลัมน์ของแผนที่ในแต่ละรอบเกม.
วงจรวัน-คืนที่เร็วขึ้นจึงมีลักษณะดังนี้:

การแสดงภาพของวงจรวัน-คืน

PRT

Adr 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) ความยาวพาเลท

ระบุจำนวนพาเลตที่พบในไฟล์นี้ แทนที่จะเป็นความยาวของบล็อกในไบต์ ตามรูปแบบบล็อกปกติ
0x0007 uint(8) ธง

น่าจะเป็นธงเหมือนที่เคยเป็นมา

อย่างไรก็ตาม ฉันไม่ทราบถึงธงใด ๆ เพราะค่าทั้งหมดที่ฉันทราบตรงกับ 0x00 ดังนั้นมันอาจเป็นไปได้ว่าจำนวนพาเลตต์นั้นเป็นเพียง uint(32) เท่านั้น

ไม่ทราบแน่ชัดว่า PRT หมายถึงอะไร; อาจจะหมายถึง 'Palette and Resource Table' - เนื่องจากไฟล์นี้ - ซึ่งพบได้ในชื่อ op2_art.prt ใน maps.vol - เป็นไฟล์ประเภทนี้ หรือจะเป็นการอธิบายฟังก์ชันได้ดี

ไฟล์นี้มีรายการของพาเลตต์, ตารางเกี่ยวกับบิตแมพที่ใช้งานทั้งหมด, คำนิยามอนิเมชันทั้งหมด และข้อมูลที่ไม่รู้จักอีกจำนวนหนึ่ง มันทำตามรูปแบบของคอนเทนเนอร์ที่ใช้ก่อนหน้านี้แบบหลวมๆ เนื่องจากไม่ใช่ทุกระเบียนที่ปฏิบัติตามโครงสร้างนี้

ส่วน CPAL (น่าจะหมายถึง พาเลตต์คอนเทนเนอร์) จะรวมข้อมูลพาเลตต์ไว้ โดยระบุจำนวนพาเลตต์ขนาด 8 บิตที่มีขนาด 1052 ไบต์ ซึ่งปกติจะมีอยู่

การระบุขนาด 1052 ไบต์นี้ไม่ได้ถือว่าเป็นข้อบังคับ เนื่องจากรูปแบบพาเลตต์อาจมีขนาดพาเลตต์ที่แตกต่างกัน มันใช้ได้เฉพาะกับข้อมูลที่ Outpost 2 ถูกส่งมอบ

หลังจากรายการพาเลตต์ จะมีรายการบิตแมพตามมาโดยตรงและไม่มีส่วนหัวแนะนำ, และรายการอนิเมชันจะตามมาต่อจากนั้น
ทั้งสองรายการจะเริ่มต้นด้วย uint(32) (หรืออีกครั้ง uint24+uint8 flags?) ซึ่งมีจำนวนระเบียนอยู่

พาเลตต์

Adr 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) ความยาวของพาเลท

ระบุจำนวนพาเลทที่สามารถพบได้ในไฟล์นี้ แทนที่จะเป็นความยาวของบล็อกในไบต์ ตามปกติในรูปแบบบล็อก
0x0007 uint(8) ธง

น่าจะเป็นเช่นเดียวกับปกติคือธง.

อย่างไรก็ตาม ฉันไม่ทราบเกี่ยวกับธงใดๆ; เนื่องจากค่าทั้งหมดที่ฉันทราบตรงกับ 0x00 ดังนั้นจึงอาจเป็นไปได้ว่าจำนวนพาเลตต์นั้นเป็นเพียง uint(32) เท่านั้น.

ข้อมูลเกี่ยวกับพาเลทอ่านได้ง่ายมาก
มันประกอบด้วยส่วนหัวและส่วนข้อมูล

ส่วนหัวของพาเลตต์

Adr 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) ความยาวของพาเลท

ระบุจำนวนพาเลทที่สามารถพบได้ในไฟล์นี้ แทนที่จะเป็นความยาวของบล็อกในไบต์ ตามปกติในรูปแบบบล็อก
0x0007 uint(8) ธง

น่าจะเป็นเช่นเดียวกับปกติคือธง.

อย่างไรก็ตาม ฉันไม่ทราบเกี่ยวกับธงใดๆ; เนื่องจากค่าทั้งหมดที่ฉันทราบตรงกับ 0x00 ดังนั้นจึงอาจเป็นไปได้ว่าจำนวนพาเลตต์นั้นเป็นเพียง uint(32) เท่านั้น.
0x0008 uint(32) เวอร์ชันรูปแบบพาเลตต์?

กำหนดว่าเวอร์ชันของรูปแบบพาเลทใดที่พาเลทนั้นปฏิบัติตาม

พาเลททั้งหมดใน Outpost2 ดูเหมือนว่าจะมีเวอร์ชัน 0x01

ข้อมูลพาเลท

Adr 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) ธง

ส่วนข้อมูลจะมีการบันทึกข้อมูลของพาเลตแต่ละรายการ จำนวนรายการพาเลตจะคำนวณจากความยาวของบล็อก / 4

รายการแต่ละรายการมีโครงสร้างที่เรียบง่ายดังนี้;

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- 04 -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(8) ส่วนประกอบสีแดง

ระบุสัดส่วนสีแดงของสี
0x0001 uint(8) องค์ประกอบสีเขียว

ระบุสัดส่วนของสีเขียว
0x0002 uint(8) ส่วนประกอบสีฟ้า

ระบุสัดส่วนสีน้ำเงินของสี
0x0003 uint(8) ไม่ทราบ - ธง?

ยังไม่ชัดเจนว่าค่านี้หมายถึงอะไร เนื่องจากดูเหมือนว่าจะเป็นพื้นฐาน 0x04。

เกี่ยวกับพาเลทก็มีเพียงต้องบอกว่า สำหรับพาเลทที่ใช้ในการทำแอนิเมชัน มีกฎต่อไปนี้:

  • สีแรกจะต้องโปร่งใสเสมอ ไม่ว่า จะมีค่าที่ระบุไว้ที่นั่นอย่างไร
  • รายการพาเลท 1-24 จะถือว่าเป็นสีของผู้เล่นในพาเลท 1-8.
    ไม่ชัดเจนว่าสีอื่นๆ มาจากไหนนอกจากผู้เล่น 1.
    ฉันสงสัยว่าสีที่เหลือถูกกำหนดไว้ล่วงหน้า

การอ้างอิงพาเลท

บิตแมพ

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(32) ความกว้างที่จัดแนว

ระบุความกว้างของแถวข้อมูลพิกเซลในไบต์ - เนื่องจากแถวเหล่านี้ถูกจัดเรียงตามขอบเขต 4 ไบต์

ดังนั้นจึงสามารถกระโดดไปยังแถวภาพที่เฉพาะเจาะจงได้อย่างรวดเร็ว

ไม่ชัดเจนว่าทำไมค่าดังกล่าวถึงถูกเก็บแยกต่างหาก แม้ว่าจะสามารถคำนวณได้
อาจจะเป็นการปรับแต่งสำหรับรหัสการเรนเดอร์
0x0004 uint(32) ออฟเซ็ต

ระบุค่าตำแหน่งของบรรทัดแรกใน Bitmap
0x0008 uint(32) ความสูง

ระบุความสูงของภาพเป็นพิกเซล
0x000c uint(32) ความกว้าง

ระบุความกว้างของภาพเป็นพิกเซล
0x0010 uint(16) ประเภท

ระบุประเภทของภาพ ที่นี่ดูเหมือนจะเป็นบิตมาสก์:

  • 0x04 จะถูกตั้งค่าเมื่อเป็นกราฟิก 1bpp
  • 0x40 จะถูกตั้งค่าเมื่อเป็นกราฟิกที่ต้องดำเนินการ Windowing
0x0012 uint(16) พาเลตต์

กำหนดว่าแผ่นสีใดจากไฟล์ PRT ควรจะถูกใช้

โครงสร้างข้อมูลของไฟล์ PRT นี้แสดงให้เห็นว่า Bitmap ที่ใช้สำหรับ Sprites านั้นมีการจัดระเบียบอย่างไร Bitmap เหล่านี้ทำหน้าที่เป็นส่วนประกอบเดียว าที่จะรวมกันเป็นเฟรมอนิเมชั่นของ Sprite หลาย ๆ เฟรม

ข้อมูลภาพที่แน่นอนจะซ่อนอยู่ใน op2_art.BMP ในไดเรกทอรีเกม
เหตุผลที่ไฟล์ Bitmap นี้มี RIFF-Bitmap header ที่ถูกต้อง (ส่วนใหญ่) านั้นยังไม่ชัดเจน อาจเป็นไปได้ว่า Outpost 2 ใช้ API ของระบบในการโหลดกราฟิก าโดยใช้ header นี้ชั่วคราวและเขียนทับฟิลด์ที่เปลี่ยนแปลงได้ที่เกี่ยวข้อง

ข้อมูลพิกเซลจะอยู่ในไฟล์ BMP ที่ ตำแหน่ง Offset + uint32-Offset าซึ่งสามารถพบได้ในไฟล์ BMP ที่ที่อยู่ 0x000A (RIFF-Bitmap-ข้อมูล offset) - และอีกครั้งจะตรงตามการจัดเรียงตามแถวจากมุมซ้ายบนไปมุมขวาล่าง

Grafik แบบ Monochrome 1bpp สามารถถูกวาดได้ โดยที่สี 0 เป็นความโปร่งใสสมบูรณ์ และสี 1 เป็นสีดำ/เทาแบบกึ่งโปร่งใส เนื่องจากกราฟิก Monochrom ามักจะถูกใช้สำหรับเงาของยานพาหนะและอาคารในอนิเมชั่น

ดังนั้นคุณสามารถประกอบกราฟิกจำนวนมากได้แล้ว

โมดูลที่อยู่อาศัยที่ถูกป้องกัน (Plymouth)

อนิเมชั่น

ตอนนี้เราจะมาที่ระดับสูงสุดของสาขาภายในรูปแบบข้อมูล Outpost 2:
การเคลื่อนไหว.

รายการการเคลื่อนไหวจะเริ่มต้นด้วยหัวข้อทั่วไประดับโลก ซึ่งมีไว้เพื่อการตรวจสอบข้อมูลเป็นหลัก.
หลังจากนั้นจะเป็นการกำหนดการเคลื่อนไหวที่ชัดเจนซึ่งแบ่งออกเป็น 3 ระดับ:

  1. การเคลื่อนไหว
    การเคลื่อนไหวคือหน่วยที่สูงที่สุด; มันแสดงถึงการเคลื่อนไหวของหน่วยหนึ่ง, อาคารหนึ่ง หรือ 'การเคลื่อนไหวของอนุภาค' (การโจมตีของดาวหาง, สภาพอากาศ, การระเบิด) ในสถานการณ์เริ่มต้นที่กำหนด.
  2. เฟรม
    เฟรมคือภาพเดียวภายในการเคลื่อนไหว. การเคลื่อนไหวสามารถมีเฟรมหนึ่งหรือหลายเฟรมได้.
  3. ซับเฟรม
    ซับเฟรมคือข้อมูลเกี่ยวกับการที่ภาพบิตแมพ tertentu จะถูกวาดในตำแหน่งเฉพาะของเฟรมภายใต้เกณฑ์บางประการ. เฟรมสามารถมีซับเฟรมหนึ่งหรือหลายซับเฟรมได้.

หลังจากนั้นจะมีการกำหนดการเคลื่อนไหวแต่ละรายการตามมา.

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(32) จำนวนอนิเมชัน

มีชุดข้อมูลการแอนิเมชันจำนวนเท่าไหร่
0x0004 uint(32) จำนวนเฟรม

ควรมีกรอบทั้งหมดกี่กรอบ
0x0008 uint(32) จำนวนซับเฟรม

ควรมี Subframe ทั้งหมดกี่ตัว
0x000c uint(32) จำนวนรายการที่เลือกได้ตามต้องการ

มีกี่ "รายการที่เลือกได้" ที่มีอยู่.

อนิเมชัน

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0010 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
0x0020 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(32) ไม่รู้จัก 1

ข้อมูลที่ไม่รู้จัก
0x0004 uint(32) กรอบเขต: ซ้าย

ระบุจุดเริ่มต้นด้านซ้าย (เป็นพิกเซล) ของ Bounding Box.
0x0008 uint(32) กรอบขอบ: ด้านบน

ระบุจุดเริ่มต้นด้านบน (เป็นพิกเซล) ของ กรอบขอบเขต.
0x000c uint(32) กล่องขอบ: ความกว้าง

ระบุความกว้าง (เป็นพิกเซล) ของ Bounding Box.
0x0010 uint(32) กรอบขอบ: ความสูง

ระบุความสูง (เป็นพิกเซล) ของ กรอบขอบเขต.
0x0014 uint(32) ออฟเซ็ต: X

ระบุจุดกึ่งกลางแนวนอนของอนิเมชัน
0x0018 uint(32) ออฟเซ็ต: Y

ระบุจุดกึ่งกลางแนวตั้งของการเคลื่อนไหว
0x001c uint(32) ไม่รู้จัก 2

ข้อมูลที่ไม่รู้จัก
0x0020 uint(32) จำนวนเฟรม

ระบุจำนวนเฟรมอนิเมชันที่มีอยู่ในอนิเมชันนี้
0x0024 uint(32) จำนวนหน้าต่าง

ระบุจำนวนหน้าต่างที่ควรใช้ในการวาดภาพ

ข้อมูลของชั้นบนสุดที่เกี่ยวข้องกับอนิเมชันนั้นเป็นข้อมูลการจัดการเป็นหลัก - Boundingbox หมายถึงพิกัดของเครื่องหมายรอบรถยนต์/อาคาร เมื่อมันถูกเลือกและยังบอกถึงพื้นที่ที่สามารถคลิกได้ด้วย.

ออฟเซ็ตเป็นตัวกำหนด "จุดศูนย์"; จุดที่ต้องนำไปคำนวณหรือหักออกจากพิกัดภายในเกม. กล่าวอีกอย่างหนึ่งได้ว่า: ออฟเซ็ตที่นี่หมายถึงจุดกำเนิดของพิกัด.

ในกรณีของหน้าต่าง (Windows) เช่นเดียวกับออฟเซ็ต จะมีค่า uint(32) จำนวน 4 ค่า (ต่อ 1 หน้าต่าง) ที่กำหนดพื้นที่ซึ่งใช้ได้สำหรับแต่ละซับเฟรม. นอกเหนือจากหน้าต่าง หากไม่ได้กำหนดไว้ในบิตแมพ จะไม่สามารถวาดได้.

กรอบ

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(8) จำนวน Subframe และ Toggle สำหรับตัวเลือก 1, 2

ค่านี้ประกอบด้วย:

  • 0x7F (บิตมาสก์): จำนวนซับเฟรมที่ใช้ในเฟรมนี้
  • 0x80: ข้อมูลเกี่ยวกับการมีอยู่ของออพชัน 1 และ 2
0x0001 uint(8) ไม่รู้จัก 1 และสลับสำหรับตัวเลือก 3, 4

ค่าตัวนี้ประกอบด้วย:

  • 0x7F (บิตมาสก์): ไม่ทราบ - ฉันค่อนข้างมั่นใจว่านี่เป็นจำนวน Gameticks ที่ผ่านไปจนกว่าภาพถัดไปจะแสดง
  • 0x80: ข้อมูลเกี่ยวกับว่ามี Optional 3 และ 4 อยู่หรือไม่
0x0002 uint(8) ทางเลือก 1

ไม่ทราบ
0x0003 uint(8) ทางเลือก 2

ไม่ทราบ
0x0004 uint(8) ทางเลือก 3

ไม่ทราบ
0x0005 uint(8) ตัวเลือก 4

ไม่ทราบ

ซับเฟรม

Adr x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF อักขระ
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ออฟเซ็ต ชนิดข้อมูล ชื่อฟิลด์ข้อมูล คำอธิบาย
0x0000 uint(16) ไอดีบิตแมพ

ระบุว่า Bitmap ใดจะถูกใช้สำหรับ Subframe นี้
0x0002 uint(8) ไม่รู้จัก 1

ยังไม่ทราบ - แต่ฉันค่อนข้างมั่นใจว่ามันน่าจะเกี่ยวกับลำดับความสำคัญในการเรนเดอร์ (Z-Layer)
0x0003 uint(8) Subframe-Id

ระบุว่าเรากำลังอยู่ในซับเฟรมใด
0x0004 sint(16) ออฟเซ็ต - แนวนอน

ระบุว่าภายในเฟรมจะวางซับเฟรมไว้ที่ไหน หรือว่าควรเลื่อนภาพบิตแมพไปทางขวากี่พิกเซล
0x0006 sint(16) ออฟเซ็ต - แนวตั้ง

ระบุว่าควรวาง Subframe ไว้ที่ใดภายในเฟรม หรือควรเลื่อน Bitmap ในแนวตั้งขึ้นหรือลงกี่พิกเซล

ด้วยเหตุนี้เราสามารถประกอบเฟรมแต่ละเฟรมรวมถึงอนิเมชั่นทั้งหมดได้ตามต้องการ โดยยกตัวอย่างที่อนิเมชั่นที่ซับซ้อนซึ่งมีดัชนี 500 เป็นตัวอย่าง

การเคลื่อนไหว 500

อนิเมชัน 500 แสดงให้เห็นว่า รถขนส่ง Plymouth ที่บรรทุกแร่ธรรมดากำลังถูกขนถ่ายออก ซึ่งเป็นหนึ่งในอนิเมชันไม่กี่ตัวที่ใช้ฟังก์ชันการจัดการหน้าต่าง

และนี่คือวิธีที่เราสามารถรวมอนิเมชันทั้งหมดเข้าด้วยกัน
น่าเสียดายที่มีปัญหากับฝาประตูโหลดด้านบน เนื่องจากบิตที่เกี่ยวข้องในข้อมูลประเภทกราฟิกไม่ได้ถูกตั้งค่า

นี่คือสไปรต์ที่สวยงามอื่นๆ ที่มีอนิเมชันจากเกม:

การเรนเดอร์ของอนิเมชัน 500 ได้รับการแสดงให้เห็น

อนิเมชัน 500 ที่ถูกประกอบเสร็จสมบูรณ์

โรงงานอาคารพลีมัธ

ท่าอวกาศอีเดน

ศูนย์การแพทย์อีเดน

SCAT

ท่าอวกาศพลีมัธ

อีสเตอร์เอ็กซ์:
ซานตาคลอส

อีสเตอร์เอ็กซ์:
สุนัขของแดน

ส่วนติดต่อผู้ใช้

ตอนนี้ยังขาด User-Interface ของเกม ซึ่งมีลักษณะเป็น โลหะขัดเงา อยู่

แต่ที่นี่ก็สามารถเห็นได้ว่า Dynamix ไม่จำเป็นต้องประดิษฐ์วงล้อใหม่; ที่นี่ไม่ได้ใช้เพียงแค่ User32 และ GDI32-APIs ที่ Windows จัดเตรียมไว้ - โดยเฉพาะอย่างยิ่งยังมีการใช้การจัดการทรัพยากรจาก User32 ด้วย

สิ่งเหล่านี้สามารถนำออกได้โดยโปรแกรมต่าง ๆ เช่น โปรแกรม Resource Hacker ที่พัฒนาโดย Angus Johnson เป็นฟรีแวร์ Resource Hacker หรือ - หากคุณไม่ต้องการใช้ Wine บน Linux / Mac OS - สามารถใช้ wrestool ที่รวมอยู่ใน icoutils เพื่อการนี้

ชื่อไฟล์ เนื้อหา
Outpost2.exe ประกอบด้วยไอคอนของเกมซึ่งแสดงสถานีอวกาศก่อน New Terra
op2shres.dll มีกราฟิกสำหรับองค์ประกอบการควบคุมเช่นขอบ, ปุ่ม, ปุ่มวิทยุ และช่องทำเครื่องหมาย รวมถึงพื้นหลังของการสนทนา, รูปภาพประกอบสำหรับเนื้อเรื่องภารกิจ และกราฟิกพื้นหลังของเมนูหลัก
out2res.dll มีการตกแต่งหน้าต่างในเกม, ไอคอนสำหรับโลหะธรรมดาและโลหะพิเศษ, หน้าจอโหลด, กราฟิกสำหรับการสนทนา รวมถึง กราฟิก ของเคอร์เซอร์เพิ่มเติม นอกจากกราฟิกเคอร์เซอร์ที่เคลื่อนไหวในไดเรกทอรีเกม