Outpost 2 ფაილის ფორმატები · bei.pm

გეორგიული
ეს ტექსტი ავტომატურად ითარგმნა OpenAI GPT-4o Mini-ს მიერ.

ამ გვერდზე აღწერილი ფაილების ფორმატები ეფუძნება Dynamix, Inc. და Sierra Entertainment-ის ინტელექტუალური საკუთრების ტექნიკურ ანალიზს.
ინტელექტუალური საკუთრება დღეს არის Activision Publishing, Inc.-ის / Activision Blizzard, Inc.-ის მასის ნაწილი და ამჟამად ეკუთვნის Microsoft Corp..

მعلوماتები შეიკრიბა Reverse Engineering და დატების ანალიზის საშუალებით არქივირების და ისტორიული მონაცემებთან ინტერპერატიულობის მიზნით.
არ ყოფილა გამოყენებული რაიმე სამ Proprietary ან კონფიდენციალური სპეციფიკაციები.

ამჟამად თამაში შესაძლებელია შეძენა gog.com-ზე როგორც ჩამოსატვირთი.

თამაშის არტვორქი

ქვემოთ მოცემული სტატიის სერია აღწერს ჩემს მიღწევებს მონაცემთა ფორმატებზე რეალური დროის სტრატეგიულ თამაშში "Outpost 2: Divided Destiny", რომელიც 1997 წელს გამოაქვეყნა Sierra და შექმნა Dynamix.

მე ძირითადად დაკავებული ვიყავი თამაშის მონაცემების ანალიზით - და რაც მათთან ერთად აკეთებს - 2015 წლის 1 ნოემბრიდან 14 ნოემბრამდე.

მნიშვნელოვანი ინფორმაციის მიხედვით, რომელიც ამ დროისთვის მოვიპოვე, Dynamix - როგორც ბევრი კომერციული კომპანია - არ იმუშავებდა სპეციალურად Outpost 2-ისთვის შექმნილ მონაცემთა ფორმატებზე, არამედ გამოიყენებდა სხვა განვითარებებში, მაგალითად, Mechwarrior სერიაში (გადამუშავებული).
ამის გარდა, უნდა აღინიშნოს, რომ მონაცემთა ფორმატების ინოვაციური ძალა პრაქტიკულად შეზღუდულია და ხშირად ეფუძნება უფრო ძველ კონცეფციებს, როგორიცაა JFIF და RIFF.

ასაკის და მონაცემთა ფორმატების ინტერპრეტაციისათვის დამატებითი ინფორმაცია ხელმისაწვდომია რა არის რა? გვერდზე.
აქ გამოკვეთილი მონაცემები ზოგადად უნდა აღიქმებოდეს როგორც Little Endian.

დასკვნის სახით, შეიძლება ითქვას, რომ რევერსული ინჟინერია ძალიან სახალისო იყო, მიუხედავად იმისა, რომ ეს არ არის სრულყოფილი.
რა თქმა უნდა, ასევე შეგიძლია ვურჩიოთ, რომ თავად ითამაშოთ თამაში, რადგან მას საინტერესო თამაშის მექანიკა აქვს.

შესახებ

Outpost 2-ის მიერ გამოყენებული მონაცემების ფორმატები JFIF / PNG-ს მსგავსია - ცალკეული მონაცემთა ბლოკები ყოველთვის შეიცავს 8 ბაიტიან სათაურებს. ამიტომ გადავწყვიტე, რომ კონკრეტულ ადგილებში თითოეული სათაური არ დოკუმენტირდეს და მხოლოდ გადახვევები აღვნიშნო.

ფორმატი ყოველთვის ასეთია; რეალური მონაცემები მასშია ჩადებული:

მისამართი 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) პატარძალები?

არ არის ცნობილი, რისთვისაა ეს ბლოკი ზუსტად საჭირო.

ვოლიუმებში ეს მნიშვნელობა ხშირად 0x80-ია, სხვა ფაილებში კი ხშირად 0x00. ეს მიუთითებს იმაზე, რომ ეს არის დროშების ნაკრები.

ნაწილები

ხარისხები წარმოადგენს მონაცემთა კონტეინერს თამაშისთვის, მსგავსი არქივის ფორმატთან, როგორიცაა Tarball. მინიმუმ Outpost 2-ში ეს ფორმატი მხოლოდ ფაილებზე მუშაობს - არა ფolders-ზე. სავარაუდოდ, ეს შეიძლება შეიქმნას შესაბამისი ფაილების სახელების გამოყენებით.

ხარისხი შედგება ხარისხის თავიდან და რამდენიმე ხარისხის ბლოკებისგან, რომლებიც კონკრეტულ ფაილებს შეესაბამება.

"ხარისხები" არის ფაილები, რომელთა გაფართოება 'vol' არის თამაშის დირექტორიაში.

მისამართი 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) მდებარეობები

ხმის სათაური

მისამართი 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) მდებარეობები

ანგარიშის თავში არ არის რაიმე მონაცემები.
ეს მხოლოდ კონტეინერის როლს ასრულებს.

ანგარიშის თავში პირველი უნდა იყოს ანგარიშის სტრინგები; მას შემდეგ უნდა მივყვეთ ანგარიშის ინფორმაციას.

მოცულობის სტრიქონები

მისამართი 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) ტვირთის სიგრძე

აჩვენებს რამდენი ბიტი არის შემდეგი მონაცემების რეალურად სასარგებლო მონაცემები.

მონაცემების დანარჩენი ნაწილი Volume-Strings სიაში აშკარად გაყიდულია.

დოკუმენტებში, რომლებიც უფრო გვიან თარიღითაა, ეს 'დანარჩენი მონაცემები' არის 0x00, რაც შეიძლება მიუთითებდეს ინსტრუმენტების ნაკრების ნაკლოვანებებზე თამაშის განვითარების პროცესში, კერძოდ, რომ მხოლოდ ძალიან გვიან იზრუნა რაიმე განვითარება ბუფერის სწორად ინიციალიზაციაზე, რადგან არ აქვს გავლენა თამაშზე, იქნება მონაცემები ინიციალიზებული თუ არა.
0x000c uint(8)[] ფაილების სახელების სია

ეს არის 0-ბაიტამდე შეწყვეტილი სიის ფაილების სახელებით, რომლებიც - მინიმუმ ამ მონაცემების კომპონენტში - მხოლოდ ASCII სიმბოლოების არსებობას მოელის.

მონაცემების ანალიზზე ამ მონაცემთა ბლოკის უფრო დეტალური განხილვა საჭირო არ არის, რადგან მოცულობის ინფორმაციის მიხედვით პირდაპირ მითითებულია ფაილების სახელების ოფსეტები.

წამების სტრიქონები არის ფაილების სახელების სია, რომლებიც მოცულობაში აარსებულია.

ხმის ინფორმაცია

მისამართი 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) მდებარეობები

ხმის ინფორმაცია შეიცავს დეტალურ ინფორმაციას ფაილებზე. ეს გარკვეულწილად წარმოადგენს FAT დირექტორიის ჩანაწერის ტიპს (FAT = ფაილის განაწილების ცხრილი)

ფაილების რაოდენობა მიიღება ბლოკის ზომის გაყოფით directory ჩანაწერების სიგრძეზე - 14 ბაიტი.

ცალკეული დირექტორიის ჩანაწერები თითოეულ შემთხვევაში შემდეგი სტრუქტურისთვის არიან განკუთვნილნი:

მისამართი 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) ფაილის ზომა

მაჩვენებს, რამდენი ბაიტი აქვს ფაილს.
0x000c uint(16) ნიშნები?

ალბათ დამატებითი ინფორმაცია ეხმარება ფაილის კოდირებაზე.

  • 0x03 ჩაიწერება, როდესაც ფაილი არის კომპრესირებული. აქ სავარაუდოდ, გამოიყენება ჰაფმანის ხე.
  • 0x80 როგორც ჩანს, ყოველთვის ჩაიწერება.

ხმის ბლოკი

მისამართი 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) მდებარეობები

ვოლიუმის ბლოკი არის კონტეინერი, რომელიც შეიცავს ფაილებს. ის მოიცავს მხოლოდ ერთხელ - ბლოკის ფორმატის გამო - გადაჭარბებულად ფაილის ზომას და მის შემდეგ პირდაპირ მოჰყვება მომხმარებელის მონაცემები.

ტაილები

მისამართი 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) ფლაგები

ტაილები არის Outpost-2-ს სპეციფიური ბიტმაპ-გრაფიკის ფორმატი. ისინი მოიცავს 13 ტაილსეტს, რომელიც "ჭ wells" well0000.bmp -დან well0012.bmp -მდე, რომლებიც იმყოფებიან მოცულობაში maps.vol.

ამასთან, ტაილსეტები / ჭები შეიცავს შემდეგს:

ფაილის სახელი შინაარსი
well0000.bmp 32x32პიქსელი ზომის, ლურჯი გრაფიკა - იდეალურია ტესტისთვის, რომ დაადგენთ, მუშაობს თუ არა თქვენი იმიჯის ლოდერი
well0001.bmp შეიცავს ნათელ ქანებს, მთების ქედებს ნათელ ქანებზე და countless ვარიანტებს კრატერების ნათელ ქანებზე
well0002.bmp შეიცავს ნათელი ქანების 'Doodads' - ანუ ელემენტები, რომლებიც შეიძლება მოთავსდეს ნათელ ქანებზე, რათა გაათავისუფლონ სივრცე (ანდა შეგნებულად, როგორც სტრუქტურა, მაგალითად კედლები), მათ შორის მცენარეულობა
well0003.bmp შეიცავს ქერქისებრ სტრუქტურას ნათელ ქანებზე
well0004.bmp შეიცავს ბნელ ქანებს, მთების ქედებს ბნელ ქანებზე და countless ვარიანტებს კრატერების ბნელ ქანებზე
well0005.bmp შეიცავს ბნელ ქანებზე 'Doodads' - ანუ ელემენტები, რომლებიც შეიძლება მოთავსდეს ბნელ ქანებზე, რათა გაათავისუფლონ სივრცე (ანდა შეგნებულად, როგორც სტრუქტურა, მაგალითად კედლები)
well0006.bmp შეიცავს ქერქისებრ სტრუქტურას ბნელ ქანებზე, ასევე გადასვლებს ნათელ და ბნელ ქანებს შორის
well0007.bmp შეიცავს ლავას, მათ შორის 4-5 ფრეგმენტის ანიმაციას
well0008.bmp შეიცავს ქვიშას და countless ვარიანტებს კრატერების ქვიშაში
well0009.bmp შეიცავს ქვიშის 'Doodads' - ანუ ელემენტები, რომლებიც შეიძლება მოთავსდეს ქვიშაზე, რათა გაათავისუფლონ სივრცე (ანდა შეგნებულად, როგორც სტრუქტურა, მაგალითად კედლები)
well0010.bmp შეიცავს 48 გადასვლას ქვიშიდან ნათელ და ბნელ ქანებზე
well0011.bmp შეიცავს რუკის პოლარული ყეფები, ბნელი ქანით როგორც ქვედა ფენა
well0012.bmp შეიცავს რუკის პოლარული ყეფები, ნათელი ქანით როგორც ქვედა ფენა

მნიშვნელოვანია, რომ Tiles-ები წინასწარ არ იქნეს rendered, რათა მათ კეშირებული იყოს, რადგან დღის/ღამის ციკლის მონაცემები ჯერ კიდევ უნდა დამუშავდეს - და ძალიან ბევრი მონაცემი წარმოიქმნება.

Tiles-ები არის 8bpp გრაფიკა ინდექსირებული პალიტრით 32x32 პიქსელის გადაჭიმულობით, რომელიც ერთმანეთთან არის განლაგებული. თუმცა, ამგვარად შექმნილ Tileset-ში შეიძლება ბევრად მეტი იყოს

მთავარი კონტეინერი შედგება 2 სექციიდან: head და data.

ტილეს სათაური

მისამართი 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 ფორმატში წარმოდგენილი პალეტების ფაილი. ზუსტი სპეციფიკაცია მოიძება - რადგან პალეტები სხვაგანაც ჩანს - გვერდზე პალეტები.

ტაილების მონაცემები

მისამართი 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-ბიტმაპების ფორმატშია წარმოდგენილი, соответствует цветის ინდექსს ფერის პალიტრაში.

პიქსელური მონაცემები იწყება ზემოდან მარცხნიდან და მთავრდება ქვემოდან მარჯვნივ.

თამაშის ძრავა ტაილს *შესაძლოა* მოთხოვნის საფუძველზე ხატავს.
ეს, სავარაუდოდ, უკავშირდება დღის და ღამის ციკლს, რომელიც 32 სხვადასხვა ტაილს იცნობს. ამ დროს, აშკარად, ბBrightness-ის მნიშვნელობიდან 'პატარა' იწურება. ზუსტი მნიშვნელობები ჯერ ვერ გაწვდილია, მე კი ანგარიშით ვმუშაობ 

v *= (daylight / 48) + 0.25;

პიქსელების HSV მონაცემებით, სადაც daylight არის 0-31 სიხშირის მნიშვნელობა და v არის 0-1 შორის მნიშვნელობა. გარდა ამისა, უნდა აღინიშნოს, რომ რუკაზე თითოეულ მხარეს 16 ტაილის საზღვარი არსებობს (ეს განკუთვნილია ერთეულების უხილავი გამოჩენისთვის).

დამატებით, დღის და ღამის ციკლი თითო თამაშის ციკლზე მხოლოდ რუკის ერთი სვეტის განახლებას ახორციელებს.
დაიხვეწილი დღის და ღამის ციკლი შემდეგნაირად გამოიყურება:

დღისა და ღამის ციკლის ვიზუალიზაცია

პარტ

მისამართი 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 Ressource Table' - რადგან ეს ფაილი - რომელიც მოიძიება როგორც op2_art.prt maps.vol-ში - სწორედ ასეთი ტიპისაა, ან ეს ფუნქცია საკმაოდ კარგად აღწერს.

ამ ფაილში არის პალეტების ჩამონათვალი, ყველა გამოყენებული bitmap-ის ცხრილი, ყველა ანიმაციის განსაზღვრის ინფორმაცია და კიდევ ბევრი უცნობი მონაცემი. ის მხოლოდ ნაწილობრივ ემთხვევა წინა კონტეინერის ფორმატს, რადგან არა ყველა ჩანაწერი შეესაბამება ამ სქემას.

CPAL-სექცია (შესაძლოა, პალეტების კონტეინერს ნიშნავს) მხოლოდ პალეტების მონაცემებს მოიცავს, მიუთითებს, რამდენი ჩვეულებრივ 1052 ბაიტიანი 8-बიტური პალეტაა ხელმისაწვდომი.

1052-ბაიტიანი ციფრი არ ითვლება სავალდებულოდ, რადგან პალეტის ფორმატი პოტენციურად სხვადასხვა ზომის პალეტებს ითვალისწინებს. ის მხოლოდ იმ მონაცემებზე ვრცელდება, რომლითაც Outpost 2 გამოდის.

პალეტების ჩამონათვალის შემდეგ დაუყოვნებლივ და გარეშე შემავალი წარწერის, უკვე იწყება bitmap-ების ჩამონათვალი; ასევე დაუყოვნებლივ მოსდევს ანიმაციების ჩამონათვალი.
ორივე იწყება uint(32)-ით (ან ისევ uint24+uint8 flags?) რომელიც შეიცავს მონაცემების რაოდენობას.

პალეტები

მისამართი 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) იყოს.

პალეტის ინფორმაცია ძალიან მარტივად იკითხება.
ისინი შედგება თითოეული ჰედერისა და მონაცემთა სეგმენტისგან.

პალეტების სათაური

მისამართი 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.

პალეტის ინფორმაცია

მისამართი 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-ზე.

ინდივიდუალური ჩანაწერები აქვთ შემდეგი, მარტივი სტრუქტურა;

მისამართი 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.

პალეტებზე მხოლოდ ეს უნდა ითქვას, რომ ანიმაციებისთვის გამოყენებული პალეტების შემთხვევაში შემდეგი წესები მოქმედებს:

  • პირველი ფერი ALWAYS არის გამჭვირვალე, არ აქვს მნიშვნელობა იქ რა მნიშვნელობაა მითითებული.
  • პალეტების ჩანაწერები 1-24 ითვლება როგორც მოთამაშის ფერი პალეტებში 1-8.
    სადაც ფერები მოთამაშე 1-ისგან განსხვავებით მოდის, unclear არის ჩემთვის.
    მივიჩნევ, რომ დარჩენილი ფერები არის hardcoded.

პალეტის რეფერენცია

ბიტმაპები

მისამართი 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) ოფსეტი

შენიშნავს ბიტმაპში პირველ ხატულას ოფსეტს
0x0008 uint(32) სიმაღლე

გამოაქვს სურათის სიმაღლე პიქსელებში
0x000c uint(32) სიგანე

შეუთავსებს სიგანეს სურათის პიქსელებში
0x0010 uint(16) ტიპი

ნაჩვენებია გამოსახულების ტიპი. აქ, როგორც ჩანს, საუბარია ბიტმასკაზე:

  • 0x04 არის ჩართული, როდესაც ეს არის 1bpp გრაფიკა.
  • 0x40 არის ჩართული, როდესაც ეს არის გრაფიკა, რომელიც უნდა განახორციელოს ვინდოინგი.
0x0012 uint(16) პალიტრა

განმარტავს, რომელი პალიტრა უნდა გამოყენებულ იქნას PRT ფაილში

PRT ფაილის ეს მონაცემთა სტრუქტურა მიუთითებს, თუ როგორ არის შექმნილი სურათები, რომლებიც გამოიყენება სპრაიტებისთვის. ეს სურათები მსახურობენ როგორც ერთეული, რომელთა მრავალი ნაწილები შეიკვრება სპრაიტის ანიმაციის ჩარჩოში.

კონკრეტული სურათის მონაცემები იმალება op2_art.BMP თამაშის დირექტორიაში.
რატომ აქვს ამ Bitmap ფაილს (მთავარად სწორი) RIFF Bitmap ჰედერი, არ არის გარკვეული. სავარაუდოდ, Outpost 2 იყენებს სისტემურ API-ებს გრაფიკის ჩატვირთვისთვის, ამ ჰედერის დროებით მიღების გზით, ხოლო შესაბამისი, ცვალებადი ველია შეცვლილი.

პიქსელური მონაცემები BMP ფაილში არის ადგილ Offset + uint32-Offset, რომელიც BMP ფაილში მდებარეობს მისამართზე 0x000A (RIFF Bitmap მონაცემების ოფსეტი), და კვლავ შეესაბამება ზოლური განლაგების იმავე წესით, რომელიც იწყება ზედა მარცხნიდან და მთავრდება მარჯვენა ქვედა მხარეს.

მონოქრომული 1bpp გრაფიკები შეიძლება დახატოს ისე, რომ ფერი 0 იყოს სრულყოფილი გამჭვირვალობა, ხოლო ფერი 1 იყოს ნახევრად გამჭვირვალე შავი/მუქი ნაცრისფერი, რადგან მონოქრომული გრაფიკები ჩვეულებრივ გამოიყენება მანქანების და შენობების ჩრდილებისთვის ანიმაციებში.

ამას უკვე მრავალი გრაფიკის შეკრება შეუძლია.

დაცული საცხოვრებელი მოდული (Plymouth)

ანიმაცია

ახლა გადავდივართ Outpost 2-ის მონაცემთა ფორმატების დისციპლინების მეფე კლასაზე:
ანიმაციებზე.

ანიმაციის სიები იწყება გლობალური ჰედერით, რომელიც ძირითადად მონაცემების ვერიფიკაციისთვის არის განკუთვნილი. ამის შემდეგ მოდის კონკრეტული ანიმაციის განსაზღვრებები, რომლებიც 3 ეტაპად იყოფა:

  1. ანიმაცია
    ანიმაცია არის უმაღლესი ინსტანცია; იგი წარმოაჩენს ერთეულის, შენობის ან 'პარტიკულების ანიმაციის' (კომეტის დარტყმა, ამინდი, აფეთქება) ანიმაციას კონკრეტულ საწყის მდგომარეობაში.
  2. ფრემი
    ფრემი არის ერთი სურათი ანიმაციის ფარგლებში. ანიმაცია შეიძლება შეიცავდეს ერთ ან რამდენიმე ფრემს.
  3. მოქნილი ფრემი
    მოქნილი ფრემი არის ინფორმაცია იმის შესახებ, რომ კონკრეტული ბიტმაპი უნდა იყოს დახატული კონკრეტულ კრიტერიუმებზე დაყრდნობით კონკრეტულ ფრემის პოზიციაზე. ფრემი შეიძლება შეიცავდეს ერთ ან რამდენიმე მოქნილ ფრემს.

შემდეგ მოდის უკვე კონკრეტული ანიმაციის განსაზღვრებები.

მისამართი 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) პარამეტრების რაოდენობა

რამდენი სუბფრეიმი უნდა იყოს ჯამში
0x000c uint(32) სავალდებულო ჩანაწერების რაოდენობა

რამდენი "არასავალდებულო ჩანაწერია" ხელმისაწვდომი.

ანიმაცია

მისამართი 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) ბრენდული ყუთი: ზედა

ბრძანებს Bounding Box-ის ზედა დასაწყისს (პიქსელებში).
0x000c uint(32) ბრძოლა: სიგანე

მიუთითებს Bounding Box-ის სიგანეს (პიქსელებში).
0x0010 uint(32) ბოქსის საზღვრები: სიმაღლე

განსაზღვრავს Bounding Box-ის სიმაღლეს (პიქსელებში).
0x0014 uint(32) Offset: X

მაკლავს ანიმაციის ჰორიზონტალურ ცენტრალურ წერტილს
0x0018 uint(32) ოდრეკი: Y

ჩააწვდოს ანიმაციის ვერტიკალური ცენტრი
0x001c uint(32) უცნობი 2

უცნობი ინფორმაცია
0x0020 uint(32) ფრემების რაოდენობა

მიუთითებს, თუ რამდენი ანიმაციის ჩარჩოა ამ ანიმაციაში ჩართული
0x0024 uint(32) ბრენდის რაოდენობა

შეგიძლიათ მიუთითოთ, რამდენი ფანჯრის გამოყენებაა საჭირო ხატვის დროს

აუცილებელი მონაცემები ზედა ფენის, ანიმაციის, ძირითადად ადმინისტრაციული მონაცემებია - Boundingbox აღნიშნავს ავტომობილის/შენობის მარკირების კოორდინატებს, როდესაც ის შერჩეულია და ასევე მიუთითებს, რომელი ტერიტორია უნდა იყოს დააჭერადი.

Offset ძირითადად განსაზღვრავს "ნულოვანი წერტილი"; წერტილი, რომელიც უნდა იყოს გათვალისწინებული ან უნდა იყოს გამოტანილი თამაშის შიდა კოორდინატებთან. უფრო მათემატიკურად რომ ვთქვათ: offset აქ განიხილავს კოორდინატების წარმოშობას.

Windows-ების შემთხვევაში, ისევე როგორც offset-ის შემთხვევაში, თითოეულ (დაახლოებით თითოეული Windows-ისთვის) 4 uint(32)-წარმოებულ მნიშვნელობებს მოიცავს, რომლებიც განსაზღვრავს ტერიტორიას, რომელიც ინდივიდუალური სუბფრეიმებისთვის გამოყენებადია. Windows-ის გარეთ, თუ ეს bitmap-ისთვის შესაბამისია, დახატვა არ უნდა მოხდეს.

ჩარჩო

მისამართი x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF სიმბოლო
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ოფსეტი მონაცემთა ტიპი სახელი განმარტება
0x0000 uint(8) სუბფრეიმების რაოდენობა და გადართვა ვარიანტისთვის 1, 2

ამი მნიშვნელობა შეიცავს:

  • 0x7F (ბიტური ნიღაბი): ქვედამონაკვეთების რაოდენობა, რომელიც ამ ჩარჩოში გამოიყენება
  • 0x80: ინფორმაცია იმის შესახებ, არის თუ არა ალტერნატიული 1 და 2 ხელმისაწვდომი
0x0001 uint(8) უცნობი 1 და გადართვა ვარიანტისთვის 3, 4

ამ მნიშვნელობაში შედის:

  • 0x7F (ბიტმასკა): უცნობია - ვვარაუდობ, რომ ეს არის გემეტიკების რაოდენობა, რომელიც გადის, სანამ შემდეგი ჩარჩო გამოჩნდება
  • 0x80: ინფორმაცია იმის შესახებ, არის თუ არა შეთავაზებული 3 და 4
0x0002 uint(8) ნებაყოფლობითი 1

უცნობი
0x0003 uint(8) დამატებითი 2

უცნობი
0x0004 uint(8) მიუხედავად იმისა, რომ ეს არის ვარიანტი 3

უცნობი
0x0005 uint(8) ოპციონალური 4

უცნობი

ზედმხარის ჩარჩო

მისამართი x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF სიმბოლო
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ოფსეტი მონაცემთა ტიპი სახელი განმარტება
0x0000 uint(16) ბიტმაპ-იდენტიფიკატორი

ჩაანაცვლებს, რომელი ბიტმაპი უნდა გამოყენებულ იქნას ამ სუბფრეიმისთვის
0x0002 uint(8) უცნობი 1

არ არის ცნობილი - თუმცა მე ძლიერ ვივარაუდებ, რომ ეს_render_პირიორიტეტთან (Z-შრე) არის დაკავშირებული.
0x0003 uint(8) ქვემასპინძური იდენტიფიკატორი

აჩვენებს, რომელ სუბფრეიმში ვიმყოფებით
0x0004 sint(16) ოფსეტი - ჰორიზონტალური

მიანიშნებს, სად უნდა იყოს სუბფრეიმი ფრეშის შიგნით განლაგებული, ან რამდენი პიქსელით უნდა იყოს ბიტმაპი ჰორიზონტალურად გადატანილი
0x0006 sint(16) ოფსეტი - ვერტიკალური

გაძლევს ინფორმაციას, სად უნდა განთავსდეს სუბფრეიმი ჩარჩოს შიგნით, ან რამდენი პიქსელით უნდა გადაიწიოს ბიტმაპი ვერტიკალურად

ამით შეგვიძლია შევკრიბოთ როგორც ინდივიდუალური ფრემები, ისე სრული ანიმაციები, რაც ამ კომპლექსური ანიმაციის, ინდექსით 500, მაგალითზე არის დემონსტრირებული

ანიმაცია 500

ანიმაცია 500 აჩვენებს, როგორ აუღებენ პლიმუთის ტრანსპორტერს, რომელიც ჩვეულებრივი მადნით არის დატვირთული. ეს არის ერთ-ერთი რამდენიმე ანიმაცია, რომელიც იყენებს ფანჯრის ფუნქციონალობას.

და ასე შეიძლება შეეწყოს სრული ანიმაცია.
სამწუხაროდ, არსებობს კიდევ ერთი პრობლემა ზედა დატვირთვის ფანჯარასთან, რადგან აქ შესაბამისი ბიტი გრაფიკული ტიპის ინფორმაციაში არ არის დაყენებული.

აქ არის კიდევ რამდენიმე მშვენივრად ანიმირებული სპრაიტი თამაშიდან:

ანიმაცია 500-ის რენდერინგი ილუსტრირებული

ანიმაცია 500 დასრულებულად შეერთებული

პლიმუთის შენობა-ფაბრიკა

ედენის კოსმოსური პორტი

ედენის სამედიცინო ცენტრი

SCAT

პლიმუთის კოსმოსური პორტი

Easteregg:
შობა

Easteregg:
Dans Dog

მომხმარებლის ინტერფეისი

ახლა თამაშის მომხმარებლის ინტერფეისი აკლია, რომელიც ბრილიანტის მეტალის სტილშია შესრულებული.

მაგრამ აქაც ჩანს, რომ Dynamix საჭიროა, რომ რადიკალურად არაფერი შეცვალოს; აქ მხოლოდ Windows-ის მიერ გაწვდილი User32 და GDI32 API-ები გამოიყენება - განსაკუთრებით User32-ის რესურსების მართვა.

მაგალითად, ეს შეიძლება მოიხელმძღვანელოს ისეთ პროგრამებზე, როგორიცაა Angus Johnson-ის მიერ თავისუფალი პროგრამის სახით შექმნილი Resource Hacker, ან - თუ Linux / Mac OS-ზე Wine-ის გამოყენება გაწვდილი არ არის - icoutils-ში არსებული wrestool-ის მეშვეობით ამოიღონ.

ფაილის სახელი შინაარსი
Outpost2.exe შედგება მხოლოდ თამაშის გამოსახულებისგან, რომელიც აჩვენებს კოსმოსურ სადგურს New Terra-ზე
op2shres.dll შეიცავს ნახატების გარდა მართვის ელემენტებისთვის, როგორიცაა საზღვრები, ღილაკები, რადიო ღილაკები და ჩექბოქსები, ასევე დიალოგის ფონებს, ისტორიის მისიის ტექსტების თანმხლები სურათებს და მთავარი მენიუს ფონურ გამოსახულებას
out2res.dll შეიცავს თამაშის ინტერფეისის დეკორაციას, სიმბოლოებს ჩვეულებრივი და სპეციალური მეტალისთვის, დატვირთვის ეკრანს, დიალოგებისთვის გამოსახულებებს და სხვა კურსორების გამოსახულებებს, დამატებით თამაშის დირექტორიაში არსებულ ანიმირებულებთან ერთად