स्तर पर हजारों दुश्मन हो सकते हैं।

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

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

0. रूपरेखा उपकरण

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

सरलतम प्रोफाइलिंग टूल मानक विंडोज सिस्टम मॉनिटर (प्रदर्शन मॉनिटर) है:


वास्तव में, यह एक काफी लचीला उपकरण है और इसके साथ काम करना बहुत आसान है। बस Ctrl + Alt + Delete दबाएं, "कार्य प्रबंधक" खोलें और "प्रदर्शन" टैब पर क्लिक करें। हालांकि, कई अन्य कार्यक्रम न चलाएं। यदि आप बारीकी से देखते हैं, तो आप आसानी से सीपीयू उपयोग और यहां तक ​​कि मेमोरी लीक में चोटियों का पता लगा सकते हैं। यह एक असंक्रामक तरीका है, लेकिन यह धीमी जगहों को खोजने में पहला कदम हो सकता है।

डिफेंडर की खोज अन्य भाषाओं में संकलित उच्च-स्तरीय हेक्स भाषा में लिखी गई है (मेरा मुख्य लक्ष्य C ++ था)। इसका मतलब यह है कि C ++ को प्रोफाइल करने में सक्षम कोई भी टूल मेरे Haxe-Generate C ++ कोड को भी प्रोफाइल कर सकता है। इसलिए जब मैंने समस्याओं के कारणों को समझना चाहा, तो मैंने Visual Studio से प्रदर्शन एक्सप्लोरर लॉन्च किया:


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

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

1. समस्या का पता लगाना

खेल प्रदर्शन केवल गति ही नहीं है, बल्कि इसकी धारणा भी है। डिफेंडर क्वेस्ट एक टॉवर रक्षा शैली का खेल है जिसे 60 एफपीएस में प्रस्तुत किया गया है, लेकिन 1 / 4x से 16x तक की रेंज में चर गेमप्ले की गति के साथ। खेल की गति के बावजूद, सिमुलेशन 1x सिमुलेशन समय के 60 अपडेट प्रति सेकंड के साथ एक निश्चित टाइमस्टैम्प का उपयोग करता है। यही है, यदि आप 16x की गति से गेम चलाते हैं, तो अपडेट लॉजिक वास्तव में 960 एफपीएस की आवृत्ति के साथ काम करेगा। ईमानदारी से, ये खेल के लिए बहुत अधिक अनुरोध हैं! लेकिन यह मैं ही था जिसने इस विधा का निर्माण किया था, और अगर यह धीमी हो जाती है, तो खिलाड़ी निश्चित रूप से इसे नोटिस करेंगे।

और खेल में एक ऐसा स्तर है:


यह अंतिम बोनस लड़ाई "अंतहीन 2" है, यह "मेरी व्यक्तिगत दुःस्वप्न" भी है। स्क्रीनशॉट को न्यू गेम + मोड में लिया गया था, जिसमें दुश्मन न केवल बहुत मजबूत होते हैं, बल्कि स्वास्थ्य को बहाल करने जैसी विशेषताएं भी होती हैं। यहां खिलाड़ी की पसंदीदा रणनीति ड्रैगन्स को अधिकतम रोअर स्तर (एओई हमले जो दुश्मनों को चौंकाती है) को पंप करने के लिए है, और उनके पीछे नॉकबैक के साथ कई शूरवीरों को रखा गया है जो ड्रैगन्स को अपने क्षेत्र के क्षेत्र में वापस भेजने के लिए सभी को पुश करने के लिए अधिकतम करने के लिए पंप करते हैं। संचयी प्रभाव यह है कि राक्षसों का एक विशाल समूह अंतहीन रूप से एक ही स्थान पर रहता है, खिलाड़ियों की तुलना में लंबे समय तक जीवित रहना होगा यदि वे उन्हें वास्तव में जानते हैं। चूंकि खिलाड़ियों को लहरों के लिए इंतजार करने और पुरस्कार और उपलब्धियों को प्राप्त करने के लिए उन्हें मारने की ज़रूरत नहीं है, इसलिए ऐसी रणनीति बिल्कुल प्रभावी और शानदार है - यह बिल्कुल खिलाड़ियों का व्यवहार है जिसे मैंने उत्तेजित किया।

दुर्भाग्य से, यह प्रदर्शन के लिए एक रोग संबंधी मामला भी है, खासकर जब खिलाड़ी 16x या 8x की गति से खेलना चाहते हैं। बेशक, केवल सबसे कट्टर खिलाड़ी एंडलेस 2 के स्तर पर नए गेम + में "हंड्रेड वेव" उपलब्धि प्राप्त करने की कोशिश करेंगे, लेकिन वे केवल वे हैं जो खेल को सबसे जोर से बोलते हैं, इसलिए मैं चाहता था कि वे खुश रहें।

यह सिर्फ एक 2D गेम है जिसमें स्प्राइट्स का एक गुच्छा है, इसमें क्या गलत हो सकता है?

और वास्तव में। चलो ठीक है।

2. टकराव का संकल्प

इस स्क्रीनशॉट पर एक नज़र डालें:


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

आज, वीडियो प्रोसेसर बहुत तेज हैं - यदि आप उन्हें बहुत ज्यादा तनाव नहीं देते हैं, तो वे लगभग किसी भी बहुभुज को संसाधित कर सकते हैं। लेकिन यहां तक ​​कि सबसे तेज सीपीयू में बहुत सरलता से सरल प्रक्रियाओं में "अड़चनें" होती हैं, खासकर जो तेजी से बढ़ती हैं। यही कारण है कि एक 2 डी गेम बहुत अधिक सुंदर 3 डी गेम की तुलना में धीमा हो सकता है - इसलिए नहीं कि प्रोग्रामर सामना नहीं कर सका (शायद यह कम से कम मेरे मामले में भी है), लेकिन सिद्धांत रूप में क्योंकि तर्क कभी-कभी अधिक महंगा हो सकता है, ड्राइंग से! सवाल यह नहीं है कि स्क्रीन पर कितने ऑब्जेक्ट हैं, लेकिन वे क्या करते हैं ।

आइए अन्वेषण और टकराव की पहचान को गति दें। तुलना के लिए, मेरा कहना है कि अनुकूलन से पहले, टकराव की पहचान मुख्य युद्ध चक्र में सीपीयू समय के ~ ५०% तक थी। अनुकूलन के बाद, 5% से कम।

यह सभी चतुष्कोणीय पेड़ों के बारे में है

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

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

यहाँ क्या गलत है?

जैसा कि यह निकला - बहुत कुछ।

स्ट्रिंग टाइपिंग

चूँकि मैंने शत्रु और रक्षक दोनों को एक चतुर्भुज वृक्ष में रखा था, इसलिए मुझे संकेत करना था कि मैं क्या देख रहा हूँ, और यह इस तरह किया गया था:

var things:Array<XY> = _qtree.queryRange(zone.bounds, "e"); //"e" - "enemy"

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

मैंने शीघ्रता से पूर्णांक स्थिरांक निकाले और कोड को इसके साथ बदल दिया:

var things:Array<XY> = _qtree.queryRange(zone.bounds, QuadTree.ENEMY);

(हाँ, यह संभवतः अधिकतम प्रकार की सुरक्षा के लिए Enum Abstract का उपयोग करने के लायक था, लेकिन मैं जल्दी में था, और मुझे पहले काम करने की आवश्यकता थी।)

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

ऐरे बनाम वेक्टर

इस पर एक नज़र डालें:

var things:Array<XY>

Haxe सरणियाँ ActionScript और JS सरणियों से बहुत मिलती-जुलती हैं, क्योंकि वे आकार बदलने योग्य वस्तुओं के संग्रह हैं, लेकिन Haxe में वे दृढ़ता से टाइप किए जाते हैं।

हालाँकि, एक और डेटा संरचना है जो स्थिर लक्ष्य भाषाओं जैसे cpp, यानी hxe.ds.Vector के साथ अधिक कुशल है। Haxe वैक्टर अनिवार्य रूप से सरणियों के समान हैं, सिवाय इसके कि जब वे बनाए जाते हैं तो उन्हें एक निश्चित आकार मिलता है।

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

आपको जो चाहिए वो ही निवेदन करें

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

तो मैं क्यों इन सभी संदर्भों को प्रत्येक QuadTree नोड के लिए XY ऑब्जेक्ट के लिए पुनरावर्ती रूप से पास कर दूं, और प्रति फ्रेम 960 बार भी ? पूर्णांक पहचानकर्ताओं की सूची वापस करने के लिए मेरे लिए पर्याप्त है।

व्यावसायिक सुझाव: पूर्णांक लगभग सभी अन्य डेटा प्रकारों की तुलना में बहुत तेजी से प्रसारित होते हैं!

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

पूंछ पुनरावृत्ति अनुकूलन

टेल-कॉल ऑप्टिमाइज़ेशन नामक एक सुरुचिपूर्ण चीज़ है। यह समझाना मुश्किल है, इसलिए मैं आपको एक उदाहरण दिखाऊंगा।

यह था:

nw.queryRange(Range, -1, result);
ne.queryRange(Range, -1, result);
sw.queryRange(Range, -1, result);
se.queryRange(Range, -1, result);
return result;

यह बन गया:

 return se.queryRange(Range, filter, sw.queryRange(Range, filter, ne.queryRange(Range, filter, nw.queryRange(Range, filter, result)))); 

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

(जो मैं जानता हूं, उसे देखते हुए, हेक्स कंपाइलर के वर्तमान संस्करण में टेल रीसर्प्शन ऑप्टिमाइज़ेशन फंक्शन नहीं है, यानी यह शायद C ++ कंपाइलर का काम है - इसलिए आश्चर्यचकित न हों अगर यह ट्रिक Haxe कोड को ट्रांसलेट करने के लिए काम नहीं करती है।

ऑब्जेक्ट पूलिंग

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

मैं ऐसा कुछ करता था:

nw = new QuadTree( new AABB( cx - hs2x, cy - hs2y, hs2x, hs2y) );
ne = new QuadTree( new AABB( cx + hs2x, cy - hs2y, hs2x, hs2y) );
sw = new QuadTree( new AABB( cx - hs2x, cy + hs2y, hs2x, hs2y) );
se = new QuadTree( new AABB( cx + hs2x, cy + hs2y, hs2x, hs2y) );

लेकिन फिर मैंने इसके साथ कोड बदल दिया:

nw = new QuadTree( AABB.get( cx - hs2x, cy - hs2y, hs2x, hs2y) );
ne = new QuadTree( AABB.get( cx + hs2x, cy - hs2y, hs2x, hs2y) );
sw = new QuadTree( AABB.get( cx - hs2x, cy + hs2y, hs2x, hs2y) );
se = new QuadTree( AABB.get( cx + hs2x, cy + hs2y, hs2x, hs2y) );

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

यदि आवश्यक हो तो विशेषज्ञता

एक XY ऑब्जेक्ट एक साधारण वर्ग है जिसमें गुण x , y और int_id । चूंकि इसका उपयोग विशेष रूप से सक्रिय रूप से आंतरिक लूप में किया गया था, इसलिए मैं इस सभी डेटा को एक विशेष डेटा संरचना में ले जाकर बहुत सारे मेमोरी आवंटन कमांड और संचालन को बचा सकता था जो Vector<XY> जैसी कार्यक्षमता प्रदान करता है। मैंने इस नए XYVector वर्ग को बुलाया और परिणाम यहां देखा जा सकता है । यह एक बहुत ही विशिष्ट अनुप्रयोग है और एक ही समय में लचीला नहीं है, लेकिन इसने हमें कुछ गति सुधार प्रदान किए हैं।

अंतर्निहित कार्य

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

 private static function _collide_circleCircle(a:Zone, b:Zone):Bool { var dx:Float = a.centerX - b.centerX; var dy:Float = a.centerY - b.centerY; var d2:Float = (dx * dx) + (dy * dy); var r2:Float = (a.radius2) + (b.radius2); return d2 < r2; } 

यह सब एक inline साथ सुधारा जा सकता है:

 private static inline function _collide_circleCircle(a:Zone, b:Zone):Bool { var dx:Float = a.centerX - b.centerX; var dy:Float = a.centerY - b.centerY; var d2:Float = (dx * dx) + (dy * dy); var r2:Float = (a.radius2) + (b.radius2); return d2 < r2; } 

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

हम संघर्षों को ध्यान में रखते हैं

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

लेकिन फिर भी - सात बार मापें, एक काटें!

फ़ंक्शन के पांडित्य अनुकूलन के दो घंटे, जिसे हर छह फ्रेम में एक बार कहा जाता है और 0.001 एमएस ले रहा है, कोड की कुरूपता और मूर्खता के बावजूद प्रयास के लायक नहीं है।

3. सब कुछ क्रमबद्ध करें

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

यदि आप खेल के स्क्रीनशॉट को देखते हैं, तो आप देखेंगे कि सभी शत्रु और रक्षकों को पहले y , और फिर x द्वारा क्रमबद्ध किया जाता है, ताकि तत्व एक-दूसरे को पीछे से बाएं से दाएं से ओवरलैप करें, जब हम ऊपरी बाएं से स्क्रीन के निचले दाएं कोने में जाते हैं।

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

अंत में, निर्णय HaxeFlixel में से एक जेन्स फिशर से आया था। उन्होंने पूछा: "क्या आपने सुनिश्चित किया है कि आप एक छँटाई एल्गोरिथ्म का उपयोग करते हैं जो लगभग छंटे हुए सरणियों के लिए तेज़ है?"

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

4. अन्य तकनीकी मुद्दे

टकराव की पहचान और छंटनी update() और draw() के तर्क में बड़ी जीत थी, लेकिन कई और नुकसानों को सक्रिय रूप से इस्तेमाल किए गए आंतरिक छोरों में छिपाया गया था।

Std.is () और कास्ट

विभिन्न "हॉट" इनर लूप्स में, मेरे पास एक समान कोड था:

 if(Std.is(something,Type)) { var typed:Type = cast(something,Type); } 

Haxe भाषा में, Std.is() हमें बताता है कि क्या वस्तु एक निश्चित प्रकार (प्रकार) या वर्ग (क्लास) से संबंधित है, और cast ने कार्यक्रम के निष्पादन के दौरान इसे एक विशिष्ट प्रकार में cast प्रयास किया है।

cast सुरक्षित और असुरक्षित संस्करण हैं - सुरक्षित cast कम प्रदर्शन का नेतृत्व करते हैं, लेकिन असुरक्षित cast नहीं करते हैं।

सुरक्षित: cast(something, Type);

असुरक्षित: var typed:Type = cast something;

जब एक असुरक्षित कलाकारों का प्रयास विफल हो जाता है, तो हम अशक्त हो जाते हैं, जबकि एक सुरक्षित कलाकार एक अपवाद फेंकता है। लेकिन अगर हम एक अपवाद को पकड़ने नहीं जा रहे हैं, तो सुरक्षित कास्ट करने का क्या मतलब है? पकड़ के बिना, ऑपरेशन अभी भी विफल रहता है, लेकिन यह अधिक धीरे-धीरे काम करता है।

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

मैं Std.is() जाँच के बाद Std.is() कलाकारों के साथ Std.is() को थोड़ा गति दे सकता हूं। लेकिन हमें उसी चीज़ को फिर से लिखने की आवश्यकता क्यों है यदि मुझे कक्षा के प्रकार की जांच करने की आवश्यकता नहीं है?

मान लीजिए मेरे पास एक CreatureSprite , जो कि DefenderSprite या EnemySprite के किसी उपवर्ग का उदाहरण हो सकता है। Std.is(this,DefenderSprite) कहने के बजाय Std.is(this,DefenderSprite) हम CreatureSprite में एक पूर्णांक फ़ील्ड बना सकते हैं Std.is(this,DefenderSprite) जैसे CreatureType.DEFENDER या CreatureType.ENEMY जैसे मान, जो और भी तेज़ी से Std.is(this,DefenderSprite) जाते हैं।

मैं दोहराता हूं, यह केवल उन जगहों पर इसे ठीक करने के लायक है जहां एक महत्वपूर्ण मंदी स्पष्ट रूप से दर्ज की गई है।

वैसे, आप हेक्स मैनुअल में सुरक्षित और असुरक्षित कलाकारों के बारे में अधिक पढ़ सकते हैं।

ब्रह्माण्ड का क्रमिककरण / वर्णन

कोड में ऐसी जगहों को ढूंढना कष्टप्रद था:

 function copy():SomeClass { return SomeClass.fromXML(this.toXML()); } 

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

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

नल को ना कहना

नल के लिए समानता की जाँच का उपयोग अक्सर किया जाता है, लेकिन जब Haxe को cpp में अनुवाद करते हैं, तो अनिश्चित वस्तु की अनुमति देने वाली एक वस्तु अनावश्यक लागतों की ओर ले जाती है, जो उत्पन्न नहीं होती है यदि कंपाइलर मान सकता है कि वस्तु कभी शून्य नहीं होगी। यह Int जैसे बुनियादी प्रकारों के लिए विशेष रूप से सच है - हैक्स अपने "पैकिंग" द्वारा स्थिर लक्ष्य प्रणाली में उनके लिए एक अपरिभाषित मूल्य की वैधता को लागू करता है, जो न केवल उन चर के लिए होता है जिन्हें स्पष्ट रूप से शून्य ( var myVar:Null<Int> ) घोषित किया जाता है, बल्कि सहायक विकल्प ( ?myParam:Int ) जैसी चीजों के लिए। इसके अलावा, नल स्वयं को अनावश्यक कचरे का कारण बनता है।

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

5. डाउनलोड समय

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

टेक्स्ट

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

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

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

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

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

सॉफ्टवेयर प्रतिपादन

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

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

बटन रेंडरिंग

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

वैकल्पिक पाठ स्कैन

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

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

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

6. मेमोरी प्रोफाइलिंग

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

आराध्य स्मृति उपयोग क्या है? कचरा संग्रहकर्ता निम्नानुसार काम करता है: डेटा और ऑब्जेक्ट जो आप समय के साथ जमा नहीं करते हैं और समय-समय पर साफ हो जाते हैं। लेकिन ऐसा होने पर आपका स्पष्ट नियंत्रण नहीं होता है, इसलिए मेमोरी उपयोग का ग्राफ आरी की तरह दिखता है:

कचरा बाहर निकालो

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

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

हमने दिए गए सीमा के भीतर रहने के लिए बड़े स्तर के बाद मेमोरी को तुरंत साफ़ करने के लिए उनका उपयोग किया है:

cpp.vm.Gc.run(false); // (true/false - / )

आपको इसका उपयोग अनपेक्षित रूप से नहीं करना चाहिए यदि आप नहीं जानते कि आप क्या कर रहे हैं, लेकिन यह सुविधाजनक है कि ऐसे उपकरण मौजूद हैं जब उनकी आवश्यकता होती है।

7. डिजाइन के माध्यम से समाधान

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

लेकिन अक्सर "सुरंग दृष्टि" होती है जब आप केवल तकनीकी हैक पर ध्यान केंद्रित करते हैं और भूल जाते हैं कि डिजाइन का एक सरल परिवर्तन स्थिति में सुधार कर सकता है ।

उच्च गति पर प्रभाव तेज

16x पर, कई प्रभाव इतनी जल्दी होते हैं कि खिलाड़ी उन्हें देखता भी नहीं है। हमने पहले से ही एक चाल का उपयोग किया है - खेल की गति के साथ अज़रा की बिजली आसान हो गई, और एओई हमलों के लिए कणों की संख्या कम है। हमने उच्च गति की क्षति संख्या और अन्य समान चाल को अक्षम करके इस तकनीक को पूरक बनाया।

हमने यह भी महसूस किया कि कुछ बिंदु पर, 16x की गति वास्तव में 8x की गति से धीमी हो सकती है जब स्क्रीन पर बहुत अधिक ऑब्जेक्ट होते हैं, इसलिए जब दुश्मनों की संख्या एक निश्चित सीमा तक बढ़ जाती है, तो हमने स्वचालित रूप से खेल की गति को 8x या 4x तक कम कर दिया। व्यवहार में, खिलाड़ी को केवल एंडलेस बैटल 2 में देखने की संभावना है। यह सीपीयू को ओवरलोड किए बिना सुचारू प्रदर्शन और रेंडरिंग की अनुमति देता है।

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

शरीर को छिपाना

एंडलेस बैटल 2 के निचले दाएं कोने में दुश्मनों के विशाल ढेर के बारे में क्या है - शाब्दिक रूप से सैकड़ों या हजारों दुश्मन हैं जो एक के ऊपर एक आकर्षित करते हैं। हम सिर्फ उन लोगों का प्रतिपादन क्यों नहीं छोड़ते जिन्हें हम देख भी नहीं सकते?

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

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

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

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

(वैसे, यहां रिड्रेस की जांच का कार्य है ।)

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

ब्रेक की तुलना में बेहतर प्रीलोड

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

हम बाद के लिए स्टॉक सुरक्षित रखते हैं

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

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

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

उन चीजों से छुटकारा पाना जो हम उपयोग नहीं करते हैं

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

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

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

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

NaNopokalipsis

यह मामला मजाकिया था। प्रोफाइलर ने बताया कि कोणों की गणना करने में बहुत समय लगता है। यहाँ प्रोफाइलर में उत्पन्न Haxe C ++ कोड है:


यह उन कार्यों में से एक है जो मान लेते हैं -90और जैसे परिवर्तित होते हैं 270। कभी-कभी आपको ऐसे मूल्य मिलते हैं -724, जो कुछ चक्रों में घट जाते हैं 4।

किसी कारण से, इस फ़ंक्शन के लिए एक मान पारित किया गया था -2147483648।


. -2147483648 360, 5 965 233 , 0 . , ( — update !) — , ( - ) .

, , NaN — , «Not a number» ( ), , . , .

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

(इस त्रुटि के लिए एक फिक्स HaxeFlixel में ही डाला गया था )।

अपने आप को बाहर मत करो

OpenFL और HaxeFlixel दोनों संसाधन कैशिंग पर आधारित हैं। इसका मतलब यह है कि जब हम किसी संसाधन को लोड करते हैं, तो अगली बार जब यह संसाधन प्राप्त होता है, तो इसे कैश से लिया जाता है, और डिस्क से पुनः लोड नहीं किया जाता है। इस व्यवहार को ओवरराइड किया जा सकता है, और कभी-कभी यह समझ में आता है।

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

8. इसके अलावा, यह एंडलेस बैटल 2 जैसे स्तरों को करने के लायक नहीं हो सकता है

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

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

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

9. निष्कर्ष में विचार

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

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

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