हम कोर्टेक्स M0 + माइक्रोकंट्रोलर पर एक पोर्टेबल प्लेटफ़ॉर्म गेम बनाते हैं

परिचय

(स्रोत कोड और KiCAD परियोजना के लिंक लेख के अंत में दिए गए हैं।)

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


Amiga पर Lionheart। यह स्थिर छवि ग्राफिक्स की सुंदरता को व्यक्त नहीं करती है।

90 के दशक के बाद से, इलेक्ट्रॉनिक्स बहुत बदल गया है, और अब कई छोटे माइक्रोकंट्रोलर हैं जो आपको अद्भुत चीजें बनाने की अनुमति देते हैं।

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

लेकिन यह कार्य हमारे लिए नहीं है - हम एक तोप से गौरैया को नहीं मारना चाहते हैं!

हम सीमित मेमोरी के साथ माइक्रोकंट्रोलर्स का उपयोग करना चाहते हैं, और एक एकीकृत जीपीयू के साथ चिप पर शक्तिशाली प्रणाली नहीं! दूसरे शब्दों में, हम कठिनाइयों चाहते हैं!

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

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

वह Arduino ड्यू जितना शक्तिशाली नहीं है, लेकिन Arduino Uno जितना कमजोर नहीं है। दिलचस्प है, "ड्यू" का अर्थ है "दो," और "ऊनो" का अर्थ है "एक"। Microsoft ने हमें सही तरीके से (1, 2, 3, 95, 98, ME, 2000, XP, विस्टा, 7, 8, 10) को गिनना सिखाया, और Arduino भी इस तरह से चला गया! हम Arduino Zero का उपयोग करेंगे, जो कि 1 और 2 के बीच में है!

हाँ, Arduino के अनुसार, 1 <0 <2।

विशेष रूप से, हम बोर्ड में ही दिलचस्पी नहीं रखते हैं, लेकिन इसके प्रोसेसर की श्रृंखला में। Arduino Zero में Cortex M0 + (48 MHz), 256 KB फ्लैश मेमोरी और 32 KB रैम के साथ ATSAMD21 श्रृंखला का माइक्रोकंट्रोलर है।

यद्यपि 48-मेगाहर्ट्ज कोर्टेक्स M0 + प्रदर्शन में पुराने 7-मेगाहर्ट्ज MC68000 से काफी बेहतर है, अमिगा 500 में 512 केबी रैम, हार्डवेयर स्प्राइट्स, एक एकीकृत दोहरी गेम बोर्ड, ब्लिटर (एक डीएमए-आधारित पिक्सेल-सटीक टक्कर मान्यता प्रणाली के साथ डीएमए-आधारित ब्लॉक ट्रांसफर इंजन) है। और पारदर्शिता) और कॉपर (एक रेखापुंज कोप्रोसेसर जो आपको कई बहुत सुंदर प्रभाव बनाने के लिए स्वीप स्थिति के आधार पर रजिस्टरों के साथ संचालन करने की अनुमति देता है)। SAMD21 में यह सब हार्डवेयर नहीं है (ब्लिटर डीएमए की तुलना में एक साधारण सरल के अपवाद के साथ), इसलिए प्रोग्राम को बहुत अधिक रूप से प्रस्तुत किया जाएगा।

हम निम्नलिखित मापदंडों को प्राप्त करना चाहते हैं:

• 1.8 इंच के एसपीआई डिस्प्ले पर रिज़ॉल्यूशन 160 x 128 पिक्सल्स।
• पिक्सेल प्रति 16 बिट्स के साथ ग्राफिक्स;
• उच्चतम फ्रेम दर। 12 मेगाहर्ट्ज एसपीआई में कम से कम 25 एफपीएस, या 24 मेगाहर्ट्ज पर 40 एफपीएस;
• लंबन स्क्रॉलिंग के साथ डबल प्लेइंग फील्ड;
• सब कुछ सी में लिखा है। कोई कोड कोड नहीं;
• टक्करों की पिक्सेल-सटीक पहचान;
• स्क्रीन ओवरले।

ऐसा लगता है कि इन लक्ष्यों को हासिल करना काफी मुश्किल है। यह है, खासकर अगर हम कोड को asm पर मना कर देते हैं!

उदाहरण के लिए, 16-बिट रंग के साथ, स्क्रीन के लिए 160 × 128 पिक्सेल के स्क्रीन बफर के लिए 40 KB की आवश्यकता होगी, लेकिन हमारे पास केवल 32 KB RAM है! और हमें अभी भी कम से कम 25/40 एफपीएस की आवृत्ति के साथ एक डबल प्लेइंग फ़ील्ड और बहुत अधिक पर लंबन स्क्रॉलिंग की आवश्यकता है!

लेकिन हमारे लिए कुछ भी असंभव नहीं है, है ना?

हम ATSAMD21 के ट्रिक्स और बिल्ट-इन कार्यों का उपयोग करते हैं! "हार्डवेयर" के रूप में हम uChip लेते हैं, जिसे इटका स्टोर में खरीदा जा सकता है।


uChip: हमारे प्रोजेक्ट का दिल!

इसमें Arduino Zero जैसी ही विशेषताएँ हैं, लेकिन यह बहुत छोटी है, और मूल Arduino Zero की तुलना में सस्ती भी है (हाँ, आप AliExpress पर $ 10 के लिए नकली Arduino Zero खरीद सकते हैं ... लेकिन हम मूल पर बनाना चाहते हैं)। यह हमें एक छोटा पोर्टेबल कंसोल बनाने की अनुमति देगा। आप Arduino Zero के लिए इस परियोजना को लगभग सहज रूप से अनुकूलित कर सकते हैं, केवल परिणाम आकार में काफी बोझिल होगा।

हमने एक छोटा परीक्षण बोर्ड भी बनाया जो गरीबों के लिए पोर्टेबल कंसोल लागू करता है। नीचे विवरण!


हम Arduino ढांचे का उपयोग नहीं करेंगे। जब यह अनुकूलन और उपकरणों के प्रबंधन की बात आती है तो यह अच्छी तरह से अनुकूल नहीं है। (और आइडी के बारे में बात नहीं करते हैं!)

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

इसके अलावा, कई और अधिक अनुकूलन विकल्प हैं, यहां तक ​​कि कोडांतरक के बिना भी!

तो, चलो हमारी यात्रा शुरू करते हैं!

जटिलता

वास्तव में, परियोजना के दो जटिल पहलू हैं: समय और मेमोरी (रैम और स्टोरेज दोनों)।

स्मृति

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


अमीगा पर तूफ़ान 2। सभी समय का सबसे अच्छा मंच खेल में से एक। आप इसमें आसानी से टाइल्स देख सकते हैं!

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

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

समय - सीपीयू

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

तो, हमें 160 × 128 पिक्सेल की स्क्रीन पर कम से कम 25 एफपीएस की आवश्यकता है। यह 512,000 पिक्सेल / s है। चूंकि माइक्रोकंट्रोलर 48 मेगाहर्ट्ज की आवृत्ति पर काम करता है, हमारे पास प्रति पिक्सेल कम से कम 93 घड़ी चक्र हैं। अगर हम 40 एफपीएस पर निशाना लगाते हैं तो यह मूल्य 58 चक्र तक गिर जाता है।

वास्तव में, हमारा माइक्रोकंट्रोलर एक बार में 2 पिक्सेल तक प्रसंस्करण करने में सक्षम है, क्योंकि प्रत्येक पिक्सेल में 16 बिट्स होते हैं, और एटीएसएएमडी 21 में 32-बिट आंतरिक बस है, अर्थात, प्रदर्शन भी बेहतर होगा!

93 घड़ी चक्र का एक मान बताता है कि कार्य पूरी तरह से संभव है! वास्तव में, हम यह निष्कर्ष निकाल सकते हैं कि सीपीयू अकेले डीएमए के बिना सभी प्रतिपादन कार्यों को संभाल सकता है। सबसे अधिक संभावना है, यह सच है, खासकर जब कोडांतरक के साथ काम करना। हालांकि, कोड को संभालना बहुत मुश्किल होगा। और सी में यह बहुत अनुकूलित किया जाना है! वास्तव में, Cortex M0 +, Cortex M3 की तरह सी-फ्रेंडली नहीं है, और इसमें बहुत सारे निर्देशों का अभाव है (यह बाद में / पूर्व-वेतन वृद्धि / वृद्धि के साथ लोड / सेव नहीं करता है, जिसे दो या अधिक सरल निर्देशों के साथ लागू किया जाना चाहिए।

आइए देखें कि दो गेम फ़ील्ड बनाने के लिए हमें क्या करने की आवश्यकता है (यह मानते हुए कि हम पहले से ही x और y निर्देशांक आदि जानते हैं)।

• फ्लैश मेमोरी में अग्रभूमि पिक्सेल के स्थान की गणना करें।
• पिक्सेल मान प्राप्त करें।
• यदि यह पारदर्शी है, तो फ्लैश में पृष्ठभूमि पिक्सेल की स्थिति की गणना करें।
• पिक्सेल मान प्राप्त करें।
• लक्ष्य स्थान की गणना करें।
• पिक्सेल को बफर में सहेजें।

इसके अलावा, प्रत्येक स्प्राइट के लिए जो बफर में जा सकता है, निम्नलिखित ऑपरेशन किए जाने चाहिए:

• फ्लैश मेमोरी में स्प्राइट पिक्सेल की स्थिति की गणना करें।
• पिक्सेल मान प्राप्त करना।
• यदि यह पारदर्शी नहीं है, तो गंतव्य बफर के स्थान की गणना करें।
• बफर में एक पिक्सेल की बचत।

ये सभी ऑपरेशन न केवल एक एएसएम निर्देश के रूप में कार्यान्वित किए जाते हैं, बल्कि रैम / फ्लैश मेमोरी तक पहुंचने पर प्रत्येक एएसएम निर्देश को दो चक्रों की आवश्यकता होती है।

इसके अलावा, हमारे पास अभी भी गेमप्ले लॉजिक नहीं है (जो, सौभाग्य से, समय की एक छोटी राशि लेता है, क्योंकि इसकी गणना प्रति फ्रेम एक बार की जाती है), टकराव की मान्यता, बफर प्रसंस्करण, और एसपीआई के माध्यम से डेटा भेजने के लिए आवश्यक निर्देश।

उदाहरण के लिए, यहाँ हमें जो करना है उसका छद्म कोड है (अब के लिए, हम मानते हैं कि खेल में स्क्रॉलिंग नहीं है, और खेल के मैदान में एक निरंतर रंग पृष्ठभूमि है!) केवल अग्रभूमि के लिए।

कैमरावाई और कैमरा एक्स को खेल की दुनिया में प्रदर्शन के ऊपरी बाएँ कोने का निर्देशांक माना जाता है।

बता दें कि xTilepos और yTilepos मानचित्र पर वर्तमान टाइल की स्थिति है।

xTilepos = cameraX / 16; // this is a rightward shift of 4 bits. yTilepos = cameraY / 16; destBufferAddress = &buffer[0][0]; for tile = 0...9 nTile = gameMap[yTilepos][xTilepos]; tileDataAddress = &tileData[nTile]; xTilepos = xTilepos + 1; for y = 0…15 for x = 0…15 pixel = *tileDataAddress; tileDataAddress = tileDataAddress + 1; *destBufferAddress = pixel; destBufferAddress = destBufferAddress + 1; next destBufferAddress = destBufferAddress + 144; // point to next row next destBufferAddress = destBufferAddress – ( 160 * 16 - 16); // now point to the position where the next tile will be saved. next 

2560 पिक्सल (160 x 16) के लिए निर्देशों की संख्या लगभग 16k है, अर्थात्। 6 प्रति पिक्सेल। वास्तव में, आप एक बार में दो पिक्सेल खींच सकते हैं। यह प्रति पिक्सेल निर्देशों की वास्तविक संख्या को आधा कर देता है, अर्थात प्रति पिक्सेल उच्च-स्तरीय निर्देशों की संख्या लगभग 3 है। हालांकि, इनमें से कुछ उच्च-स्तरीय निर्देशों को या तो दो या अधिक कोडांतरक निर्देशों में विभाजित किया जाएगा, या उन्हें पूरा करने के लिए कम से कम दो चक्रों की आवश्यकता होगी। स्मृति के लिए। इसके अलावा, हमने फ्लैश मेमोरी के लिए जंप और वेट स्टेट्स के कारण सीपीयू पाइपलाइन को रीसेट करने पर विचार नहीं किया। हां, हम अभी भी अपने निपटान में 58-93 चक्रों से दूर हैं, लेकिन हमें अभी भी खेल के मैदान और स्प्राइट्स की पृष्ठभूमि को ध्यान में रखना होगा।

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

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

SysTick टाइमर का उपयोग करते हुए, हमें पता चला कि पूरे ब्लॉक के लिए डीएमए तैयार करने के लिए आवश्यक समय, और फिर डीएमए को पूरा करने के लिए लगभग 12k घड़ी चक्र है। नोट: घड़ी चक्र! उच्च स्तरीय निर्देश नहीं! केवल 2560 पिक्सेल के लिए चक्रों की संख्या काफी अधिक है, अर्थात 1,280 32-बिट शब्द। वास्तव में, हम प्रति 32-बिट शब्द के बारे में 10 चक्र प्राप्त करते हैं। हालांकि, आपको डीएमए तैयार करने के लिए आवश्यक समय पर विचार करने की आवश्यकता है, साथ ही डीएमए को रैम से स्थानांतरण विवरणकों को लोड करने के लिए समय लगता है (जिसमें अनिवार्य रूप से पॉइंटर्स और स्थानांतरित बाइट्स की संख्या शामिल है)। इसके अलावा, हमेशा कुछ प्रकार की मेमोरी बस परिवर्तन होता है (ताकि सीपीयू बिना डेटा के निष्क्रिय न खड़ा हो), और फ्लैश मेमोरी में कम से कम एक प्रतीक्षा स्थिति की आवश्यकता होती है।

समय - एसपीआई

एक और अड़चन है SPI। क्या 12 मेगाहर्ट्ज 25 एफपीएस के लिए पर्याप्त है? इसका उत्तर हां है: 12 मेगाहर्ट्ज प्रति सेकंड लगभग 36 फ्रेम से मेल खाती है। अगर हम 24 MHz का उपयोग करते हैं, तो सीमा दोगुनी हो जाएगी!

वैसे, डिस्प्ले और माइक्रोकंट्रोलर के विनिर्देशों का कहना है कि अधिकतम एसपीआई गति क्रमशः 15 और 12 मेगाहर्ट्ज है। हमने परीक्षण किया और यह सुनिश्चित किया कि इसे समस्याओं के बिना 24 मेगाहर्ट्ज तक बढ़ाया जा सकता है, कम से कम "दिशा" में हमें ज़रूरत है (प्रदर्शन के लिए माइक्रोकंट्रोलर लिखते हैं)।

हम लोकप्रिय 1.8-इंच SPI डिस्प्ले का उपयोग करेंगे। हमने यह सुनिश्चित किया कि ILI9163 और ST7735 दोनों 12 मेगाहर्ट्ज की आवृत्ति के साथ सामान्य रूप से संचालित होते हैं (कम से कम 12 मेगाहर्ट्ज के साथ। यह सत्यापित किया जाता है कि ST7735 24 मेगाहर्ट्ज तक की आवृत्ति के साथ संचालित होता है)। यदि आप ट्यूटोरियल में "Arduino Uno पर वीडियो कैसे चलाएं" के समान प्रदर्शन का उपयोग करना चाहते हैं, तो हम अनुशंसा करते हैं कि आप इसे भविष्य में SD समर्थन जोड़ना चाहते हैं। हम एसडी कार्ड संस्करण का उपयोग कर रहे हैं ताकि हमारे पास अन्य तत्वों के लिए बहुत जगह हो, जैसे कि ध्वनि या अतिरिक्त स्तर।

ग्राफिक्स

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


दो टाइलें 32 × 32 पिक्सेल आकार में (बाईं और केंद्र), जो एक छोटे से भाग में भिन्न होती हैं (पिक्सेल का ऊपरी दाहिना भाग 16 इंच) है। इसलिए, हमें 32 × 32 पिक्सेल के आकार के साथ दो अलग-अलग टाइलों को संग्रहीत करने की आवश्यकता है। यदि हम 16 × 16 पिक्सेल टाइल (दाईं ओर) का उपयोग करते हैं, तो हमें केवल दो 16 × 16 टाइलें (पूरी तरह से सफेद टाइल और दाईं ओर एक टाइल) संग्रहीत करने की आवश्यकता है। हालांकि, 16 × 16 टाइल्स का उपयोग करते समय, हमें 4 मानचित्र तत्व मिलते हैं।

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

हमारी स्क्रीन का आकार 160 × 128 है। दूसरे शब्दों में, हमें प्रति स्क्रीन 10 × 8 टाइलें चाहिए, अर्थात्। तालिका में 80 प्रविष्टियाँ। 10 × 10 स्क्रीन (या 100 × 1 स्क्रीन) के बड़े स्तर के लिए, केवल 8,000 रिकॉर्ड की आवश्यकता होगी (यदि हम रिकॉर्डिंग के लिए 16 बिट्स का उपयोग करते हैं तो 16 केबी। बाद में हम दिखाएंगे कि हमने रिकॉर्डिंग के लिए 16 बिट्स चुनने का फैसला क्यों किया)।

इसकी तुलना उस मेमोरी से करें जिसकी पूरी स्क्रीन पर बड़ी तस्वीर के कब्जे में होने की संभावना है: 40 KB * 100 = 4 MB! यह पागल है!

चलो प्रतिपादन प्रणाली के बारे में बात करते हैं।

प्रत्येक फ्रेम में (ड्राइंग क्रम में) होना चाहिए:

• बैकग्राउंड ग्राफिक्स (बैक प्लेइंग फील्ड)
• स्तर का ग्राफ ही (अग्रभूमि)।
• स्प्राइट
• पाठ / शीर्ष ओवरले।

विशेष रूप से, हम क्रमिक रूप से निम्नलिखित कार्य करेंगे:

1. ड्राइंग पृष्ठभूमि + अग्रभूमि (टाइल्स)
2. पारभासी टाइल्स + स्प्राइट + शीर्ष ओवरले खींचना
3. एसपीआई द्वारा डेटा भेजना।

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


आंशिक रूप से पारदर्शी टाइल (बाएं) और पूरी तरह से अपारदर्शी (दाएं)। आंशिक रूप से पारदर्शी टाइल में, कुछ पिक्सेल (निचले बाएँ में) पारदर्शी होते हैं, और इसलिए इस क्षेत्र के माध्यम से एक पृष्ठभूमि दिखाई देती है।

आंशिक रूप से पारदर्शी टाइल, स्प्राइट और ओवरले को डीएमए द्वारा प्रभावी ढंग से प्रस्तुत नहीं किया जा सकता है। वास्तव में, एटीएसएएमडी 21 चिप डीएमए सिस्टम केवल डेटा की प्रतिलिपि बनाता है, और अमीगा कंप्यूटर के ब्लिटर के विपरीत, यह पारदर्शिता (रंग मान द्वारा निर्धारित) की जांच नहीं करता है। सभी आंशिक रूप से पारदर्शी तत्व सीपीयू द्वारा तैयार किए गए हैं।


डेटा को फिर डीएमए का उपयोग करके डिस्प्ले में प्रसारित किया जाता है।

पाइप लाइन बनाना

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

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

यहाँ एक ही समय में क्या होता है:

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

डीएमए

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

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

डीएमए अलग-अलग लंबाई के डेटा के साथ काम कर सकता है: बाइट्स, हाफ़वर्ड्स (16 बिट्स) और शब्द (32 बिट्स)। विनिर्देशन में, इस लंबाई को "हरा आकार" कहा जाता है। एसपीआई के लिए, हमें बाइट ट्रांसफर का उपयोग करने के लिए मजबूर किया जाता है (हालांकि वर्तमान REVD विनिर्देशन में कहा गया है कि ATSAMD21 SERCOM चिप्स में FIFO है, जो माइक्रोचिप के अनुसार, 32-बिट डेटा को स्वीकार कर सकता है, वास्तव में, ऐसा लगता है कि उनके पास FIFO नहीं है। REVD विनिर्देश में भी उल्लेख है। SERCOM CTRLC रजिस्टर, जो हेडर फ़ाइलों और रजिस्टर विवरण अनुभाग दोनों में अनुपस्थित है। सौभाग्य से, AVR के विपरीत, ATSAMD21 में कम से कम एक बफर ट्रांसफर डेटा रजिस्टर है, इसलिए ट्रांसमिशन में कोई रोक नहीं होगी!)। टाइल्स खींचने के लिए, हम, निश्चित रूप से, 32 बिट्स का उपयोग करते हैं। यह आपको प्रति पिक्सेल दो पिक्सेल कॉपी करने की अनुमति देता है। एटीएसएएमडी 21 डीएमए चिप प्रत्येक स्रोत को बीट आकार की निश्चित संख्या से स्रोत या गंतव्य पते को बढ़ाने के लिए हरा देता है।

ये दो पहलू बहुत महत्वपूर्ण हैं और वे टाइल खींचने के तरीके को निर्धारित करते हैं।

सबसे पहले, अगर हम एक पिक्सेल प्रति बीट (16 बिट्स) प्रदान करते हैं, तो हम अपने सिस्टम के थ्रूपुट को आधा कर देंगे। हम पूर्ण बैंडविड्थ को मना नहीं कर सकते हैं!

हालाँकि, यदि हम प्रति पिक्सेल दो पिक्सेल खींचते हैं, तो खेल क्षेत्र केवल पिक्सेल की एक समान संख्या को स्क्रॉल करने में सक्षम होगा, जिससे चिकनी गति होगी। इसे संभालने के लिए, आप एक बफर का उपयोग कर सकते हैं जो दो या दो से अधिक पिक्सेल बड़ा हो। डिस्प्ले में डेटा भेजते समय, हम सही ऑफ़सेट (0 या 1 पिक्सेल) का उपयोग करेंगे, इस पर निर्भर करते हुए कि हमें "कैमरा" को एक समान या विषम संख्या में पिक्सेल ले जाने की आवश्यकता है।

हालांकि, सादगी के लिए, हम 11 पूर्ण टाइलों (160 + 16 पिक्सल) के लिए स्थान आरक्षित करते हैं, और 160 + 2 पिक्सल के लिए नहीं। इस दृष्टिकोण का एक बड़ा फायदा है: हमें प्रत्येक डीएमए विवरणक के प्राप्तकर्ता पते की गणना और अद्यतन नहीं करना है (इसके लिए कई निर्देशों की आवश्यकता होगी, जिसके परिणामस्वरूप प्रति टाइल बहुत अधिक गणना हो सकती है)। निश्चित रूप से, हम केवल न्यूनतम पिक्सेल की संख्या को आकर्षित करेंगे, अर्थात 162 से अधिक नहीं। हां, अंत में हम थोड़ी अतिरिक्त मेमोरी (तीन बफ़र्स खाते हुए यह लगभग 1500 बाइट्स लेते हैं) को गति और सरलता के लिए खर्च करेंगे। आप आगे अनुकूलन भी कर सकते हैं।


इस GIF एनीमेशन में सभी 16-लाइन ब्लॉक बफ़र (बिना डिस्क्रिप्टर के) दिखाई दे रहे हैं। दाईं ओर वह है जो वास्तव में प्रदर्शित होता है। पहले 32 फ्रेम GIF में दिखाए गए हैं, जिस पर हम प्रत्येक फ्रेम में दाईं ओर 1 पिक्सेल ले जाते हैं। बफर का काला क्षेत्र वह हिस्सा है जिसे अपडेट नहीं किया गया है, और इसकी सामग्री केवल पिछले ऑपरेशन से बनी हुई है। जब स्क्रीन एक विषम संख्या में फ़्रेम को स्क्रॉल करती है, तो 162 पिक्सेल चौड़ा क्षेत्र बफर में खींचा जाता है। हालांकि, उनमें से पहला और अंतिम कॉलम (जिसे एनीमेशन में हाइलाइट किया गया है) को छोड़ दिया गया है। जब स्क्रॉल मूल्य 16 पिक्सल का एक मल्टीपल होता है, तो बफर में ड्रा ऑपरेशन पहले कॉलम (x = 0) से शुरू होता है।

ऊर्ध्वाधर स्क्रॉलिंग के बारे में क्या?

फ्लैश मेमोरी में टाइल्स को स्टोर करने की विधि दिखाने के बाद हम इससे निपटेंगे।

टाइल्स कैसे स्टोर करें

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

ऐसा फैसला भोला क्यों है? क्योंकि इस मामले में, डीएमए केवल 16 पिक्सेल प्रति डीएमए डिस्क्रिप्टर को प्रस्तुत कर सकता है! इसलिए, हमें 16 विवरणकों की आवश्यकता होगी, जिनमें से प्रत्येक को 4 + 4 मेमोरी एक्सेस संचालन की आवश्यकता है (अर्थात, 32 बाइट्स को स्थानांतरित करने के लिए - 8 मेमोरी रीड ऑपरेशंस + 8 मेमोरी राइट ऑपरेशन - डीएमए को 4 और रीडिंग + 4 राइट्स करना होगा)। यह बहुत अक्षम है!

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

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


एक टाइल कैसे संग्रहीत किया जाता है?

ऊपर दिए गए आंकड़े में, प्रत्येक संख्या उस क्रम को दर्शाती है जिसमें 16-बिट पिक्सेल को टाइल सरणी में संग्रहीत किया जाता है।

यह एक डिस्क्रिप्टर के साथ किया जा सकता है, लेकिन हमें दो चीजें चाहिए:

• टाइलें संग्रहीत की जानी चाहिए ताकि स्रोत को एक शब्द से बढ़ाते समय, हम हमेशा सही पिक्सेल स्थिति की ओर इशारा करें। दूसरे शब्दों में, अगर (आर, सी) पंक्ति आर और कॉलम सी में एक पिक्सेल है, तो हमें पिक्सेल (0,0) (0,1) (1,0) (1,1) (2,0) क्रमिक रूप से सहेजने की आवश्यकता है (2.1) ... (15.0) (15.1) (0.2) (0.3) (1.2) (1.3) ...
• बफर 256 पिक्सेल चौड़ा होना चाहिए (160 नहीं)

पहला लक्ष्य हासिल करना बहुत आसान है: बस डेटा के क्रम को बदल दें, आप ऐसा कर सकते हैं जब ग्राफिक्स को फ़ाइल सी में निर्यात कर सकते हैं (छवि देखें)।

दूसरी समस्या हल हो सकती है क्योंकि डीएमए आपको प्रत्येक बाइट को 512 बाइट्स के बाद प्राप्तकर्ता का पता बढ़ाने की अनुमति देता है। इसके दो परिणाम हैं:

• हम SPI ब्लॉक पर एक एकल डिस्क्रिप्टर का उपयोग करके डेटा नहीं भेज सकते हैं। यह बहुत गंभीर समस्या नहीं है, क्योंकि अंत में हम 160 पिक्सल के माध्यम से एक डिस्क्रिप्टर पढ़ते हैं। प्रदर्शन प्रभाव न्यूनतम होगा।
• ब्लॉक का आकार 256 * 2 * 16 बाइट्स = 8 KB होना चाहिए, और इसमें बहुत सारे "अप्रयुक्त स्थान" होंगे।

हालांकि, इस स्थान का उपयोग अभी भी किया जा सकता है, उदाहरण के लिए, वर्णनकर्ताओं के लिए।

वास्तव में, प्रत्येक विवरणक आकार में 16 बाइट्स है। हमें टाइल्स के लिए कम से कम 10 * 8 (और वास्तव में 11 * 8!) की आवश्यकता है, टाइल्स के लिए विवरण और एसपीआई के लिए 16 डिस्क्रिप्टर।

यही कारण है कि अधिक टाइल, उच्च गति। वास्तव में, अगर हमने उदाहरण के लिए, एक 32 x 32 टाइल का उपयोग किया है, तो हमें प्रति स्क्रीन (320 के बजाय 640) की आवश्यकता होगी। इससे संसाधनों की बर्बादी कम होगी।

डेटा ब्लॉक प्रदर्शित करें

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

DisplayBlock 16 displayLineData_t तत्वों की एक सरणी है। डिस्प्लेलाइन डेटा में 176 पिक्सेल प्लस 80 शब्द हैं। इन 80 शब्दों में, हम डिस्प्ले डिस्क्रिप्टर या अन्य उपयोगी डिस्प्ले डेटा (यूनियन का उपयोग करके) स्टोर करते हैं।



चूंकि हमारे पास 16 लाइनें हैं, इसलिए स्थिति में प्रत्येक टाइल X लाइनों के पहले 8 डीएमए विवरणकों (0 से 7) का उपयोग करती है। चूंकि हमारे पास अधिकतम 11 टाइलें हैं (डिस्प्ले लाइन 176 पिक्सल चौड़ी है), टाइलें केवल पहले डीएमए डिटेक्टरों का उपयोग करती हैं। डेटा की 11 पंक्तियाँ। सभी पंक्तियों के विवरण ors- ९ और ११-१५ पंक्तियों के ०- ९ विवरणक मुक्त हैं।

इनमें से, एसपीआई के लिए 0..7 लाइनों के डिस्क्रिप्टर 8 और 9 का उपयोग किया जाएगा।

डिस्क्रिप्टर्स 0..9 लाइन्स 11-15 (50 डिस्क्रिप्टर तक, हालांकि हम उनमें से केवल 48 का उपयोग करेंगे) का उपयोग बैकग्राउंड फील्ड के लिए किया जाएगा।

नीचे दिया गया आंकड़ा उनकी संरचना को दर्शाता है।

पृष्ठभूमि खेल मैदान

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

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

पृष्ठभूमि और सामने खेल के मैदानों की तुलना करें:

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

सामने खेल का मैदान

जैसा कि कहा गया था, प्रत्येक ब्लॉक में हमारे पास 11 टाइलें (10 पूर्ण टाइलें, या 9 पूर्ण टाइलें और 2 आंशिक फाइलें) हैं। इनमें से प्रत्येक टाइल, यदि यह पारदर्शी के रूप में चिह्नित नहीं है, तो डीएमए तैयार है। यदि यह पूरी तरह से अपारदर्शी नहीं है, तो इसे सूची में जोड़ा जाता है, जिसका विश्लेषण बाद में किया जाएगा, जब स्प्राइट प्रदान किया जाएगा।

हम दो खेल मैदानों को एक साथ जोड़ते हैं

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

स्प्राइट्स और टाइलें पारदर्शिता के साथ

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

लंबवत स्क्रॉलिंग

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

ऊर्ध्वाधर स्क्रॉलिंग के साथ काम करते समय, हमें रिसीवर रजिस्टर और ट्रांसमिशन वॉल्यूम दोनों की गणना करने की आवश्यकता होती है। उन्हें प्रति फ्रेम कई बार सेट किया जाना चाहिए। इस उपद्रव से बचने के लिए, हम प्रति फ्रेम 9 पूर्ण ब्लॉक तक खींच सकते हैं (8 यदि स्क्रॉल 16 की एक बहु है)।

उपकरण

जैसा कि हमने कहा, सिस्टम का दिल uChip है। बाकी के बारे में क्या?

यहाँ एक चित्र है! इसके कुछ पहलू ध्यान देने योग्य हैं।

कुंजी

I / O के उपयोग को अनुकूलित करने के लिए, हम थोड़ी चाल का उपयोग करते हैं। हमारे पास 4 सेंसर बसें L1-L4, और एक सामान्य LC वायर होगा। 1 और 0 को वैकल्पिक रूप से आम तार पर लागू किया जाता है तदनुसार, सेंसर बसों को आंतरिक पुल-अप प्रतिरोधों की मदद से वैकल्पिक रूप से नीचे या ऊपर खींचा जाएगा। प्रत्येक मुख्य बस और एक सामान्य बस के बीच दो कुंजियाँ जुड़ी होती हैं। इन दोनों कुंजियों के साथ श्रृंखला में एक डायोड डाला जाता है। इनमें से प्रत्येक डायोड को विपरीत दिशा में स्विच किया जाता है, ताकि हर बार केवल एक कुंजी "रीड" हो।

चूंकि कोई अंतर्निहित कीबोर्ड नियंत्रक नहीं है (और कोई अंतर्निहित कीबोर्ड नियंत्रक इस दिलचस्प विधि का उपयोग नहीं करता है), प्रत्येक फ्रेम की शुरुआत में आठ चाबियाँ जल्दी से परागित होती हैं। चूंकि इनपुट को ऊपर और नीचे खींचना चाहिए, इसलिए हम बाहरी प्रतिरोधों का उपयोग नहीं कर सकते (और नहीं चाहते), इसलिए हमें एकीकृत लोगों का उपयोग करने की आवश्यकता है, जिसमें काफी उच्च प्रतिरोध (60 kOhm) हो सकते हैं। इसका मतलब यह है कि जब सामान्य बस बदलती है, और डेटा बसें अपनी अप / डाउन पुल स्थिति को बदलती हैं, तो आपको कुछ देरी सम्मिलित करने की आवश्यकता होती है ताकि अंतर्निहित अप / डाउन पुल-अप रोकनेवाला अनुबंध को बदल दे और आवारा समाई को वांछित स्तर पर सेट कर दे। लेकिन हम इंतजार नहीं करना चाहते हैं! इसलिए, हम आम बस को उच्च प्रतिबाधा की स्थिति में डालते हैं (ताकि कोई असहमति न हो), और पहले सेंसर बसों को तार्किक मान 1 या 0 में बदल दें।अस्थायी रूप से उन्हें आउटपुट के रूप में कॉन्फ़िगर करना। बाद में उन्हें ऊपर या नीचे खींचकर इनपुट के रूप में कॉन्फ़िगर किया जाता है। चूंकि आउटपुट प्रतिरोध ओम्स के दसियों के आदेश पर है, इसलिए राज्य कुछ नैनोसेकंड में बदलता है, अर्थात जब सेंसर बस इनपुट पर वापस जाता है, तो यह पहले से ही वांछित स्थिति में होगा। उसके बाद, सामान्य बस विपरीत ध्रुवीयता के साथ आउटपुट पर स्विच करती है।

यह स्कैन की गति में बहुत सुधार करता है और नप देरी / निर्देशों की आवश्यकता को समाप्त करता है।

एसपीआई कनेक्शन

हमने SD और डिस्प्ले को कनेक्ट किया ताकि वे ATSAMD21 को डेटा ट्रांसफर किए बिना एक दूसरे के साथ संवाद करें। यदि आप वीडियो चलाना चाहते हैं तो यह उपयोगी हो सकता है।

MISO और MOSI को जोड़ने वाले प्रतिरोधक कम होने चाहिए। यदि वे बहुत बड़े हैं, तो एसपीआई काम नहीं करेगा, क्योंकि संकेत बहुत कमजोर होगा।

अनुकूलन और आगे विकास

सबसे बड़ी समस्याओं में से एक रैम का उपयोग है। तीन ब्लॉक 8 केबी पर कब्जा करते हैं, केवल 8 केबी प्रति स्टैक और अन्य चर छोड़ते हैं। फिलहाल, हमारे पास केवल 1.3 KB का मुफ्त RAM + 4 KB स्टैक (4 KB प्रति स्टैक - यह बहुत है, शायद हम इसे कम कर देंगे)।

हालाँकि, आप 16 नहीं, बल्कि 8 पिक्सेल की ऊँचाई वाले ब्लॉक का उपयोग कर सकते हैं। इससे डीएमए डिस्क्रिप्टर पर संसाधनों की बर्बादी बढ़ेगी, लेकिन ब्लॉक बफर द्वारा कब्जा की गई मेमोरी की मात्रा को लगभग आधा कर दें (ध्यान दें कि यदि हम 16 × 16 टाइल्स का उपयोग करना जारी रखते हैं तो डिस्क्रिप्टर की संख्या नहीं बदलेगी, इसलिए हमें ब्लॉक की संरचना को बदलना होगा)। यह लगभग 7.5 केबी रैम को मुक्त कर सकता है, जो गुप्त रूप से जोड़ने या ध्वनि जोड़ने के लिए एक परिवर्तनीय कार्ड जैसे कार्यों को लागू करने के लिए बहुत उपयोगी होगा (हालांकि 1 केबी के साथ ध्वनि भी जोड़ा जा सकता है)।

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

इसके बजाय, आप अनुकूलन कर सकते हैं। उदाहरण के लिए, गेमपैप में आप न केवल टाइल के मूल्य को स्टोर कर सकते हैं, बल्कि संपादक में सेट किए गए टाइल की पारदर्शिता को इंगित करते हुए एक झंडा भी लगा सकते हैं। यह हमें जल्दी से यह जांचने की अनुमति देगा कि क्या टाइल का प्रतिपादन किया जाना चाहिए: डीएमए या सीपीयू। इसलिए हमने टाइल कार्ड के लिए 16-बिट रिकॉर्ड का उपयोग किया। यदि हम मानते हैं कि हमारे पास 256 टाइलों का एक सेट है (फिलहाल हमारे पास 128 से कम टाइलें हैं, लेकिन नए लोगों को जोड़ने के लिए फ्लैश मेमोरी पर पर्याप्त जगह है), तो 7 मुफ्त बिट्स हैं जो अन्य उद्देश्यों के लिए उपयोग किए जा सकते हैं। इन सात बिट्स में से तीन का उपयोग यह इंगित करने के लिए किया जा सकता है कि स्प्राइट / ऑब्जेक्ट संग्रहीत किया जा रहा है या नहीं। उदाहरण के लिए:

0b000 =
0b001 =
0b010 =
0b011 =
0b100 =
0b101 =
0b110 =
0b111 = , , .

फिर आप रैम में एक बिट टेबल बना सकते हैं जिसमें प्रत्येक बिट का अर्थ है कि क्या (उदाहरण के लिए, एक दुश्मन) का पता लगाया गया है या नहीं (उदाहरण के लिए, एक बोनस) उठाया गया है / क्या एक निश्चित वस्तु सक्रिय है (स्विच)। 10 × 10 स्क्रीन के स्तर पर, इसके लिए 8000 बिट्स की आवश्यकता होगी, अर्थात्। 1 केबी की रैम। जब दुश्मन का पता लग जाता है या बोनस उठाया जाता है तो बिट रीसेट कर दिया जाता है।

CreateNextFrameScene () में, हमें वर्तमान दृश्यमान क्षेत्र में टाइलों के अनुरूप बिट्स की जांच करनी चाहिए। यदि उनका मान 1 है:

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

इस दृष्टिकोण के नुकसान हैं।

1. -, ( ). .
2. -, 80 , , . , 32 . , «/» ( «», .. 0!). «», «» ( ).
3. -, . ( ), . , .
4. -, , , , . , , . , , , , !
5. , (, Unreal Tournament , ).

फिर भी, इस तरह से हम एक स्तर पर स्प्राइट को स्टोर और प्रोसेस कर सकते हैं।

हालांकि, यह तकनीक गेम के ग्राफिक्स इंजन की तुलना में "गेम लॉजिक" के लिए अधिक प्रासंगिक है।

शायद भविष्य में हम इस समारोह को लागू करेंगे।

संक्षेप में कहना

हमें उम्मीद है कि आपको यह परिचय लेख अच्छा लगा होगा। हमें कई और पहलुओं की व्याख्या करने की आवश्यकता है जो भविष्य के लेखों के विषय होंगे।

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

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

जल्द ही हम एक मानचित्र संपादक जारी करेंगे, लेकिन अब समुदाय के लिए इसे दिखाना बहुत अशिष्टता है!

वीडियो

(नोट: खराब प्रकाश व्यवस्था के कारण, वीडियो बहुत कम फ्रेम दर पर रिकॉर्ड किया गया था! जल्द ही हम वीडियो को अपडेट करेंगे ताकि आप 40 एफपीएस पर पूरी गति का अनुमान लगा सकें!)

धन्यवाद

खेल के ग्राफिक्स (और कुछ छवियों पर दिखाए गए टाइल) ansimuz द्वारा बनाई गई मुक्त संपत्ति "सनी लैंड" से लिए गए हैं ।

डाउनलोड करने योग्य सामग्री

परियोजना का स्रोत कोड सार्वजनिक डोमेन में है, अर्थात, यह नि: शुल्क प्रदान किया जाता है। हम इसे इस उम्मीद में साझा करते हैं कि यह किसी के लिए उपयोगी होगा। हम गारंटी नहीं देते हैं कि कोड में किसी भी बग / त्रुटि के कारण कोई समस्या नहीं होगी!

योजनाबद्ध आरेख

KiCad

परियोजना Atmel स्टूडियो 7 परियोजना (स्रोत)