Outpost 2 दिनांक फॉरमॅट्स · bei.pm

मराठी
हा मजकूर OpenAI GPT-4o Mini द्वारे स्वयंचलितपणे अनुवादित करण्यात आला आहे.

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

या माहितीचे संकलन रिव्हर्स इंजिनियरिंग आणि डेटा विश्लेषण द्वारे ऐतिहासिक डेटासह संग्रहण आणि परस्परसंवादासाठी केले गेले आहे.
कोणत्याही खास किंवा गोपनीय विशिष्टता वापरली गेली नाही.

हा खेळ सध्या gog.com वर डाउनलोड म्हणून खरेदी केला जाऊ शकतो.

खेळाची कला

खालील लेख मालिका "आउटपॉस्ट २: डिव्हाइडेड डेस्टिनी" या रिअल-टाइम स्ट्रॅटेजी खेळातील डेटा स्वरूपांवर माझ्या निरीक्षणांचे दस्तऐवजीकरण करते, जे १९९७ मध्ये सिएरा द्वारे प्रकाशित झाले आणि डायनामिक्सने विकसित केले.

मी ०१ नोव्हेंबर २०१५ पासून १४ नोव्हेंबर २०१५ पर्यंत मुख्यतः खेळाच्या डेटाच्या विश्लेषणात व्यस्त होतो - आणि त्याच्या वापराबद्दल.

ज्या माहितीचा मी आतापर्यंत अभ्यास केला आहे, त्यानुसार डायनामिक्स - अनेक व्यावसायिक कंपन्यांप्रमाणे - आउटपॉस्ट २ साठी विशेषतः काही डेटा स्वरूपे विकसित केलेली नाहीत, तर मॅकवॉरियर सिरीजसारख्या इतर विकासांमध्ये (फारक केलेले) वापरली आहेत.
याशिवाय, डेटा स्वरूपांच्या नवोन्मेष शक्तीची मर्यादा स्पष्टपणे आहे आणि सामान्यतः JFIF आणि RIFF सारख्या दीर्घकालीन अस्तित्वात असलेल्या संकल्पनांवर आधारित आहे.

तालिका आणि डेटा स्वरूपांच्या अर्थ लावण्यासाठी अधिक माहिती काय आहे काय? येथे उपलब्ध आहे.
येथे दिलेली माहिती सामान्यतः लघु एंडियन म्हणून समजली पाहिजे.

शेवटी, उलट अभियांत्रण खूप मजेदार होते, जरी ते पूर्णपणे झालेले नाही.
निश्चितपणे, मी खेळ स्वतः खेळण्याचीही शिफारस करतो, कारण यामध्ये रोचक खेळ यांत्रिकी आहेत.

परिचय

आउटपोस्ट 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 नकाशाच्या ध्रुवीय कॅप्स, उजळ खडक असलेल्या मागणीत

सुसंगत अंमलबजावणीसाठी, टाइल्स आधीच रेंडर करणे आणि त्यांच्या कॅशिंगसाठी टाळणे उचित आहे, कारण दिवस/रात चक्रासाठी डेटा अद्याप प्रक्रिया करणे आवश्यक आहे - आणि खूपच अधिक डेटा निर्माण होईल.

टाइल्स 8bpp ग्राफिक्स आहेत, ज्यामध्ये 32x32 पिक्सेल रिझोल्यूशनसह अनुक्रमित पॅलेट आहे, जे एकमेकांच्या वर ठेवलेले आहेत. अशा प्रकारे बनलेल्या टाइलसेटमध्ये मात्र अधिक असू शकतात.

मुख्य कंटेनर 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) रुंदी (आडव्या समाधान)

चित्रफाईल किती रुंद आहे हे दर्शवते (पिक्सेलमध्ये).

आउटपोस्ट 2 च्या सर्व वेल्समध्ये इथे 0x20 किंवा 32 हा मूल्य अपेक्षित असेल.
0x0010 uint(32) उंचाई (उभ्या समाधान)

संदेशित करते की चित्र फाइलची उंची किती आहे (पिक्सेलमध्ये).

आउटपोस्ट 2 च्या सर्व वेल्ससाठी येथे मूल्य 0x20 किंवा 32 अपेक्षित असेल.
0x0014 uint(32) रंगाची खोली?

या मूल्याचा अर्थ अज्ञात आहे.

कारण तो सर्व चाचणी घेतलेल्या फाइलमध्ये 8 मूल्य समाविष्ट आहे, त्यामुळे हे रंगाच्या खोलीचा निर्देश असू शकतो.
0x0018 uint(32) रंगाची खोली २?

या मूल्याचे महत्त्व अज्ञात आहे.

कदाचित हे 'लक्ष्य'-रंग गडदतेचे असू शकते.

या माहितीनुसार, एक मानक 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;

pixel च्या 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) असू शकते, हेही शक्य आहे.

पॅलेट माहिती वाचणे खूप सोपे आहे.
त्यात प्रत्येक वेळी एक हेडर आणि एक डेटा-सSegment समाविष्ट आहे.

पॅलेट्स-हेडर

अड्रेस 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) सामान्य रुंदी

पिक्सेल डेटा ओळींची रुंदी बाइटमध्ये दर्शवते - कारण ती ४-बाइटच्या सीमांकडे संरेखित आहेत.

त्यामुळे निश्चित चित्र ओळवर झूम करणे जलद शक्य आहे.

हा मूल्य स्वतंत्रपणे का संग्रहित केला जातो, जरी तो गणना करून मिळवता येईल, हे अस्पष्ट आहे.
कदाचित हे रेंडर कोडसाठी एक ऑप्टिमायझेशन आहे.
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-बिटमॅप हेडर का आहे, हे अस्पष्ट आहे. संभवतः आउटपोस्ट 2 ग्राफिक्स लोड करण्यासाठी सिस्टम-APIs वापरते, हे हेडर तात्पुरते स्वीकारून आणि संबंधित, बदलणारे क्षेत्र ओव्हरराईट करून.

BMP फाईलमध्ये पिक्सेल डेटा स्थान ऑफसेट + uint32-ऑफसेटवर आहे, जे BMP फाईलमध्ये पत्ता 0x000A येथे आढळते (RIFF-बिटमॅप-डेटा ऑफसेट), आणि हे वरच्या डावीकडून उजवीकडे खालील ओळीतून व्यवस्थित केलेले आहे.

मोनोक्रोम 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) बाउंडिंग बॉक्स: डावे

या बाउंडिंग बॉक्स चा डावा आरंभ (पिक्सेलमध्ये) दर्शवतो.
0x0008 uint(32) बाउंडिंग बॉक्स: वर

उपरी सुरूवात (पिक्सेलमध्ये) बाउंडिंग बॉक्स दर्शवते.
0x000c uint(32) बाउंडिंग बॉक्स: रुंदी

बाँधणीत बॉक्सची रुंदी (पिक्सेलमध्ये) दर्शवते.
0x0010 uint(32) बाउंडिंग बॉक्स: उंची

हे Bounding Box ची उंची (पिक्सेलमध्ये) दर्शवते.
0x0014 uint(32) ऑफसेट: एक्स

अॅनिमेशनचा आडवा केंद्र बिंदू दर्शवतो
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: पर्यायी 1 आणि 2 उपलब्ध आहेत का याची माहिती
0x0001 uint(8) अज्ञात 1 आणि वैकल्पिक 3, 4 साठी टॉगल

हा मूल्य समाविष्ट करते:

  • 0x7F (बिटमास्क): अज्ञात - मला ठाम विश्वास आहे की हे गेमटिक्सची संख्या आहे, जी पुढील फ्रेम प्रदर्शित होईपर्यंत लागते
  • 0x80: वैकल्पिक ३ आणि ४ आहेत का याबद्दलची माहिती
0x0002 uint(8) ऐच्छिक 1

अज्ञात
0x0003 uint(8) पर्यायी 2

अज्ञात
0x0004 uint(8) पर्यायी 3

अज्ञात
0x0005 uint(8) पर्यायी ४

अज्ञात

सबस्ट्रक्चर

अड्रेस x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF किरदार
0x0000 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- . . . . . . . . . . . . . . . .
ऑफसेट डेटा प्रकार नाव स्पष्टीकरण
0x0000 uint(16) बिटमैप-आयडी

या सबफ्रेमसाठी कोणती बिटमॅप वापरली जावी हे दर्शवते
0x0002 uint(8) अज्ञात 1

अज्ञात आहे - तथापि, मला असे दृढ संशय आहे की हे एक रेंडर प्राधान्य (Z-लेयर) आहे.
0x0003 uint(8) सबफ्रेम-आयडी

कुठल्या उपफ्रेममध्ये आपण आहोत ते दर्शवित आहे
0x0004 sint(16) ऑफसेट - आडवा

संकेत करते की फ्रेमच्या आत उपफ्रेम कुठे ठेवला जावा, किंवा बिटमॅप किती पिक्सेल्सने आडवे हलवला जावा
0x0006 sint(16) ऑफसेट - उभा

फ्रेमच्या आत सबफ्रेम कुठे ठेवला जावा याची माहिती देते, किंवा बिटमॅप किती पिक्सेल उभ्या दिशेने हलवला जावा याची माहिती देते

यामुळे आता आपण स्वतंत्र फ्रेम्स तसेच संपूर्ण अ‍ॅनिमेशन योग्यरीत्या एकत्रित करू शकतो, इथे एक अधिक जटिल अ‍ॅनिमेशन, इंडेक्स 500 सह अ‍ॅनिमेशनवर उदाहरणार्थ दर्शवले आहे

एनिमेशन ५००

एनिमेशन 500 मध्ये एक प्लायमाउथ ट्रान्सपोर्टर, जो सामान्य खाणीनं भरलेला आहे, कसा उतरवला जातो हे दाखवले आहे. हे विंडोइंग कार्यक्षमता वापरणाऱ्या काहीच एनिमेशन्सपैकी एक आहे.

आणि असे संपूर्ण एनिमेशन एकत्र करता येते.
दुर्दैवाने, वरच्या लोडिंग हूपसंबंधी अजून एक समस्या आहे, कारण येथे ग्राफिक प्रकाराच्या माहितीत योग्य बिट सेट केलेले नाही.

खेळातील आणखी काही सुंदर एनिमेटेड स्प्राइट्स येथे आहेत:

एनिमेशन 500 चे रेंडरिंग दर्शवित आहे

एनिमेशन 500 पूर्णपणे एकत्रित केलेले

प्लायमाउथ इमारत-फॅक्टरी

एडन स्पेसपोर्ट

एडन मेडिकल सेंटर

SCAT

प्लायमाउथ स्पेसपोर्ट

ईस्टर अंडी:
क्रिसमसचा माणूस

ईस्टर अंडी:
Dans Dog

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

आता खेळाचे यूजर इंटरफेस उर्वरित आहे, जे ब्रश केलेल्या धातूच्या स्वरूपात आहे.

परंतु येथे देखील स्पष्ट आहे की Dynamix ने चाक नव्याने तयार करण्याची आवश्यकता नाही; येथे फक्त Windows द्वारे प्रदान केलेल्या User32 आणि GDI32-API चा वापर केला जात नाही - विशेषतः User32 च्या संसाधन व्यवस्थापनाचा देखील वापर केला जातो.

यांना उदाहरणार्थ Angus Johnson द्वारे फ्रीवेअर म्हणून विकसित केलेले Resource Hacker सारख्या कार्यक्रमांद्वारे किंवा - जर तुम्ही Linux / Mac OS वर Wine चा वापर टाळत असाल - icoutils मध्ये समाविष्ट wrestool चा वापर करून काढता येते.

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