क्या मुझे स्प्राइटशीट का उपयोग करना चाहिए, क्योंकि या मेरी विशाल संख्या में छवियों के बावजूद?


13

मैं एक 2D गेम विकसित कर रहा हूं, और मेरे पास बहुत सारे स्प्राइट हैं। मैंने 2D में रेंडर करने के लिए 3D एनिमेशन और मॉडल्स का इस्तेमाल किया, ताकि उन्हें "फॉलआउट" या "डियाब्लो" लुक दिया जा सके। यह हाथ से ड्राइंग, लोल से भी आसान है।

मुझे पहले से ही 15fps तक फ्रैमरेट में कटौती करनी पड़ी, जो कि सबसे कम मैं उन्हें बिना चॉपी वाला लुक दे सकता था। हालांकि, यह अविश्वसनीय रूप से चिकनी 24 फ़्रेमों को देखने के कारण उदास था।

ऐसा करने के दो कारण हैं:

1) HDD स्पेस में कटौती करें। जितनी कम छवियां होंगी, मेरा कुल खेल उतना ही छोटा होगा।

2) रैम की खपत में कटौती। लोड करने के लिए कम छवियां, अधिक संभावना है कि मैं अपनी रैम सीमा को फुलाने वाले मुद्दों से बचता हूं।

हालांकि, अगर HDD स्पेस और RAM दोनों में इमेज को कंप्रेस करने का कोई तरीका होता, तो मैं ऐसा करता। मैंने पहले इसका परीक्षण किया है, और RGBG8888 से RGBA5555 को देते समय गुणवत्ता में कोई बदलाव नहीं आया है और अपने TexturePacker प्रोग्राम में RGBA4444 में परिवर्तित होने पर केवल थोड़ा हिट हुआ है। मैं वर्तमान में ऐसा नहीं करता हूं, क्योंकि SFML स्मृति की समान मात्रा का उपयोग करने के लिए लगता है चाहे वह किस प्रकार की .PNG छवि है। मैंने इस पर शोध किया कि इसे अलग तरीके से कैसे लोड किया जाए, लेकिन इस विषय पर कुछ भी पता लगाने में विफल रहा।

मैंने 2 डी वीडियो गेम को कैसे संभालना है, इसके बारे में बहुत कुछ पढ़ा है। आम सहमति भारी है: अपने स्प्राइट्स को शानदार प्रदर्शन के लिए एक बड़े बनावट में पैक करें! तो मैं TexturePacker का उपयोग करके अपने छोटे स्प्राइट्स को बहुत बड़े स्प्राइटशीट में पैक करता हूं।

हालाँकि, मेरी योजना है कि प्रति वर्ण 10-15 एनिमेशन, स्थानांतरित करने के लिए 5 निर्देश, और प्रति एनीमेशन 15-40 फ्रेम (शायद औसतन 24)। 15 एनिमेशन, 5 दिशाओं और औसतन 24 फ्रेम प्रति एनीमेशन के साथ; यह प्रति वर्ण 1800 व्यक्तिगत फ्रेम है। यदि स्प्राइट शीट में पैक किया जाता है, तो इसके बजाय केवल 75 चित्र हैं। (एक स्प्राइट शीट प्रति एनिमेशन, दिशा के अनुसार। 15 * 5)

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

पात्रों के लिए, मैं पहले से ही उन्हें स्प्राइटशीट में पैक कर देता हूं। एक एकल चरित्र के बारे में घूमना, यह ज्यादातर समय काम करता है, हालांकि कभी-कभी यह रुक जाता है। हालाँकि, मैं अपने बीमार कल्पना कोड के लिए उस चरित्र के लिए सभी बनावट को उतारने के बजाय बनावट को स्वैप करता हूं।

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

हालाँकि, मुझे लगता है कि उन्हें एक समय में एक मेमोरी से बाहर और बाहर स्ट्रीमिंग करना बहुत तेज़ होगा, इसलिए मुझे केवल एक समय में मेमोरी में एक ही छवि रखने की आवश्यकता होगी। क्या इसका मतलब यह नहीं होगा कि किसी भी क्षण में मैं केवल प्रत्येक चरित्र को 45 + एमबी के बजाय कुछ KB का उपभोग करूंगा?

मुझे लगता है कि यह मेरे प्रदर्शन को मार देगा, क्योंकि स्ट्रीमिंग को अविश्वसनीय रूप से तेज़ होना होगा (15 छवियां स्मृति और प्रतिपादन से बाहर जा रही हैं, प्रति सेकंड) और हालांकि छवियां बहुत छोटी होंगी- चरित्र स्प्राइटशीट लोड करने के लिए यह एक बेहतर विचार हो सकता है। इसके बजाय स्मृति में। लेकिन मुझे अपने बड़े बॉस किरदार के लिए वैसे भी सिंगल-इमेज स्ट्रीम-जैसे रेंडर सिस्टम को कोड करना होगा।

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


1. आपने अपनी रैम या एचडीडी बाधाओं को निर्दिष्ट नहीं किया। तेज पहुंच में कितने पात्रों की आवश्यकता है? 2. पाठ के साथ कई प्रश्न हैं, हो सकता है कि आप उन्हें बोल्ड के साथ फोकस कर सकें या प्रश्नों को भागों में विभाजित कर सकें?
क्रॉम्स्टर

ओह मुझे खेद है। ज्यादा नहीं। मुझे लगता है कि किसी भी समय स्क्रीन पर व्यक्तिगत पात्रों की अधिकतम संख्या लगभग 40 होगी। यदि लोग अपने ग्राहकों को क्रैश करने की कोशिश करने के लिए एक बिंदु बनाते हैं, तो ... 130 पूर्ण अधिकतम है। आमतौर पर, ठेठ अधिकतम के लिए केवल 10 होना चाहिए, और पूर्ण अधिकतम <40 से अधिक नहीं होगा। 40 से ऊपर की कोई भी चीज़ एक चरम, चरम दुर्लभता होगी, जिसमें उपयोगकर्ता उद्देश्यपूर्ण ढंग से स्क्रीनशॉट के अलावा किसी अन्य कारण से पात्रों में रटना करने की कोशिश कर रहे हैं या पात्रों में रटना का मज़ा ले सकते हैं। 10 से ऊपर कुछ भी दुर्लभ है, और 40 के बारे में कुछ भी अत्यंत दुर्लभ है।
कार्टर 81१

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

आपको स्क्रीन पर कितने UNIQUE वर्णों की आवश्यकता है?
क्रॉस्टर

20 से अधिक नहीं। ऊपर से कुछ भी असंभव के बगल में होगा जब तक कि उन्होंने धोखा नहीं दिया। आमतौर पर 5-10।
कार्टर .81

जवाबों:


16

हमारे RTS रीमेक के साथ भी ऐसा ही मामला है। सभी इकाइयाँ और घर स्प्राइट हैं। हमारे पास इकाइयों और घरों और इलाकों के लिए 18 000 स्प्राइट हैं, साथ ही टीम के रंगों के लिए एक और ~ 6 000 (मास्क के रूप में लागू)। लंबे समय तक फैला हुआ हमारे पास फोंट में इस्तेमाल किए जाने वाले कुछ ~ 30 000 अक्षर भी हैं।

तो एटलस के पीछे मुख्य कारण हैं:

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

हमारे लिए क्या काम नहीं किया:

  • तालु बनावट। यह सुविधा केवल OpenGL 1.x 2.x में मौजूद थी और तब भी ज्यादातर GPU निर्माताओं द्वारा गिरा दी गई थी। हालाँकि, यदि आप OpenGL + Shaders का लक्ष्य रखते हैं, तो आप ऐसा कर सकते हैं कि shaders अपने आप को ठीक कर ले!
  • एनपीओटी बनावट, हमारे पास गलत सीमाओं और धुंधले स्प्राइट्स के साथ मुद्दे थे, जो पिक्सेल कला में अस्वीकार्य है। रैम का उपयोग बहुत अधिक था।

अब हमारे पास 1024x1024 के कई दर्जनों में पैक किए गए सभी सामान हैं (आधुनिक GPU भी बड़े आयामों का समर्थन करते हैं) और यह केवल ~ 300mb मेमोरी खाने के लिए अच्छी तरह से काम करता है, जो एक पीसी गेम के लिए काफी ठीक है। कुछ अनुकूलन हमारे पास थे:

  • RGBA8 (चेकरबोर्ड छाया) के बजाय RGB5_A1 का उपयोग करने के लिए उपयोगकर्ता विकल्प जोड़ें
  • जब संभव हो 8bit अल्फा से बचें और RGB5_A1 प्रारूप का उपयोग करें
  • कसकर पैक atlases में फैलता है (बिन पैकिंग एल्गोरिदम देखें)
  • HDD से एक चंक में सब कुछ स्टोर और लोड करें (संसाधन फ़ाइलों को ऑफ़लाइन उत्पन्न किया जाना चाहिए)
  • आप हार्डवेयर संपीड़न प्रारूप (DXT, S3TC, आदि) भी आज़मा सकते हैं

जब आप गंभीरता से मोबाइल उपकरणों पर जाने पर विचार करते हैं तो आप बाधाओं के बारे में चिंता करेंगे। अभी के लिए बस खेल काम कर रहे हैं और खिलाड़ियों को आकर्षित! ;)


यह अब तक का सबसे अच्छा समाधान था! मेरे स्प्राइट्स RGB5_A1 या RGBA4444 में किसी भी अलग नहीं दिखते हैं, लेकिन यह मेमोरी को बचाता है। राम और वीआरएएम में मेरी सभी संपत्तियों को लोड करने के लिए चैट में आपका सुझाव एकदम सही है। इससे भी आगे, आपने वैकल्पिक ग्राफिक स्तर रखने का सुझाव दिया है, जैसे कि उन लोगों के लिए उच्च परिभाषा क्लाइंट, जिनके पास रैम है, या आधे से framerate को कम करने का विकल्प है, आदि सभी के चारों ओर महान सुझाव, और वास्तव में मुझे क्या चाहिए!
कार्टर 81१

5

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

लोडिंग के समय:

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

Atlases में अपने बनावट में शामिल होने से बहुत कम प्रभाव पड़ेगा, क्योंकि आपके द्वारा VRAM में भेजे जाने वाली पूरी जानकारी समान होगी। वास्तव में, यदि आप अपने बनावट को दोहरा रहे हैं, और आपको अपने atlases में रिक्त स्थान छोड़ना है, तो आप वास्तव में VRAM में अधिक डेटा भेजेंगे , और इसलिए यह भाग धीमा होगा!

प्रदर्शन का प्रतिपादन:

एक बार जब आपके सभी बनावट वीआरएएम में हैं, तो आपके पास जितने टेक्सचर हैं, वे रेंडरिंग प्रदर्शन को प्रभावित नहीं करेंगे। आपके रेंडरिंग प्रदर्शन को प्रभावित करने वाले चार तत्व हैं:

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

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

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

  2. ड्रॉ कॉल: सामान्य तौर पर, आप अपनी ड्रॉ कॉल को न्यूनतम रखना चाह सकते हैं। अंगूठे का एक अच्छा नियम यह है कि यदि दो ड्रॉ कॉल के बीच कोई रेंडर राज्य परिवर्तन नहीं हैं, तो आप उन्हें एक ड्रॉ कॉल में शामिल कर सकते हैं। अधिक उन्नत प्रदर्शन लाभ के लिए, आप प्रत्येक 8 बनावट के लिए 8 बनावट नमूने, और समूह ड्रॉ कॉल का उपयोग, कह सकते हैं, इसलिए आपको केवल प्रत्येक 8 बनावट को बदलना होगा।

  3. त्रिकोण गणना: वास्तव में, आप जितने अधिक त्रिभुज खींचते हैं, उन्हें खींचने में उतना ही अधिक समय लगेगा। हालांकि, आधुनिक कंप्यूटरों में, और अधिकांश 2D गेम्स के लिए, आप इसे अधिकतम करने से बहुत दूर होंगे। आप सुरक्षित रूप से प्रति फ्रेम हजारों की संख्या में स्प्राइट्स खींच सकते हैं और फिर भी बहुत अच्छे फ्रैमरेट्स प्राप्त कर सकते हैं। यदि आप अपने GPU के साथ समस्याएँ आने से पहले आप अत्यधिक मात्रा में स्प्राइट्स खींच रहे हैं तो आप शायद अधिक CPU-बाउंड होंगे।

  4. एपीआई सेटिंग्स: यदि आप सब कुछ सही कर रहे हैं, और आप अभी भी कम अजीब हो रहे हैं, तो उन सेटिंग्स की जांच करें जिनके साथ आप अपने स्प्राइट्स को आकर्षित कर रहे हैं। मुझे एसएफएमएल का पता नहीं है, लेकिन उदाहरण के लिए, डायरेक्ट 3 डी 9 में, एक वर्टेक्स बफर बनाना D3DUSAGE_DYNAMIC, या D3DPOOL_MANAGEDआसानी से आपके रेंडरिंग टाइम्स को दस गुना बढ़ा सकता है। बेशक, vSync का उपयोग आपके मॉनिटर की ताज़ा दर पर आपके फ्रैमरेट को कैप करेगा। इसके अलावा, गैर-संरेखित FVFs का उपयोग करने से कुछ GPU में प्रदर्शन में कमी आ सकती है। यह भी Direct3D 9 के लिए है।

    आपके मामले में, आपके द्वारा उपयोग किए जा रहे एपीआई के लिए प्रलेखन की जाँच करें।

यदि आपके पास केवल पाठों की मात्रा कम से कम (1GB से कम) है, और आप स्प्राइट्स की कम मात्रा (प्रति फ्रेम एक लाख से कम) आकर्षित कर रहे हैं, तो पहली चीज जो मैं देखूंगा, वह है एपीआई सेटिंग्स को बदलना, और फिर रेंडर स्टेट्स की मात्रा कम करना और कॉल ड्रॉ करना।


अगर मुझे लोड समय की परवाह नहीं है, तो क्या मैं यह मान सकता हूं कि जब तक मैं रैम या वीआरएएम से बाहर नहीं निकल जाता, मुझे बस पहले से ही सब कुछ मेमोरी में लोड करना चाहिए?
कार्टर 81१

मैं केवल उन सभी चीज़ों से संबंधित हूँ जिनके बारे में मुझे RAM / VRAM पर कम चलने का डर है। मैं नहीं जानता कि क्यों, लेकिन यह मुझे इस बात की पुष्टि करता है कि जब भी वे बहुत सारे अनूठे स्प्राइट्स वाले क्षेत्र में लोड करने का प्रयास करेंगे, तो मेरा गेम क्रैश करने वाले उपयोगकर्ता क्रैश हो जाएंगे, या जब भी बहुत सारे पात्र अपनी स्क्रीन पर चलेंगे, दुर्घटनाग्रस्त हो जाएंगे। अगर मैं गलत नहीं हूं और प्रत्येक व्यक्ति स्प्राइट 96KB की खपत करता है, तो अगर प्रत्येक अद्वितीय चरित्र में 15 एनिमेशन, 5 दिशाएं, और औसत 24 फ्रेम प्रति एनीमेशन हैं- प्रत्येक व्यक्तिगत चरित्र पूरी तरह से लोड किया गया 173MB है। एक बार में स्क्रीन पर 10, शायद और भी अधिक, अद्वितीय वर्ण हो सकते हैं।
कार्टर 81१

@KromStern: यदि आप एटलस करते हैं, और आपको खाली स्थान (पैडिंग) छोड़ना है, तो डेटा बड़ा होगा, और इसलिए लोडिंग समय अधिक होगा। यह स्पष्ट है कि अधिक लोडिंग समय का कारण खाली स्थान है, और यह कुल लोडिंग समय डेटा की कुल राशि से संबंधित है, न कि बनावट की मात्रा से। मुझे वहां कुछ भी भ्रामक नहीं दिख रहा है, और मुझे लगता है कि मूल प्रश्न को समझने के लिए पर्याप्त ज्ञान वाला व्यक्ति डॉट्स में शामिल होने और सभी मामलों के लिए अपने स्वयं के निष्कर्ष बनाने में सक्षम होगा जब बनावट और एटलस पीओटी और एनओओटीटी हैं।
पांडा पायजामा

1
@ Carter81: आपको अपना लक्ष्य हार्डवेयर कॉन्फ़िगरेशन चुनना होगा, जैसे "i5, 1gb RAM, NVidia GT260, 400mb hdd" और उसी से काम करना होगा। हमेशा ऐसे पीसी होने वाले होते हैं जो कमज़ोर होते हैं और उनमें रैम कम होती है।
क्रॉस्टर

जाहिर है, उन्हें किसी भी समय सभी 15 एनिमेशन की आवश्यकता नहीं है। हालांकि, क्या होगा यदि सभी 10 अद्वितीय वर्ण एक ही समय में "कॉम्बैट मोड" में जाते हैं, और इस प्रकार 5 और एनिमेशन (वॉक, रन, आइडल, नॉन-कॉम्बैट वगैरह) के 5 सेट की आवश्यकता होती है, जिसे 5 और के साथ स्वैप किया जाए (कॉम्बैट वॉक, मुकाबला बेकार, मुकाबला आदि)? मैं बनावट की अदला-बदली करने से डरता हूं क्योंकि जब मैंने एसएफएमएल के साथ ऐसा करने की कोशिश की, तो इसने बनावट के कम होने पर क्लाइंट के ध्यान देने योग्य फ्रीज या पॉज बनाया । मैं नहीं जानता कि इतने सारे स्प्राइट्स को संभालने के लिए विभिन्न रणनीतियों के साथ मेरी अड़चन क्या होगी।
कार्टर .81
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.