डॉ.रिप्टाइड गेम के उदाहरण पर खेल संसाधनों के स्वरूपों का अनुसंधान

मैंने एक बार इस गेम को अधिक आधुनिक प्लेटफार्मों पर पोर्ट करने के लिए निर्धारित किया है। लेकिन निश्चित रूप से, खेल खुले स्रोत से बहुत दूर है, और एक बार वापस आने के बाद 1994 में, डेवलपर्स ने इसके लिए 25 रुपये लिए, और इसलिए सभी गेम संसाधनों को फिर से तैयार किया गया या एक ही गेम आर्काइव किया गया। मैंने क्या किया।

RIPTIDE.DAT नाम का एक गेम आर्काइव अपने ही फॉर्मेट की बाइनरी फाइल है। वैसे, यह एक संग्रह नहीं है, बल्कि एक तथाकथित छद्म संग्रह है। यानी फ़ाइलों को संपीड़न के बिना एक ही कंटेनर में संग्रहीत किया जाता है, और कुछ आदिम फ़ाइल प्रणाली है जो बताती है कि कंटेनर के अंदर फ़ाइलों तक कैसे पहुंचा जाए।
यदि हम इस फाइल को किसी भी हेक्स एडिटर में खोलते हैं, तो हम देखेंगे कि कंटेनर के अंदर फाइलों के बारे में रिकॉर्ड बहुत शुरुआत में होता है, और फिर बाइनरी डेटा खुद। दरअसल, आपको यह पता लगाने की जरूरत है कि कंटेनर में कितनी फाइलें हैं और खुद रिकॉर्डिंग फॉर्मेट। पहली चीज जिस पर हम ध्यान देते हैं, वह है एक निश्चित रिकॉर्ड लंबाई, अर्थात्। एक रिकॉर्ड में फ़ाइल नाम की शुरुआत से, अगले में शुरुआत तक, सभी रिकॉर्ड के लिए, समान और 0x19 (25) बाइट्स के बराबर।



हालांकि, पहले रिकॉर्ड का फ़ाइल नाम फ़ाइल की शुरुआत से थोड़ा ऑफसेट है, इसलिए हम देखेंगे कि इसके सामने क्या है। क्योंकि आमतौर पर कंपाइलर 1 (बाइट), 2 (वर्ड), 4 (डॉर्ड), 8 (क्वॉर्ड) बाइट्स के मानक डेटा का उपयोग करते हैं, फिर हम अपने दिमाग में डेटा को ऐसे आकार के लगभग ब्लॉक में विभाजित करेंगे। दो dwords 0x00001A60 और 0x00013EEC और शब्द 0x010E हमारा ध्यान आकर्षित करते हैं क्योंकि वे डेटा की शुरुआत या डेटा के आकार का संकेत दे सकते हैं क्योंकि यह फ़ाइल के आकार से छोटा है। 0x00013EEC और 0x00013EEC कोई रुचि नहीं है। कुछ बाइनरी डेटा के मध्य में पहला बिंदु, दूसरा फ़ाइल रिकॉर्ड के बीच में आता है। लेकिन 0x00001A60 अंतिम फ़ाइल प्रविष्टि के तुरंत बाद स्थित बाइनरी डेटा को समान रूप से इंगित करता है। चूंकि यह फ़ील्ड एक फ़ाइल रिकॉर्ड को संदर्भित करती है, हम अगले रिकॉर्ड के लिए उसी फ़ील्ड को देखते हैं। ऐसा करने के लिए, ऑफसेट नंबर 0x19 को जोड़ें, जो ऊपर प्राप्त किया गया था और जो फ़ाइल रिकॉर्ड की लंबाई है: 0x0000000A+0x19=0x00000023 । इस ऑफसेट पर dword'e में नंबर 0x0001594C , जो फ़ाइल के आकार के भीतर भी है। हम 0x00013EEC कि पहली फ़ाइल रिकॉर्ड से संख्या 0x00013EEC इस संख्या से कम है। इसकी जाँच करें। 0x00001A60+0x00013EEC=0x0001594C हम इसे अन्य रिकॉर्ड पर जांचते हैं और निष्कर्ष निकालते हैं कि इस फ़ील्ड में कंटेनर में स्थित फ़ाइल का आकार है।




सिद्धांत रूप में, यह कंटेनर से सभी फ़ाइलों को प्राप्त करने के लिए पहले से ही पर्याप्त है, लेकिन आइए देखें कि बाकी क्षेत्र क्या हैं। ऑफसेट और आकार के बीच की संख्याएं छद्म-संग्रह के आकार की तुलना में बहुत बड़ी हैं, और इसलिए या तो पता या आकार नहीं हो सकता है। पहली चीज़ जो दिमाग में आती है वह है चेकसम, क्योंकि फ़ाइल के टूटने की स्थिति में डेटा की जाँच करना तर्कसंगत होगा। हालाँकि, इस मामले में, डेवलपर्स ने अलग तरह से काम किया। इन फ़ील्ड्स में फ़ाइलों की टाइम स्टैम्प होती है। इसकी आवश्यकता क्यों है यह एक रहस्य बना हुआ है। पहले फ़ाइल रिकॉर्ड के उदाहरण का उपयोग करते हुए, 0x1CEF2292 प्रारूप में 0x1CEF2292 को 07/15/1994 04:20:36 में बदल दिया जाता है।
अंतिम अनसुलझा मूल्य फ़ाइल के बहुत शुरुआत में केवल शब्द 0x010E रहता है। यह मानना ​​सबसे तर्कसंगत है कि इसमें कंटेनर में फ़ाइलों की संख्या शामिल है। यह सत्यापित करना आसान है। हम पहली फ़ाइल रिकॉर्ड 0x00001A60 से पहली फ़ाइल के लिए ऑफसेट 0x00001A60 शब्द द्वारा 2 बाइट्स घटाते हैं, और 0x19 बाइट्स के फ़ाइल रिकॉर्ड की लंबाई से विभाजित करते हैं और बिल्कुल (00001A60-2)/19 = 010E आवश्यकतानुसार प्राप्त करते हैं।
नतीजतन, यह सी के रूप में संरचनाओं के रूप में लिखा जा सकता है:

 typedef _FILE_ITEM { uint32_t Size; uint32_t TimeStamp; uint32_t Offset; char Name[13]; } FILE_ITEM, *PFILE_ITEM; typedef _HEADER { uint16_t Count; FILE_ITEM Files[0]; } HEADER, *PHEADER; 

अनपैक करने के बाद, हमें 270 फाइलें एक्सटेंशन CMF, L, M, PCS, PCX, TXT, VOC के साथ मिलती हैं।
इन एक्सटेंशनों में, TXT, PCX का विश्लेषण करने की आवश्यकता नहीं है, जो काफी सामान्य प्रारूप हैं। एक छोटी खोज के बाद, सीएमएफ और वीओसी का विश्लेषण करने की आवश्यकता नहीं थी, जो ध्वनि फाइलें हैं। L, M और PCS बने रहें। ईमानदारी से, पीसीएस के लिए क्या उपयोग किया जाता है, मुझे अभी भी पता नहीं चला है, और इसके लिए कोई आवश्यकता नहीं थी।

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

एल प्रारूप

ग्राफिक्स का विश्लेषण करते हुए, हम इस तथ्य पर भरोसा करते हैं कि कहीं भी किसी भी प्रारूप में छवि का आकार और ग्राफिक्स के रूप में प्रदर्शित होने वाली जानकारी को कहीं न कहीं संकेत किया जाना चाहिए। एनीमेशन के लिए, फ़्रेम के बीच कम से कम एक और संख्या और संभवतः समय अंतराल जोड़े जाते हैं।
फिर से, हेक्स संपादक में फ़ाइल (या कुछ ही) खोलें। जो आपकी आंख को तुरंत पकड़ लेता है वह यह है कि पहले बाइट द्वारा खेल में सभी ग्राफिक्स को स्टेटिक रूप से प्रदर्शित किया जाता है, इसका मान 0x01 होता है, और जो एनिमेटेड होते हैं उनमें एक से अधिक होते हैं। इस प्रकार, हम यह अनुमान लगाते हैं कि यह संख्या फ़ाइल में फ़्रेम की संख्या को इंगित करती है। अगला दो बाइट्स हैं, जिसके बाद अधिकांश मामलों में शून्य हैं। मान लीजिए कि यह चौड़ाई और ऊंचाई है। चेक करें - हम पहले को दूसरे से गुणा करते हैं और हम शुरुआत में सिर्फ तीन बाइट्स में फ़ाइल की लंबाई लगभग घटाते हैं।
चूंकि रंग का वर्णन करने के लिए प्रति रंग केवल एक बाइट का उपयोग किया जाता है, तो रंगों को पैलेट में सूचकांकों द्वारा इंगित किया जाता है, और एक साथ उपयोग किए जाने वाले रंगों की अधिकतम संख्या 256 है, जो उस समय के ग्राफिक मोड से मेल खाती है। 256-रंग मोड में, निम्नलिखित पैलेट का उपयोग किया जाता है:



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



इस आंकड़े में, आप ऑफसेट को दूसरे फ्रेम में आसानी से पा सकते हैं। हम ऑफसेट को पहले फ्रेम 0x00000001 पर ले जाते हैं और पहले आकार के लिए आवंटित 2 बाइट्स जोड़ते हैं, और फिर शेड्यूल के लिए 0x0C * 0x10। हमें सिर्फ 0x000000C3 मिलता है।

अंतरिक्ष को बचाने के लिए क्या उल्लेखनीय है, वर्णित फ्रेम के आकार भिन्न हो सकते हैं। पारदर्शी रंग के लिए, मान 0 का उपयोग किया जाता है।

एम प्रारूप

यदि इससे पहले, प्रारूप सरल थे और कठिन नहीं थे और हमें लगभग पता था कि क्या देखना है, अब हमें बेहद सहजता से कार्य करना होगा।

पुन: एक हेक्स संपादक में एक बार में कई एम-फाइलें खोलें और उनमें समान क्षेत्रों की पहचान करने का प्रयास करें।
एक छोटे विश्लेषण के बाद, हम फ़ाइल में कई मुख्य ब्लॉक नोटिस करते हैं:

• फ़ाइल की शुरुआत में 4 बाइट्स
• डेटा विरल शून्य के बड़े ब्लॉक
• डेटा को दोहराने के जंजीरों के साथ आकार में हमेशा 0x8000 बाइट्स का डेटा ब्लॉक, लेकिन लगभग शून्य बाइट्स
• फ़ाइल के अंत में शून्य के साथ डेटा विरल का छोटा ब्लॉक
• फ़ाइल के बहुत अंत में 4 बाइट्स

पहली बात यह देखी गई कि सभी फाइलों में तीसरा ब्लॉक 0x8000 बाइट्स का है। दूसरी बात जिस पर ध्यान दिया गया था कि दूसरा ब्लॉक DWORDs की एक सरणी के समान है, और इसकी लंबाई पहले चार बाइट्स से कई शब्दों की है। यह मानना ​​तर्कसंगत था कि इन दो शब्दों ने दो-आयामी सरणी के ऐडवर्ड्स के आयामों को सेट किया, और फिर खुद को सरणी।
हम इस सरणी के मूल्यों को देखना शुरू करते हैं। किसी भी डॉर्ड की कम बाइट ज्यादातर मामलों में गैर-शून्य होती है, लेकिन उच्च-ऑर्डर बिट्स के करीब, कम अक्सर गैर-शून्य मान होते हैं।
इस द्वि-आयामी सरणी को एक छवि के रूप में प्रदर्शित करने का निर्णय लिया गया था जिसमें बिंदु के 2 बाइट्स इंगित करेंगे कि बिंदु को चित्रित करना है या नहीं।

निम्नलिखित चित्र निकला:


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



तस्वीर साफ होने लगती है। ये मान स्थिर और गतिशील गेम ऑब्जेक्ट का वर्णन करते हैं, जिसके लिए एल-फाइलों में एक अलग ग्राफिक है।

यह स्पष्ट हो गया कि डॉर्ड की पहली बाइट टाइल के नक्शे में छवि की सूचकांक संख्या को संग्रहीत कर रही थी, जिसे इस स्थान पर प्रदर्शित किया जाना था। लेकिन चूंकि ग्राफिक मैप्स में टाइल के नक्शे को कहीं भी संग्रहीत नहीं किया गया था, इसलिए उस डेटा ब्लॉक को 0x8000 बाइट के आकार में प्रदर्शित करने का प्रयास किया गया था। चूंकि मुझे छवि की चौड़ाई का पता नहीं था, इसलिए मूल रूप से 1 पिक्सेल मोटाई की एक लंबी पट्टी प्राप्त की गई थी। धीरे-धीरे छवि की चौड़ाई कम करते हुए, कुछ मानचित्र चित्रों के सिल्हूट दिखाई देने लगे। 8 पिक्सेल की छवि चौड़ाई के साथ, मुझे स्पष्ट छवि मिली जिसमें टाइलों में स्पष्ट वर्ग कटौती की गई थी। परिणाम 8 की चौड़ाई और 4096 पिक्सल की ऊंचाई के साथ एक छवि थी।
मैं नीचे के चित्र में कुछ अंश प्रस्तुत करूंगा। बाइट मान का उपयोग RGB रंग घटक के रूप में किया गया था, इसलिए छवि ग्रे रंग में बदल गई।
वैसे, ज्यादातर मामलों में, चित्रों में आप जो कुछ भी देखते हैं, वह विशाल तालिकाओं के साथ प्रदान किए गए HTML पृष्ठों के स्क्रीनशॉट हैं, जिनमें से कोशिकाओं को अपने रंग में चित्रित किया गया था। बाइनरी फ़ाइलों के पार्सिंग को PHP के माध्यम से किया गया था। ऐसा नहीं है कि मैं एक विकृत था, मैं ग्राफिक रूप से पुस्तकालयों की ओर देखने के लिए बहुत आलसी था।



यदि हम 4096 पिक्सल के टाइल मैप की ऊंचाई 8 से विभाजित करते हैं, तो हमें 512, 256 चित्र मिलते हैं। इस प्रकार, जो मैंने सोचा था कि दीवारों के साथ टकराव की जांच के लिए एक मुखौटा था जो नक्शे में समान छवि सूचकांक है। इस तरह डेवलपर्स ने एक शॉट में एक पत्थर से दो पक्षियों को मार दिया। यानी उन वस्तुओं के लिए छोटी 256 छवियां जिनके माध्यम से तैरना असंभव है, पुराने वाले जिनके माध्यम से यह संभव है। और 2 बाइट्स इंडेक्स के लिए आवंटित किए जाते हैं, एक नहीं।

प्रस्तुत ओवरले मानचित्र अब इस तरह दिखता है:



यह अब पूरा मानचित्र एक स्क्रीन पर आसानी से फिट होता है, और 320x200 पिक्सल के संकल्प के साथ ग्राफिक्स के समय में, गेम में पृष्ठभूमि आसानी से स्क्रॉल की जाती है।

क्यों प्रारूप में अंतिम दो ब्लॉक सहज रूप से विफल पाए जाने का इरादा है।