Outpost 2 फ़ाइल प्रारूप · bei.pm

हिंदी
यह पाठ स्वचालित रूप से OpenAI GPT-4o Mini द्वारा अनुवादित किया गया है।

इस पृष्ठ पर वर्णित फ़ाइल प्रारूप Dynamix, Inc. और Sierra Entertainment के बौद्धिक संपदा के तकनीकी विश्लेषण पर आधारित हैं।
आज बौद्धिक संपदा Activision Publishing, Inc. / Activision Blizzard, Inc. के अधीन है और वर्तमान में Microsoft Corp. के स्वामित्व में है।

जानकारियाँ रिवर्स इंजीनियरिंग और डेटा विश्लेषण के माध्यम से संग्रहित की गई हैं ताकि ऐतिहासिक डेटा के साथ संग्रहण और अंतःक्रियाशीलता सुनिश्चित हो सके।
किसी भी स्वामित्व या गोपनीय विशिष्टताओं का उपयोग नहीं किया गया है।

यह खेल वर्तमान में gog.com पर डाउनलोड के लिए खरीदा जा सकता है।

खेल का आर्टवर्क

निम्नलिखित लेख श्रृंखला "आउटपोस्ट 2: डिवाइडेड डेस्टिनी" नामक वास्तविक समय की रणनीति खेल में डेटा प्रारूपों के बारे में मेरी अंतर्दृष्टियों का दस्तावेजीकरण करती है, जिसे 1997 में सिएरा द्वारा जारी किया गया और डायनामिक्स द्वारा विकसित किया गया।

मैंने लगभग 01 नवंबर 2015 से 14 नवंबर 2015 तक खेल के डेटा का विश्लेषण करने पर ध्यान केंद्रित किया - और इसके साथ क्या किया जा सकता है।

अब तक जो जानकारी मैंने प्राप्त की है, उसके अनुसार डायनामिक्स - जैसे कि कई वाणिज्यिक कंपनियाँ - ने कुछ डेटा प्रारूपों को विशेष रूप से आउटपोस्ट 2 के लिए नहीं बनाया, बल्कि अन्य विकासों जैसे कि मेकवारियर्स श्रृंखला में (संशोधित) उपयोग किया।
इससे अलग, यह भी देखा जा सकता है कि डेटा प्रारूपों की नवाचार क्षमता व्यावहारिक रूप से सीमित है और अक्सर सामान्य प्रारूपों जैसे JFIF और RIFF से लंबे समय से स्थापित अवधारणाओं पर आधारित होती है।

तालिकाओं और डेटा प्रारूपों की व्याख्या के लिए और जानकारी क्या है क्या? पर उपलब्ध है।
यहाँ दिए गए डेटा को सामान्यतः लिटिल एंडियन के रूप में समझा जाना चाहिए।

अंत में, यह कहा जा सकता है कि रिवर्स इंजीनियरिंग करना बहुत मजेदार था, भले ही यह पूरी तरह से नहीं है।
बिल्कुल, मैं भी केवल यह सिफारिश कर सकता हूँ कि खेल को स्वयं खेलें, क्योंकि यह दिलचस्प खेल यांत्रिकी प्रदान करता है।

परिचय

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 होता है। यह सुझाव देता है कि यह एक फ्लैग सेट हो सकता है।

खंड

वॉल्यूम एक डेटा कंटेनर है जो खेल के लिए होता है, यह एक संग्रह प्रारूप की तरह है जैसे कि टारबॉल। कम से कम आउटपॉस्ट 2 में, यह प्रारूप केवल फ़ाइलों को पहचानता है - कोई फ़ोल्डर नहीं। हालांकि, इन्हें उचित फ़ाइल नामों के माध्यम से अनुकरण किया जा सकता है।

एक वॉल्यूम वॉल्यूम-हेडर और कई वॉल्यूम ब्लॉकों से बना होता है, जो विशिष्ट फ़ाइलों के अनुरूप होते हैं।

"वॉल्यूम" वे फ़ाइलें हैं जिनका विस्तार '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) पेलोड-लंबाई

यह बताता है कि निम्नलिखित डेटा में से कितने बाइट वास्तव में उपयोगी डेटा हैं।

वॉल्यूम-स्ट्रिंग सूची के बाकी बचे डेटा को स्पष्ट रूप से गंदगी के रूप में माना जाना चाहिए।

जिस फ़ाइल की तारीख बाद में है, उसमें ये 'बचे हुए डेटा' 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 = फ़ाइल आवंटन तालिका) के समान है।

फाइलों की संख्या ब्लॉक आकार को निर्देशिका प्रविष्टियों की लंबाई - 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-विशिष्ट Bitmap-ग्राफ़िक प्रारूप हैं। ये 13 टाइलसेट्स में फैले हुए हैं, जिन्हें "वेल्स" कहा जाता है (well0000.bmp से well0012.bmp), जो maps.vol वॉल्यूम के भीतर स्थित हैं।

इन टाइलसेट्स / वेल्स में निम्नलिखित शामिल हैं:

फाइल नाम सामग्री
well0000.bmp एक 32x32px आकार की नीली ग्राफिक - अपने इमेज लोडर के काम करने की जांच के लिए आदर्श
well0001.bmp हल्की चट्टान, हल्की चट्टान पर पर्वत श्रृंखलाएँ और हल्की चट्टान में अनगिनत प्रकार के क्रेटर
well0002.bmp हल्की चट्टान पर सजावटी तत्व - यानी ऐसे तत्व जो हल्की चट्टान पर सजावट के लिए (या जानबूझकर संरचना के रूप में, जैसे दीवारें) रखे जा सकते हैं, जिसमें वनस्पति भी शामिल है
well0003.bmp हल्की चट्टान पर एक परत जैसी संरचना
well0004.bmp गहरी चट्टान, गहरी चट्टान पर पर्वत श्रृंखलाएँ और गहरी चट्टान में अनगिनत प्रकार के क्रेटर
well0005.bmp गहरी चट्टान पर सजावटी तत्व - यानी ऐसे तत्व जो गहरी चट्टान पर सजावट के लिए (या जानबूझकर संरचना के रूप में, जैसे दीवारें) रखे जा सकते हैं
well0006.bmp गहरी चट्टान पर एक परत जैसी संरचना और हल्की और गहरी चट्टान के बीच संक्रमण
well0007.bmp लावा सहित 4-5 फ्रेम की एनीमेशन
well0008.bmp बालू और बालू में अनगिनत प्रकार के क्रेटर
well0009.bmp बालू पर सजावटी तत्व - यानी ऐसे तत्व जो बालू पर सजावट के लिए (या जानबूझकर संरचना के रूप में, जैसे दीवारें) रखे जा सकते हैं
well0010.bmp बालू से हल्की और गहरी चट्टान में 48 संक्रमण
well0011.bmp मैप के ध्रुवीय टोपी, गहरी चट्टान के तल पर
well0012.bmp मैप के ध्रुवीय टोपी, हल्की चट्टान के तल पर

सटीक कार्यान्वयन के लिए यह उचित है कि टाइल्स को पहले से रेंडर न किया जाए ताकि उन्हें कैश किया जा सके, क्योंकि दिन/रात चक्र के लिए डेटा को अभी भी संसाधित करना होगा - और बहुत सारे डेटा उत्पन्न होंगे।

टाइल्स 32x32 पिक्सल के रिज़ॉल्यूशन के साथ इंडेक्स्ड पैलेट के 8bpp ग्राफ़िक्स हैं, जो एक-दूसरे के ऊपर व्यवस्थित होते हैं। एक ऐसे बने हुए टाइलसेट में हालांकि कहीं अधिक हो सकता है।

मुख्य कंटेनर में 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 अलग-अलग टाइल्स की संरचनाएँ हैं। इस प्रक्रिया में स्पष्ट रूप से प्रत्येक बार ब्राइटनेस वैल्यू से 'थोड़ा' घटाया जाता है। सटीक मान अभी तक निर्धारित नहीं किए जा सके हैं, मैं गणना के आधार पर काम कर रहा हूँ 

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 Resource Table' हो - क्योंकि यह फ़ाइल op2_art.prt के रूप में maps.vol में पाई जाती है, जो कि ऐसी ही एक फ़ाइल है, या यह कार्यक्षमता को काफी अच्छी तरह से वर्णित कर सकती है।

यह फ़ाइल एक पैलेट की सूची, सभी उपयोग की गई बिटमैप्स की तालिका, सभी एनीमेशन परिभाषाएँ और कुछ अज्ञात डेटा शामिल करती है। यह अब तक के कंटेनर प्रारूप का कुछ हद तक पालन करती है, क्योंकि सभी रिकॉर्ड इस स्कीमा का पालन नहीं करते हैं।

CPAL सेक्शन (शायद पैलेट कंटेनर के लिए) केवल पैलेट डेटा को घेरता है, यह बताते हुए कि प्रत्येक सामान्यतः 1052 बाइट आकार के 8-बिट पैलेट्स में से कितने मौजूद हैं।

1052-बाइट का यह उल्लेख अनिवार्य नहीं माना जाता है, क्योंकि पैलेट प्रारूप संभावित रूप से विभिन्न पैलेट आकारों का समर्थन कर सकता है। यह केवल उन डेटा सेट के लिए मान्य है, जिनके साथ आउटपॉस्ट 2 वितरित किया जाता है।

पैलेट की सूचियों के बाद तुरंत और बिना किसी प्रारंभिक शीर्षक के, पहले से ही बिटमैप्स की सूची आती है; इसके तुरंत बाद एनीमेशन सूचियाँ आती हैं।
दोनों को क्रमशः एक uint(32) (या फिर uint24+uint8 फ्लैग?) के साथ शुरू किया जाता है, जो रिकॉर्ड की संख्या को दर्शाता है।

पालेट्स

ऐड्र 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 है।

पैलेट के बारे में केवल इतना कहना है कि एनिमेशन के लिए उपयोग की जाने वाली पैलेट के लिए निम्नलिखित नियम लागू होते हैं:

  • पहला रंग हमेशा पारदर्शी होता है, चाहे वहां कोई भी मान दिया गया हो।
  • पैलेट के प्रविष्टियाँ 1-24 को पैलेट 1-8 में खिलाड़ी के रंग के रूप में माना जाता है।
    खिलाड़ी 1 के अलावा अन्य रंग कहाँ से आते हैं, यह मेरे लिए स्पष्ट नहीं है।
    मैं अनुमान लगाता हूँ कि बाकी रंग हार्डकोडेड हैं।

पैलेट संदर्भ

बिटमैप्स

ऐड्र 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 में छिपा हुआ है।
यह स्पष्ट नहीं है कि यह बिटमैप फ़ाइल एक (मुख्यतः सही) RIFF-बिटमैप हेडर क्यों रखती है। संभवतः आउटपॉस्ट 2 ग्राफिक्स को लोड करने के लिए सिस्टम-API का उपयोग करता है, इस हेडर को अस्थायी रूप से ग्रहण करके और संबंधित, भिन्न फ़ील्ड को अधिलेखित करके।

BMP फ़ाइल में पिक्सल डेटा उस स्थान पर पाया जा सकता है जहाँ ओफ़सेट + uint32-ओफ़सेट है, जो BMP फ़ाइल में पते 0x000A (RIFF-बिटमैप डेटा ओफ़सेट) पर स्थित है - और यह फिर से बाईं ओर से दाईं ओर नीचे की ओर पंक्तिबद्ध है।

मोनोक्रोम 1bpp ग्राफिक्स को इस प्रकार बनाया जा सकता है कि रंग 0 पूर्ण पारदर्शिता है, और रंग 1 एक अर्ध-पारदर्शी काला/ग्रे है, क्योंकि मोनोक्रोम ग्राफिक्स आमतौर पर एनिमेशन में वाहन और भवन की छायाएँ बनाने के लिए उपयोग की जाती हैं।

इससे पहले से ही कई ग्राफिक्स को जोड़ा जा सकता है।

संरक्षित आवासीय मॉड्यूल (प्लायमाउथ)

एनिमेशन

अब हम आउटपोस्ट 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) बाउंडिंग बॉक्स: बाईं ओर

बाएँ प्रारंभ (पिक्सेल में) बाउंडिंग बॉक्स का निर्दिष्ट करता है।
0x0008 uint(32) बाउंडिंग बॉक्स: ऊपर

ऊपर की शुरुआत (पिक्सल में) बाउंडिंग बॉक्स को दर्शाती है।
0x000c uint(32) बाउंडिंग बॉक्स: चौड़ाई

यह बाउंडिंग बॉक्स की चौड़ाई (पिक्सेल में) को दर्शाता है।
0x0010 uint(32) बाउंडिंग बॉक्स: ऊँचाई

यह बाउंडिंग बॉक्स की ऊँचाई (पिक्सल में) बताता है।
0x0014 uint(32) ऑफसेट: X

एनिमेशन का क्षैतिज मध्य बिंदु दर्शाता है
0x0018 uint(32) ऑफसेट: Y

एनिमेशन का ऊर्ध्वाधर केंद्र बताता है
0x001c uint(32) अज्ञात 2

अज्ञात जानकारी
0x0020 uint(32) फ्रेम की संख्या

यह बताता है कि इस एनीमेशन में कितने एनीमेशन फ्रेम शामिल हैं
0x0024 uint(32) खिड़कियों की संख्या

यह बताता है कि चित्रण करते समय कितने विंडो का उपयोग करना है

ऊपर की परत के डेटा, जो कि एनीमेशन से संबंधित हैं, मुख्य रूप से प्रशासनिक डेटा हैं - Boundingbox उस चिह्न के चारों ओर के समन्वय को दर्शाता है जो वाहन/भवन के लिए है, जब इसे चुना गया है और यह भी बताता है कि कौन सा क्षेत्र क्लिक करने योग्य होना चाहिए।

ऑफसेट मुख्य रूप से "शून्य बिंदु" को निर्धारित करता है; वह बिंदु जो खेल के अंदर के समन्वयों में जोड़ने या घटाने के लिए है। इसे गणितीय रूप से भी कहा जा सकता है: इस संदर्भ में, ऑफसेट समन्वय का मूल बिंदु है।

विंडोज़ भी, ठीक वैसे ही जैसे कि ऑफसेट, प्रत्येक (प्रति विंडो) 4 uint(32)-मान हैं, जो एक क्षेत्र को निर्दिष्ट करते हैं, जो कि अलग-अलग सबफ्रेम के लिए उपयोगी माना जाता है। विंडोज़ के बाहर, यदि यह बिटमैप के लिए उपयुक्त है, तो नहीं बनाया जाना चाहिए।

फ्रेम

ऐड्र x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF कैरेक्टर
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ऑफसेट डेटा प्रकार नाम व्याख्या
0x0000 uint(8) सबफ्रेम की संख्या और वैकल्पिक 1, 2 के लिए टॉगल

इस मान में शामिल हैं:

  • 0x7F (बिटमास्क): इस फ्रेम में उपयोग किए जाने वाले सबफ्रेम की संख्या
  • 0x80: यह जानकारी कि क्या Optional 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) Bitmap-आईडी

यह बताता है कि इस सबफ्रेम के लिए कौन सा बिटमैप उपयोग किया जाना चाहिए
0x0002 uint(8) अज्ञात 1

यह अज्ञात है - हालांकि मुझे इस बात का मजबूत संदेह है कि यह एक रेंडर प्राथमिकता (जेड-लेयर) हो सकता है।
0x0003 uint(8) सबफ्रेम-आईडी

यह बताता है कि हम किस सबफ़्रेम में हैं
0x0004 sint(16) ऑफसेट - क्षैतिज

यह बताता है कि फ्रेम के भीतर उपफ्रेम कहाँ रखा जाना चाहिए, या बिटमैप को क्षैतिज रूप से कितने पिक्सल स्थानांतरित किया जाना चाहिए
0x0006 sint(16) ऑफसेट - वर्टिकल

यह बताता है कि फ्रेम के भीतर सबफ्रेम कहाँ रखा जाना चाहिए, या बिटमैप को कितने पिक्सल ऊर्ध्वाधर रूप से स्थानांतरित किया जाना चाहिए।

इससे हम अब व्यक्तिगत फ्रेम और संपूर्ण एनिमेशन को मिलाकर बना सकते हैं, यहाँ एक जटिल एनिमेशन, इंडेक्स 500 के एनिमेशन के उदाहरण के रूप में प्रदर्शित किया गया है।

एनिमेशन 500

एनिमेशन 500 दिखाता है कि एक Plymouth-ट्रांसपोर्टर, जो सामान्य खनिजों से भरा हुआ है, कैसे उतारा जाता है। यह उन कुछ एनिमेशनों में से एक है जो विंडोइंग कार्यक्षमता का उपयोग करती है।

इस प्रकार पूरी एनिमेशन को जोड़ा जा सकता है।
दुर्भाग्यवश, ऊपरी लोडिंग हैच के साथ अभी भी एक समस्या है, क्योंकि यहाँ ग्राफ़िक प्रकार की जानकारी में उपयुक्त बिट सेट नहीं किया गया है।

यहाँ खेल से कुछ और, सुंदर एनिमेटेड स्प्राइट्स हैं:

एनिमेशन 500 का रेंडरिंग दर्शाया गया है

एनिमेशन 500 पूरी तरह से जोड़ दिया गया है

प्लाईमाउथ भवन-कारखाना

एडन अंतरिक्षपोर्ट

एडन चिकित्सा केंद्र

एससीएटी

प्लाईमाउथ अंतरिक्षपोर्ट

ईस्टरएग:
क्रिसमस का आदमी

ईस्टरएग:
डैंस कुत्ता

उपयोगकर्ता इंटरफेस

अब खेल का उपयोगकर्ता इंटरफ़ेस बाकी है, जो एक ब्रश किए हुए धातु लुक में है।

लेकिन यहाँ भी यह स्पष्ट है कि Dynamix को पहिया फिर से नहीं बनाना पड़ा; यहाँ केवल Windows द्वारा प्रदान की गई User32 और GDI32 एपीआई का उपयोग नहीं किया गया है - विशेष रूप से User32 के संसाधन प्रबंधन का भी उपयोग किया गया है।

उन्हें उदाहरण के लिए Angus Johnson द्वारा फ्रीवेयर के रूप में विकसित Resource Hacker जैसे कार्यक्रमों के माध्यम से निकाला जा सकता है, या - यदि आप Linux / Mac OS पर Wine का उपयोग नहीं करना चाहते हैं - तो icoutils में शामिल wrestool की मदद से।

फ़ाइल का नाम सामग्री
Outpost2.exe केवल खेल का आइकन शामिल है, जो New Terra के सामने स्थित अंतरिक्ष स्टेशन को दर्शाता है
op2shres.dll बॉर्डर, बटन, रेडियो बटन और चेकबॉक्स जैसे नियंत्रणों के लिए ग्राफ़िक्स के साथ-साथ संवाद पृष्ठभूमियाँ, कहानी मिशन पाठों के लिए सहायक चित्र और मुख्य मेनू की पृष्ठभूमि ग्राफ़िक्स शामिल हैं
out2res.dll इन-गेम विंडो सजावट, सामान्य और विशेष धातु के लिए आइकन, लोडिंग स्क्रीन, संवादों के लिए ग्राफ़िक्स और अन्य कर्सर ग्राफ़िक्स शामिल हैं, खेल निर्देशिका में एनिमेटेड के अतिरिक्त