Outpost 2 फाइल स्वरूपहरू · bei.pm

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

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

जानकारीहरू रिभर्स इन्जिनियरिङ र डाटा विश्लेषण द्वारा संग्रहित गरिएको हो जसले ऐतिहासिक डाटासँगको आर्काइविङ र अन्तरक्रियाशीलता को उद्देश्य राख्छ।
कुनै पनि स्वामित्व वा गोप्य विशिष्टता प्रयोग गरिएको छैन।

खेल हाल gog.com मा डाउनलोडको लागि किनेर प्राप्त गर्न सकिन्छ।

खेलको कला

निम्न लेख श्रृंखलाले 1997 मा सिएरा द्वारा प्रकाशन गरिएको र डायनामिक्स द्वारा विकास गरिएको वास्तविक समयको रणनीति खेल "आउटपोस्ट 2: डिभाइडेड डेस्टिनी" मा डेटा ढाँचाबारे मेरा ज्ञानहरूलाई दस्तावेजीकरण गर्दछ।

मैले लगभग १ नोभेम्बर २०१५ देखि १४ नोभेम्बर २०१५ सम्म खेलको डेटा विश्लेषण गर्नमा ध्यान केन्द्रित गरेको छु - र यससँग के गर्न सकिन्छ।

मैले अहिलेसम्म प्राप्त गरेको जानकारी अनुसार, डायनामिक्स - जस्तै धेरै वाणिज्यिक कम्पनीहरू - ले केही डेटा ढाँचाहरू विशेष रूपमा आउटपोस्ट 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) ब्लक-लम्बाइ

यसले निम्न डाटा ब्लक कति ठूलो (बाइटमा) छ भन्ने जानकारी समावेश गर्दछ।

यसमा शुद्ध प्रयोगकर्ता डेटा बुझिन्छ - ८ हेडर बाइटहरू यसमा समावेश छैनन्।
0x0007 uint(8) झण्डा?

यो ब्लकको उद्देश्य के हो भन्ने कुरा अज्ञात छ।

भोल्युमहरूमा यो मान प्रायः 0x80 हुन्छ, जबकि अन्य फाइलहरूमा प्रायः 0x00 हुन्छ। यसले संकेत गर्दछ कि यो एक फ्ल्याग सेट हो।

भोल्यूमहरू

भोल्युमहरू खेलका लागि डेटा कन्टेनर हुन्, जुन टार्बल जस्ता अर्काइभ फर्म्याटसँग समान छ। कम्तिमा आउटपोस्ट २ मा यो फर्म्याटले केवल फाइलहरूलाई मात्र चिन्छ - कुनै फोल्डरहरू होइन। सायद यीलाई उपयुक्त फाइल नामहरूद्वारा अनुकरण गर्न सकिन्छ।

एक भोल्युम भोल्युम-हेडर र धेरै भोल्युम ब्लकहरूबाट बनेको हुन्छ, जुन निश्चित फाइलहरूलाई प्रतिनिधित्व गर्छन्।

"भोल्युमहरू" खेल निर्देशिकामा '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 = फाइल आवंटन तालिका)

फाइलहरूको संख्याको गणना ब्लकको आकारलाई डाइरेक्ट्री प्रविष्टिको लम्बाई - १४ बाइटले भाग गर्दा प्राप्त हुन्छ।

प्रत्येक डाइरेक्ट्री प्रविष्टिको संरचना तलको जस्तो हुन्छ:

एड्र 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) झण्डा

टाइलहरू आउटपोस्ट-२ विशेष बिटमैप ग्राफिक फर्म्याट हुन्। यी १३ टाइलसेटहरूमा फैलिएका छन्, जसलाई "वेल्स" भनिन्छ (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 नक्साको ध्रुवीय टोपीहरू समावेश गर्दछ, हल्का चट्टानको आधारमा

यो सटीक कार्यान्वयनको लागि सिफारिश गरिन्छ कि Tiles लाई पहिले नै रेंडर नगर्नुहोस् ताकि तिनीहरूलाई क्याश गर्न सकियोस्, किनभने दिन/रात चक्रको लागि डेटा अझै प्रशोधन गर्न आवश्यक छ - र धेरै धेरै डेटा संचित हुनेछ।

Tiles हरु 32x32 पिक्सेलको रिजोल्युसनमा 8bpp ग्राफिक्स हुन् जुन अनुक्रमित प्यालेटका साथ क्रमबद्ध गरिएका छन्। यसरी बनेको 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 का सबै Wells मा यहाँ मान 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;

पिक्सेलका 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 खण्ड (सायद प्यालेट कन्टेनरको लागि) मात्र प्यालेट डाटाहरूलाई समेट्छ, जसले कति ८-बिट प्यालेटहरू छन् जुन सामान्यतया १०५२ बाइटको आकारमा हुन्छ भन्ने कुरा जनाउँछ।

१०५२-बाइटको उल्लेख अनिवार्य रूपमा मान्य हुँदैन, किनकि प्यालेट ढाँचाले सम्भावित रूपमा विभिन्न प्यालेट आकारहरूको व्यवस्था गर्न सक्छ। यो केवल त्यस डाटाबेसको लागि मान्य छ, जसमा आउटपोस्ट २ वितरण गरिएको छ।

प्यालेटहरूको सूची पछि बिना कुनै प्रारम्भिक शीर्षकको तुरुन्तै बिटम्यापहरूको सूची आउँछ; त्यसपछि एनिमेशन सूची पनि तुरुन्तै आउँछ।
दुवैलाई प्रत्येकमा 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) पालेttesformat-संस्करण?

संभावित रूपमा परिभाषित गर्दछ, कुन पलेट फर्म्याटको संस्करण पलेटले अनुसरण गर्छ।

सभी 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 हो।

प्यालेटहरूको बारेमा अन्य कुरा भन्नु पर्दा, एनिमेशनका लागि प्रयोग गरिने प्यालेटमा यस्ता नियमहरू लागु हुन्छन्:

  • पहिलो रंग सधैं पारदर्शी हुन्छ, त्यहाँ केहि पनि मान दिइएको होस्।
  • प्यालेटका प्रविष्टिहरू १-२४ प्यालेट १-८ मा खेलाडीको रंगको रूपमा मान्नुपर्छ।
    रंगहरू खेलाडी १ बाहेक कहाँबाट आउँछन्, मलाई थाहा छैन।
    म अनुमान गर्छु कि बाँकी रंगहरू हार्डकोडेड छन्।

प्यालेटको सन्दर्भ

बिटमैपहरू

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

Pixel डेटा BMP फाइलमा स्थान Offset + uint32-Offset मा पाइन्छ, जुन BMP फाइलमा ठेगाना 0x000A मा भेटिन्छ (RIFF-बिटम्याप-डेटा ओफ्सेट), र यो फेरि माथि बायाँबाट दायाँ तलसम्मको पंक्तिबद्धता अनुसार हुन्छ।

Monochrome 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) अवकाश: X

एनिमेसनको क्षैतिज केन्द्र बिन्दु दिन्छ
0x0018 uint(32) अवधि: Y

एनिमेशनको ठाडो केन्द्र बिन्दु जनाउँछ
0x001c uint(32) अज्ञात 2

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

यस एनिमेशनमा कति एनिमेशन फ्रेमहरू समावेश छन् भनेर जनाउँछ
0x0024 uint(32) विन्डोजको संख्या

कति विन्डोहरू चित्रण गर्दा प्रयोग गर्नुपर्छ भन्ने जनाउँछ

उपरी तहका तथ्यांक, एनिमेशनका लागि, प्राथमिक रूपमा व्यवस्थापन तथ्यांक हुन् - Boundingbox ले वाहन/भवनको चारैतिरको चिह्नको समन्वयलाई जनाउँछ, जब यो चयन गरिएको छ र यसले यो पनि जनाउँछ कि कुन क्षेत्र क्लिक गर्न योग्य हुनु पर्छ।

आफ्नो स्थानले प्रमुख रूपमा "शून्य बिन्दु"लाई निर्धारण गर्छ; यो बिन्दु हो जुन खेलका आन्तरिक समन्वयमा जोड्न वा घटाउन आवश्यक छ। गणितीय रूपमा भन्नु पर्दा: यो स्थानले यहाँ समन्वयको मूल बिन्दुलाई जनाउँछ।

विन्डोहरूमा, जसरी आफ़्नो स्थानमा, प्रत्येक (प्रत्येक विन्डोका लागि) ४ 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) अज्ञात १ र वैकल्पिक ३, ४ का लागि टोगल

यस मानमा समावेश गरिएको छ:

  • 0x7F (बिटमास्क): अनजान - म दृढ विश्वास लिन्छु कि यो खेलका टिकहरूको संख्या हो जुन अर्को फ्रेम देखापर्नेमा बित्छ
  • 0x80: वैकल्पिक 3 र 4 उपस्थित छन् कि छैन भन्ने जानकारी
0x0002 uint(8) वैकल्पिक 1

अज्ञात
0x0003 uint(8) वैकल्पिक 2

अज्ञात
0x0004 uint(8) वैकल्पिक ३

अज्ञात
0x0005 uint(8) वैकल्पिक ४

अज्ञात

सबफ्रेम

एड्र 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

अज्ञात छ - तर म यसमा बलियो अनुमान लगाउँछु कि यो एक रेंडर प्राथमिकता (Z-लेयर) हो।
0x0003 uint(8) सबफ्रेम-आईडी

यो बताउँछ कि हामी कुन सबफ्रेममा छौं
0x0004 sint(16) अवधि - क्षैतिज

फ्रेम भित्र सबफ्रेम कहाँ राख्ने हो र बिटमैपलाई कति पिक्सेल horizontally सरेको हुनुपर्छ भनी जनाउँछ
0x0006 sint(16) अफसेट - खडा

फ्रेम भित्र सबफ्रेम कहाँ राखिनेछ भन्ने बताउँछ, वा बिटम्याप कति पिक्सेल vertically सरेको हुनेछ।

यसले हामीलाई अब व्यक्तिगत फ्रेमहरू र सम्पूर्ण एनिमेसनहरूलाई मिलाएर बनाउन सक्षम बनाउँछ, यहाँ एक जटिल एनिमेसनको उदाहरणको रूपमा, अनुक्रमणिका 500 सँगको एनिमेसनमा प्रदर्शन गरिएको छ।

एनिमेसन 500

एनिमेशन 500 ले देखाउँछ, कि कसरी एउटा Plymouth-Transporter, जसलाई सामान्य खनिजले भरेको छ, खाली गरिन्छ। यो विन्डोइङ कार्यक्षमता प्रयोग गर्ने थोरै एनिमेशनमध्ये एक हो।

र यसरी सम्पूर्ण एनिमेशनलाई एकत्रित गर्न सकिन्छ।
दुर्भाग्यवश, माथिल्लो लोडिङ ढोकासँग अझै एक समस्या छ, किनकि यहाँ ग्राफिक प्रकारको सूचनामा सम्बद्ध बिट सेट गरिएको छैन।

यहाँ खेलबाट केही अन्य, सुन्दर एनिमेटेड स्प्राइटहरू छन्:

एनिमेशन 500 को रेंडरिंग चित्रण गर्दछ

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

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

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

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

SCAT

प्लिमथ अन्तरिक्षपोर्ट

ईस्टरइग:
क्रिसमसको बाबा

ईस्टरइग:
डान्स कुकुर

प्रयोगकर्ता अन्तरफलक

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

तर यहाँ पनि यसले दर्शाउँछ कि Dynamix ले चक्रलाई फेरि आविष्कार गर्नु परेको छैन; यहाँ केवल Windows द्वारा प्रदान गरिएका User32 र GDI32-APIs को प्रयोग गरिएको छैन - विशेष गरी User32 को स्रोत व्यवस्थापन पनि प्रयोग गरिएको छ।

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

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