मैंने पहले ही शौकिया अनुवाद पर एक लेख लिखा था , जहां मैंने इस प्रक्रिया के व्यंजनों का वर्णन करने की कोशिश की। लेकिन, मेरी राय में, यह अनुभव पूरी तरह से सफल नहीं था। बड़ी संख्या में दृष्टिकोणों को देखते हुए, सब कुछ का वर्णन करना असंभव है, और सार का अत्यधिक सामान्यीकरण प्रतिबिंबित नहीं करता है। इसलिए, मैंने अपनी राय में, एक विशिष्ट मामले का वर्णन करने का फैसला किया।

ईमानदारी से, यह वास्तव में हमारे पिछले अनुवाद के बारे में नहीं है। तथ्य यह है कि इस लेख को लिखने का विचार मेरे पास तब आया जब हमारा व्यवसाय गिरावट में था और "अंतिम" शब्द का अर्थ वास्तव में इस स्तर पर हमारे अंतिम काम था। लेकिन, परियोजना के लिए वास्तविक उत्पादन अभ्यास के परिणामस्वरूप प्राप्त पेशेवर दृष्टिकोण और अनुभव को लागू करते हुए, मुझे एहसास हुआ कि मैं इसके साथ रह सकता हूं और दृढ़ता से फैसला किया कि हमें एक और अनुवाद पूरा करना चाहिए, जिसे हम दो साल से अधिक समय से देख रहे हैं। इसलिए, वर्तमान परिस्थितियों में, इस शब्द का अर्थ है "लिखने के समय अंतिम।"

यह एक पीसी पर खेलने के बारे में नहीं है, यह बहुत उबाऊ होगा - क्योंकि रिवर्स इंजीनियरिंग का एक्सिज़लिज़्म और रोमांस नहीं है जो कंसोल गेम के आंतरिक भाग में निहित है। यह निनटेंडो Wii पर खेलने के बारे में है।

मैं पहले से ही फूले हुए लेख और उबाऊ उत्तरार्ध के लिए अग्रिम में माफी माँगता हूँ, लेकिन जैसा कि वे कहते हैं, आपने गीत से शब्दों को नहीं मिटाया।

प्रागितिहास

यह सब 2010 में कहीं शुरू हुआ था, सटीक तारीख को याद नहीं किया जा सकता है। एक छात्र होने के नाते, मैं और डैनगार्ड ( जंगली गीज़ और लिटिल रेड राइडिंग हूड के बारे में कई लेखों के लेखक) काफी समय से शौकिया अनुवाद में लगे हुए हैं: मैंने उपकरण लिखे, और उन्होंने अनुवाद किया। और हमारी एक बुरी आदत थी - हमारे द्वारा पसंद किए गए किसी भी खिलौने का अनुवाद शुरू करने के लिए, यही वजह है कि हमारे देश में परित्यक्त परियोजनाओं की संख्या पूरी होने वालों की संख्या की तुलना में बहुत अधिक है। हमारी पसंदीदा गेम श्रृंखला में से एक हमारे पास मौजूद थी और कुख्यात मेट्रॉइड - एक दो-आयामी साहसिक गेम , मेट्रोडवानिया शैली के संस्थापक, और मैं हमेशा यह देखना चाहता था कि इस शैली को मेट्रॉइड प्राइम सीरीज़ के गेम्स में 3 डी में कैसे पोर्ट किया गया था, जो निनटेंडो गेमक्यूब और Wii पर जारी किया गया था।

और कुछ बिंदु पर मैं Wii का गर्व मालिक बन गया, और निश्चित रूप से, तुरंत अपनी जिज्ञासा को संतुष्ट करने का फैसला किया। मुझे पता नहीं क्यों, लेकिन गेमप्ले के पहले मिनटों में मेट्रॉयड प्राइम का पहला भाग वास्तव में मुझे प्रभावित नहीं करता है - जाहिर है, असामान्य नियंत्रण ने मुझे प्रभावित किया, और मुझे स्वाद लेने का समय नहीं मिला क्योंकि मैं बल्कि अन्य खेलों की कोशिश करना चाहता था। हालांकि, इस तथ्य को ध्यान में रखते हुए कि पहले दो भाग गेमक्यूब के साथ केवल एक बंदरगाह थे, तीसरे के विपरीत, जो मूल रूप से Wii पर लॉन्च किया गया था, मैंने इसे देखने का फैसला किया। मैंने लगभग छह घंटे के बाद इसे देखना बंद कर दिया, और खेल में जानकारी की मात्रा से बहुत प्रभावित हुआ - शाब्दिक रूप से हर वस्तु को संक्षिप्त जानकारी या यहां तक ​​कि एक संपूर्ण लेख प्राप्त करके स्कैन किया जा सकता है।

उनकी आंखें एक विचार के साथ प्रज्ज्वलित हुईं, और उनके हाथ पहले से ही दीक्षा के पहले से ही परिचित संस्कार करने के लिए शुरू हो गए थे - सही उपकरण का प्रक्षेपण। इसलिए इस अनुवाद की परियोजना का जन्म हुआ।

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

संसाधनों की तलाश में

तो, पहली बात यह थी कि रिवर्स इंजीनियरिंग के उद्देश्य से खेल फ़ाइलों को प्राप्त किया जाए। यह किसी भी तरह से संभव होना था, इसलिए मैंने पहले से ही Google में एक संगत अनुरोध निकाल दिया। पहले WiiScubber प्रोग्राम था, जिसे शून्य के साथ गेम डिस्क की छवि के अप्रयुक्त क्षेत्रों में भरने के लिए डिज़ाइन किया गया था, ताकि यह तब बेहतर तरीके से संपीड़ित हो जाए (अधिक सटीक रूप से, इसके एन्क्रिप्शन के कारण, यह कम से कम किसी तरह से संपीड़ित होगा), जो उन्हें खोलना भी जानता था। यह ध्यान देने योग्य है कि इस कार्यक्रम ने परियोजना के दौरान एक भूमिका निभाई, लेकिन बाद में उस पर अधिक।

छवि को खोलने और इसकी सामग्री की जांच करने के बाद, पहले मैंने * .pak के साथ बड़ी फ़ाइलों को देखा। निस्संदेह, वे खेल संसाधनों के भंडारण के लिए मुख्य संदिग्ध थे, और हेक्स संपादक में विच्छेदन के लिए पहले से ही प्रतियां तैयार की जा रही थीं।


फ़ाइल की शुरुआत में, एक आदिम हेडर दिखाई देता था, जो फॉर्म के रिकॉर्ड के साथ शुरू होता था:

struct PakHeader { uint32 unknown; // version? uint32 totalHeaderSize; uint64 unknown; // hash? }; 

निम्नलिखित उपयोगी डेटा 0x40 की ऑफसेट के साथ शुरू हुआ, जिसने 64 बाइट्स के ब्लॉक आकार में डेटा को संरेखित करने के बारे में निष्कर्ष निकालने का कारण दिया। इन आंकड़ों के बीच, कुछ पहचानकर्ता स्पष्ट रूप से बाहर खड़े थे: एसटीआरजी, आरएसएचडी और डेटा। मुझे फॉर्च्यूनटेलर के पास नहीं जाना था - यह स्पष्ट हो गया कि संग्रह को खंडों, या अनुभागों में विभाजित किया गया था। प्रत्येक पहचानकर्ता के बाद एक मूल्य है जो 64 वें का एक बहु है - दो स्पष्ट विकल्प थे: या तो आकार या ऑफसेट।


चूंकि अगला डेटा ब्लॉक आकार में 0x800 बाइट्स था, और उसी मूल्य ने पहले खंड के पहचानकर्ता का पालन किया, यह स्पष्ट हो गया कि ये अभी भी आकार थे।

 struct SectionRecord { char name[4]; uint32 size; }; 

वर्गों के साथ, सब कुछ स्पष्ट है, यह उनके उद्देश्य को निर्धारित करने के लिए रहता है। यहां पहचानकर्ताओं ने सहज स्तर पर मदद की - सिर में संक्षिप्त रूप से शब्द " जी एस में str ", " r e e ource h ea d ers" और, अजीब तरह से पर्याप्त, " डेटा " के साथ पंक्तिबद्ध थे। धाराप्रवाह सब कुछ के माध्यम से स्क्रॉल करना और यह विचार करना कि कुछ अभिलेखागार में एसटीआरजी अनुभाग खाली है, मैंने पहले आरएसएचडी अनुभाग से परिचित होने का फैसला किया।


फिर से, यह स्पष्ट है कि यह खंड एक संग्रह है जिसमें संग्रह में संग्रहीत फ़ाइलों के बारे में जानकारी है। डेटा ऐरे में, पहचानकर्ता देखे गए - TXTR, SCAN, STRG, इत्यादि। फ़ाइलें टाइप की जाती हैं और यह अच्छा है। अनुभाग तालिका के अंतर्ज्ञान और संरचना के आधार पर, मैंने माना कि पहले 4 बाइट उनकी संख्या है। इसे सत्यापित करने के लिए, मैंने मानक रूप से कार्य किया: मैंने रिकॉर्ड के आकार की गणना की, पड़ोसी पहचानकर्ताओं (24 बाइट्स) की शुरुआत और इस मूल्य (0x1CA) से गुणा के बीच की दूरी की गणना की। मैंने परिणामी मान (0x2AF0) को 0x40 के कारक पर गोल किया, 2B00 प्राप्त किया। जैसा कि अपेक्षित था, यह खंड तालिका में निर्दिष्ट आकार से मेल खाता था।

अब यह फ़ाइल प्रविष्टि के प्रारूप को पार्स करना है। पहचानकर्ता के साथ सब कुछ स्पष्ट है - यह फ़ाइल के प्रकार को इंगित करता है। उसके अलावा, मुझे कम से कम फ़ाइल के कुछ पहचानकर्ता, साथ ही साथ इसके आकार और संग्रह में ऑफसेट की उम्मीद थी।


दृश्य विश्लेषण के माध्यम से, मैंने कुछ पैटर्न की पहचान की। पहली संख्या हमेशा 0 या 1 होती है, इसलिए यह सबसे अधिक संभावना है कि यह बूलियन मान है। यह देखते हुए कि यह एक संग्रह है, यह संभव है कि यह एक संपीड़न ध्वज हो। इसके बाद पहचानकर्ता आया, जिसके साथ मेरी समझ में आया। इसके पीछे - अराजक जानकारी के 8 बाइट, एक हैश के समान और ऐसा लगता है, फ़ाइल की पहचानकर्ता हैं। पिछले दो मान गए: दोनों 0x40 के गुणक हैं, लेकिन बाद में रिकॉर्ड की संख्या के साथ वृद्धि हुई। निष्कर्ष खुद से अनुरोध किया गया था: फ़ाइल का आकार और ऑफसेट। चूंकि पहली फ़ाइल की ऑफसेट शून्य है, यह स्पष्ट है कि यह खंड की शुरुआत के सापेक्ष इंगित किया गया है।

संकेतित ऑफसेट पर कूदने और उनमें आयाम जोड़ने के बाद, मैं अपने अनुमानों के बारे में आश्वस्त हो गया और जो कुछ बचा था, उसे एक संरचना के रूप में लिखना था:

 struct FileRecord { uint32 packed; char type[4]; uint8 hash[8]; uint32 size; uint32 offset; }; 

तब मुझे फ़ाइल डेटा में ही दिलचस्पी थी। संग्रह और आकार में उनकी स्थिति के बारे में जानकारी ज्ञात थी, इसलिए मैंने जल्दी से एक साधारण चिमटा निकाला और अभिलेखागार की सामग्री को बाहर निकाल लिया। कुछ फाइलों को देखने के बाद, मुझे एहसास हुआ कि वे वास्तव में पैक हैं। लेकिन मुझे पहले से ही एल्गोरिथ्म पता था - इस तरह की गतिविधियों में कई वर्षों के अनुभव ने खुद को महसूस किया, और हेक्स संपादक की खिड़की पर एक नज़र पर्याप्त थी। यह केवल यह सुनिश्चित करने के लिए बना रहा कि अनुभव ने मुझे धोखा नहीं दिया, और मैंने फ़ाइलों में से एक को STUNS कार्यक्रम में खिलाया , जो कुछ सामान्य संपीड़न एल्गोरिदम को पूरी तरह से प्रकट करता है। मैं गलत नहीं था, यह LZO था।

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


सबसे पहले, यह स्पष्ट था कि ऐसी सभी फाइलों पर एक हस्ताक्षर है - सीएमपीडी। यह तीन संस्करणों - 1, 2, और बहुत कम में पाया गया मूल्य के बाद था - 3. मैंने फैसला किया कि यह प्रारूप का कुछ प्रकार या संस्करण था, पहले इसे कोई अर्थ दिए बिना। अगले बाइट में एक अज्ञात मान होता है, और अगले तीन बाइट्स, फ़ाइल का आकार शून्य 16। यह मुझे विश्वास दिलाता है कि फ़ाइल के पहले 16 बाइट्स हेडर थे। अज्ञात बाइट के मूल्यों का विश्लेषण करने के बाद, मैंने देखा कि अक्सर केवल एक या दो बिट अलग होते हैं, और फैसला किया कि ये कुछ झंडे हैं। चार और बाइट्स का पालन किया गया, अनपैक्ड फ़ाइल के आकार के बराबर, जो मेरे लिए STUNS द्वारा बाहर रखा गया था - निष्कर्ष स्पष्ट है, यह स्रोत डेटा का आकार है।

16 बाइट्स समाप्त हो गए, STUNS के अनुसार, दो और बाइट्स के बाद, संपीड़ित धारा स्वयं शुरू हुई। मुझे यकीन था कि यह शास्त्रीय योजनाओं में से एक है: डेटा के एक हिस्से का आकार दो बाइट्स में इंगित किया गया है, फिर पैक्ड डेटा का हिस्सा स्वयं का पालन करता है, और इसी तरह जब तक कि धारा समाप्त नहीं हो जाती। वास्तव में, इन दो बाइट्स के मूल्य धारा के आकार के साथ मेल खाते थे।

प्राप्त जानकारी को संसाधित करने के बाद, मैंने शीर्ष लेख संरचना बनाई।

 struct CompressedFileHeader { char signature[4]; uint32 type; unsigned flags : 8; unsigned lzoSize : 24; uint32 dataSize; }; 

अब यह स्पष्ट था कि इन फ़ाइलों को कैसे पढ़ा जाए, और मैं अच्छे पुराने मिनीज़ो पर चढ़ गया। इसके मिनी-ढांचे और धागे के लिए घर-निर्मित अमूर्त के व्यापक उपयोग के कारण, एक एलजेडओ स्ट्रीम को अनपैक करने के कार्यान्वयन में अधिक समय या कोड लाइनें नहीं लगीं।


एक वितरक के पद पर मेरे आदिम निकालने वाले को उठाकर, मैंने पहली बार यह सुनिश्चित किया कि मैं संग्रह फ़ाइल तालिका में बूलियन फ़ील्ड के उद्देश्य को सही ढंग से समझ गया हूं। यह पता चला कि वास्तव में, जिन फाइलों के लिए यह गलत है, उन्हें ज़िप नहीं किया गया था। शांत होने के बाद, मैंने इसे कोड में ध्यान में रखा, बड़ी फ़ाइलों में से एक पर प्रोग्राम सेट किया और प्रगति के लिए संतुष्टि के साथ देखना शुरू किया ...

लेकिन कार्यक्रम को सफलतापूर्वक पूरा करने के लिए नियत नहीं किया गया था। दुर्घटनाग्रस्त पहली TXTR फ़ाइल को अनपैक करने का प्रयास। यह तब था जब मुझे एहसास हुआ कि किसी कारण से इन फ़ाइलों का कुछ संस्करण है। हेक्स संपादक में एक संपीड़ित बनावट को खोलने के बाद, मैंने मतभेदों की तलाश शुरू की।


बेशक, अब एक प्रकार के रूप में एक इकाई नहीं थी। पहली चीज जिसने मेरी आंख को पकड़ा, वह हेडर के आकार में अंतर था: यह 20 बाइट्स बड़ा हो गया। इसके अलावा, अब हेडर में 12 और दूसरे 12 नए बाइट्स के दो मान थे। मेरे पास एक कूबड़ था और मुझे एक असम्बद्ध बनावट का उदाहरण देखने को मिला। एक पाया जाने के बाद, मैंने इसकी शुरुआत को देखा और देखा कि यह उन 12 बाइट्स के समान था, जो अन्य चीजों के अलावा, हेडर में जोड़े गए थे।

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

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


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

 struct NameRecord { char name[]; // C-string char type[4]; uint8 hash[8]; }; 

वास्तव में, यह पूरा खंड फ़ाइल नाम के लिए हैश (या जोड़े [हैश, टाइप]) की क्रमबद्ध मैपिंग है।

अब मेरे पास सभी आवश्यक संसाधनों तक पहुंच थी, और उन्हें शोध करने का समय था।

पाठ का पीछा

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

मैंने टेक्स्ट डेटा को क्रमबद्ध करने के तरीकों का विश्लेषण करते हुए बहुत सी चीजें देखीं, इसलिए जब मैंने हेक्स संपादक में इनमें से एक फाइल को खोला, तो मैं किसी भी चीज के लिए तैयार था। और व्यर्थ में नहीं, जैसा कि यह निकला, क्योंकि मामला तुच्छ नहीं था।


मेरी लाइन ने तुरंत "ENGLJAPNGERMFRENSPANITAL" लाइन को पकड़ा - खेल द्वारा समर्थित छह भाषाओं की एक सूची। फ़ाइल के उत्तरार्ध में पाठ से, यह स्पष्ट था कि फ़ाइल में वास्तव में इन सभी भाषाओं में लाइनें थीं। भाषाओं की पहचान करने वालों के सामने आने वाली हर चीज एक हेडर की तरह दिखती थी, और अन्य फाइलों में एक ही तस्वीर होती थी, इसलिए मैं इस पर सहमत हुआ: पहले 24 बाइट हेडर हैं।

इसके बाद, मैंने उन तथ्यों की तुलना करना शुरू किया जिन्हें मैं इस शीर्षक के अर्थों के साथ जानता हूं। उदाहरण के लिए, यह स्पष्ट था कि छह भाषाओं के लिए डेटा की दो पंक्तियों को एक फ़ाइल में संग्रहीत किया गया था, इसलिए मान 6 और 2 के शब्दार्थ ने सवाल नहीं उठाए। इसी तरह, पहले चार बाइट्स के साथ सब कुछ स्पष्ट था: हस्ताक्षर आम हैं। हालांकि, अगले 4 बाइट्स, हालांकि यह फ़ाइल में किसी अन्य डेटा के साथ संचार की कमी के कारण प्रारूप का एक सहज संस्करण लग रहा था, लेकिन संकुचित फ़ाइलों के साथ अनुभव के बाद, मुझे अभी भी संदेह पैदा हुआ। बस मामले में, मैंने एक दर्जन फाइलों को देखा, और हर जगह मैंने एक ही तीन को देखा, इस पर शांत। शीर्षक दो शून्य मानों के साथ समाप्त हुआ, जिसे मैंने आरक्षित क्षेत्रों में लिखा था, जो अक्सर द्विआधारी स्वरूपों में पाए जाते हैं।

 struct Header { uint32 signature; uint32 version; uint32 langCount; uint32 stringsCount; uint32 reserved1; uint32 reserved2; }; 

मुझे भाषा पहचानकर्ताओं की एक सूची मिली। इसके बाद, तार्किक रूप से, लाइन ऑफ़सेट्स की एक तालिका का पालन किया जाता है, और फिर खुद को लाइनें। खैर, आपको यह बात उठानी होगी। फ़ाइल में छह भाषाएं और दो लाइनें हैं, लेकिन तालिका में 12 नहीं हैं, लेकिन 18 मान हैं - इसका मतलब है कि प्रत्येक भाषा के लिए दो लाइनों के लिए ऑफसेट के अलावा एक अतिरिक्त मूल्य है।

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

 struct OffsetTable { uint32 totalStringsLength; uint32 stringOffsets[header.stringCount]; }; 

यह एक deserializer लिखने का समय है। यूरोपीय भाषाओं के पाठ से, यह स्पष्ट था कि UTF-8 का उपयोग किया गया था। उस समय, मैं बहुत पहले डेल्फी से सी ++ तक नहीं गया था, और डेल्फी पर कुछ घटनाक्रमों के कारण, साथ ही वीसीएल में ज्ञान और एसटीएल के केवल सतही ज्ञान के कारण, मैंने अक्सर डेल्फी में टूलकिट का हिस्सा लिखकर पाप किया। उसी डेल्फी के बाद से मेरे पास एक पुरानी सिद्ध लाइब्रेरी थी जिसमें पाठ को आसानी से पढ़ने योग्य और आसानी से संपादन योग्य प्रारूप में रखा गया था, मैंने इस तकनीक का भी सहारा लेने का फैसला किया। मेरी शर्म की बात है, हालांकि मैंने OOP और सभ्य कोडिंग के अन्य लाभों का सहारा लेने की कोशिश की, लेकिन मुझे अक्सर एक नूडल-जैसे कोड के साथ पाप किया जाता है, इसलिए इस लेख को लिखते समय मुझे कुछ विवरण याद रखने में कठिनाई हुई।

सामान्य तौर पर, UTF-8 डिकोडिंग के लिए आवश्यक WinApi दस्तावेज़ीकरण खंड का अध्ययन किया गया था, डीसेरलाइज़र लिखा गया था और, एक छोटी डीबगिंग के बाद, इसे तैयार फ़ाइल पर परीक्षण किया गया था। महान, यह खेल स्क्रिप्ट निकालने का समय है! मैंने सभी उपलब्ध एसटीजी फाइलों को अभिलेखागार से निकाला और उन पर डिसेरिज़लाइज़र सेट किया ... निश्चित रूप से, मैं पकड़ के लिए इंतजार कर रहा था, और वह था। कुछ मैंने ध्यान में नहीं लिया, और फिर से एक दुर्घटना को पकड़ लिया।

मैंने समस्या फ़ाइल को खोला और देखा कि मैं उत्साहित हो गया, कुछ हेडर फ़ील्ड को आरक्षित के रूप में चिह्नित किया।


पसंद 0, पसंद 1 ... क्यों, ये रेखा पहचानकर्ता हैं! इसलिए, कुछ पहचानकर्ताओं को कुछ पंक्तियों को सौंपा जा सकता है ताकि उन्हें सूचकांक द्वारा नहीं, बल्कि इन पहचानकर्ताओं द्वारा एक्सेस किया जा सके। पहले "आरक्षित" क्षेत्र इन पहचानकर्ताओं की संख्या निकला, और फिर अगले अनुभाग का आकार।

 struct Header { uint32 signature; uint32 version; uint32 langCount; uint32 stringCount; uint32 idCount; uint32 idsSectionSize; }; 

अनुभाग की शुरुआत में एक तालिका थी, जो ऑफ़सेट्स और पंक्ति सूचकांकों का एक अपूर्ण सरणी बन गई थी, जिसके लिए ये पहचानकर्ता अभिप्रेत हैं। तालिका के बाद पहचानकर्ताओं द्वारा स्वयं को शून्य-समाप्त स्ट्रिंग्स के रूप में देखा गया।

 struct IdRecord { uint32 offset; uint32 index; }; 

नए डेटा के अनुसार डिसेरिएलाइज़र को ठीक करने और फिर से प्रक्रिया शुरू करने का समय है। इस बार समस्याओं के बिना समस्याग्रस्त फाइलें निगल ली गईं और प्रगति आगे बढ़ गई। मैं पहले से ही जीत का जश्न मनाने की तैयारी कर रहा था, लेकिन किए गए काम के साथ संतुष्टि की मेरी भावना अचानक एक और दुर्घटना से बाधित हो गई ... ठीक है, इसकी आदत न डालें। मैं मानक प्रक्रिया को फिर से दोहराता हूं, समस्या फ़ाइल को हेक्स संपादक में खोलता है।


फिर भी, मैं हेडर फ़ील्ड के साथ गलत नहीं था जो प्रारूप के संस्करण को संग्रहीत करता है। लेकिन मुझे नहीं लगता कि आमतौर पर अन्य संस्करणों का उपयोग खेल द्वारा किया जाता है। मुझे इस संस्करण को भी अलग करना पड़ा, क्योंकि यह काफी सरल था।

हेडर के पहले 16 बाइट्स पहले से खोजे गए प्रारूप के समान थे। फिर तुरंत भाषाओं के बारे में जानकारी का पालन किया, लेकिन थोड़ा अलग रूप में।

 struct LangSectionRecord { char langId[4]; uint32 offset; uint32 size; }; 

और उसके बाद, हेडर के अंतिम 8 बाइट्स और समान स्वरूप में पहचानकर्ता अनुभाग का पालन किया। तो, उस प्रारूप में, ये 8 बाइट्स हेडर का हिस्सा नहीं थे।

अनुसरण करने वाले अंतिम खंड भाषा डेटा थे। प्रत्येक खंड की शुरुआत में लाइन ऑफ़सेट्स की एक सूची थी। इस बार स्वयं स्ट्रिंग्स को यूनिकोड में संग्रहीत किया गया था और केवल लंबाई निर्दिष्ट किए बिना, इसे शून्य-समाप्त कर दिया गया था।

 struct LangData { uint32 offsetTable[header.langCount]; uint32 size; }; 

मैंने इस प्रारूप के लिए समर्थन जोड़ा और पिछली बार के लिए डिसेरिएलाइज़ेशन प्रक्रिया को फिर से लॉन्च किया। अब सब कुछ सुचारू रूप से काम कर रहा था और मेरे हाथों में मेरे पास एक खेल स्क्रिप्ट थी।

फोंट

ग्रंथों को समीक्षा के लिए डंगार्ड भेजा गया था, और यह फोंट की बारी थी। मैंने पहले टाइप फॉंट के साथ कुछ फाइलों पर ध्यान दिया, और मुझे इसमें कोई संदेह नहीं था कि वे खुद में फोंट स्टोर करते हैं।


आमतौर पर, फोंट में दो घटक होते हैं: एक रेखापुंज और इस रेखापुंज को प्रदर्शित करने के तरीके के बारे में जानकारी। लेकिन, फ़ाइल को देखने के बाद, मुझे एहसास हुआ कि इसमें कोई रेखापुंज नहीं है। और इसका मतलब है कि इसे अलग से संग्रहीत किया जाना चाहिए - उदाहरण के लिए, बनावट में। इसलिए, रेखापुंज के किसी भी संदर्भ के संकेतों को खोजना आवश्यक था।

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

हेडलाइन बुद्धिमान थी, और मैंने इसे बाद में छोड़ने का फैसला किया। फ़ॉन्ट नाम और बनावट हैश से थोड़ा आगे, पहले उल्लेख किया गया था, जिसमें कुछ आवधिकता का पता लगाया गया था। अधिक बारीकी से देखने के बाद, मैंने हेक्स संपादक विंडो की आवश्यक चौड़ाई को उठाया और देखा कि यह संरचनाओं की एक सरणी थी।


पहले क्षेत्र को देखते हुए, जहां, एक शक के बिना, प्रतीक कोड संग्रहीत किए गए थे, यह ग्लिफ़ के बारे में जानकारी है। सरणी से पहले, इसका आकार शास्त्रीय रूप से स्थित था। मैंने संरचनाओं के इस सरणी में विशेषता तत्वों की खोज करना शुरू किया, और पहली चीज जो मैंने देखी वह मानक IEEE 754 प्रारूप में चार स्पष्ट रूप से भेद करने योग्य फ्लोट मान थी। वे 3 डी, 3 ई, 3 एफ बाइट्स और 4 बाइट्स के अंतराल के साथ अन्य समान मूल्यों की उपस्थिति के साथ प्रारूप संरचना के कारण अलग-अलग हैं - फ्लोटिंग पॉइंट संख्याओं के एक बड़े संचय के साथ, यह पैटर्न याद रखना मुश्किल है। मान स्वयं 0 से 1 तक थे और यह स्पष्ट हो गया कि ये बनावट निर्देशांक हैं। मैं बनावट को देखे बिना शेष मूल्यों के शब्दार्थ को निर्धारित नहीं कर सकता था, इसलिए मैंने रेखापुंज को समझना शुरू किया।

बाद में TXTR संरचना के विश्लेषण को स्थगित करते हुए, मैंने बस रेखापुंज का पता लगाने और उसे संसाधित करने का निर्णय लिया। ऐसे मामलों में, मैं हमेशा पहले यह जांचता हूं कि क्या रेखापुंज अनुक्रमणित रंगों के साथ छवि के मामले में रंगों या अनुक्रमित का एक सामान्य सरणी है। और इसलिए, टाइल संपादक में फ़ाइल को खोलने और रंग का चयन करने के बाद, मैंने एक दिलचस्प तस्वीर देखी।


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



प्रत्येक परत एक बनावट एटलस थी - अर्थात। इस पर कई ग्लिफ़ थे, और अभिलेखों में ग्लिफ़ पात्रों के अनुरूप यूवी-निर्देशांक दर्शाए गए थे ।

फ़ॉन्ट संपादकों के लिए, मेरे पास लंबे समय से डेल्फी पर एक रिक्त स्थान था, जो 2006 में एक "सहयोगी" से एक और वर्ष में विरासत में मिला था। मैंने जल्दी से रैस्टर डिकोडर को स्केच किया और फ़ॉन्ट को लोड करने की कोशिश करना शुरू कर दिया, ग्लिफ़ संरचनाओं में खेतों की अलग-अलग व्याख्या की। कई दिनों के प्रयोगों के बाद, मेरे पास कुछ विचार था और यहां तक ​​कि काफी सफलतापूर्वक फ़ॉन्ट डाउनलोड किया गया।


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

सामान्य तौर पर, तस्वीर धीरे-धीरे साफ हो गई, और लगभग हर चीज ग्लिफ़ के बारे में जानी जाने लगी।

 struct Rect { float left; float top; float right; float bottom; }; struct CharRecord { wchar_t code; Rect glyphRect; uint8 layerIndex; uint8 leftIdent; uint8 ident; uint8 rightIdent; uint8 glyphWidth; uint8 glyphHeight; uint8 baselineOffset; uint16 unknown; }; 

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

 struct Header { uint32 maxCharWidth; uint32 fontHeight; uint32 unknown1; uint32 unknown2; uint32 unknown3; uint32 unknown4; uint16 unknown5; uint32 unknown6; char fontName[]; uint64 textureHash; uint32 textureColorCount; uint32 unknown7; }; 

यह सब लगता है, यह फ़ॉन्ट को बचाने का काम करने का समय है, लेकिन यहां मैंने एक अजीब जोड़ देखा, जो फ़ाइल के अंत में संग्रहीत है।


कुछ मान कुछ जोड़े वर्णों से जुड़े थे, सबसे अधिक बार 0, 1 और -1 ... टाइपोग्राफी के विशेषज्ञों ने शायद पहले ही अनुमान लगा लिया था कि यह क्या था, लेकिन मैं अभी समझ में नहीं आया और विषयगत मंच पर विषय भी उठाया। लेकिन जल्द ही मुझे लगता है करने के लिए शुरू किया, और Googling, वांछित परिभाषा पर ठोकर खाई ... हाँ, यह था कर्निंग पिक्सेल में।

 struct KerningRecord { wchar_t first; wchar_t second; int32 kerning; }; 

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

अब इस तरह के एक फ़ॉन्ट के संरक्षण को व्यवस्थित करना संभव था। मैंने जोखिम नहीं उठाए और बनावट के आकार में वृद्धि हुई, इसलिए यहां मुख्य समस्या सीमित क्षेत्र में सभी ग्लिफ़ों की नियुक्ति थी। मैंने कर्निंग के विषय में पूछा कि क्या किसी को इसके लिए एक सरल एल्गोरिथ्म पता था, और जवाब में मुझे लाइटिंग मैप्स पैकिंग के बारे में gamedev.ru पर एक लेख का लिंक दिया गया था । यह वही था जिसकी आवश्यकता थी, और एल्गोरिथ्म के कार्यान्वयन के बाद, फोंट को बचाया जा सकता था।

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

तो अगला प्रारूप मेरी उंगलियों पर गिर गया, और इस पर आप बनावट के अध्ययन में बारीकी से संलग्न हो सकते हैं।

पेश है बनावट

खेल में बड़ी संख्या में बनावट शामिल नहीं थी जो अनुवाद की आवश्यकता थी, लेकिन उस समय मुझे यह पता नहीं था और सबसे खराब स्थिति को ध्यान में रखते हुए काम किया। निकाली गई TXTR फ़ाइलों में चारों ओर घूमते हुए, मुझे एहसास हुआ कि फ़ॉन्ट बनावट एक पतित मामला है, और अधिकांश बनावट अनुक्रमित रंगों का उपयोग नहीं करते हैं।


आकार में 12 बाइट्स के हेडर को पार्स करना मुश्किल नहीं था। पहला मान शायद एक बनावट प्रकार की संख्या थी, क्योंकि यह अनुक्रमित रंगों के साथ बनावट के लिए अलग था। 640 और 480 के मूल्यों का पालन किया गया - निश्चित रूप से बहुत परिचित संख्याएं, सही? सामान्य तौर पर, मुझे संदेह नहीं था कि क्या शीर्षक में अनुमति थी, लेकिन बाद के मूल्य का उद्देश्य इतना स्पष्ट नहीं है। लेकिन मैं यह शपथ लेने के लिए तैयार था कि यह कई मामलों में पाए जाने वाले रिप्लेसमेंट स्तरों की संख्या है ।

 struct TextureHeader { uint32 type; uint16 width; uint16 height; uint32 mipmapCount; }; 

शीर्षक का अध्ययन किया गया था, लेकिन मुख्य समस्या रेखापुंज प्रारूप की परिभाषा थी। सौभाग्य से, एक नेत्रहीन समान संरचना मेरे लिए बहुत परिचित थी - यह निश्चित रूप से S3TC परिवार से एक एल्गोरिथ्म था , डीडीएस कंटेनर और डीएक्सटीएन एल्गोरिदम के साथ कई परिचित थे । ये प्रारूप वीडियो मेमोरी में संपीड़ित बनावट के उपयोग के लिए हैं और ऐसा लगता है कि Wii और Gamecube दोनों हार्डवेयर समर्थित हैं। इसलिए, डायरेक्टएक्स के साथ जुड़ाव के बावजूद, यहां कुछ भी आश्चर्यजनक नहीं है।

एक विशिष्ट एल्गोरिथ्म को निर्धारित करना मुश्किल नहीं था: इन सभी प्रारूपों में एक कड़ाई से निश्चित संपीड़न अनुपात होता है, और, संपीड़ित एक को मूल रेखापुंज के आकार के अनुपात के आधार पर, यह 8: 1 (या 6: 1 अल्फा चैनल को ध्यान में रखे बिना), यह केवल DXT1 हो सकता है। यह केवल अनुमानों को सुनिश्चित करने का समय है, और मैंने बनावट से उधार लेने वाले के साथ रेखापुंज की जगह एक ही प्रारूप और संकल्प की एक डीडीएस छवि बनाई है। लेकिन परिणामस्वरूप फ़ाइल खोलने पर मुझे जो मिला वह पूरी तरह से सार्थक छवि नहीं थी ...


यह ब्रेनवॉश करने का समय है। चूंकि आउटपुट छवि से मिलता-जुलता कुछ है, इसलिए यह स्पष्ट था कि यह अभी भी डीएक्सटी 1 था, लेकिन बदल गया। दो कारक दिमाग में आए जो प्रारूप को प्रभावित कर सकते हैं: बाइट ऑर्डर और टाइल बनावट संरचना। लेकिन, इसे सत्यापित करने के लिए, मुझे स्वयं डिकोडिंग प्रक्रिया को नियंत्रित करने की आवश्यकता थी, और इस उद्देश्य के लिए मैंने कुछ पुस्तकालय की तलाश शुरू कर दी।

सौभाग्य से, मैं समय में एक अद्भुत खुला स्रोत पुस्तकालय भर में आया था - NVIDIA बनावट उपकरण। समस्याओं के बिना नहीं, लेकिन मैं अभी भी अपने उद्देश्यों के लिए इसके कोड को अनुकूलित करने में सक्षम था, और प्रयोग करना शुरू कर दिया। सबसे पहले, पहला अनुमान सही निकला, जबकि एक अलग क्रम में यह बाइट्स नहीं था, लेकिन पूरे शब्द, साथ ही साथ उनमें बिट्स भी थे। उनकी पुनर्व्यवस्था के साथ कुछ जोड़तोड़ के बाद, छवि ने अधिक पर्याप्त रूप ले लिया।


मुझे एहसास हुआ कि मैं टाइल संरचना के बारे में गलत नहीं था। लेकिन, यह देखते हुए कि डीएक्सटी 1 स्वयं 4x4 ब्लॉकों में एन्कोडेड है, मैं केवल आंशिक रूप से सही था: यहां टाइलों के कुछ स्विज़लिंग का उपयोग किया गया था, अर्थात। उन्हें एक निश्चित मैट्रिक्स में पुनर्व्यवस्थित किया गया था। खैर, ज़ाहिर है, छवि उलटी थी।

मैं अपने मस्तिष्क को तनाव देने और मैट्रिक्स को बहाल करने के लिए बहुत आलसी था, और मैंने लंबे समय से तैयार किए गए पथ को ले लिया - निर्देशांक के अनुवाद के लिए सूत्रों का चयन करने की कोशिश कर रहा था। ईमानदारी से, मुझे नहीं पता कि मैंने यह कैसे किया है, लेकिन मैंने इस मैट्रिक्स में पैटर्न की उपस्थिति को देखते हुए, अंतर्ज्ञान द्वारा और अभिनय किया, जो कि मेरी अवचेतना मेरी भागीदारी के बिना महसूस कर सकती थी, अंत में यह काम कर गया। और आखिरकार, मुझे मूल छवि मिली।


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

पहले नमूने

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

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

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

जब आवश्यक कार्यक्षमता तैयार हो गई, तो मैंने खेल में परिवर्तित डेटा के साथ संग्रह को खिलाकर अपनी किस्मत आजमाने का फैसला किया। पहले से उल्लेख किए गए WiiScrubber को लेना और कम से कम शक्तिशाली अभिलेखागार में से एक का पुनर्निर्माण करना, मैंने इसे बदलने की कोशिश की। लेकिन मैं निराश था: मूल फ़ाइल का आकार पार हो गया था। छवि के पुनर्निर्माण की समस्याओं से निपटने के लिए मैं वास्तव में कम से कम चाहता था, इसलिए मैंने वर्कअराउंड की तलाश शुरू कर दी। और मैंने उन्हें पाया: समाधान फोंट के मामले में मेरे द्वारा उपयोग किए जाने के समान था। चूंकि मुझे अन्य भाषाओं के डेटा में कोई दिलचस्पी नहीं थी, इसलिए मैंने पुनर्निर्माण फ़ंक्शन में एक फ़ाइल के मैपिंग को दूसरे में सेट करने की क्षमता जोड़ी। यानीयदि अगली फ़ाइल को संसाधित किया जा रहा है, तो उसे प्रदर्शन के लिए चिह्नित किया गया था, तो उसकी सामग्री कहीं भी नहीं लिखी गई थी, और केवल फ़ाइल तालिका में इसकी प्रविष्टि प्रभावित हुई थी - लक्ष्य फ़ाइल के ऑफसेट और आकार से बदल गई थी। इस प्रकार, उदाहरण के लिए, मैंने विभिन्न भाषाओं में प्रारंभिक स्क्रीन की छवियों के सभी संस्करणों को "एकल मैप" किया - अंग्रेजी बोलने वाले, जिन्हें रूसी-भाषी बनने के लिए किस्मत में था।

मैंने फिर से संग्रह को फिर से बनाया है, और इस बार यह फिट है। और इसलिए मैंने बदले हुए संसाधनों के साथ खेल का पहला टेस्ट रन बनाया ... मैंने यह नहीं कहा कि सब कुछ सरल और फ्रीज के बिना हो गया - मैंने गलत बाइट ऑर्डर का उपयोग किया, मैं LZO में पैकिंग करते समय भाग के बारे में भूल गया, और फोंट और पाठ के लिए समस्याएं थीं, लेकिन अंत में सब कुछ डिबग हो गया और खेल ने स्पष्ट समस्याओं के बिना आश्वस्त संग्रह को निगल लिया। हुर्रे, यह काम किया: मैंने रूसी पाठ देखा। लेकिन यह सड़क के अंत से बहुत दूर था, बहुत कुछ किया जाना था।

प्रक्रिया संगठन

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

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

ठीक है, यदि ऐसा है, तो आपको एक ओपन सोर्स प्रोजेक्ट और आवश्यक क्षमताओं के निकटतम लोगों की तलाश करने की आवश्यकता है। सबसे पहले, मेरी नजर डॉल्फिन पर पड़ी- एक अद्भुत और सिर्फ मौजूदा एमुलेटर गेमक्यूब और Wii। बेशक, वह जानता है कि छवियों के साथ कैसे काम किया जाए, इसलिए मैंने उसका स्रोत कोड डाउनलोड किया और उनका अध्ययन करना शुरू किया। लेकिन वास्तुकला काफी जटिल हो गई, और मैंने विकल्पों की तलाश करने का फैसला किया। अचानक मेरे पास एक विचार आया, और मैंने "Google WiiScrubber स्रोतों" में काम किया ... बिंगो! वे मौजूद हैं!

मुझे कहना होगा, यह परियोजना के इतिहास में सबसे कठिन चरणों में से एक की शुरुआत थी। अगर मुझे यह पता होता, तो मैं खुद बैठकर सबकुछ लिखता। अपनी आवश्यकताओं के लिए बहुत ही संकीर्ण रूप से लक्षित कोड को अपनाने से बदतर कुछ भी नहीं है। यही कारण है कि व्यवहार में मैंने पैटर्न का पालन करने और कोड संस्कृति का पालन करने के महत्व और आवश्यकता को पूरी तरह से महसूस किया। आखिरकार, मुझे शाब्दिक रूप से चित्रमय इंटरफ़ेस से कार्यक्षमता को काटना पड़ा। कोड को MFC का उपयोग करके लिखा गया था, और तर्क को GUI में एकीकृत किया गया था, जहां, इसके अलावा, कुछ डेटा संग्रहीत किया गया था - उदाहरण के लिए, फ़ाइल ऑफ़सेट्स को TreeCtrl पाठ नोड्स से पार्स किया गया था। मुझे संस्थाओं को बदलना पड़ा और नकली वर्गों को नियंत्रण में लिखना पड़ा, ताकि सब कुछ किसी तरह इकट्ठा हो जाए और काम किया जाए। नहीं-तो-साफ कोड के साथ, यह बैसाखी, गंदे हैक्स और एंटीपार्टर्न के खूनी गड़बड़ में बदल गया,जो जल्द ही या बाद में उखड़ना होगा।

हालांकि, लक्ष्य हासिल कर लिया गया था। कोड से खून बह रहा था, लेकिन मैंने अपना काम किया - मुझे प्रोग्राम को फ़ाइलों को गेम में बदलने का अवसर मिला। अब खेल में डेटा डालने के लिए आंतरिक उपयोगिता लिखना आवश्यक था। और चूंकि यह न केवल मेरे लिए इसका उपयोग करने के लिए था, मुझे इसे एक सरल और सहज चित्रमय इंटरफ़ेस के साथ बनाना था। मैं वास्तव में MFC या WinApi के सभी प्रकार के चौखटे से निपटने या चढ़ाई करने के लिए नहीं चाहता था, इसलिए मैंने VCL में अपने ज्ञान का पुन: उपयोग करने का निर्णय लिया। मैंने बोरलैंड C ++ बिल्डर 6.0 लिया और लिखना शुरू किया।

मुझे कहना होगा, इस आईडीई से इस प्रक्रिया में कुछ सकारात्मक भावनाएं थीं। मुझे नहीं पता कि गलती क्या है, लेकिन परियोजना के पूर्ण पुनर्निर्माण के बिना, कार्यक्रम हर बार भी शुरू नहीं हुआ। इसके अलावा, निरंतर "श्रोडिंगबैग" ने मुझे त्रुटि की जगह को स्थानीय बनाने की अनुमति नहीं दी, जिसके परिणामस्वरूप मुझे लगातार सभी डरावनी घटनाओं की समीक्षा करनी पड़ी जो मुझे पहले बनानी थी। मुझे कोड पर काम करना था ताकि बोरलैंड इसे समझ सके।

संकलन मुद्दों से निपटने के बाद, मैं कार्यक्षमता के मुद्दों पर लौट आया। फाइलों को जल्दी और कम अनावश्यक रूप से बदलने की प्रक्रिया को संभव बनाने के लिए, आपको प्रतिस्थापन के लिए विशिष्ट फ़ाइलों का चयन करने की क्षमता को कसना होगा। अभिलेखागार की सामग्री के आधार पर, मैंने निर्धारित किया कि किस स्थान पर किसका उपयोग किया जाता है, और संबंधित नोटों के साथ अभिलेखागार की एक सूची बनाई। अब, खेल मेनू में पाठ की जांच करने के लिए, सब कुछ और सब कुछ के एक पूरे आश्वस्त का सहारा लेना आवश्यक नहीं था।

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

बहुत कम से कम, अनुवाद को "असेंबल" करने की प्रक्रिया स्वचालित थी। अब अनुवादक के लिए जीवन को आसान बनाना आवश्यक था। मैंने देखा कि अलग-अलग नामों (अधिक सटीक, हैश) वाली कई फ़ाइलों में एक ही सामग्री है, अर्थात्। पाठ बहुत बार दोहराया गया। इसलिए, आउटपुट टेक्स्ट फ़ाइलों में, मैंने ऐसे सभी डुप्लिकेट को एक में "ढह" दिया, उन्हें समग्र नाम दिया। और जब क्रमबद्ध, यह सिर्फ एक के बजाय फ़ाइलों का एक गुच्छा निकला।

फिर मैंने पाठ में तकनीकी डेटा की प्रचुरता पर ध्यान आकर्षित किया। टैग्स की विशाल संख्या के कारण यह मानव आंखों के लिए अपठनीय था।


सौभाग्य से, मुझे ऐसी समस्याओं को पहले ही हल करना था, और मैंने नोटपैड ++ के सिंटैक्स के विवरण के साथ एक एक्सएमएल-फाइल को स्केच किया। यह बहुत सुविधाजनक था कि डंगार्ड ने इसमें पाठ का अनुवाद किया था, क्योंकि वर्ड और अन्य पाठ अपने स्वयं के ऑटो-रिप्लेसमेंट और अन्य चीजों के साथ मिलकर बहुत सारी समस्याएं पैदा कर सकते हैं। इन जोड़तोड़ के बाद, पाठ को समझना बहुत सरल हो गया - समस्या हल हो गई।


बाद में इसने पाठ के साथ थोड़ा और भ्रम पैदा किया। डंगार्ड ने मुझसे पूछा - स्थान के नामों की एक शब्दावली रखने और हर जगह अनुवाद में इसका उपयोग करने के लिए अविश्वसनीय रूप से उबाऊ था, इसलिए मुझे इस प्रक्रिया को स्वचालित करने की आवश्यकता थी। मैंने एक प्रोग्राम को स्केच किया, जिसमें एक ग्लोसरी के साथ एक फ़ाइल पढ़ी, पाठ के साथ पार्स की गई फाइलें, और अगर लाइन पूरी तरह से ग्लॉज़री के तत्व के अनुरूप थी, तो इसे अनुवादित संस्करण के साथ बदल दिया।

अनुवाद अच्छी तरह से हो गया और डंगार्ड ने तकनीकी पाठ के बड़े संस्करणों का अनुवाद करते हुए बैटन को रोक दिया।

काल्पनिक खत्म

समय बीतता गया, प्रगति स्थिर नहीं रही। और अब, कुछ बिंदु पर, डंगार्ड ने गेम पत्रिका के अनुवाद के पूरा होने पर रिपोर्ट की - पाठ का सबसे जटिल और चमकदार हिस्सा, क्योंकि यह वहां था कि लगभग सभी खेल वस्तुओं का वर्णन था और उनके अधिक विस्तृत विचार के लिए मिनी-लेखों का एक व्यापक संग्रह था। यह निस्संदेह अनुवाद के पूरा होने की दिशा में प्रगति का एक पूर्वसर्ग था।

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

थोड़ा और समय बीत गया, और इस तरह के दूर के काम के पूरा न होने की आशंका पहले से ही थी। परियोजना से बहुत थक गए, हमने पहले से ही परीक्षकों के एक सेट की घोषणा करने का फैसला किया। तथ्य यह है कि हमें कुछ समस्या मिली: हमारे अनुवादित पाठ हमेशा निर्दिष्ट स्क्रीन स्पेस में फिट नहीं होते हैं, और इस संबंध में, हमने तय किया कि जितनी जल्दी हम ऐसी जगहों का पता लगाने और उन्हें सही करना शुरू करेंगे, उतना ही यह सभी के लिए बेहतर होगा। आखिरकार, जितना अधिक समय बीत गया, कम उत्साह हमारे डिब्बे में बना रहा।

यह निराशाजनक था कि केवल एक व्यक्ति ने कॉल का जवाब दिया। कुछ भी उतना नहीं है जितना एहसास है कि आपके काम की इतनी मांग नहीं है, और काम कम खुशी के साथ जारी है। स्थिति को खेल में छवियों को बदलने के लिए समस्याग्रस्त कोड को पुन: सक्रिय करने की आवश्यकता से बढ़ गया था, क्योंकि यदि यह आंतरिक उपयोग के लिए उपयुक्त था, तो विवेक ने इसे उत्पादन में जारी करने की अनुमति नहीं दी। एक और रोक कारक एक पैच बनाने की आवश्यकता थी जो आवश्यकताओं को पूरा करता है।

किसी और ने जवाब नहीं दिया, और हमारे मामले की परिस्थितियों के वजन के तहत, वे क्षय में गिर गए और सब कुछ गिर गया, जैसा कि अक्सर होता है। ऑपरेशन को वापस करने के लिए कई प्रयास किए गए थे, लेकिन थोड़े समय के लिए पर्याप्त उत्साह नहीं था। एक बार, आवाज अभिनय के अपने सपनों में, मैंने उस प्रारूप को भी छांटा जिसमें भाषण की ध्वनि संग्रहीत की गई थी - ये एफएमओडी पुस्तकालय के संस्करणों में से एक के कंटेनर थे । हालांकि, मैं एक पूर्ण ध्वनि नहीं प्राप्त कर सका, लेकिन यह कठिनाई की बात नहीं है, लेकिन आवश्यकता की कमी के कारण - मुझे शुरू में पता था कि आप अपने घुटने पर एक अच्छी आवाज अभिनय नहीं कर सकते।

दूसरी हवा

तब से दो साल बीत चुके हैं। इस दौरान मुझे नौकरी मिली, विश्वविद्यालय से स्नातक किया और अपनी विशेषता में बहुत कुछ नया अनुभव प्राप्त किया। दुर्भाग्य से, लापरवाह समय बीत चुका है और काम के बाद मेरे शौक के लिए बहुत कम समय और प्रयास बने हुए हैं। लेकिन इस समय, अंतरात्मा को इस विचार से सताया गया था कि हमारे पास अधूरी परियोजनाएं हैं जो कभी समाज के लिए वादा किया गया था। सोचा "आवश्यक" मेरे सिर में मंडराया, लेकिन जैसे ही यह बात सामने आई, यह स्पष्ट हो गया कि यह विचार अकेले पर्याप्त नहीं था। डंगार्ड ने समय-समय पर कुछ का अनुवाद किया और मुझ पर एक छड़ी लहराई, जिससे मुझे भी चिंता हुई।

कुछ बिंदु पर, मैंने फिर से अपने घटनाक्रम को देखा, और फैसला किया कि कुछ को बदलना होगा। और मैंने सब कुछ बदलना शुरू कर दिया, किसी भी पर्याप्त व्यावसायिक प्रक्रिया के लिए आवश्यकताओं के अनुसार सब कुछ लाने की कोशिश की। सबसे पहले, पुनर्गठन ने डेटा समन्वय की हमारी विधि का संबंध किया। इन उद्देश्यों के लिए ड्रॉपबॉक्स का उपयोग करना अच्छा नहीं था, और मैंने संस्करण नियंत्रण प्रणालियों की ओर देखना शुरू किया। कोई फर्क नहीं पड़ता कि वे क्या कहते हैं, लेकिन मुझे तोड़फोड़ पसंद है, इसलिए मैंने एक होस्टिंग साइट पर एक svn रिपॉजिटरी बनाई और वहां डेटा ट्रांसफर करना शुरू कर दिया।

तुरंत एक समस्या सामने आई। पाठ यूनिकोड में संग्रहीत किया गया था, क्योंकि नोटपैड ++ ने हमेशा सही ढंग से यूटीएफ -8 को नहीं बचाया, जिससे समय-समय पर कुछ पात्रों को नुकसान पहुंचा। शायद BOM की उपस्थिति के कारणएसवीएन ने फाइलों को बाइनरी के रूप में मान्यता दी है, इसलिए मुझे पाठ प्रकार की सामग्री को मैन्युअल रूप से सेट करना पड़ा। इन जोड़तोड़ के बाद, पाठ को समस्याओं के बिना माना जाता था, लेकिन तब समस्याएं थीं - संस्करण की तुलनात्मक उपयोगिताओं ने यूनिकोड का अनुभव नहीं किया, या जब विरोध उत्पन्न हुआ, तो संबंधित पाठ लेबल को एएनएसआई पाठ के रूप में फाइलों में लिखा गया था। लेकिन कुछ बदलने के लिए बहुत देर हो चुकी थी, और इस तरह की समस्याएं अक्सर पैदा नहीं होती थीं, इसलिए सब कुछ जैसा था वैसा ही रह गया।

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

उत्पादन के अनुभव के डेढ़ साल के लिए, मुझे वास्तव में क्यूटी से प्यार हो गया, इसलिए इसे यहां उपयोग करने का निर्णय लिया गया। सभी आवश्यक परियोजनाएं तुरंत बनाई गईं और काम उबलने लगा। पहले तो मैंने परीक्षण के साथ फिर से लिखा सब कुछ कवर किया, लेकिन फिर मैं इससे थक गया और मैंने आउटपुट की शुद्धता पर ध्यान देने का फैसला किया, न कि कोड की शुद्धता पर।

फ़ॉन्ट संपादक और पाठ धारावाहिक के अपवाद के साथ सभी उपकरण फिर से लिखे गए थे - उन्होंने काम किया और ठीक से काम किया, और अब तक, कहीं भी इस कार्यक्षमता को पेश करने की आवश्यकता नहीं थी। थोड़ी देर के बाद, मेरे हाथ उस खूनी गंदगी तक पहुंच गए जिसे मुझे छवि में फ़ाइलों को बदलने की संभावना के लिए प्रजनन करना पड़ा। एक दर्जन के आने के बाद, इस कोड ने कम से कम कुछ रूप धारण कर लिया, और मैं पहले से ही इसका इस्तेमाल करने के लिए एक पैचर बनाने में खर्च कर सकता था। इसके बाद, VCL के बजाय Qt का उपयोग करके डेटा सम्मिलित पूरी तरह से फिर से लिखा गया था।


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

विचार मुझे पहले से ही मिलने लगे हैं, लेकिन क्या मैं केवल उन कोड और डेटा को काट सकता हूं, जिनकी मुझे पुस्तकालयों से आवश्यकता नहीं है? और मैंने यहां हेबेरा पर एक सवाल पूछा । मेरी उम्मीद जायज थी - मिखाइलएडॉशिन ने मुझे यह कहकर बचाया कि MSVC में झंडे हैं जो कोड को एक विशेष तरीके से संकलित करने और लिंकर को अप्रयुक्त डेटा को काटने की अनुमति देते हैं। इस तरीके को आजमाने के बाद, मुझे एहसास हुआ कि यह बहुत अच्छा काम करता है।

मैंने एक पैचर प्रोजेक्ट बनाया और इसे विकसित करना शुरू किया। अगर दो साल पहले मैं इसकी गुणवत्ता को किसी हैकर शिल्प की याद ताजा करना चाहता था, तो अब यह एक ठोस इंस्टॉलर देखने की इच्छा थी जो लेखकों को संभावित कानूनी समस्याओं से अधिकतम तक की रक्षा करेगा। इसलिए मैंने QWizard लिया और इंस्टॉलर की सर्वश्रेष्ठ परंपराओं में इसके आधार पर एक पैचर बनाना शुरू किया।


ऐसा लगता है कि सब कुछ ठीक हो गया, लेकिन जल्द ही एक अप्रिय समस्या पैदा हुई ...

अप्रत्याशित फ्रीज

कुछ बिंदु पर, मुख्य मेनू के बाद खेल लटकने लगा। यह भयानक था, क्योंकि इससे पहले कि सब कुछ काम करता था और कुछ भी लटका का कारण हो सकता है। WiiScrubber के माध्यम से अभिलेखों को प्रतिस्थापित करना एक ही प्रभाव देता है, इसलिए मैं विशेष रूप से पैच को दोष नहीं दे सकता।

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

सार को प्रकट करने के लिए, आपको सबसे पहले Wii डिस्क डिवाइस के बारे में थोड़ा बताना होगा। जबकि एक नियमित डीवीडी को आकार में 2048 बाइट्स के क्षेत्रों में विभाजित किया गया है, एक Wii डिस्क को 0x8000 बाइट्स में क्लस्टर किया गया है। क्लस्टर्स, बदले में, 0x400 बाइट्स के आकार और 0x7C00 बाइट्स के डेटा के हेडर से मिलकर बनता है। समूहों को स्वयं आठ टुकड़ों के उपसमूहों में बांटा गया है, जिन्हें बाद में आठ उपसमूहों के समूहों में बांटा गया है। क्लस्टर हैडर में हैश, हैश की हैश, और हैश की हैश की हैश ... सामान्य तौर पर, पहले चीजें होती हैं।

 typedef uint8 Hash[20]; struct ClusterHeader { Hash h0[31]; uint8 padding0[20]; Hash h1[8]; uint8 padding1[32]; Hash h2[8]; uint8 padding2[32]; }; struct Cluster { ClusterHeader header; uint8 data[0x7C00]; }; 

सबसे पहले, हेडर में 31 वें SHA1 हैश से एक तालिका होती है, जिसे H0 कहा जाता है। यह क्लस्टर में प्रत्येक 1024-बाइट डेटा ब्लॉक की हैश को संग्रहीत करता है।

दूसरी तालिका, H1, उप समूह में प्रत्येक क्लस्टर के H0 तालिकाओं के हैश को संग्रहीत करता है। चूंकि यह तालिका प्रत्येक क्लस्टर के शीर्षलेख में है, सभी समूहों के एक उपसमूह के ढांचे के भीतर इसकी सामग्री समान है।

एक H2 तालिका भी है जो समूह में सभी उपसमूहों के H1 तालिकाओं के हैश को संग्रहीत करती है। इसलिए, यह, बदले में, समूह के सभी समूहों के लिए समान है।

और अंत में, डिस्क पर प्रत्येक विभाजन में एक वैश्विक हैश तालिका होती है जो प्रत्येक क्लस्टर समूह के H2 तालिकाओं के हैश को संग्रहीत करती है। इस तालिका को अनुभाग में शीर्ष लेख की बाकी जानकारी के साथ, डिजिटल रूप से हस्ताक्षरित किया गया है, जो वास्तव में अन्य स्तरों की तालिकाओं की सुरक्षा करता है, जिसमें परिणामस्वरूप, स्वयं क्लस्टर का डेटा शामिल है। वे, वैसे, एन्क्रिप्टेड भी हैं।

छवि में किसी भी परिवर्तन के साथ, सभी हैश को पुनर्गणना और वैश्विक हैश तालिका पर फिर से हस्ताक्षर करना आवश्यक है। लेकिन निन्टेंडो को छोड़कर कोई भी हस्ताक्षर करने के लिए निजी कुंजी नहीं जानता है, इसलिए हस्ताक्षर बग के रूप में जाना जाने वाला समाधान का उपयोग किया जाता है ।

तथ्य यह है कि Wii फर्मवेयर में एक बग का पता लगाया गया था: जब एक डिजिटल हस्ताक्षर की जांच करते हैं, तो strncmp फ़ंक्शन का उपयोग करके हैश की तुलना की जाती थी। यह फ़ंक्शन स्ट्रिंग्स के लिए डिज़ाइन किया गया है और इसमें एक विशेषता है: यदि दोनों तुलनात्मक डेटा श्रृंखलाओं की शुरुआत में एक शून्य बाइट है, तो उन्हें खाली स्ट्रिंग्स के रूप में लिया जाता है, और, परिणामस्वरूप, समान माना जाता है। इसलिए, Wii पर संशोधित सामग्री को लॉन्च करने के लिए, एक पूर्व-तैयार डिजिटल हस्ताक्षर का उपयोग किया जाता है, जिसका हैश खरोंच से शुरू होता है। सामग्री हैश को खरोंच से भी शुरू करने के लिए, आरक्षित क्षेत्रों को बदलकर डेटा को समायोजित किया जाता है।

यह जानकर, मैंने एक सत्यापन कार्य लिखा, जो हैश को गिना और उनकी तुलना निर्दिष्ट लोगों से की। और वास्तव में - किसी बिंदु पर, अमान्य हैश के कारण चेक विफल हो गया। फ्रीज के साथ समस्या यह है कि WiiScrubber स्रोत में एक बग था, जिसके परिणामस्वरूप, कुछ मामलों में, अंतिम संसाधित क्लस्टर का हैश अपडेट नहीं किया गया था। बग को ठीक करने के बाद, सब कुछ काम करना शुरू कर दिया, जिसे मैं बहुत खुश था।

इस अप्रिय अनुभव को देखते हुए, मैंने पैच की आंतरिक असेंबली में छवि की वैधता और खुद को पुनर्निर्माण अभिलेखों की एक अनिवार्य जांच में बनाया। जिस स्थिति में पैच बस लागू नहीं होगा।

परीक्षण और रिलीज

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

इससे पहले, मैंने पैच विधानसभा प्रक्रिया में कई परीक्षण जोड़कर अधिकांश तकनीकी त्रुटियों को रोकने की कोशिश की। यदि वे विफल रहे, तो पैच बस नहीं जा रहा था।

लेकिन समस्याएं अभी भी बह रही हैं। मेरे पास बग रिपोर्ट को संसाधित करने के लिए मुश्किल से समय था, क्योंकि नए दिखाई दिए। उसी समय, यह न केवल त्रुटियों के बारे में बताया गया था, बल्कि कान काटने के किसी भी सुझाव के बारे में भी था, इसलिए जल्द ही परीक्षण पूरे पाठ के विस्तृत प्रसंस्करण में बदल गया।

यह पता चला कि गैर-फिटिंग पाठ के साथ समस्या बहुत बड़े पैमाने पर थी जितना हम कल्पना कर सकते थे। रूसी भाषा की ख़ासियत के कारण, अनुवाद लंबा था और बस स्क्रीन पर फिट नहीं होता था। इसलिए, अपने दांतों को पीसते हुए, मैं बैठ गया और एक खेल पटकथा संपादक को पाठ की लगभग कल्पना करने की क्षमता के साथ लिखा।


परीक्षकों में से एक, जिसका नाम SonyLover है, पहले हमारी एक परियोजना में अनुवादक था। उन्होंने अनुवाद पूरा करने में अपनी मदद की पेशकश की, और हम एक साथ हर वाक्य को संपादित करने लगे।

इस बीच, फोंट के साथ एक अप्रिय समस्या का पता चला: कुछ अक्षर दूसरों की तुलना में अधिक लग रहे थे, जिसने "कूद" पाठ का प्रभाव पैदा किया। करीब से देखने के बाद, मैंने इस समस्या को मूल रूप में देखा, लेकिन यह कम स्पष्ट था और इसलिए ध्यान देने योग्य नहीं था।


कारण सरल था और कुछ इसी तरह का वर्णन पहले से ही हैबे पर किया गया था : बनावट के किनारों से सटे हुए पात्रों को बगल की तरफ से प्रक्षेपित नहीं किया गया था, और इसलिए किनारे से आगे आने वाले पात्रों की तुलना में अधिक स्पष्ट दिखे। नेत्रहीन, इसने पात्रों की ऊंचाई में अंतर का प्रभाव पैदा किया। हालाँकि, इस समस्या का हल केवल पारदर्शी पिक्सेल के फ्रेम को जोड़कर किया गया था ताकि कोई भी चरित्र बनावट के किनारों पर फिट न हो।

इस गति से, हमने डेढ़ महीने तक काम किया, सभी अवांछनीय क्षणों को चमकाने और हर छोटी चीज़ पर बहस करने के लिए। और अब, हम रिलीज के करीब हैं। यद्यपि अंतिम समय में हमें काफी वैश्विक बदलावों का सहारा लेना पड़ा, जैसे कि दो तत्वों को बदलना या खेल की निष्पादन योग्य फ़ाइल में अनियंत्रित सिस्टम संदेशों का पता लगाना, हम अब उनका सत्यापन नहीं कर सकते थे।

और आखिरकार, हमारे लिए एक शुभ दिन आ गया है। 26 जनवरी, 2013 को, मैंने अंतिम बदलाव किए, रिपॉजिटरी में खुद को चुना, पैच को रिलीज़ कॉन्फ़िगरेशन के साथ एकत्र किया, और अनुवाद को जारी करने की घोषणा की। यह कहने के लिए कि पहाड़ मेरे कंधे से गिर गया, कुछ नहीं कहना है। बेशक, मुझे अवर्णनीय खुशी महसूस नहीं हुई, लेकिन मेरे विवेक में मुझे कमतर आंका गया।

बेशक, अनुवाद पूरी तरह से काम नहीं करता था - पूर्णता की कोई सीमा नहीं है, और रिलीज के तुरंत बाद अप्रिय के एक जोड़े, लेकिन पाठ स्वरूपण के साथ महत्वपूर्ण क्षणों की खोज नहीं की गई थी। लेकिन एक नया संस्करण जारी करने के लिए पांच मिनट का मामला है, इसलिए इससे मुझे ज्यादा परेशान नहीं होना पड़ा। मुख्य बात यह है कि हम अपने काम के साथ-साथ अपने लक्षित दर्शकों से संतुष्ट थे।

अंतभाषण

हेडलाइन पर लौटते हुए मैं अपनी योजनाओं के बारे में थोड़ी बात करना चाहता हूं। कुछ समय पहले तक, मुझे यकीन था कि मैं अनुवाद गतिविधियों में नहीं लौटूंगा, लेकिन, जाहिर है, मुझसे गलती हुई थी। तब मुझे लगा कि यह अनुवाद शायद मेरे लिए आखिरी होगा, लेकिन तब मैंने फैसला किया कि हमें कम से कम एक अधूरी इमारत को पूरा करना चाहिए, जिसमें सैकड़ों लोग दो साल से हमारा इंतजार कर रहे हैं - मूक पहाड़ी: टूटी हुई यादें अनुवाद । और यह देखा जाएगा कि क्या आत्मा अभी भी शौकिया अनुवाद के लिए झूठ बोलती है। फिर भी, यह व्यर्थ नहीं है कि बहुत से, बड़े होकर, इस दृश्य को छोड़ दें।

ईमानदारी से, यह मेरे लिए सौंदर्य की जरूरतों को पूरा करने के लिए पर्याप्त नहीं है, जिस तरह समय अन्य चिंताओं के आगमन के साथ पर्याप्त नहीं है। शायद अब कुछ और करने का समय आ गया है। उदाहरण के लिए, बचपन और युवाओं के सपने को पूरा करने के लिए, खेलों का विकास करना। कौन जानता है, शायद किसी दिन वे अपनी छोटी कृति को रिलीज करने में सक्षम होंगे।

आपके ध्यान के लिए धन्यवाद, मेरी कहानी यहाँ समाप्त होती है।

अद्यतन : स्रोत github पर पोस्ट किए गए हैं ।