गेम लूप में अपडेट स्वतंत्र रेंडरिंग का क्या मतलब है?

Question

खेल छोरों पर दर्जनों लेख, किताबें और चर्चाएं होती हैं। हालाँकि, मैं अक्सर कुछ इस तरह से आता हूँ:

while(running)
{
    processInput();
    while(isTimeForUpdate)
    {
        update();
    }
    render();
}

मूल रूप से इस दृष्टिकोण के बारे में मुझे जो परेशान कर रहा है वह है "अपडेट-इंडिपेंडेंट" रेंडरिंग जैसे कि एक फ्रेम रेंडर करना जब कोई बदलाव नहीं होता है। तो मेरा सवाल यह है कि इस दृष्टिकोण को अक्सर क्यों पढ़ाया जाता है?

Comments

व्यक्तिगत रूप से, मुझे gameprogrammingpatterns.com/game-loop.html एक उपयोगी स्पष्टीकरण मिला

— नील्स

रेंडरिंग में सभी परिवर्तन गेम स्थिति में परिलक्षित नहीं होते हैं। और मुझे संदेह है कि आपको कोड के उस टुकड़े के बारे में गलतफहमी है - यह आपको प्रति बार कई बार अपडेट करने की अनुमति देता है, प्रति अपडेट कई बार रेंडर नहीं करता।

— लुआं

ध्यान दें कि कोड पढ़ता है while (isTimeForUpdate), नहीं if (isTimeForUpdate)। मुख्य लक्ष्य यह नहीं है कि render()जब कोई हो update(), लेकिन update()बार-बार render()एस के बीच में न हो । बावजूद, दोनों स्थितियों के वैध उपयोग हैं। पूर्व मान्य होगा यदि राज्य आपके updateफ़ंक्शन के बाहर बदल सकता है , उदाहरण के लिए, वर्तमान समय जैसे अंतर्निहित स्थिति के आधार पर जो प्रदान किया गया है उसे बदल दें। उत्तरार्द्ध वैध है क्योंकि यह आपके भौतिकी इंजन को बहुत सारे छोटे, सटीक अपडेट करने की संभावना देता है, जो कि बाधाओं के माध्यम से 'वार करने' की संभावना को कम करता है।

— थियरी

एक और तार्किक प्रश्न होगा "अपडेट की बात क्या

— user1306322

आपके पास कितनी बार एक अपडेट है जो कुछ भी नहीं करता है? पृष्ठभूमि एनिमेशन या ऑन-स्क्रीन घड़ियों को भी अपडेट नहीं कर रहे हैं?

— pjc50

Answer 1

रास्ते में बहुत सारी आकर्षक चुनौतियों के साथ हम इस आम सम्मेलन में कैसे पहुंचे, इसका एक लंबा इतिहास है, इसलिए मैं चरणों में प्रेरित करने की कोशिश करूंगा:

1. समस्या: डिवाइस अलग-अलग गति से चलते हैं

कभी एक आधुनिक पीसी पर एक पुराना डॉस गेम खेलने की कोशिश करें, और यह अनपेक्षित रूप से तेज चलता है - बस एक धब्बा?

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

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

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

यहाँ अचूक उपाय उस दर को लॉक करना है जिस पर हम गेमप्ले स्टेट अपडेट करते हैं। इस तरह हम नतीजों की गारंटी दे सकते हैं।

2. तो, क्यों न केवल फ्रैमरेट को लॉक किया जाए (जैसे। VSync का उपयोग करके) और फिर भी गेमप्ले स्टेट अपडेट और लॉकस्टेप में रेंडरिंग चलाएं?

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

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

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

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

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

3. एक निश्चित टाइमस्टेप पर अपडेट नहीं करने से क्या समस्याएँ होती हैं?

मुझे लगता है कि यह मूल प्रश्न का मांस है: अगर हम अपने अपडेट को कम कर देते हैं और कभी-कभी बीच में कोई गेम स्टेट अपडेट के साथ दो फ्रेम रेंडर करते हैं, तो क्या यह कम फ्रैमरेट में लॉकस्टेप रेंडरिंग के समान नहीं है, क्योंकि इसमें कोई दृश्य परिवर्तन नहीं है स्क्रीन?

वास्तव में कई अलग-अलग तरीके हैं जो गेम इन अद्यतनों को अच्छी तरह से प्रभावित करने के लिए उपयोग करते हैं:

a) अद्यतन दर प्रदान की गई फ्रैमरेट की तुलना में तेज़ हो सकती है

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

अब 120 एफपीएस पर रेंडर करने वाले खिलाड़ी को प्रति फ्रेम 2 अपडेट मिल सकते हैं, जबकि 30 एफपीएस पर कम स्पेक हार्डवेयर रेंडरिंग पर खिलाड़ी को प्रति फ्रेम 8 अपडेट मिलते हैं, और उनके दोनों गेम एक ही गेमप्ले-टिक-प्रति-रियलटाइम-सेकंड की गति से चलते हैं। बेहतर हार्डवेयर इसे सुचारू बनाता है, लेकिन गेमप्ले कैसे काम करता है, यह मौलिक रूप से नहीं बदलता है।

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

ख) इंटरपोलेटिंग (या एक्सट्रपॉलेटिंग) अपडेट के बीच गेम स्टेट

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

जब यह सही किया जाता है, तो आंदोलन को चिकना महसूस होता है, और यहां तक ​​कि फ्रैमरेट में कुछ उतार-चढ़ाव को मुखौटा करने में मदद करता है, जब तक कि हम बहुत कम नहीं छोड़ते हैं ।

ग) गैर-गेमप्ले-राज्य परिवर्तनों में चिकनाई जोड़ना

गेमप्ले स्टेट को इंटरपोल किए बिना भी हम कुछ स्मूथनेस जीत सकते हैं।

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

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

4. हर चीज़ के लिए सिर्फ (c) स्टाइल का उपयोग क्यों नहीं किया जाता है? यदि यह एनीमेशन और UI के लिए काम करता है, तो क्या हम वर्तमान गेमरेट को मैच करने के लिए अपने गेमप्ले स्टेट अपडेट को सरलता से माप नहीं सकते हैं?

हां * यह संभव है, लेकिन नहीं यह सरल नहीं है।

यह उत्तर पहले से ही लंबा है इसलिए मैं सभी विवरणों में नहीं जाऊंगा, बस एक त्वरित सारांश:

• रैखिक परिवर्तन के deltaTimeलिए परिवर्तनशील-लंबाई अपडेट को समायोजित करने के लिए कार्यों द्वारा गुणा (उदाहरण के लिए निरंतर वेग के साथ आंदोलन, एक टाइमर की उलटी गिनती, या एक एनीमेशन समयरेखा के साथ प्रगति)

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

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

इसलिए, मध्यम जटिलता के खेल के लिए सामान्य मामले में, deltaTimeस्केलिंग के माध्यम से पूरी तरह से निरंतर व्यवहार और निष्पक्षता बनाए रखना कहीं न कहीं बहुत मुश्किल और रखरखाव के लिए एकमुश्त संक्रामक है।

अद्यतन दर को मानकीकृत करने से हम कई परिस्थितियों में अधिक सरल व्यवहार की गारंटी देते हैं , अक्सर सरल कोड के साथ।

रेंडरिंग से डिकोड किए गए उस अपडेट रेट को रखने से हमें गेमप्ले लॉजिक में बदलाव किए बिना अनुभव की चिकनाई और प्रदर्शन को नियंत्रित करने की सुविधा मिलती है ।

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

Comments

ऐसे मामलों में जहां सब कुछ समान फ्रेम दर का उपयोग कर रहा होगा, सब कुछ सिंक्रनाइज़ करने से नियंत्रक के नमूने में देरी हो सकती है और जब खेल प्रतिक्रिया करता है। कुछ पुरानी मशीनों पर कई गेमों के लिए, सबसे खराब स्थिति 17ms से कम होगी (नियंत्रण ऊर्ध्वाधर रिक्त की शुरुआत में पढ़ा जाता है, फिर गेम राज्य परिवर्तन लागू होते हैं, और बीम को स्क्रीन के नीचे ले जाने के दौरान अगला फ्रेम प्रदान किया जाता है) । चीजों को कम करने से अक्सर सबसे खराब स्थिति में महत्वपूर्ण वृद्धि होगी।

— सुपरकैट

हालांकि यह सच है कि अधिक जटिल अपडेट पाइपलाइनों को अनायास ही विलंबता का परिचय देना आसान हो जाता है, यह सही तरीके से लागू होने पर डिकोड किए गए दृष्टिकोण का एक आवश्यक परिणाम नहीं है। वास्तव में, हम विलंबता को कम करने में भी सक्षम हो सकते हैं । चलो 60 एफपीएस पर एक गेम लेते हैं। read-update-renderलॉकस्टेप के साथ , हमारी सबसे खराब स्थिति विलंबता 17ms (ग्राफिक्स पाइपलाइन की अनदेखी और अब के लिए प्रदर्शन विलंबता) है। एक ही फ्रैमरेट में एक डिकूप्ड (read-update)x(n>1)-renderलूप के साथ , हमारी सबसे खराब स्थिति विलंबता केवल एक ही या बेहतर हो सकती है क्योंकि हम इनपुट पर अक्सर या अधिक जांच करते हैं और कार्य करते हैं। :)

— DMGregory

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

— 17 अक्टूबर को Oskuro

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

— सुपरकैट

@ ऑस्कर: यह एक गड़बड़ नहीं था। अपडेट लूप की गति स्क्रीन पर कितने आक्रमणकारियों की परवाह किए बिना स्थिर रहती है, लेकिन गेम हर अपडेट लूप पर सभी आक्रमणकारियों को आकर्षित नहीं करता है।

— सुपरकैट

Answer 2

अन्य उत्तर अच्छे हैं और बात करते हैं कि गेम लूप मौजूद क्यों है और रेंडर लूप से अलग होना चाहिए। हालांकि, "क्यों एक फ्रेम प्रस्तुत करना जब कोई परिवर्तन नहीं हुआ है?" के विशिष्ट उदाहरण के लिए यह वास्तव में सिर्फ हार्डवेयर और जटिलता के लिए आता है।

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

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

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

Comments

यहाँ प्रतिपादन के बीच एक अंतर किया जा सकता है (सब कुछ) केवल जब कुछ बदल गया है (जो सवाल के बारे में पूछता है), और केवल उन भागों का प्रतिपादन किया है जो बदल गए हैं (आपका उत्तर क्या वर्णन करता है)।

— DMGregory

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

— Waddles

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

— स्टीवन स्टैडनिक

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

— DMGregory

Answer 3

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

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

Comments

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

— ग्राहम

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

— सुपरकैट

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

— tyjkenn

मानव आमतौर पर 60 एफपीएस से अधिक तेजी से अनुभव नहीं कर सकता है, इसलिए यह संसाधनों को तेजी से प्रदान करने पर व्यर्थ है। मैं उस बयान के साथ मुद्दा उठाता हूं। VR HMDs 90Hz पर रेंडर करता है, और यह ऊपर जा रहा है। मेरा विश्वास करो जब मैं आपको बताता हूं कि आप हेडसेट पर 90 हर्ट्ज और 60 हर्ट्ज के बीच अंतर को महसूस कर सकते हैं। इसके अलावा, मैंने हाल ही में कई खेलों को देखा है जो सीपीयू-बाउंड जीपीयू-बाउंड के रूप में हैं। "प्रतिपादन आमतौर पर सबसे धीमी प्रक्रिया है" यह कहना जरूरी नहीं है।

— डी एनवी

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

— tyjkenn 21

Answer 4

आपके प्रश्न में एक निर्माण जैसा अर्थ हो सकता है यदि रेंडर सबसिस्टम में "अंतिम रेंडर के बाद बीता हुआ समय" की कुछ धारणा है ।

उदाहरण के लिए, एक दृष्टिकोण जिसमें खेल की दुनिया में किसी वस्तु की स्थिति का निर्धारण (x,y,z)एक ऐसे निर्देश के साथ किया जाता है, जो वर्तमान आंदोलन वेक्टर को संग्रहीत करता है (dx,dy,dz)। अब, आप अपना गेम लूप लिख सकते हैं ताकि स्थिति का परिवर्तन updateविधि में हो, लेकिन आप इसे डिजाइन भी कर सकते हैं ताकि आंदोलन का परिवर्तन उस दौरान हो update। बाद के दृष्टिकोण के साथ, भले ही आपका खेल राज्य वास्तव में अगले update, ए तक नहीं बदलेगाrender-एक उच्च आवृत्ति पर कहा जाने वाला फंक्शन पहले से ही थोड़ा अद्यतन स्थिति में वस्तु को खींच सकता है। जबकि यह तकनीकी रूप से आप जो देखते हैं और जो आंतरिक रूप से प्रतिनिधित्व करते हैं, के बीच एक विसंगति की ओर जाता है, अंतर सबसे व्यावहारिक पहलुओं के लिए मायने नहीं रखने के लिए पर्याप्त है, फिर भी एनिमेशन बहुत अधिक चिकनी दिखने की अनुमति देता है।

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

Answer 5

अन्य उत्तरों के अलावा ...

राज्य के परिवर्तन की जाँच के लिए महत्वपूर्ण प्रसंस्करण की आवश्यकता होती है। अगर यह वास्तव में प्रसंस्करण की तुलना में परिवर्तनों की जांच करने के लिए समान (या अधिक!) प्रसंस्करण समय लेता है, तो आपने वास्तव में स्थिति को बेहतर नहीं बनाया है। इमेज रेंडर करने के मामले में, जैसा कि @Waddles कहता है, एक वीडियो कार्ड वास्तव में बार-बार एक ही गूंगा काम करने में अच्छा है, और इसे बदलने के लिए डेटा के प्रत्येक chunk को जांचना अधिक महंगा है, बस इसे इसे स्थानांतरित करना है प्रसंस्करण के लिए वीडियो कार्ड के लिए। इसके अलावा अगर रेंडरिंग गेमप्ले है तो स्क्रीन के आखिरी टिक में नहीं बदला है।

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