2 डी गेम में हम बड़ी वीडियो मेमोरी आवश्यकताओं को कैसे हल करते हैं?

40

हम एलीग्रो सी / सी ++ में 2 डी गेम (फैक्टरियो) विकसित कर रहे हैं, और गेम की सामग्री बढ़ने पर हमें वीडियो मेमोरी आवश्यकताओं में वृद्धि का सामना करना पड़ रहा है।

हम वर्तमान में उन सभी छवियों के बारे में पूरी जानकारी इकट्ठा करते हैं जो पहले इस्तेमाल की जा रही हैं, इन सभी छवियों को यथासंभव अधिक से अधिक फसलें और उन्हें बड़े एटलायस में कसकर व्यवस्थित करें। ये एटलस वीडियो मेमोरी में संग्रहीत होते हैं, जिनमें से आकार सिस्टम की सीमाओं पर निर्भर करता है; वर्तमान में यह आमतौर पर 8192x8192 तक की 2 छवियां हैं, इसलिए उन्हें 256Mb से 512Mb वीडियो मेमोरी की आवश्यकता होती है।

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

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

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

हमारे पास कुछ अतिरिक्त आवश्यकताएं हैं:

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

परीक्षण में 1x1 से 300x300 तक के आकार के लिए एक बैच में 10 000 स्प्राइट्स शामिल हैं, हर कॉन्फ़िगरेशन के लिए कई बार। मैंने Nvidia Geforce GTX 760 पर परीक्षण किए।

वीडियो बिटमैप से वीडियो बिटमैप ड्राइंग में 0.1us प्रति स्प्राइट लिया गया, जब स्रोत बिटमैप व्यक्तिगत बिटमैप (एटलस संस्करण) के बीच नहीं बदल रहा था; आकार मायने नहीं रखता था
वीडियो बिटमैप वीडियो बिटमैप ड्राइंग के लिए, जबकि स्रोत बिटमैप चित्र (गैर एटलस संस्करण) के बीच स्विच किया गया था, प्रति स्प्राइट 0.56us लिया; आकार या तो मायने नहीं रखता था।
वीडियो बिटमैप ड्राइंग के लिए मेमोरी बिटमैप वास्तव में संदिग्ध था। 1x1 से 200x200 तक के आकार में 0.3 बिट प्रति बिटमैप लिया गया, इसलिए यह बहुत धीमा नहीं है। बड़े आकार के लिए, समय बहुत नाटकीय रूप से, 9x पर 201x201 के लिए 3116us से 291x291 के लिए शुरू हुआ।

एटलस का उपयोग करने से 5 से अधिक के कारक से प्रदर्शन में वृद्धि होती है। यदि मेरे पास प्रतिपादन के लिए 10ms थे, तो एटलस के साथ मैं प्रति फ्रेम 100 000 स्प्राइट्स तक सीमित हूं, और इसके बिना, 20 000 स्प्राइट्स की सीमा। यह समस्याग्रस्त होगा।

मैं भी छाया के लिए बिटमैप संपीड़न और 1bpp बिटमैप प्रारूप का परीक्षण करने का एक तरीका खोजने की कोशिश कर रहा था, लेकिन मुझे एलीग्रो में ऐसा करने का तरीका नहीं मिल पा रहा था।

c++ 2d memory-efficiency allegro

— Marwin
स्रोत

1

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

— MichaelHouse

सहायता का शुक्रिया। तो फिर उस जगह को पूछने के लिए कौन सी तकनीक का उपयोग करना है? मैं विशिष्ट इंजन की सिफारिश के साथ उत्तर की तलाश में नहीं हूं, लेकिन मैं 2d इंजन की गहराई से तुलना करने और प्रदर्शन और प्रयोज्य परीक्षणों सहित मैन्युअल रूप से एक-एक करके उनका निरीक्षण करने में सक्षम नहीं था।

— मर्विन

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

— MichaelHouse

2

क्या आप अपनी बनावट को संकुचित कर रहे हैं?

— गयआरटीटी

3

@Marwin, संपीड़ित बनावट असम्पीडित बनावट की तुलना में बहुत बेहतर प्रदर्शन कर सकते हैं क्योंकि वे आवश्यक मेमोरी बैंडविड्थ को कम कर देते हैं (यह विशेष रूप से मोबाइल प्लेटफार्मों पर सच है जहां बैंडविड्थ बहुत कम है)। आप केवल अपने बनावट को संकुचित करके स्मृति की एक बड़ी राशि बचा सकते हैं। वास्तव में, एकमात्र नकारात्मक पक्ष कलाकृतियाँ हैं जिन्हें अनिवार्य रूप से पेश किया जाता है।

— गाइर टीटी

17

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

इसलिए RGBA32 के खिलाफ कुछ अनुकूलन आप उपयोग कर रहे हैं:

अपने स्प्राइट्स पूल को पहले कई छोटे-छोटे परमाणुओं में विभाजित करें और उन्हें अन्य उत्तरों में कवर किए गए मांग पर उपयोग करें। यह भी व्यक्तिगत रूप से प्रत्येक एटलस के लिए विभिन्न अनुकूलन तकनीकों का उपयोग करने की अनुमति देता है । मुझे संदेह है कि आपके पास व्यर्थ रैम की थोड़ी कम होगी, जब इतने बड़े बनावट के लिए पैकिंग होती है, तो आमतौर पर तल पर अप्रयुक्त क्षेत्र होते हैं;
तालु बनावट का उपयोग करने का प्रयास करें । यदि आप shaders का उपयोग करते हैं तो आप shaders कोड में पैलेट को "लागू" कर सकते हैं;
आप RGBA8 के बजाय RGB5_A1 का उपयोग करने के लिए एक विकल्प जोड़ने पर विचार कर सकते हैं (यदि उदाहरण के लिए चेकरबोर्ड छाया आपके खेल के लिए ठीक है)। जब संभव हो तो 8bit अल्फा से बचें और छोटे सटीक (एक जैसे RGBA4) के साथ RGB5_A1 या समकक्ष प्रारूपों का उपयोग करें, वे आधे स्थान लेते हैं;
सुनिश्चित करें कि आप एटलस में स्प्राइट्स पैकिंग कर रहे हैं (बिन पैकिंग एल्गोरिदम देखें), जब आवश्यक हो तो स्प्राइट को घुमाएं और देखें कि क्या आप रोम्बस स्प्राइट्स के लिए पारदर्शी कोनों को ओवरलैप कर सकते हैं;
आप हार्डवेयर संपीड़न प्रारूपों (DXT, S3TC, आदि) की कोशिश कर सकते हैं - वे नाटकीय रूप से रैम उपयोग को कम कर सकते हैं, लेकिन संपीड़न कलाकृतियों के लिए जाँच करें - कुछ छवियों पर अंतर ध्यान देने योग्य हो सकता है (आप इसे पहले बुलेट बिंदु में वर्णित के रूप में चुनिंदा उपयोग कर सकते हैं) लेकिन कुछ पर - बहुत उच्चारण। विभिन्न संपीड़न प्रारूप अलग-अलग कलाकृतियों का कारण बनते हैं, इसलिए आप एक को चुन सकते हैं जो आपकी कला शैली के लिए सबसे अच्छा है।
बड़े स्प्राइट को विभाजित करने में देखें (निश्चित रूप से मैन्युअल रूप से नहीं, लेकिन आपकी बनावट एटलस पैकर के भीतर) स्टेटिक बैकग्राउंड स्प्राइट और एनिमेटेड भागों के लिए छोटे स्प्राइट्स।

— क्रॉमस्टर कहते हैं कि मोनिका का समर्थन करें
स्रोत

2

डीएक्सटी का उपयोग करने के लिए +1, यह बहुत अच्छी बात है। महान संपीड़न और सीधे GPU द्वारा उपयोग किया जाता है ताकि ओवरहेड न्यूनतम हो।

1

मैं dxt से सहमत हूं। आप संभवतः DXT7 समर्थन (DX11 + हार्डवेयर) के लिए क्वेरी भी कर सकते हैं, जो कि DXT1 के समान आकार (लेकिन स्पष्ट रूप से) उच्च गुणवत्ता वाला है। हालाँकि आपको या तो लोडिंग के दौरान डबल टेक्सचर (एक DXT7 और एक DXT1), या कंप्रेस / डीकंप्रेस की आवश्यकता होगी।

— प्रोग्राममेड

5

सबसे पहले आपको अधिक, छोटे बनावट वाले एटलासेस का उपयोग करने की आवश्यकता है। कम बनावट आपके पास अधिक कठिन और कठोर मेमोरी प्रबंधन होगा। मैं सुझाव देता हूं कि 1024 का एक एटलस आकार होगा, जिस स्थिति में आपके पास 2 के बजाय 128 बनावट होंगे, या 2048 के मामले में आपके पास 32 बनावट होंगे, जिन्हें आप आवश्यकतानुसार लोड और अनलोड कर सकते हैं।

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

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

हालांकि एक मुद्दा यह है कि क्या होता है जब कुछ अप्रत्याशित होता है जो खेल को आगे बढ़ाने में सक्षम नहीं था?

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

— एपीआई-जानवर
स्रोत

मैंने कुछ आवश्यकताएँ जोड़ीं जिन्हें मैंने छोड़ दिया। लोडिंग स्क्रीन, या किसी भी तरह की लोडिंग संभव नहीं है। सब कुछ पृष्ठभूमि में किया जाना चाहिए, या व्यक्तिगत टिक्स को कम करना (प्रत्येक के लिए 15ms से कम), जबकि आमतौर पर पहले से ही तैयार तैयारी और गेम अपडेट द्वारा उपयोग किया जाता है। वैसे भी, छोटे भागों में विभाजित करने से स्विचिंग में कुछ लचीलापन आ सकता है, यह निश्चित रूप से तेज़ होगा। सवाल यह है कि रेंडर करते समय यह प्रदर्शन को कितना नुकसान पहुंचाता है, क्योंकि रेंडर को धीमा करते हुए सोर्स बिटमैप स्विच करना। कितना होगा कहने के लिए मुझे सटीक माप करना होगा।

— मर्विन

@Marwin प्रदर्शन प्रभाव, हाँ, लेकिन जब से आप 2D के साथ काम कर रहे हैं तब भी आपको इसे एक मुद्दा बनने से बहुत दूर होना चाहिए। यदि रेंडरिंग वर्तमान में 1ms प्रति फ्रेम लेता है, और छोटे बनावट के माध्यम से यह अचानक 2ms लेता है, तो यह अभी भी तेजी से 60 एफपीएस तक पहुंचने के लिए पर्याप्त से अधिक है। (16ms)

— एपीआई-जानवर

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

— एपीआई-बीस्ट

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

— मर्विन

@Marwin Hm, 10k ऑब्जेक्ट्स आमतौर पर पीसी या आधुनिक लैपटॉप के लिए कोई समस्या नहीं होनी चाहिए यदि आप उचित बैचिंग का उपयोग करते हैं, तो क्या आपने अपने रेंडरिंग कोड को प्रोफाइल किया है?

— एपीआई-बीस्ट

2

वाह, कि 3 जी मॉडल मैं अनुमान से उत्पन्न एनीमेशन स्प्राइट की एक मोटी राशि है?

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

मुझे नहीं लगता कि लोडिंग और अनलोडिंग आपके लिए बहुत कुछ करेगी क्योंकि आप एक ही समय में स्क्रीन पर बहुत अधिक सब कुछ कर सकते हैं।

— aaaaaaaaaaaa
स्रोत

2

सबसे पहले सबसे कुशल बनावट प्रारूप को खोजें, जिसे आप अभी भी खेल के दृश्यों से खुश हो सकते हैं, चाहे यह RGBA4444 हो, या DXT कम्प्रेशन आदि। यदि आप एक DXT अल्फा संपीड़ित छवि में उत्पन्न कलाकृतियों से खुश नहीं हैं, तो क्या यह व्यवहार्य है अल्फा के लिए 4 या 8 बिट ग्रेस्केल मास्किंग बनावट के साथ संयुक्त रंग के लिए डीएक्सटी 1 संपीड़न का उपयोग करके छवियों को गैर-पारदर्शी बनाने के लिए? मुझे लगता है कि आप GUI के लिए RGBA8888 पर बने रहेंगे।

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

अगला कदम इन बनावटों के मिपमैप संस्करणों को उत्पन्न करना होगा जैसा कि किसी ने ऊपर बताया है। मैं उन्हें एक फ़ाइल में अलग से संग्रहीत नहीं करूँगा। इसलिए आप प्रत्येक फ़ाइल के 1024x1024, 512x512, 256x256 आदि संस्करणों के साथ समाप्त हो जाएंगे और मैं ऐसा तब तक करूंगा जब तक कि मैं विस्तार के सबसे निचले स्तर तक नहीं पहुँच जाता, जिसे मैं कभी प्रदर्शित करना चाहता हूँ।

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

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

— ईसाई
स्रोत

1

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

बड़े ज़ूम-आउट के लिए जिसे आप लागू करना चाहते हैं, आपको mipmaps का उपयोग करना होगा। Mipmaps आपके बनावट के निचले-रिज़ॉल्यूशन संस्करण हैं जो तब उपयोग किए जाते हैं जब ऑब्जेक्ट कैमरे से काफी दूर होते हैं। इसका मतलब है कि आप अपने 8192x8192 को 4096x4096 के रूप में और फिर 2048x2048 और इसी तरह के अन्य को बचा सकते हैं, और आप छोटे प्रस्तावों पर स्विच करते हैं जो आप स्क्रीन पर स्प्राइट को देखते हैं। लोड करने के दौरान आप दोनों को अलग-अलग बनावट के रूप में सहेज सकते हैं या उनका आकार बदल सकते हैं (लेकिन रनटाइम के दौरान mipmaps बनाने से आपके खेल के लिए लोडिंग समय बढ़ जाएगा)।

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

— पाब्लो एरियल
स्रोत

1

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

— मर्विन

हाँ, आपको सब कुछ लोड नहीं करना है, आपको केवल वही उपयोग करना है जो आप उपयोग करते हैं। जब भी आप VRAM में भरी हुई बनावट पर एक पिक्सेल बदलना चाहते हैं, सिस्टम को RAM में ENTIRE TEXTURE को स्थानांतरित करना है, बस आपको एक पिक्सेल को संशोधित करने के लिए, इसे वापस VRAM में ले जाना है। यदि आपके पास एक ही बनावट में सब कुछ है, तो इसमें 256 एमबी रैम तक चलना फिर वीआरएएम पर वापस जाना शामिल है, जो पूरे कंप्यूटर को लॉक करता है। इसे अलग-अलग फाइलों और बनावटों में अलग-अलग करने से यह करने का सही तरीका है।

— पाब्लो एरियल

बनावट का संशोधन जो स्मृति और कॉपी में राम को कॉपी करता है, केवल निरंतर बिटमैप के लिए लागू होता है, कैश संभवतः निरंतर पर सेट नहीं किया जाएगा, केवल नकारात्मक पक्ष यह प्रदर्शित होने / खो जाने पर इसे ताज़ा करने की आवश्यकता होगी। लेकिन एलेग्रो में, vram से मेमोरी बिटमैप (गेम प्रीव्यू) को बचाने के लिए 640X480 तस्वीर की भी सरल कॉपी में काफी लंबा समय लगता है।

— मर्विन

1

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

— मर्विन

1

अलग-अलग फ़ाइलों में इन मैप-मैप किए गए टेक्सचर के होने से मुझे प्लेयर के ज़ूम होने पर सभी एटलस को फिर से लोड करने के लिए मजबूर होना पड़ेगा। चूंकि इंजन में एमएस की कुछ इकाइयाँ हैं।

— मर्विन

0

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

— Darxval
स्रोत