Duke Nukem: Zero Hour N64 ROM रिवर्स इंजीनियरिंग परियोजना ने 100% लक्ष्य पूरा किया

 (github.com/Gillou68310)
1 पॉइंट द्वारा GN⁺ 2025-10-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Duke Nukem: Zero Hour के Nintendo 64 ROM को पूरी तरह डीकॉम्पाइल करने वाले एक ओपन सोर्स परियोजना का परिचय
  • इस रिपॉज़िटरी ने मूल गेम सॉफ़्टवेयर के सभी स्रोत कोड को पुनर्जीवित करने का कार्य 100% पूरा कर लिया है
  • उपयोगकर्ता को गेम का अपना ROM होना चाहिए, और मूल US या फ्रेंच ROM के जरिए पूर्ण बिल्ड और टेस्टिंग संभव है
  • पहले मौजूद डीकॉम्पाइलिंग परियोजनाओं की तुलना में, इसमें पूरी तरह से फंक्शनल संगतता और डिबगिंग टूल सपोर्ट के कारण तकनीकी बढ़त है
  • यह परियोजना गेम इंजन रिसर्च, मॉडिंग, पोर्टिंग और इंजन विश्लेषण के लिए अत्यंत उपयोगी संसाधन है

परियोजना का महत्व और प्रतिस्पर्धी बढ़त

  • Duke Nukem: Zero Hour एक प्रसिद्ध एक्शन गेम है जो केवल Nintendo 64 प्लेटफ़ॉर्म पर रिलीज़ हुआ था
  • यह ओपन सोर्स परियोजना गेम की पूरी ROM को C, Python आदि में पूरी तरह डीकॉम्पाइल करके स्रोत कोड स्तर पर फिर से संरचित करती है
  • अन्य N64 डीकॉम्पाइल परियोजनाओं से अलग, इसमें पूरी संगतता सुनिश्चित की गई है—सही ROM बिल्ड और रनटाइम एक्सीक्यूशन, स्रोत-कोड आधारित डिबगिंग और मल्टी-वर्ज़न सपोर्ट तक उपलब्ध है
  • 1990 के दशक के कंसोल गेम डेवलपमेंट नॉलेज और गेम इंजन की संरचना को समझने के लिए यह असाधारण अध्ययन सामग्री है
  • कई स्वचालित एनालिसिस/डीकॉम्पाइलिंग टूल (asm-differ, mips2c, splat, decomp-permuter आदि) परियोजना में इंटीग्रेट किए गए हैं, जिससे डेवेलपर्स की उत्पादकता अधिकतम होती है

मुख्य सुविधाएँ और संरचना

कुल संरचना

  • परियोजना मल्टी-लैंग्वेज आधारित है, जिसमें C (95% से अधिक), Python, Roff, C++, Makefile और Shell के हिस्से अलग-अलग विभाजित हैं
  • प्रमुख डायरेक्टरी:
    • .github/workflows: CI और ऑटोमेशन सेटअप
    • include, libs, src: गेम स्रोत, लाइब्रेरी और हेडर मैनेजमेंट
    • tools: एनालिसिस, एक्सट्रैक्शन, ट्रांसफ़ॉर्मेशन टूल
    • versions: US/FR आदि कई गेम वर्ज़नों का साथ-साथ सपोर्ट देने वाली संरचना
  • लगभग 370 कमिट के साथ यह परियोजना सक्रिय रूप से मेंटेन की जा रही है

बिल्ड और उपयोग विधि का संक्षेप

  • Ubuntu 20.04 बेस्ड वातावरण और Docker सपोर्ट
  • ROM एक्सट्रैक्शन, बिट-स्तर तुलना, गैर-संगत (NON_MATCHING) मोड सपोर्ट
  • फ्रेंच वर्ज़न और US वर्ज़न ROM दोनों का समर्थन, आवश्यकता के अनुसार विकल्प चुने जा सकते हैं
  • Docker वातावरण और Mutagen Extension के साथ विभिन्न OS (WIN/Mac/Linux) संगतता प्रदान की गई है

डिबगिंग और डेवलपमेंट टूल

  • gdb और mupen64plus आधारित स्रोत-कोड स्तर की डिबगिंग सपोर्ट (वर्तमान में Windows प्राथमिक)
  • Visual Studio Code तथा Native Debug Extension के साथ इंटीग्रेशन सपोर्ट
  • प्रमुख स्वचालित एनालिसिस टूल:
    • asm-differ: असेंबली स्तर पर सोर्स/टार्गेट तुलना
    • decomp-permuter: कोड रीऑर्गनाइज़ेशन और ऑटो स्कोरिंग
    • mips2c: MIPS असेंबली को C में बदलना
    • splat: ROM स्ट्रक्चर एनालिसिस टूल

उपयोग परिदृश्य

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

निष्कर्ष

  • यह ओपन सोर्स परियोजना 1990 के दशक के क्लासिक कंसोल गेम सॉफ़्टवेयर का पूर्ण स्रोत सार्वजनिक होने का दुर्लभ उदाहरण है
  • गेम और कंसोल रिवर्स इंजीनियरिंग शोधकर्ता, नई पीढ़ी के डेवलपर्स, गेम पोर्टर्स और फैन गेम मेकर सभी के लिए यह कीमती संसाधन है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-20
Hacker News की राय
  • यह देखना दिलचस्प है कि 100% C में decompile हो चुका है, लेकिन कई function और variable names अभी auto-generated हैं, इसलिए labeling अभी पूरी तरह complete नहीं है. अगर कोई अभी porting की कोशिश करे तो मज़ेदार होगा
    • सोचता हूँ कि labeling में LLM कितना effective होगा. कहीं गलत labeling की वजह से समय बर्बाद न हो जाए, यही चिंता है
    • आजकल Ghidra जैसे tools मुफ्त में उपलब्ध हैं, इसलिए "100% C में decompile" अपने आप में उतनी बड़ी बात नहीं लगती
    • Build engine का source code non-commercial purpose के लिए public है, तो क्या यह function और variable names को map करने में मदद कर सकता है, यह जानने की उत्सुकता है
  • Gillou68310 ने शायद 99% काम अकेले किया है, जो सच में कमाल की dedication है. The Legend of Zelda: Twilight Princess पर भी अच्छा काम चल रहा है https://decomp.dev/zeldaret/tp
    • इसी मौके पर Castlevania: Symphony of the Night decompilation project को भी support देना चाहूँगा. यह काफ़ी अच्छी तरह आगे बढ़ रहा है (हालाँकि अभी बहुत काम बाकी है) https://github.com/Xeeynamo/sotn-decomp
  • Zero Hour N64 दौर के must-play titles में से एक था, और Duke Nukem series के बाद के हिस्से में आने वाले कुछ अच्छे games में गिना जा सकता है. इसमें challenging platforming elements और कुछ काफ़ी तकलीफ़देह stages हैं, लेकिन इसके environments लगातार मज़बूत रहे और इसने Duke 3D के आकर्षण को दोबारा पकड़ने की अच्छी कोशिश की. हाल की Perfect Dark porting शानदार रही, इसलिए उम्मीद है कि इस decompilation को भी वैसी ही quality के साथ handle किया जाएगा
  • जिज्ञासा है कि आखिर Duke Nukem: Zero Hour ही क्यों चुना गया
    • Zero Hour थोड़ा भुला दिया गया hidden gem है. Playstation के Duke Nukem games Tomb Raider की नकल जैसे हैं और उन्हें खास ratings भी नहीं मिलीं, लेकिन Zero Hour original Duke Nukem 3D की तरह Build engine based है. भले ही वह उस स्तर तक नहीं पहुँचता, फिर भी 3D Realms के बाहर बने Duke Nukem games में इसे सबसे अच्छा कहा जा सकता है. कमी यह है कि इसने camera को third-person कर दिया (हालाँकि एक अधूरा first-person mode cheat से मौजूद है) और controls भी खास अच्छे नहीं हैं. लेकिन अब source code है, तो इन समस्याओं को ठीक किया जा सकता है
    • अच्छा सवाल है. बस अफ़सोस है कि screenshots नहीं हैं, वरना मैं इसे दोस्तों के साथ share करता. पहले दोस्तों के साथ खेलते समय यह pure chaos का paradise था
  • सोचता हूँ कि लोग (या groups) ऐसे decompilation projects में समय और मेहनत क्यों लगाते हैं. क्या यह अपने पसंदीदा game title से प्यार करने वाले hobby gamers का समुदाय है, या फिर digital preservation का उद्देश्य है?
    • मैं वही व्यक्ति हूँ जिसने Cosmo's Cosmic Adventure (DOS, 1992) को reimplement किया था. वजह बस इतनी थी कि मैं जानना चाहता था कि इस game ने कमज़ोर hardware (IBM AT) पर इतने शानदार graphics tricks कैसे किए. यह ज़रूरी नहीं कि game objectively महान था, लेकिन मेरे बचपन की अहम यादों में से एक था, इसलिए लगाव था. इस अनुभव से मैंने PC platform, 80s के C ecosystem, और अपनी पसंद के बारे में बहुत कुछ सीखा https://github.com/smitelli/cosmore https://cosmodoc.org/
    • मैंने vintage synthesizer firmware की reverse engineering में बहुत समय दिया है (जो modern games की तुलना में सरल है). उदाहरण के लिए Yamaha DX7 और DX9 synth ROMs को annotate किया, और इस प्रक्रिया ने मेरी engineering skills को बहुत बढ़ाया. यह मज़ेदार भी था, और इससे कई बेहद बुद्धिमान लोगों से मिलने का मौका भी मिला. यह किसी technical puzzle जैसा है. इसी प्रक्रिया से कुछ मज़ेदार firmware mods भी निकले DX7 annotated DX9 annotated DX97 और reverse engineering process पर एक tutorial भी लिखा tutorial. यह archaeology जैसा भी लगता है, क्योंकि इससे पहले के engineers की सोच की झलक मिलती है. याद है कि N64 उस समय development के लिहाज़ से काफ़ी कठिन platform था
    • यह बस game के प्रति प्यार की वजह से भी हो सकता है. मैं भी बचपन में Mega Man Battle Network 2 को बहुत चाहता था, और उसी game की वजह से मैंने English सीखी और programmer बना. मेरे पास उसकी दो physical cartridges अब भी हैं. कभी-कभी IDA में उसे analyze करके धीरे-धीरे समझने की कोशिश करता हूँ, हालाँकि ROM hacking community जितनी skill या time मेरे पास नहीं है
    • मेरे हिसाब से ये वही लोग हैं जो खुद करके देखना चाहते हैं या जिनमें अलग तरह की challenge spirit होती है
    • इस साल Game On Expo में मैंने Castlevania: Symphony of the Night decompilation पर talk दी थी https://github.com/xeeynamo/sotn-decomp. ज़्यादातर लोग ऐसे कामों में इसलिए शामिल होते हैं क्योंकि वे game से बहुत प्यार करते हैं. उसके बाद porting, modding, learning, preservation जैसी अलग-अलग motivations आती हैं. मेरे लिए इसमें challenge का मज़ा भी है (कुछ-कुछ math puzzle जैसा). लंबे समय तक यह काम करने के लिए compiler history और theory के साथ-साथ उस दौर के game development के business और engineering pressures को भी समझना पड़ता है. इसी से कभी-कभी यह भी समझ आता है कि game के कुछ हिस्से वैसे क्यों बनाए गए थे. मैं SotN work पर stream भी करता हूँ, और अगर कोई सवाल हो तो chat में कुछ भी पूछ सकता है https://m.twitch.tv/madeupofwires/home
  • बढ़िया project है! लेकिन... platform GitHub है, इसलिए थोड़ी चिंता होती है. कहीं जल्द takedown notice न आ जाए
    • मैंने repository जल्दी से देखी, और उसमें copyrighted material दिखाई नहीं दिया. वहाँ सिर्फ वही code है जो decompilation करने के लिए इस्तेमाल होता है
    • Nintendo game decompilations भी GitHub पर public हैं, तो फिर इसे हटाया ही क्यों जाना चाहिए, समझ नहीं आता
  • यह बात रेखांकित की गई कि वहाँ लिखा है: “Duke Nukem Zero Hour N64 decompilation. Note: इस repository का उपयोग करने के लिए आपके पास game cartridge होना चाहिए”
  • जिज्ञासा है कि क्या LLM ऐसे reverse engineering काम के लिए उपयुक्त है
    • LLM की मदद से labeling का काफ़ी हिस्सा automate किया जा सकता है. "binary से match होने तक बार-बार सुधार" वाला तरीका भी संभव लगता है, लेकिन मैंने इसका कोई ठीक-ठाक documented example नहीं देखा. संदर्भ के लिए decompai project थोड़ा ऐसा approach लेता है (हालाँकि यह project उससे थोड़ा अलग है). मैंने खुद इसे चलाया है, और जब पहले से कुछ context हो, तब variable name guessing में यह काफ़ी काम आता है. counters या temporary variables की naming जैसे boring, repetitive tasks में यह ख़ास तौर पर उपयोगी है. algorithm patterns देखकर function names का भी अनुमान लगाया जा सकता है
    • पता नहीं EFF ने LLM के इस्तेमाल पर कोई official position दी है या नहीं, लेकिन copyright के नज़रिए से इसमें legal risk हो सकता है. Decompilation इसलिए संभव मानी जाती है क्योंकि उससे एक नया creative work निकलता है, जबकि LLM पर derivative/non-creative output देने का आरोप लगाना आसान है. AI companies द्वारा training data licenses पर भारी रकम खर्च करना भी बात को और जटिल बना देता है. मैं शायद ऐसे copyright risk की वजह से इसका उपयोग न करूँ. लेकिन अगर LLM-based decompilation सच में बहुत आसान हो जाए, तो जल्द ही नया case law देखने को मिल सकता है
    • मुझे यह काफ़ी उपयोगी लगता है. परफ़ेक्ट नहीं है, लेकिन समय बहुत बचाता है. खासकर library functions या well-known algorithms की पहचान में यह इंसानों की पहुँच से भी ज़्यादा accurate हो सकता है. compile और decompile process में ख़राब हो चुके code में भी यह उन्हें पहचान लेता है
    • मैं agents का इस्तेमाल करके game porting कर रहा हूँ. Source code होने के बावजूद कई बार काम ठीक से नहीं चलता. LLM कई libraries को port करने की कोशिश ही नहीं करता, इसलिए repetitive workload कम करने की कोशिश करते-करते मामला उल्टा stubs और assumptions से भर गया और पूरा काम गड़बड़ा गया
    • मैंने खुद इस्तेमाल नहीं किया, लेकिन variable/function renaming जैसी local improvements में यह मददगार हो सकता है
  • “repository का उपयोग करने के लिए game cartridge own करना ज़रूरी है” वाली चेतावनी का भी खास तौर पर ज़िक्र हुआ
    • जो लोग Chinese retro handheld devices इस्तेमाल करते हैं, उनके लिए technically ROM खुद dump करना ही legal है. लेकिन अगर आप 10,000 games वाला सस्ता bundle खरीद लें, तो न जाने कैसे सब legal हो जाता है. वैसे सच यह है कि शायद ही किसी को इस पर सज़ा मिलती हो, इसलिए ऐसे disclaimers थोड़े प्यारे लगते हैं
    • असल में game cartridge के बिना भी यह ठीक चला. मुझे लगता है disclaimer ग़लत है
    • यह सचमुच सिर्फ एक legal caution है, कोई वास्तविक enforcement requirement नहीं
  • मैं अभी भी Duke Nukem Forever का बेसब्री से इंतज़ार कर रहा हूँ. इतना समय हो गया कि अब ठीक से याद भी नहीं कि कितने साल बीत गए
    • पता नहीं यह मज़ाक है या नहीं, लेकिन अगर आपको मालूम न हो तो Duke Nukem Forever पहले ही Steam पर release हो चुका है https://store.steampowered.com/agecheck/app/57900/