गेम ब्वॉय, पार्ट 2 के लिए गेम बनाना

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

शानदार स्प्राइट और वे कहाँ रहते हैं

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

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

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

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

सोनिक 2 कार्ड प्रारूप

मैंने ध्वनि 2 में संपादक का उपयोग करने का इरादा किया क्योंकि मैं उत्पत्ति के लिए एक हैक बनाना चाहता था। सोनिक 1 और 3K मूल रूप से लगभग समान हैं, लेकिन जटिल नहीं होने के लिए, मैं खुद को दूसरे भाग के बारे में कहानी तक सीमित करूंगा।

सबसे पहले, आइए स्प्राइट के नक्शे देखें। यहाँ एक सुंदर ठेठ पूंछ स्प्रिंक, ब्लिंक एनीमेशन का हिस्सा है।


जेनेसिस कंसोल कुछ अलग तरीके से स्प्राइट बनाता है। जेनेसिस टाइल (ज्यादातर प्रोग्रामर इसे "पैटर्न" कहते हैं) गेम बॉय की तरह 8x8 है। स्प्राइट में 4x4 टाइल तक का आयताकार होता है, गेम बॉय पर 8x16 स्प्राइट मोड जैसा, लेकिन अधिक लचीला। यहां चाल यह है कि स्मृति में ये टाइलें एक दूसरे के बगल में होनी चाहिए। सोनिक 2 डेवलपर्स एक खड़े पूंछ फ्रेम से एक निमिष पूंछ फ्रेम के लिए जितनी संभव हो उतनी टाइलों का पुन: उपयोग करना चाहते थे। इसलिए, पूंछ को 2 हार्डवेयर स्प्राइट्स में विभाजित किया गया है, जिसमें 3x2 टाइल शामिल हैं - एक सिर के लिए, दूसरा शरीर के लिए। उन्हें नीचे दिए गए चित्र में दिखाया गया है।


इस संवाद बॉक्स के शीर्ष पर हार्डवेयर स्प्राइट विशेषताएँ हैं। इसमें प्रारंभिक बिंदु के सापेक्ष उनकी स्थिति होती है (नकारात्मक संख्याएं काट दी जाती हैं; वास्तव में, ये -16 और -12 पहले स्प्राइट के लिए और -12 दूसरे के लिए), वीआरएएम में प्रयुक्त प्रारंभिक टाइल, स्प्राइट की चौड़ाई और ऊंचाई, साथ ही साथ विभिन्न स्थिति बिट्स के लिए। स्प्राइट और पैलेट की दर्पण छवि।

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


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

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

हम सूप को संरचनाओं से साफ करते हैं

आइए कार्डों के प्रकार देखें:

1. स्प्राइट मैप्स: स्प्रिट्स की एक सूची जिसमें एक प्रारंभिक टाइल होती है, टाइल्स की संख्या, स्थिति, प्रतिबिंब स्थिति (स्प्राइट मिरर किया जाता है या नहीं) और एक पैलेट।
2. DPLC: ROM टाइल्स की एक सूची जिसे वीआरएएम में लोड करने की आवश्यकता है। DPLC में प्रत्येक आइटम में एक प्रारंभिक टाइल और एक लंबाई होती है; प्रत्येक आइटम को आखिरी के बाद वीआरएएम में रखा गया है।
3. एनिमेशन मैप्स: एनिमेशन की एक सूची जिसमें स्प्राइट मैप, स्पीड वैल्यू और साइकल एक्शन की सूची शामिल है।
4. एनीमेशन सूची: प्रत्येक एनीमेशन की कार्रवाई को इंगित करने वालों की एक सूची।

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

आइए यह पता लगाना शुरू करें कि मेरे गेम में समान प्रणाली को कैसे लागू किया जाए।

2e5e5b7 प्रतिबद्ध के साथ जांचें !

आइए शुरू करते हैं स्प्राइट मैप से। मानचित्र के प्रत्येक तत्व को OAM (ऑब्जेक्ट एट्रीब्यूट मेमोरी - स्प्राइट वीआरएएम) को दर्पण करना चाहिए और इस प्रकार ऑब्जेक्ट को प्रदर्शित करने के लिए एक सरल लूप और मेम्ची पर्याप्त होगा। आपको याद दिला दूं कि OAM में एक तत्व Y, X, एक प्रारंभिक टाइल और एक विशेषता बाइट होता है । मुझे बस उनकी एक सूची बनाने की जरूरत है। इकट्ठे छद्म-संचालक EQU का उपयोग करते हुए, मैंने पहले से ही विशेषता बाइट तैयार किया ताकि विशेषताओं के हर संभव संयोजन के लिए मेरे पास एक पठनीय नाम हो। (आप देख सकते हैं कि पिछली प्रतिबद्धताओं में, मैंने वाई / एक्स टाइल को कार्डों में बदल दिया था। ऐसा इसलिए हुआ क्योंकि मैंने ओएएम विनिर्देशों को अनजाने में पढ़ा। मैंने यह जानने के लिए एक स्प्रिट काउंटर भी जोड़ा कि लूप को कितना समय लेना चाहिए।)

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

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

रजिस्टरों के साथ नृत्य

इस फाइल को 1713848 पर देखें।

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

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

मान लीजिए कि हमारे पास 4 स्प्राइट हैं। हमने डी रजिस्टर (चक्र काउंटर) को 4, एचएल रजिस्टर (गंतव्य) ओएएम बफर पते, और बीसी (स्रोत) को रोम में स्थान निर्धारित किया है जहां हमारे कार्ड संग्रहीत हैं। अब मैं मेमकी को बुलाना चाहूंगा। हालाँकि, एक छोटी सी समस्या उत्पन्न होती है। एक्स और वाई निर्देशांक याद है? उन्हें प्रारंभिक बिंदु के सापेक्ष इंगित किया जाता है, वस्तु के केंद्र का उपयोग टकराव और पसंद के लिए किया जाता है। यदि हमने उन्हें दर्ज किया है, तो प्रत्येक वस्तु स्क्रीन के ऊपरी बाएँ कोने में प्रदर्शित होगी। यह हमें शोभा नहीं देता। इसे ठीक करने के लिए, हमें वस्तु के X और Y निर्देशांक को स्प्राइट के X और Y से जोड़ना होगा।

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

निर्णय की समीक्षा

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

शुरू करने के लिए, इसे "चरणों" में विभाजित करें। प्रत्येक चरण को केवल प्रतिलिपि प्राप्त करने वाले अंतिम के अपवाद के साथ, अगले के लिए डेटा प्राप्त करना चाहिए।

1. ऑब्जेक्ट (लूप) - यह पता लगाता है कि क्या वस्तु का प्रतिपादन किया जाना चाहिए, और उसे प्रस्तुत करना चाहिए।
2. एनीमेशन सूची - यह निर्धारित करती है कि किस एनीमेशन को प्रदर्शित करना है। किसी वस्तु के गुण भी मिलते हैं।
3. एनिमेशन (लूप) - यह निर्धारित करता है कि कौन से नक्शे का उपयोग करना है, और इसमें से प्रत्येक नक्शे को प्रस्तुत करना है।
4. मानचित्र (चक्र) - iteratively स्प्राइट की सूची में प्रत्येक स्प्राइट से गुजरता है
5. स्प्राइट - प्रतियां स्प्राइट्स OAM बफर को विशेषताएँ

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

विवरण	आकार	मंच	के उपयोग	कहाँ से?	जगह	कहाँ तक
OAM बफर	2	प्रेत	सूचक	HL	HL
नक्शा स्रोत	2	प्रेत	सूचक	ईसा पूर्व	ईसा पूर्व
वर्तमान बाइट	1	प्रेत	कार्य स्थान	नक्शा स्रोत	ए
एक्स	1	प्रेत	परिवर्तनशील	हीराम	एक
Y	1	प्रेत	परिवर्तनशील	हीराम	एक
एनीमेशन मैप की शुरुआत	2	स्प्राइट मैप	सूचक	Stack3	डे
नक्शा स्रोत	2	स्प्राइट मैप	सूचक	[डे]	ईसा पूर्व
शेष रहना	1	स्प्राइट मैप	खरोंच	नक्शा स्रोत	डी
OAM बफर	1	स्प्राइट मैप	सूचक	HL	HL	Stack1
एनीमेशन मैप की शुरुआत	2	एनीमेशन	कार्य स्थान	बीसी / स्टैक 3	ईसा पूर्व	Stack3
शेष कार्ड	1	एनीमेशन	कार्य स्थान	एनीमेशन शुरू	हीराम
कार्ड की कुल संख्या	1	animaniya	परिवर्तनशील	एनीमेशन शुरू	हीराम
वस्तु दिशा	1	एनीमेशन	परिवर्तनशील	हीराम	हीराम
प्रति फ्रेम कार्ड	1	एनीमेशन	परिवर्तनशील	एनीमेशन शुरू	उपयोग नहीं किया !!!
फ्रेम नंबर	1	एनीमेशन	परिवर्तनशील	हीराम	एक
नक्शा सूचक	2	एनीमेशन	सूचक	एनिमस्टार्ट + डीआर * टीएमसी + एमपीपीएफ * एफ #	ईसा पूर्व	डे
OAM बफर	2	एनीमेशन	सूचक	Stack1	HL
एनीमेशन तालिका की शुरुआत	2	एनीमेशन सूची	कार्य स्थान	कठिन सेट	डे
वस्तु स्रोत	2	एनीमेशन सूची	सूचक	HL	HL	Stack2
फ्रेम नंबर	1	एनीमेशन सूची	परिवर्तनशील	वस्तु स्रोत	हीराम
एनीमेशन संख्या	1	एनीमेशन सूची	कार्य स्थान	वस्तु स्रोत	एक
एक्स ऑब्जेक्ट	1	वस्तुओं की सूची	परिवर्तनशील	वस्तु स्रोत	हीराम
Y वस्तु	1	एनीमेशन सूची	परिवर्तनशील	वस्तु स्रोत	हीराम
वस्तु दिशा	1	एनीमेशन सूची	परिवर्तनशील	Obj src	हीराम
एनीमेशन मैप की शुरुआत	2	एनीमेशन सूची	सूचक	[एनिमेटेड तालिका + एनिमेटेड #]	ईसा पूर्व
OAM बफर	2	एनीमेशन सूची	सूचक	डे	Stack1
वस्तु स्रोत	2	वस्तु चक्र	Ukaztel	हार्ड सेट / स्टैक 2	HL
शेष वस्तु	1	वस्तु चक्र	परिवर्तनशील	गणना	बी
किसी वस्तु का सक्रिय क्षेत्र	1	वस्तु चक्र	परिवर्तनशील	गणना	सी
OAM बफर	2	वस्तु चक्र	सूचक	कठिन सेट	डे

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

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

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

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

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

भाग 4. लंबन पृष्ठभूमि

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

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

पृष्ठभूमि

गेम बॉय पर पृष्ठभूमि 8x8 टाइलों के 32x32 सरणी में मेमोरी में संग्रहीत की जाती है। हर 32 बाइट टाइल्स की एक पंक्ति से मेल खाती है।


अब तक, मैं पूरे 32x32 अंतरिक्ष में टाइल के एक ही कॉलम को दोहराने की योजना बना रहा हूं। यह बहुत अच्छा है, लेकिन यह एक छोटी सी समस्या पैदा करता है: मुझे प्रत्येक टाइल को लगातार 32 बार सेट करना होगा। यह लिखने के लिए एक लंबा समय होगा।

सहज रूप से, मैंने 32 बाइट्स / लाइन जोड़ने के लिए REPT कमांड का उपयोग करने का निर्णय लिया, और फिर VRAM में पृष्ठभूमि की प्रतिलिपि बनाने के लिए मेमचपी का उपयोग किया।

 REPT 32 db BG_SKY ENDR REPT 32 db BG_GRASS ENDR ... 

हालांकि, इसका मतलब यह होगा कि आपको केवल एक पृष्ठभूमि के लिए 256 बाइट आवंटित करना होगा, जो कि बहुत अधिक है। यह समस्या समाप्त हो जाती है यदि आपको याद है कि पहले से बनाए गए पृष्ठभूमि मानचित्र को मेम्ची के साथ कॉपी करने से आप महत्वपूर्ण जटिलता और बर्बाद रॉम कारतूस के ढेर के बिना अन्य प्रकार के कॉलम (उदाहरण के लिए, गेट्स, बाधाएं) को जोड़ने की अनुमति नहीं देंगे।

इसलिए इसके बजाय, मैंने इस प्रकार एक एकल स्तंभ स्थापित करने का निर्णय लिया:

 db BG_SKY, BG_SKY, BG_SKY, ..., BG_GRASS 

और फिर इस सूची में प्रत्येक आइटम को 32 बार कॉपी करने के लिए एक साधारण लूप का उपयोग करें। ( LoadGFX प्रतिबद्ध LoadGFX फ़ाइल LoadGFX देखें।)

इस दृष्टिकोण की सुविधा यह है कि बाद में मैं इस तरह से कुछ लिखने के लिए एक कतार जोड़ सकता हूं:

 BGCOL_Field: db BG_SKY, ... BGCOL_LeftGoal: db BG_SKY, ... BGCOL_RightGoal: db BG_SKY, ... ... BGMAP_overview: db 1 dw BGCOL_LeftGoal db 30 dw BGCOL_Field db 1 dw BGCOL_RightGoal db $FF 

अगर मैं BGMAP_overview रेंडर करने का फैसला करता हूं, तो यह LeftGoal के 1 कॉलम को आकर्षित करेगा, जिसके बाद फ़ील्ड के 30 कॉलम और RightGoal के 1 कॉलम होंगे। अगर BGMAP_overview रैम में है, तो मैं इसे एक्स में कैमरे की स्थिति के आधार पर मक्खी पर बदल सकता हूं।

कैमरा और स्थिति

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

हमें दो समन्वय प्रणालियों के साथ काम करने की आवश्यकता है। पहली स्क्रीन निर्देशांक है । यह 256x256 का एक क्षेत्र है जिसे गेम बॉय कंसोल के वीआरएएम में शामिल किया जा सकता है। हम इन 256x256 के भीतर स्क्रीन के दृश्य भाग को स्क्रॉल कर सकते हैं, लेकिन जब हम सीमाओं से परे जाते हैं, तो हम ढह जाते हैं।

चौड़ाई में, मुझे 256 पिक्सेल से अधिक की आवश्यकता है, इसलिए मैं विश्व निर्देशांक जोड़ता हूं, जिसमें इस खेल में 65536x256 के आयाम होंगे। (मुझे वाई में अतिरिक्त ऊंचाई की आवश्यकता नहीं है, क्योंकि खेल एक सपाट मैदान पर होता है।) यह प्रणाली स्क्रीन समन्वय प्रणाली से पूरी तरह से अलग है। दुनिया के निर्देशांक में सभी भौतिकी और टकरावों का प्रदर्शन किया जाना चाहिए, क्योंकि अन्यथा वस्तुएं अन्य स्क्रीन पर वस्तुओं से टकराएंगी।


स्क्रीन और दुनिया के समन्वय की तुलना

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

ऐसा करने के लिए, हम "कैमरा एक्स" चर सेट करेंगे, जिसे दुनिया में स्क्रीन की बाईं सीमा के रूप में परिभाषित किया गया है। उदाहरण के लिए, यदि camera X 1000 है, तो हम दुनिया के निर्देशांक 1000-1192 देख सकते हैं, क्योंकि दृश्यमान स्क्रीन की चौड़ाई 192 पिक्सेल है।

वस्तुओं को संसाधित करने के लिए, हम बस X (उदाहरण के लिए, 1002) में उनकी स्थिति लेते हैं, कैमरे की स्थिति को 1000 के बराबर घटाते हैं, और अंतर द्वारा दी गई स्थिति पर वस्तु को खींचते हैं (हमारे मामले में, 2)। एक ऐसी पृष्ठभूमि के लिए जो दुनिया के निर्देशांक में नहीं है, लेकिन पहले से ही स्क्रीन निर्देशांक में वर्णित है, हम camera X चर के निचले बाइट के बराबर स्थिति सेट करते हैं। इसके लिए धन्यवाद, पृष्ठभूमि कैमरे के साथ बाएं और दाएं स्क्रॉल करेगी।

लंबन

हमने जो सिस्टम बनाया है वह सपाट दिखता है। प्रत्येक पृष्ठभूमि परत एक ही गति से चलती है। यह त्रि-आयामी महसूस नहीं करता है, और हमें इसे ठीक करने की आवश्यकता है।

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

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



हालांकि, गेम बॉय पर इस तरह की प्रणाली को लागू करते समय, एक छोटी सी समस्या उत्पन्न होती है। कंसोल में केवल एक पृष्ठभूमि परत है। यह इस तथ्य के समान है कि हमारे पास कागज की केवल एक शीट है। आप कागज के सिर्फ एक शीट के साथ एक लंबन प्रभाव नहीं बना सकते। या यह संभव है?

एच रिक्त

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

VBlank इंटरप्ट के समान, जिसे हम VRAM में रिकॉर्डिंग के लिए फ्रेम के अंत तक लगातार इंतजार करते थे, एक HBlank इंटरप्ट है। $FF41 में रजिस्टर 6 की बिट 6 सेट करके, LCD STAT रुकावट को चालू करते हुए, और $FF45 पर लाइन नंबर $FF45 , हम गेम बॉय को LCD STAT व्यवधान शुरू करने के लिए कह सकते हैं जब वह निर्दिष्ट लाइन (और जब वह उसके HBlank में हो) के बारे में है।

इस समय के दौरान, हम किसी भी वीआरएएम चर को बदल सकते हैं। यह बहुत समय नहीं है, इसलिए हम कुछ रजिस्टरों से अधिक नहीं बदल सकते हैं, लेकिन हमारे पास अभी भी कुछ संभावनाएं हैं। हम $FF43 पर क्षैतिज स्क्रॉल रजिस्टर बदलना चाहते हैं। इस मामले में, निर्दिष्ट लाइन के नीचे स्क्रीन पर सब कुछ एक निश्चित राशि से स्थानांतरित हो जाएगा, एक लंबन प्रभाव पैदा करेगा।

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

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


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

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

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

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

परिणाम

इस सब के बाद , मुझे निम्नलिखित मिला:


गेम बॉय पर गेम के लिए, यह वास्तव में बहुत अच्छा है। जहां तक ​​मुझे पता है, उनमें से सभी को इस तरह से लंबन स्क्रॉल लागू नहीं किया गया है।