कंप्यूटर कला त्यौहारों का इतिहास, जिसे लोकनाट्य के रूप में भी जाना जाता है, हमारे देश में लगभग एक चौथाई सदी तक रहा है। पुराने या आधुनिक कंप्यूटर और अल्ट्रा-छोटी मात्रा के कोड से असंभव को निकालने में देश भर के लोग अपने अभ्यास को दिखाने के लिए एकत्रित हो रहे हैं। पहले पांच साल की अवधि में,
CAFe (अचानक,
कंप्यूटर आर्ट फेस्टिवल ), जो कि 1999 से 2003 तक कज़ान में आयोजित किया गया था, देश में प्रमुख लोकतंत्रों में से एक बन गया। बाद में, वह लंबे समय के लिए रडार से गायब हो गया, हथेली को अधिक प्रसिद्ध
कैओस कंस्ट्रक्शंस और
डायहॉल्ट को दे दिया , और इस साल उसकी वापसी काफी विजयी रही - यदि घटना के पैमाने से नहीं, तो विभिन्न कार्यों की संख्या से, जो सुबह छह बजे तक चली। उनमें से मेरा था, जिसके निर्माण पर इस लेख में चर्चा की जाएगी।
लोकतंत्र पर, मैं एक सक्रिय भागीदार की तुलना में अधिक सहानुभूतिपूर्ण हूं। मेरा मुख्य हित रेट्रो गेम और साउंड सॉफ्टवेयर के विकास में हैं। इससे पहले, मैंने
लाल फोन के लिए केवल एक सशर्त पूर्ण
डेमो बनाया था, जो तब से एक दृश्य मेम बन गया है, और विभिन्न प्लेटफार्मों के लिए लगभग एक दर्जन छोटे इंट्रो।
CAFe आयोजकों, जिन्होंने पहले से, पारस्परिक रूप से, पारस्परिक मित्रों के माध्यम से, और फिर व्यक्तिगत बैठकों में लेखकों के व्यक्तिगत आंदोलन की शुरुआत की थी, अंततः मुझे पूर्ण-लंबाई वाले डेमो श्रेणी में अपना पहला सही मायने में पूर्ण कार्य बनाने के लिए प्रेरित किया। जैसा कि यह हुआ, एक और सबसे लोकप्रिय मंच पर नहीं -
एनईएस /
फेमीकॉम गेम कंसोल, जिसे डंडी के नाम से जाना जाता है।
आयोजन
प्रारंभ में, मैं एक और, अधिक लोकप्रिय 8-बिट प्लेटफ़ॉर्म के लिए एक लंबे समय से कल्पित डेमो बनाने जा रहा था। लेकिन इसके क्रियान्वयन के लिए, अनुसंधान कार्य का एक महत्वपूर्ण हिस्सा करना आवश्यक था, अर्थात, समय की समझ, विचार की मौलिक व्यवहार्यता या संभावित परिणाम की गुणवत्ता की कोई समझ नहीं थी। इसलिए, विशिष्ट कार्यों को बहुत धीरे से लिया गया था। समय सीमा काफी हद तक समाप्त हो गई, और यह स्पष्ट हो गया कि अगर मैं भागीदारी का वादा रखना चाहता हूं, तो कार्यान्वयन में एक और, अधिक अनुमानित परियोजना का चयन करना जरूरी है। दूसरे विचार पर विचार करने के बाद,
जंगली श्रेणी के लिए, जिसे प्रयोग की भी आवश्यकता थी, मैंने तीन साल पहले
एनईएस के लिए लंबे समय तक चलने वाले डेमो ब्लैंक पर लौटने का फैसला किया, फिर
मल्टीमाटोग्राफ के लिए । नतीजतन, वे स्वयं वास्तव में उपयोग नहीं किए गए थे, लेकिन काम की दिशा आखिरकार निर्धारित की गई थी।
विशेष रूप से
एनईएस के लिए काम करने की योजना को अंततः अक्टूबर की शुरुआत में मंजूरी दे दी गई थी, जब तक कि
सीएएफई को लगभग तीन सप्ताह दूर नहीं थे। प्रोजेक्ट फ़ोल्डर 5 अक्टूबर को बनाया गया था, लेकिन उससे पहले कुछ हलचलें हुईं।
पहला प्रश्न जो हल करने की आवश्यकता थी, एक साधारण परिचय के बजाय बड़े रूप का दावा करने के लिए डेमो की अवधि को पर्याप्त बनाने के लिए कितने प्रभावों (दृश्यों) की आवश्यकता थी। यह समझने के लिए भी आवश्यक था कि यह पर्याप्त अवधि क्या थी।
इसके लिए, अन्य बातों के अलावा,
पोएट पर चयनित मंच के लिए वर्तमान शीर्ष कार्यों
की समीक्षा की गई , और दो सबसे अच्छे लोगों का विश्लेषण किया गया -
हाई होप्स और
एनईएसईसीईसीवाई । आखिरी एक, जो उसी डेमोपति के लिए एक निमंत्रण है, दिसंबर 2018 में जारी किया गया था, और उस क्षण तक मैंने किसी तरह अपनी आंख नहीं पकड़ी थी। सबसे पहले, इसने प्रेरणा को कुछ हद तक प्रभावित किया, क्योंकि मैंने शुरू में अपने भविष्य के काम के लिए एक स्तर आसान माना।
विश्लेषण के परिणामों के अनुसार, यह पता चला कि
हाई होप्स में लगभग छह प्रभाव और 2:45 की अवधि होती है, और
NESPECCY में लगभग 11 प्रभाव और 3:45 की अवधि होती है। यह औसतन लगभग 25 सेकंड प्रति प्रभाव है। मैंने सुझाव दिया कि, औसतन 10-15 प्रभाव पर्याप्त होंगे, इस धारणा के आधार पर कि उनमें से केवल 3-5 तकनीकी रूप से जटिल होंगे, और बाकी सरल लेकिन सुंदर भराव हो सकते हैं। साधारण दृश्यों के प्रदर्शन में देरी न करने के लिए, औसतन यह लगभग 15 सेकंड प्रति प्रभाव होगा, डेमो की कुल अवधि लगभग दो या तीन मिनट में।
इसके बाद गणना की गई कि प्रत्येक प्रभाव को बनाने में कितना समय खर्च किया जा सकता है। यह डेढ़ से दो दिनों में बदल गया, कई अन्य आवश्यक कार्यों की गिनती नहीं करना, जैसे कि संगीत, ग्राफिक्स, किसी तरह का विचार, और बस एक तकनीकी आधार तैयार करना जो प्रभावों को जोड़ती है। ऐसा कोई शेड्यूल बहुत यथार्थवादी नहीं है, लेकिन मैंने प्रत्येक के लिए दो दिनों में फिट होने की कोशिश करते हुए कई प्रभाव बनाने का फैसला किया।
इस प्रकार, प्राथमिकता कार्य निर्धारित किया गया था - प्रतियोगिता में भाग लेने के लिए कम से कम कुछ समय में करने में सक्षम होने के साथ-साथ "समझाने का समय नहीं" की शैली में विकास मोड। इसने विकास डायरी को भी खारिज कर दिया, और अब आपको स्मृति से घटनाओं को पुनर्प्राप्त करना होगा, बहुत अधिक झूठ न बोलने की कोशिश करना।
नौकरी करने का काम, पहले स्थान का दावा, पेश नहीं किया गया था। मुख्य बात जीत नहीं है, लेकिन भागीदारी और वह सब, और सामान्य तौर पर मुख्य जीत स्वयं से ऊपर है। मैंने चयनित श्रेणी की अलोकप्रियता के लिए प्रतियोगिता के परिणामों के आधार पर कोई विशेष पूर्वानुमान नहीं लगाया, यह उम्मीद करते हुए कि कई काफी मजबूत कार्यों की प्रतियोगिता में सबसे खराब (सबसे अच्छा) मामले में, मेरा कम्पो फिलर बन जाएगा, जो आवश्यक और महत्वपूर्ण भी है, और अगर कोई काम नहीं है, तो मैं फिर से करूंगा। आपस में एक विजेता, जैसा कि अन्य विषयों में पहले ही हो चुका है। बेशक, मैं एक अच्छी लड़ाई जीतना चाहता था, लेकिन मैंने खुद अपने काम को कम से कम मूल्यांकन किया जो दर्शकों ने अंत में अनुमान लगाया था।
कोड
समय सीमा निर्धारित होने के बाद, यह स्पष्ट हो गया कि इस तरह की परियोजना को बढ़ाने के लिए समय के लिए, अनुचित पूर्णतावाद के साथ टाई करना आवश्यक था और सबसे तकनीकी या कॉम्पैक्ट डेमो कोड बनाने की कोशिश न करें। पर्याप्त बाहरी प्रभाव को बनाए रखते हुए, सरल और तेज, बेहतर।
एक काफी शक्तिशाली और यहां तक कि निरर्थक कॉन्फ़िगरेशन का चयन करने का निर्णय लिया गया - एक
MMC3 मैपर रॉम कोड के 256 किलोबाइट और ग्राफिक्स ग्राफिक्स के 256 किलोबाइट के साथ, और यह चिंता न करने की कोशिश करें कि इसकी पूरी क्षमता अप्रयुक्त रहेगी। यह कॉन्फ़िगरेशन मौजूदा के सबसे उन्नत नहीं है और इससे भी अधिक संभव है,
सुपर मारियो के साथ शुरू होने वाले व्यावसायिक खेलों में इसका व्यापक रूप से उपयोग किया गया है
। 3 (1988), लेकिन पहले
NES के लिए डेमो के लेखक सरल मैपर और कम मेमोरी तक सीमित
थे । नतीजतन, ROM कोड की मात्रा का 80% उपयोग किया गया था और रोम ग्राफिक्स की मात्रा के दो-तिहाई से थोड़ा कम था। स्मृति की अत्यधिक मात्रा ने हमें डेटा संपीड़न समस्या को सुलझाने में अतिरिक्त समय बर्बाद नहीं करने की अनुमति दी, हालांकि यह इसके बिना नहीं कर सकता था।
विकास पद्धति भी स्पष्ट थी - मुख्य रूप से सी में, असेंबलर आवेषण के साथ, मुख्य रूप से वीडियो मेमोरी, इंटरप्ट हैंडलर और एक म्यूजिक प्लेयर की नकल। मैं लंबे और सफलतापूर्वक रेट्रो प्लेटफार्मों पर इस दृष्टिकोण का उपयोग कर रहा हूं। यह विकास के समय को बहुत बचाता है, क्योंकि कोड प्रोटोटाइप स्थानीय रूप से किया जा सकता है: पहले इसे सी में लागू करें और तुरंत एक परिणाम प्राप्त करें जो
एनईएस पर काम करता है, और फिर, अगर यह पर्याप्त तेजी से काम नहीं करता है, तो इसे पहले से ही टेम्पलेट के अनुसार कोडांतरक के कुछ हिस्सों में फिर से लिखें। आवश्यक गति तक पहुँच गया है।
मुख्य अपेक्षित समस्याओं में से एक, जो, हालांकि, व्यवहार में बहुत परेशानी नहीं हुई, मुख्य रैम की मात्रा थी -
एनईएस पर यह केवल 2 किलोबाइट है, और अपने काम में मैंने इसे विस्तार किए बिना करने का फैसला किया, हालांकि मैपर मूल रूप से यह कदम है।
6502 प्रोसेसर पर आधारित प्रणालियों में मेमोरी
, इसकी कुल आठ-बिट क्षमता को देखते हुए, अक्सर 256-बाइट पृष्ठों में माना जाता है, और उनमें रैम का वितरण निम्नानुसार निकला:
- "तेज़" चर के लिए एक पृष्ठ;
- हार्डवेयर स्टैक और पैलेट के लिए एक पृष्ठ (स्टैक का एक महत्वपूर्ण हिस्सा उपयोग नहीं किया जाता है);
- स्प्राइट सूची बफर के लिए एक पृष्ठ (वीडियो नियंत्रक वास्तुकला की सुविधाओं की आवश्यकता है);
- वीडियो मेमोरी अपडेट की सूची के लिए एक पृष्ठ;
- रेखापुंज प्रभाव के लिए मापदंडों की एक सूची के लिए एक पृष्ठ।
कार्यक्रम में पिछले दो को 256 बाइट्स के सामान्य अहस्ताक्षरित चार सरणियों के रूप में घोषित किया गया है और कुछ स्थानों पर अन्य उद्देश्यों के लिए भी उपयोग किया जाता है। शेष तीन पृष्ठ
cc65 प्रोग्राम स्टैक के तहत दिए गए हैं, जो कि C प्रोग्राम के वैश्विक और स्थानीय चर के तहत है।
यह ध्यान दिया जाना चाहिए कि ऐसे प्लेटफार्मों पर मेमोरी (मॉलोक / मुक्त) के गतिशील आवंटन का व्यावहारिक रूप से उपयोग नहीं किया जाता है, एक स्थिर समाधान की आवश्यकता थी। सबसे पहले, मैंने यथासंभव अधिक से अधिक स्थानीय चर का उपयोग करने की विधि का पालन किया, जिससे मुझे उनके लिए सॉफ़्टवेयर स्टैक की मेमोरी का स्वचालित रूप से पुन: उपयोग करने की अनुमति मिली। लेकिन स्थानीय चर बहुत धीरे-धीरे काम करते हैं, और इसके परिणामस्वरूप, वैश्विक चर के लिए उपलब्ध मात्रा में कमी होने लगी, और इस तरह से कोड को लिखना असहज था, बार-बार एक ही नाम के चर का उपयोग करना। तब मैंने एक पूर्व अप्रयुक्त समाधान लागू किया: एक ही पते पर भौतिक रूप से स्थित कई रैम खंडों के लिंकर कॉन्फ़िगरेशन में एक विज्ञापन। एक ही प्रभाव के भीतर उपयोग किए जाने वाले चर के समूह को इन खंडों में संकलक निर्देशों का उपयोग करके रखा गया था, जो एक ही मेमोरी का पुन: उपयोग करने की अनुमति देता है।
एक अन्य समस्या - कोड मेमोरी बैंकों द्वारा सी प्रोग्राम कोड का वितरण (
एनईएस विस्तारित मेमोरी के लिए पेज एड्रेसिंग का उपयोग करता है) - पहले अन्य परियोजनाओं में मेरे द्वारा हल किया गया था, और समस्याओं का कारण नहीं था। पृष्ठों में रखने के लिए कोड 16 किलोबाइट्स (स्विचेबल मेमोरी विंडो के आकार) तक एक कार्यात्मक रूप से पूर्ण अनुभाग तक सीमित है, और इसे ओवरले विधि द्वारा कहा जाता है: वांछित पृष्ठ जुड़ा हुआ है, इससे कोड संसाधित होता है, निष्पादन मुख्य पृष्ठ पर लौटता है, और पृष्ठों के बीच मेमोरी का उपयोग असंभव है। संकलक निर्देशों के माध्यम से बैंकों को मैन्युअल रूप से कार्य आवंटित किए जाते हैं। कार्यक्रम के सभी हिस्सों में आवश्यक कोड, जैसे कि एक म्यूजिक प्लेयर, स्प्राइट आउटपुट और इंटरप्ट हैंडलर, ऊपरी गैर-स्विचेबल मेमोरी विंडो में स्थित है, आकार में भी 16 किलोबाइट।
अंतिम प्रभाव पर काम करते समय, मारियो के साथ गलियारा, मैं एक मनोरंजक संकलन त्रुटि संदेश आया:
स्थानीय लेबल अतिप्रवाह । जैसा कि मैं इसे समझता हूं, संकलक में एक वस्तु मॉड्यूल के अंदर उत्पन्न स्थानीय लेबल (जाहिरा तौर पर 65536) की आंतरिक सीमा होती है, लेकिन मैंने साझा मेमोरी के प्रबंधन को आसान बनाने के लिए एक सामान्य मॉड्यूल का उपयोग किया। संभावित समाधानों में से एक कोड को कई मॉड्यूलों में विभाजित करना था, और मैंने पहले से ही इसे लागू करने की योजना बनाई थी, हालांकि, स्रोत से सी में एक सरणी स्थिरांक को असेंबलर भाग (एक बाहरी लेबल के साथ
इंकबिन ) में स्थानांतरित करने के बाद, समस्या स्वयं हल हो गई, सीमा पार हो गई, और जोड़ने के बाद भी बंद हो गई। कोड की एक सौ से अधिक लाइनें त्रुटि संदेश अब नहीं हुआ।
डिज़ाइन
प्रभावों की पसंद में खुद को सरल, लेकिन हमेशा चिकनी रखने की योजना थी, पूर्ण प्रदर्शन गति (60 फ्रेम प्रति सेकंड) पर काम करना। प्लाज्मा और जूम रोटेटर्स जैसे पारंपरिक डेमो इफेक्ट्स पर शुरू में विचार नहीं किया गया था, क्योंकि वे सेट-टॉप बॉक्स की वास्तुकला के साथ अच्छी तरह से फिट नहीं होते हैं, जिसमें वीडियो मेमोरी तक पहुंच पर महत्वपूर्ण प्रतिबंध हैं - यह उन प्लेटफार्मों की तुलना में घटिया लगेगा जहां ऐसे प्रभाव बार-बार अपनी महिमा में लागू किए जाते हैं।
सबसे पहले, मैं एक तीन वर्षीय योजना के अनुसार प्रभावों का थोक बनाना चाहता था, जो प्रदर्शित रेखापुंज के साथ लाइन-बाय-लाइन जोड़तोड़ पर आधारित था - प्रत्येक पंक्ति के ऊर्ध्वाधर और क्षैतिज विस्थापन को बदलना, साथ ही प्रदर्शित ग्राफिक के किनारे, जबकि किरण रेखापुंज से गुजरती है। ऐसा दृष्टिकोण कोड के एक सामान्य ब्लॉक के आधार पर काम कर सकता है, जिससे विकास समय की बचत होती है, लेकिन प्रभाव काफी समान होगा, और कई अन्य कार्यों में पाया जाने वाला काफी पारंपरिक भी है। इसके अलावा, कोड के इस सामान्य ब्लॉक को डिबग करने में कठिनाइयां थीं, और परिणामस्वरूप, डेमो में इस प्रकार का केवल एक प्रभाव शामिल था, एक घूर्णन कारतूस।
पुराने विचारों पर आधारित कुछ प्रभावों से निपटने के दौरान, जिनमें से एक अंततः किर्बी प्रभाव बन गया, और दूसरा डेमो में नहीं गया, मैंने एक पाठ दस्तावेज़ लिखना शुरू किया, जहां मैंने अपने सिर पर आने वाले सभी विचारों को लिखा, दोनों व्यक्तिगत प्रभाव और सामान्य अवधारणा के लिए। इस सूची में 40 से अधिक प्रभाव शामिल थे, जबकि अंतिम कार्य में 15 से कम लागू किए गए थे। एक ही समय में, अधिकांश प्रभाव एक प्रकार या किसी अन्य के एनिमेशन हैं, हालांकि इसका प्रत्येक संस्करण काफी अनूठा है और स्वीकार्य स्मृति खपत और आवश्यक सुचारू संचालन सुनिश्चित करने के लिए विभिन्न तरकीबों का उपयोग करता है। । यह भी अनायास ही हुआ कि प्रमुख प्रकार का प्रभाव किसी चीज का घूमना है। सिद्धांत रूप में, यह एक अच्छा संयोग है, क्योंकि एक तरह की वैचारिक एकता उत्पन्न हुई।
मेरे पिछले काम के विषय पर एक मजाक के रूप में एक हाथी के साथ एक परिचय और बनाया गया था, फिर रंगीन धारियों और हस्तक्षेप के साथ एक प्रभाव। बहुत ज्यादा सोचे-
समझे , शीर्षक के रूप में काम करने वाले शीर्षक,
एचओएचईडीएमओ को परिचय (
एचओआई आईएस ही) से मजाक का एक निरंतरता के रूप में चुना गया था। जब नाम के प्रदर्शन के साथ दृश्य की प्राप्ति हुई, तो इसे अंतिम रूप दिया गया, क्योंकि उस समय तक अधिक सफल विचार नहीं थे, और उनके साथ आने का कोई समय नहीं था।
नाम डेमो के साथ एक सहज निर्णय ने सभी काम की अंतिम अवधारणा को प्रेरित किया, जो अंत में समय सीमा से दस दिन पहले आकार ले लिया। यह पहचानने योग्य वीडियो गेम और पॉप संस्कृति सामग्री, जैसे कि पात्रों, लोगो, गेम से दृश्यों का उपयोग करता है, लेकिन इस तरह से संशोधित किया गया है ताकि मूल को थोड़ा अलग किया जा सके (जैसे "उन्हें नहीं")। प्रारंभिक और अंतिम दृश्यों से हास्य को पूरे डेमो में फैलाने का भी निर्णय लिया गया था, इस प्रकार यह बहुत उच्च तकनीकी स्तर के लिए क्षतिपूर्ति नहीं करता है, जो उद्धृत युग (मध्य -90 के दशक) की भावना में काफी है, और एक व्यापक दर्शक के लिए अपील करता है - आखिरकार, पुराने गेम कंसोल का अपना है, डेमोसिन के साथ प्रतिच्छेद नहीं करना और प्रौद्योगिकी में बहुत प्रबुद्ध नहीं, बल्कि बहुत विशाल दर्शक। लगभग उसी समय, 90 के दशक के अंतर्निहित डेमो को अलग-अलग स्वतंत्र दृश्यों में विभाजित करने का उपयोग करने का निर्णय लिया गया था, क्योंकि वे उपलब्ध समय में करना आसान है, और इसके बाद संगीत भाग और इसके साथ प्रभावों के सिंक्रनाइज़ेशन में बहुत मदद मिली।
विद के साथ दृश्यों का विचार, एक घूर्णन लोगो और गलियारे में मारियो के साथ आंशिक रूप से भी काम के दौरान स्वाभाविक रूप से उत्पन्न हुआ। उन्हें बारी-बारी से बनाया गया था, एक तरह की शिथिलता के रूप में - जब तक कि मुख्य नियोजित प्रभाव से चिपके नहीं थे।
सभा
प्रारंभ में, यह स्पष्ट था कि समय का सबसे लंबा समय एक परिचय, शीर्षक, अभिवादन और अंतिम क्रेडिट के साथ भागों को ले जाएगा। पहले उन पर काम किया गया था, इसलिए कुछ बिंदु पर यह पता चला कि डेमो में पहले से ही एक पूरी शुरुआत और अंत है (अंतिम रिलीज के समान), लेकिन लगभग कोई बीच का मैदान नहीं है जिसके लिए केवल एक या अधिक तैयार था प्रभाव। समय सीमा एक करीबी के लिए आ रहे थे। परियोजना पर काम एक घंटे के मैराथन में बदल गया, सभी संभव मुफ्त ले, और मुफ्त भी नहीं, समय। योजनाओं में शेष प्रभाव जटिलता द्वारा हल किए गए थे, सभी विचारों को यथासंभव सरल किया गया था। अंतरिक्ष आक्रमणकारियों को बनाया गया था, एक घूर्णन कारतूस के साथ समस्याओं को हराया गया था, और एक क्रेक के साथ एक आसान-से-कार्यान्वयन टॉवर पूरा हो गया था (उपस्थिति के साथ प्रयोग किया गया था)। जैसा कि प्रभाव तैयार थे, उनके प्रदर्शन का क्रम निर्धारित किया गया था।
प्रत्येक ट्रिफ़ल को पहले की तुलना में तीन गुना अधिक समय लगा, और समय सीमा से कुछ दिन पहले, जब प्रभाव या संगीत का कोई आधा हिस्सा अभी भी नहीं था, तो एक मजबूत भावना थी कि यह काम नहीं करेगा। प्लान बी पर विचार किया गया था, किसी अन्य डेमोपाती पर या उसके बाहर काम को पूरा करने और उजागर करने के लिए। लेकिन तब एक और प्रभावी निर्णय लिया गया: तुरंत पहले से मौजूद हर चीज को इकट्ठा करने और पूरा करने के लिए, किसी उत्पाद को रिलीज के लिए तैयार करने का कम से कम, यहां तक कि पूरी तरह से बेवकूफ, इसके लिए कुछ संगीत लिखने के लिए, और अगर उसके बाद भी समय बाकी है, तो अधिक प्रभाव जोड़ने का प्रयास करें। अंतिम क्षणों में जोड़े गए ऐसे दृश्यों में पाक और कॉरिडोर थे, दोनों मूल विचारों की तुलना में सबसे सरल संस्करण में थे।
असेंबली के इस तरीके ने डेमो के बीच में प्रभाव की एक ध्यान देने योग्य असंगति और कई दृश्यों के बीच संगीत का एक पूर्ण परिवर्तन किया। हालांकि, इसने बहुत समय बचाने में मदद की, और वास्तव में यह कार्य समय सीमा से एक दिन पहले जारी करने के लिए पूरी तरह से तैयार था। यह अतिरिक्त समय सभी भागों में और संगीत में विभिन्न trifles को अंतिम रूप देने पर खर्च किया गया था। विशेष रूप से, यह इस समय था कि आक्रमणकारियों और टॉड ने अपनी वैकल्पिक उपस्थिति हासिल कर ली थी।
डिबगिंग
असली हार्डवेयर, साथ ही हार्डवेयर पर डिबगिंग क्षमताओं की कमी के लिए, डेमो को विशेष रूप से एमुलेटर में डीबग किया गया था। मुख्य कार्य
FCEUX एमुलेटर में था। यह बहुत सटीक नहीं है, लेकिन इसमें एक अच्छा डिबगर है और यह बहुत जल्दी शुरू होता है, जो कि "दो पंक्तियों को जोड़ना, दौड़ना, जाँचना" की विकास पद्धति के साथ महत्वपूर्ण है। समय-महत्वपूर्ण प्रभावों को बहुत अधिक सटीक लेकिन कम सुविधाजनक
मेसेन, प्यून्स और
नेस्टोपिया में डीबग किया गया था ।
चूंकि डेमो फॉर्मेट का अर्थ है कि वह उस प्लेटफॉर्म से प्राप्त करने की इच्छा रखता है जो उस पर पहले किसी और ने नहीं किया था, यह ताकत के लिए एमुलेटर की सटीकता का परीक्षण करता है, जिसमें विभिन्न चरम मामलों के बारे में उनकी असहमति दिखाते हुए शामिल है। एक एमुलेटर में प्रभाव को डिबग करने के बाद, आप अन्य एमुलेटर में कलाकृतियों को प्राप्त कर सकते हैं। इसके कारण, और
एनईएस वास्तुकला की विशेषताओं के कारण भी, सटीक समय से बंधे कई प्रभावों को कई बार बार-बार डिबग करना पड़ा। नतीजतन, मैंने लोकप्रिय
एफसीईएक्स एमुलेटर में साफ काम के लिए डेमो स्थापित किया, जिसके साथ इसे प्रतियोगिता में भेजा गया, और अन्य सभी एमुलेटर में सामान्य काम के लिए।
डिबगिंग के दौरान मिली दिलचस्प त्रुटियों में से एक घूर्णन लोगो के साथ दृश्य में एक समस्या थी, खुद को विशेष रूप से
मेसेन एमुलेटर में प्रकट करना। inspired by, , . ,
Mesen . .
NTSC - ,
PAL — , . ,
PAL -, . , 17% .
–
NES ,
Famicom AV ,
Pegasus (
Dendy Classic 2 , ). , , , , . , ,
MMC3 Flash -,
MMC3 .
Pegasus , — . , — — .
, , . , , .
Flash -.
« » «». . ' , . , , , , . , . .
NES , , , -. , , , , , . , .
Reaper MIDI-, ,
FamiTracker . MIDI-, Reaper,
FamiTracker .
FamiTracker NES , , , — , . , . , «»
FamiTracker '
NSF - . , ,
NES .
. .
FamiTracker Zxx , .
. , . « » , , .
, , . .
, —
Graphics Gale , (10). , .
NES Screen Tool .
, , , . , , .
8 32 , PC. . MMC3, ( ), , . , .
, . — , , .
, , . 12x16 , 8x8, — . — 00 99, — . . , .
, , MMC3, , .
, 32 . 238 , 7 . , , , 53. , PC, , .
नाम
, , .
. . . Blender . , ,
NES Screen Tool – 82 . , .
, . , , . , , . , .
MMC3 , .
, , ,
Gale . , , .
. .
, . , , .
प्रभावों की कमी और उन्हें विकसित करने का समय होने के कारण, मैंने कुछ साल पहले लिखे एक छोटे से परिचय का पुन: उपयोग करने का फैसला किया, जिसमें पत्र एक स्थैतिक लोगो के चारों ओर एक ही रास्ते से उड़ गए। हाल ही में, मुझे फिर से
N64 उपसर्ग में दिलचस्पी हो गई, जिसे मैंने 90 के दशक के उत्तरार्ध में अनदेखा कर दिया, और अन्य प्रभावों पर काम करने की प्रक्रिया में, प्रसिद्ध लोगो के रोटेशन के एनीमेशन के साथ एक सहज विचार आया, जिसे लागू करना बहुत सरल लग रहा था - ये दो विचार एक साथ आए, लेकिन कार्यान्वयन उम्मीद से ज्यादा लंबा समय लिया।
दृश्य की मुख्य तकनीकी जटिलता इस तरह के एक चिकनी और बड़े एनीमेशन के लिए आवश्यक स्मृति की मात्रा में कमी है। यदि आप इसके फ्रेम को बिना संपीड़न के स्टोर करते हैं, तो एक फ्रेम एक 4-किलोबाइट सेट पर कब्जा कर लेगा (क्योंकि दो फ्रेम 256 टाइल में फिट नहीं हो सकते हैं), और यह ग्राफिक्स ROM के 256 किलोबाइट लेगा, अर्थात, डेमो में उपयोग किया गया सभी वॉल्यूम। इस समस्या को हल करने के लिए, तीन चालें एक ही बार में लागू की गईं: रोटेशन का एनीमेशन केवल 90 डिग्री (64 फ्रेम), जिसके बाद दो चेहरे का रंग बदली गई; 256 टाइल्स के सेट में चार फ्रेम के समूहों को रखने के लिए हानिपूर्ण ग्राफिक्स रूपांतरण; रेखापुंज के दृश्य भाग में वीडियो मेमोरी को अपडेट करने के साथ-साथ। इस प्रकार, एनीमेशन ने चार गुना कम जगह ली।
लेटर मॉडल और रोटेशन एनीमेशन
ब्लेंडर में बने हैं। के दौरान उसे दर्पण अपने विचार डेमो अवधारणा है कि मेल खाती है आया, और यह मजेदार था - "। और-और-और-और-और-और" दृश्य, कह रहा है एनिमेशन फ्रेम को समूहीकृत किया जाता है, रंग की गहराई 4 तक कम हो जाती है, और इन छवियों को
एनईएस स्क्रीन टूल में हानिपूर्ण आयात फ़ंक्शन द्वारा परिवर्तित किया जाता है। यह फ़ंक्शन शायद मेरा मुख्य गुप्त हथियार है - यदि संपीड़न के दौरान टाइल की सीमा पार हो जाती है, तो यह सबसे अधिक समान दृश्य टाइलों की खोज करता है और उन्हें तब तक संयोजित करता है जब तक कि आवश्यक संख्या में टाइल नहीं रहती हैं। बेशक, यह दृश्य रूपांतरण कलाकृतियों को देता है और इसके बाद के मैनुअल शोधन की आवश्यकता होती है, लेकिन आप सीमा में कम श्रम के साथ अधिक जटिल छवियों को निचोड़ने की अनुमति देते हैं।
लोगो के एनीमेशन के लिए, टाइलों के सेटों को स्विच किया जाता है, और बैकग्राउंड टाइल मैप में 14 टाइल्स की 14 की विंडो को अपडेट किया जाता है, जिसके लिए MMC3 इंटरप्ट, जिसे टेक्स्ट लाइन से पहले ट्रिगर किया जाता है, का उपयोग किया जाता है। लाइन को फ़ॉन्ट पर सेट ग्राफिक्स को स्विच करने की भी आवश्यकता होती है, जिसके बाद कोड में देरी होती है जब शिलालेख की लाइनें प्रदर्शित होती हैं, तो डिस्प्ले बंद हो जाता है (पृष्ठभूमि रंग लगातार प्रदर्शित होता है) और डेटा वीडियो मेमोरी में स्थानांतरित हो जाता है।
सिक्के स्प्राइट द्वारा प्रदर्शित किए जाते हैं और कम या ज्यादा ईमानदारी से गणना (एक निश्चित बिंदु का उपयोग करके) पथ के साथ उड़ते हैं। पुराने कोड को संशोधित किया गया है ताकि रोटेशन आगे बढ़े, यदि संभव हो तो बिना बड़े लोगो के साथ अंतर किए बिना, साथ ही साथ सिक्के दिखाई देते हैं और सही क्षणों में धीरे-धीरे गायब हो जाते हैं। वे उस प्राथमिकता ध्वज के उपयोग से लोगो के ग्राफिक्स से आगे निकल जाते हैं जो प्रत्येक स्प्राइट में होता है।
घूमता हुआ कारतूस
प्रभाव का कार्यान्वयन शब्दों में बहुत सरल है, लेकिन इसके लिए लंबी डीबगिंग की आवश्यकता है। इंटरप्ट हैंडलर वांछित लाइन (मुख्य थ्रेड के लिए समय छोड़ने के लिए) पर एक रास्टर प्रभाव लॉन्च करता है। अगला, बहुत सटीक रूप से चयनित समय के साथ कोड को स्क्रीन की प्रत्येक पंक्ति के लिए प्रदर्शित टाइल मानचित्र के पिक्सेल-बाय-पिक्सेल ऊर्ध्वाधर ऑफसेट सेट करने के लिए निष्पादित किया जाता है। इसके लिए
PPU रजिस्टरों को लिखने की बहुत ही कठिन योजना की आवश्यकता होती है, और उनमें से कुछ को निश्चित रूप से लाइन में एक निश्चित स्थान पर गिरना चाहिए। सेट-टॉप बॉक्स के
NTSC संस्करण में, प्रोसेसर घड़ी की गति और पिक्सेल पुनरावृत्ति दर कई नहीं हैं, और कोड निष्पादन समय कई कारकों के आधार पर थोड़ा भिन्न हो सकता है, इसलिए प्रत्येक पंक्ति का समय धीरे-धीरे दूर हो जाता है और सुधार की आवश्यकता होती है।
इस दृश्य के लिए ग्राफिक्स का मुख्य भाग
एनईएस के लिए एक डेमो बनाने के पिछले प्रयास के लिए कई साल पहले खींचा गया था, लेकिन अब इसे अन्य कारतूस के चेहरे और एक डेमो लोगो के साथ पूरक किया गया है। मूल छवि एक स्क्रीन में ऊंचाई पर खड़ी है। प्रभाव कोड को सरल बनाने के लिए, कारतूस के पीछे एक ही रेखाओं को कई बार दोहराया जाता है।
रोटेशन एनीमेशन की गणना एक पीसी प्रोग्राम का उपयोग करते हुए पूरी तरह से की जाती है और रोम में कोड की एक महत्वपूर्ण राशि लेता है - प्रत्येक के 16 किलोबाइट्स के तीन बैंक, जिसमें एनीमेशन के 256 फ्रेमों में से प्रत्येक के लिए एक तालिका 176 रेखीय रेखापुंज लाइनों में संग्रहीत होती है। वास्तविक समय में एक प्रभाव बनाना संभव था, मैंने पहले से ही एक अन्य मंच के लिए एक समान डेमो किया था, लेकिन इस मामले में पर्याप्त मुक्त मेमोरी थी और अतिरिक्त समय नहीं था।
Pacman
प्रारंभ में, एक अधिक जटिल दृश्य की योजना बनाई गई थी, लेकिन समय की कुल कमी के कारण, उसने संगीत के परिवर्तन के समय दृश्यों के टूटने के रूप में, सबसे न्यूनतर संस्करण में डेमो में प्रवेश किया।
मुख्य समस्या जल्दी से एनिमेशन बनाने का एक तरीका मिल रहा था। सबसे पहले,
ब्लेंडर या अन्य ग्राफिक्स कार्यक्रमों का फिर से उपयोग करने के लिए विचार आया। लेकिन पहले प्रयासों और कुछ गणनाओं के बाद, यह स्पष्ट हो गया कि मुंह को पूरी तरह से बंद स्थिति से पूरी तरह से खुली स्थिति में खोलने के एनीमेशन के केवल आठ फ्रेम पर्याप्त होंगे, और वे
गेल में मैन्युअल रूप से आकर्षित करने के लिए बहुत आसान और तेज़ होंगे।
अगला, पीसी के लिए एक प्रोग्राम लिखा गया था, एक पूर्ण एनीमेशन चक्र के फ़्रेमों का क्रम लेते हुए और टाइलों के बीच परिवर्तित किए गए फ़्रेमों को खोजने के लिए। वीडियो मेमोरी में टाइल मैप में इन टाइलों के पते को चर-लंबाई सूची के रूप में सहेजा जाता है, डेमो में प्रभाव बस इन सूचियों के बदले हुए वर्गों को अपडेट करता है। सभी फ़्रेमों के ग्राफिक्स एक टाइल सेट में फिट होते हैं और प्रभाव के दौरान बदलते नहीं हैं।
किर्बी
इस प्रभाव को मेरे
पुराने कैट्रिक्स चित्र पर डीबग किया गया था। कुछ प्रकार के दृश्य प्रभाव के माध्यम से चेशायर बिल्ली के साथ एक बिल्ली के चेहरे की छवि को वैकल्पिक चित्र में बदलने की योजना थी। जब थोड़े चुनाव के बाद गेम के पात्रों को डेमो में जोड़ने के लिए विचार आया, तो दो नए पूर्ण-स्क्रीन चित्रों को खींचना जरूरी था - किर्बी को लेने और इसे "चेशायर" संस्करण बनाने का निर्णय लिया गया। प्रक्रिया में बदलती छवियों के प्रभाव को कम झिलमिलाहट के लिए सरल बनाया गया है।
सही जगह पर पहुंचने पर टाइल के नक्शे पर मूविंग इमेज ब्लॉक को स्प्राइट्स के रूप में प्रदर्शित किया जाता है। इसी तरह, ब्लॉक विलोपन होता है।
मीनार
मुझे
बैटललेट्स गेम के अंतिम स्तर में हमेशा प्रभाव पसंद आया, और मैं इसे दोहराना चाहता हूं। डेमो में, वह अभिवादन के साथ दृश्य में एक जगह आया।
तकनीकी भाग बहुत सरल है, यह एक पृष्ठभूमि परत की एक सामान्य ऊर्ध्वाधर स्क्रॉलिंग है। टाइल्स के ग्राफिक्स के एनीमेशन द्वारा रोटेशन प्रभाव प्राप्त किया जाता है, जबकि टाइल्स का मानचित्र अपरिवर्तित रहता है। एनीमेशन के लिए,
MMC3 मोड का
उपयोग चार
स्विचेबल CHR विंडो के साथ
किया जाता है । पहली विंडो में स्थिर भाग की टाइलें हैं, जबकि अन्य तीन अलग-अलग गति से स्विच करते हैं। खिड़कियों में से एक भी एनीमेशन की दिशा को सुचारू रूप से बदल देता है। चूंकि प्रत्येक खिड़की में 64 टाइलें रखी जाती हैं, और एनिमेटेड तत्व को केवल 28 की आवश्यकता होती है, इसलिए विपरीत दिशा में एनीमेशन प्राप्त करने के लिए प्रत्येक विंडो में टाइल्स के ग्राफिक्स को डुप्लिकेट किया जाता है।
प्रभाव को महसूस करने में मुख्य समस्या एनीमेशन की तैयारी थी। यह एक पीसी पर एक प्रोग्राम द्वारा निष्पादित किया गया था जो इनपुट में प्रत्येक पिक्सेल कॉलम के लिए 16x16 बनावट और एक गति तालिका लेता है, और 256 टाइल के सेट के रूप में एनीमेशन के 16 फ्रेम का एक ब्लॉक उत्पन्न करता है (जिनमें से कुछ खाली हैं)। सेट को
NES स्क्रीन टूल में वांछित प्रारूप में परिवर्तित किया जाता है और
इनबिन असेंबलर निर्देश के विकल्पों के माध्यम से वांछित ऑफसेट के साथ ROM ग्राफिक्स के बैंकों में वितरित किया जाता है।
अभिवादन के संबंध में एक और महत्वपूर्ण कार्य यह था कि उन्हें हर किसी को पारित करना न भूलें, जो करना चाहते हैं। चूंकि यह संख्या अनंत तक जाती है, और एक लंबे समय तक दृश्य उबाऊ लगता है। मैंने खुद को केवल उन लोगों तक सीमित रखने का फैसला किया जिनके साथ मैं एक साल से पार कर रहा था। उनके दिमाग में आते ही एक टेक्स्ट फाइल में नाम आ गए। बेशक, काम पूरा करने के बाद, यह पता चला कि मैं अभी भी बहुत से लोगों का उल्लेख करना भूल गया हूं।
गलियारा
एक दृष्टिकोण के साथ किसी तरह का दृश्य बनाने की इच्छा थी, जैसे कि एक क्लासिक सुरंग। क्लासिक सुरंग या एक वास्तविक
वोल्फेंस्टीन 3 डी रैकेस्टर जटिलता के कारण गायब हो गए हैं। इसके अलावा,
एनईएस में पहले से ही कई वास्तविक राकस्टर्स हैं, जिसमें बनावट शामिल हैं, लेकिन वे सभी बहुत कम गति के कारण बहुत प्रभावशाली नहीं दिखते हैं।
मुझे शुरुआती खेलों में छद्म-त्रि-आयामी ग्राफिक्स में बहुत दिलचस्पी है, और पुराने घटनाक्रमों के बीच पहले से ही मोड़ के चिकनी एनीमेशन के साथ एक प्रेत गलियारा था, जो
जेडएक्स स्पेक्ट्रम के लिए
ज़िग ज़ैग खेल से प्रेरित था। इसका उपयोग करने का निर्णय लिया गया। चूंकि अमूर्त गलियारा अपने आप में बहुत दिलचस्प नहीं है, इसलिए मारियो और शौचालय हास्य के साथ दृश्य का एक आंतरिक प्लॉट का आविष्कार किया गया था, जो तार्किक रूप से इसे पूरा करता है, साथ ही साथ डेमो भी। इस दृश्य को बहुत ही अंतिम रूप दिया गया था, और ब्लैंक के उपयोग के बावजूद, इस पर काम करने की योजना बनाने के दौरान तैयारी के काम की गिनती नहीं करते हुए, लगातार 11 घंटे से अधिक समय लगा।
सभी गति फ्रेम मैन्युअल रूप से आंधी में खोजे जाते हैं। 60 फ्रेम प्रति सेकंड से कम गति पर जाना, डेमो में यह एकमात्र प्रभाव है, हालांकि यह बिना किसी समस्या के उस गति से काम कर सकता है। गलियारे के साथ-साथ फेंकने के दौरान संगीत के साथ दृश्य पठनीयता और सिंक्रनाइज़ेशन के कारणों के लिए, स्क्रीन ताज़ा दर आंदोलन के मध्यवर्ती चरणों को जोड़ने के विकल्प के रूप में प्रति सेकंड 30 फ्रेम तक सीमित थी, जिसकी तैयारी के लिए कोई समय नहीं बचा था।
ग्राफिक्स फ्रेम टाइल्स के दो सेट ले गए। एनीमेशन के आवश्यक क्षणों में, पृष्ठभूमि की परत को अपडेट किया जाता है, ग्राफिक्स का वांछित सेट जुड़ा हुआ है और दो रंगों को दो पैलेट (स्क्रीन के ऊपरी और निचले आधे हिस्से के लिए) में सेट किया जाता है, जब 90 डिग्री मोड़ने के बाद दीवारों के रंग बदल जाते हैं।
एनीमेशन टाइल कार्ड को पहले RAM में एक नियत बैंक के एक कोड द्वारा ROM के दो प्लग-इन निचले बैंकों में से एक में कॉपी किया जाता है। प्रभाव की प्रदर्शित विंडो के ठीक नीचे रेखापुंज के प्रदर्शन के दौरान, रेंडर को बंद कर दिया जाता है और डेटा को रैम से वीडियो मेमोरी में स्थानांतरित किया जाता है। रेंडर को बंद करना भी मारियो स्प्राइट के लिए दृश्य कतरन के निचले हिस्से के रूप में कार्य करता है।
कैप्शन
यह दृश्य रंग सलाखों के बाद पहले में से एक था, जो पुरानी परियोजनाओं में से एक कोड के आधार पर था। इसके पास पहले से ही दो फोंट, अलग-अलग पट्टियों और अंत में मंदी के लिए समर्थन था। डेमो के लिए, नए फोंट तैयार किए गए थे, जो हर जगह उपयोग किए जाते हैं, और स्क्रीन के किनारों पर एक प्रभाव जोड़ा गया था।
पहले मैं किनारों को सुचारू रूप से कम करना चाहता था, लेकिन प्रारंभिक प्रयोगों के दौरान मैंने क्षैतिज रेखा ऑफसेट के साथ विकल्पों की कोशिश की, मुझे परिणाम पसंद आया, और मैंने अतिरिक्त समय नहीं बिताने का फैसला किया।
NES वीडियो
कंट्रोलर की विवादास्पद विशेषता, रंग घटकों के लाभ-म्यूटिंग का उपयोग करके थोड़ा सा छायांकन जोड़ा जाता है। विवाद इस तथ्य में निहित है कि कंसोल के विभिन्न क्षेत्रीय संस्करणों और क्लोनों में, यह फ़ंक्शन अलग-अलग काम करता है, लेकिन इस एप्लिकेशन में कोई विशेष समस्या नहीं होनी चाहिए (तथाकथित
आरजीबी पीपीयू को गिनना नहीं है, जहां किनारों को सफेद रंग से भरा जाएगा)।
राय
जिस समय के लिए कैप्शन दृश्य बनाया जा रहा था, उस समय इस दृश्य का विचार अनायास ही उठ गया। प्रारंभिक विचार इसे एक यादृच्छिक क्षण में सम्मिलित करना था, लेकिन अंत में यह सफलतापूर्वक समापन में फिट हो गया। इसकी छोटी अवधि के बावजूद, दृश्य में तीन तत्व होते हैं: स्प्राइट के स्केलिंग का अनुकरण करना, दो फ़्रेमों को बारी-बारी से ग्रे के रंगों की संख्या बढ़ाना, और प्रोग्रामेटिक रूप से
डीपीसीएम नमूना खेलना।
स्केलिंग का अनुकरण करने के लिए, यह तथ्य कि
एनईएस पर सभी बड़े स्प्राइट्स छोटे से बने होते हैं, इस मामले में आकार में 8x16 का उपयोग किया जाता है। यदि आप उन्हें एक दूसरे के सापेक्ष स्थानांतरित करते हैं, तो आप स्केलिंग या विरूपण का प्रभाव प्राप्त कर सकते हैं, जो परिवर्तनों के छोटे मूल्यों के साथ काफी सभ्य दिखता है। इस आशय के लिए, आपको केंद्र से प्रत्येक स्प्राइट के ऑफसेट को एक पैमाने से गुणा करना होगा, लेकिन चूंकि
एनईएस प्रोसेसर बड़ी संख्या में पूर्णांक गुणाओं का सामना नहीं कर सकता है, इसलिए चाल को लागू किया जाता है - फ्रेम की शुरुआत में, एक्स और वाई एक्सिस के साथ समन्वित ग्रिड माना जाता है, और स्प्राइट आउटपुट इन पूर्व-परिकलित मानों का उपयोग करता है । इस प्रकार, आवश्यक गुणा की संख्या काफी कम हो जाती है - 8x8 तत्वों (64 स्प्राइट्स) के एक समग्र स्प्रे के साथ, केवल 16 (8 + 8) गुणा 128 (8 * 8 * 2) के बजाय आवश्यक हैं।
NES केवल सफ़ेद और काले सहित ग्रे के 4 रंगों को प्रदर्शित कर सकता है। प्रभाव 7 ग्रेडों का अनुकरण करता है: यदि आप फ्रेम के माध्यम से एक सफेद और सफेद पिक्सेल प्रदर्शित करते हैं, तो यह सफेद होगा, अगर ग्रे और ग्रे यह ग्रे होगा, और यदि आप सफेद और ग्रे को वैकल्पिक करते हैं, तो नेत्रहीन यह सफेद और ग्रे रंग के मध्यवर्ती उन्नयन की तरह दिखेगा। मुख्य कठिनाई फिर से ग्राफिक्स की तैयारी है, अर्थात् छवि के दो आधे फ्रेम, जो
गेल और
जीआईएमपी में कई मैनुअल जोड़तोड़ द्वारा किया गया था। झिलमिलाहट को कम करने के लिए, आधे तख्ते की लाइनें वैकल्पिक होती हैं।
डीपीसीएम के प्रोग्रामेटिक प्लेबैक की आवश्यकता थी क्योंकि बेहतर प्रारूपों में नमूने के लिए कोई स्थान नहीं था, हार्डवेयर समर्थन मेमोरी के निचले आधे हिस्से से नमूने नहीं चला सकता था, लेकिन ऊपरी गैर-स्विटटेबल मेमोरी में ऐसी लंबाई के नमूने के लिए कोई स्थान नहीं था। ध्वनि का टुकड़ा अपने आप में मूल स्क्रीन सेवर से नहीं है, बल्कि वास्तविक परिष्करण के समय ध्वनि के साथ अच्छी तरह से ज्ञात गेम से एक समान लग रहा है।
मेमोरी कार्ड
विकास में, एनईएस स्पेस चेकर उपयोगिता का लगातार उपयोग किया गया था, जो मेमोरी बैंकों के भरने की कल्पना करता है। कार्यक्रम के अंदर क्या और कहाँ है, इसका एक अच्छा उदाहरण देखना काफी दिलचस्प है।
PRG00 ...
PRG02 - संगीत डेटा
PRG03 - एक दृश्य के साथ एक दृश्य के लिए नमूना
PRG04 ...
PRG06 - कारतूस रोटेशन एनीमेशन डेटा
PRG07 - गलियारे में टाइल एनीमेशन गहरा
PRG08 - गलियारे में टाइल रोटेशन एनीमेशन
PRG09 - टॉवर दृश्य कोड
PRG0A - घूर्णन लोगो के साथ दृश्य कोड
PRG0B - एक नाम और एक गलियारे के साथ दृश्य कोड
PRG0C - घूर्णन कारतूस, किर्बी, दृश्य, आक्रमणकारियों,
पाकमैन के साथ दृश्य कोड
PRG0D -
इंट्रो , शोर, रंग बार, कैप्शन के साथ दृश्य कोड
PRG0E - कोड का मुख्य बैंक, सभी दृश्यों के केवल कॉल हैं
PRG0F - फिक्स्ड कोड बैंक, म्यूजिक प्लेयर, स्प्राइट आउटपुट, इंटरप्ट हैंडलर
CHR00 - बच्चे हाथी और रंगीन धारियों के लिए टाइल
CHR01 - फ़ॉन्ट और शोर
CHR02 - देखें स्प्राइट और नाम में घूमते हुए अक्षरों की टाइलें
CHR03 - सामान्य किर्बी
टाइलेंCHR04 - चेशायर किर्बी
टाइलेंCHR05 - घूर्णन कारतूस के साथ एक दृश्य के लिए ग्राफिक्स
CHR06 ...
CHR0D - घूर्णन लोगो एनीमेशन
CHR0E - अभिवादन और आक्रमणकर्ता टाइलों के एनीमेशन के लिए एक फ़ॉन्ट
CHR0F -
पाकमैन टाइलेंCHR10 ...
CHR13 - टॉवर बनावट एनीमेशन
CHR14 - गलियारा
टाइलेंCHR15 -
स्प्राइट मारियो
CHR16 ...
CHR1F - उपयोग नहीं किया गया
एक निष्कर्ष के बजाय
मैं कॉम्बो मेमे के साथ समाप्त हो जाऊंगा: किसी भी विषम स्थिति में, डेमो दृश्य, सज्जनों को लिखूंगा!