IOS गेम में फुल-स्क्रीन एनीमेशन, या क्या होगा अगर ग्राफिक्स वास्तव में मेमोरी में लोड नहीं किए जा सकते हैं

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


तो, हर किसी ने शायद एक बात कर रहे बिल्ली के साथ एक खेल देखा जो एक अजीब आवाज में दोहराता है कि वे उससे क्या कहते हैं? इसलिए हमारे ग्राहक को एक समान खेल बनाने की इच्छा थी, लेकिन एक अलग चरित्र के साथ।

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

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

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

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

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

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

नंबर एक की कोशिश

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



ऐसा करने के लिए, हमने फ़ोटोशॉप क्रिया का उपयोग किया, जिसे हमने प्रत्येक एनीमेशन के लिए क्रॉप ज़ोन के आकार को सेट करने के लिए संपादित किया और इसे पूरे एनीमेशन फ़ोल्डर में लागू किया।

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

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

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

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

नंबर दो का प्रयास

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

एक और माइनस ज्यामितीय आकार और अनुपात से जुड़े प्रतिबंध हैं। PVRTC प्रारूप में सभी फाइलें दो की बराबर शक्ति के साथ वर्गाकार होनी चाहिए।
सभी फाइलों की मात्रा का अनुमान लगाने पर, अगर iPad3 के लिए हम अपने सभी फ्रेम 2048x2048 में लाते हैं, तो हमने तुरंत इस विचार को छोड़ दिया। और उन्होंने इसे दो आकारों तक सीमित करने का फैसला किया। IPhone के लिए, 512x512 फ़्रेम का उपयोग करें, और सभी iPads के लिए, अपने आप को 1024x1024 के टेक्स्ट तक सीमित रखें। क्योंकि एनीमेशन के प्लेबैक के दौरान, iPad3 और iPad2 पर तस्वीर की गुणवत्ता में अंतर वैसे भी ध्यान देने योग्य नहीं है, क्योंकि स्क्रीन के ज्यामितीय आकार के बाद से, सभी एक समान है, बाद में चित्र जल्दी बदल जाते हैं।
इसलिए यह किसी भी तरह से हमारे सभी ग्राफिक्स को अपने अराजक फ्रेम साइज (वे जैसे - 1355x1278) से 1024x1024 (और iPhone के लिए 512x512) के साथ लाना आवश्यक था।

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



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

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

उसके बाद, हमने एक धारणा की जाँच करने का निर्णय लिया।

नंबर तीन का प्रयास

हमने सुझाव दिया कि शायद ये लोग सिर्फ UIKit में सभी एनिमेशन चलाते हैं, ओपनगेल का उपयोग भी नहीं कर रहे हैं। और वास्तव में, आपको ओपनजीएल की आवश्यकता क्यों है यदि आप प्रति सेकंड 5 फ्रेम के साथ संतुष्ट होने जा रहे हैं।

मज़े के लिए, हमने UIKit टूल के साथ अपने मूल ग्राफिक्स को खोने की कोशिश करने का फैसला किया - बस प्रत्येक पूर्ण आकार के फ्रेम को UIImageView क्रमिक रूप से लोड कर रहा है।
यह पता चला है कि इस मोड में, iPad2 इसे 30 फ्रेम प्रति सेकंड की गति से चलाने का प्रबंधन करता है, और iPad3 (चित्र के चार गुना आकार के बावजूद) बाहर देता है, प्रति सेकंड 20 सभ्य फ्रेम भी!
और यह पूरे एनीमेशन को प्रीलोड किए बिना है, हम सिर्फ एक फ्रेम को लोड करते हैं, इसे प्रदर्शित करते हैं और वहीं, इसे मेमोरी से अनलोड करते हुए, इसे फ्रेम के बीच किसी भी देरी के बिना दूसरे के साथ बदलें।
यहाँ एक खोज है! यह संभव नहीं था कि कुछ भी नहीं किया जाए, सब कुछ ठीक काम करेगा, और जेपीजी प्रारूप में ग्राफिक्स बहुत छोटे अनुप्रयोग आकार देगा, और कुछ भी स्मृति में संग्रहीत करने की आवश्यकता नहीं है। इस दृष्टिकोण के साथ, एनीमेशन किसी भी लंबाई का हो सकता है, यह केवल आवेदन के वांछित आकार तक सीमित है।
अंत में, हम इस दृष्टिकोण का उपयोग करके खेल को फिर से लिखते हैं।

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

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