👶🏿 👩‍❤️‍💋‍👩 📺 खेल चक्र या इलेक्ट्रोकार्डियोगामा 🧑🏾‍🤝‍🧑🏾 🗃️ 👨‍⚖️

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

खेल चक्र

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

bool game_is_running = true; while( game_is_running ) { update_game(); display_game(); }

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

एफपीएस
एफपीएस "फ्रेम्स प्रति सेकंड" (कार्मिक प्रति सेकंड, लगभग। ट्रांसलेशन।) का संक्षिप्त नाम है। ऊपर प्रस्तुत गेम लूप कार्यान्वयन के संदर्भ में, यह एक सेकंड में डिस्प्ले_गेम () पर कॉल की संख्या है।

खेल की गति
गेम की गति एक सेकंड में गेम स्टेट अपडेट की संख्या है। दूसरे शब्दों में, समय की प्रति सेकंड update_game () को कॉल की संख्या।

निरंतर खेल की गति के आधार पर एफपीएस

कार्यान्वयन

समय समस्या का सबसे आसान समाधान 25 बार / सेकंड की निश्चित आवृत्ति पर कॉल करना है। इस दृष्टिकोण को लागू करने वाला कोड नीचे है।

 const int FRAMES_PER_SECOND = 25; const int SKIP_TICKS = 1000 / FRAMES_PER_SECOND; DWORD next_game_tick = GetTickCount(); // GetTickCount() returns the current number of milliseconds // that have elapsed since the system was started int sleep_time = 0; bool game_is_running = true; while( game_is_running ) { update_game(); display_game(); next_game_tick += SKIP_TICKS; sleep_time = next_game_tick - GetTickCount(); if( sleep_time >= 0 ) { Sleep( sleep_time ); } else { // Shit, we are running behind! } }

यह एक बड़े प्लस के साथ एक कार्यान्वयन है: SIMPLICITY! जैसे ही आप जानते हैं कि update_game () को प्रति सेकंड 25 बार कहा जाता है, बाकी कोड लिखना स्टीमर शलजम की तुलना में आसान हो जाता है। उदाहरण के लिए, रिप्ले कार्यक्षमता को लागू करना एक तुच्छ कार्य बन जाता है। यदि गेम यादृच्छिक चर का उपयोग नहीं करता है, तो आप बस उपयोगकर्ता इनपुट में लॉग इन कर सकते हैं और बाद में इसे खेल सकते हैं। अपनी परीक्षण मशीन पर, आप FRAMES_PER_SECOND के लिए कुछ समझौता मूल्य पा सकते हैं, लेकिन एक तेज़ या धीमे हार्डवेयर पर क्या होता है? आइए जानें।

कमजोर लोहा

यदि लोहा किसी दिए गए FPS का सामना करने में सक्षम है, तो कोई समस्या नहीं है। जब मशीन एक निश्चित स्तर पर एफपीएस नहीं रख सकती है तो समस्याएं दिखाई देंगी। खेल धीमा चलेगा। सबसे खराब स्थिति में, खेल कुछ अंतराल खो देगा, जबकि अन्य में यह ठीक काम करेगा। समय अलग-अलग गति से बहेगा, जो अंत में आपके खेल को अजेय बना सकता है।

उत्पादक लोहा

शक्तिशाली हार्डवेयर पर कोई समस्या नहीं होगी, लेकिन कंप्यूटर बेकार हो जाएगा, "कीमती" (जाहिरा तौर पर विडंबना? - बर्बाद करना। अनुवाद।) प्रोसेसर समय। 25..30 एफपीएस से खेल शुरू करने में शर्म आएगी, जब यह 300 के लिए दे सकता है! प्रोसेसर को पूरी तरह से उपयोग करते समय यह दिखा सकता है कि इसकी तुलना में आपका खेल आकर्षण में खो जाएगा। दूसरी ओर, मोबाइल प्लेटफार्मों पर यह बेहतर के लिए हो सकता है - यह ऊर्जा बचाएगा।

निष्कर्ष

एफपीएस को एक निश्चित गेम स्पीड में बांधना एक सरल उपाय है जो कोड को सरल रखता है। लेकिन समस्याएं हैं: एफपीएस के लिए बहुत अधिक मूल्य निर्धारित करना हम कमजोर हार्डवेयर पर समस्याएं पैदा करेंगे; मूल्य को बहुत कम करने से अकुशल रूप से शक्तिशाली लोहे का उपयोग होगा।

चर एफपीएस खेल की गति

कार्यान्वयन

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

 DWORD prev_frame_tick; DWORD curr_frame_tick = GetTickCount(); bool game_is_running = true; while( game_is_running ) { prev_frame_tick = curr_frame_tick; curr_frame_tick = GetTickCount(); update_game( curr_frame_tick - prev_frame_tick ); display_game(); }

कोड जटिल है क्योंकि अब हमें update_game () में समय डेल्टा को संभालना होगा। लेकिन कोड थोड़ा जटिल हो गया। मैंने बहुत सारे स्मार्ट डेवलपर्स को देखा जिन्होंने इस दृष्टिकोण को लागू किया। निश्चित रूप से उनमें से एक इस पोस्ट को पढ़ने से पहले अपने दम पर इस तरह के चक्र को लागू करने में सक्षम होना चाहेंगे। नीचे मैं दिखाऊंगा कि क्यों इस दृष्टिकोण में कमजोर हार्डवेयर और शक्तिशाली हार्डवेयर (हाँ ... और शक्तिशाली हार्डवेयर भी) पर गंभीर समस्याएं हो सकती हैं।

कमजोर लोहा

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

शक्तिशाली लोहा

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

>>> 0.1
0.10000000000000001

यह अपने आप में निडर है, लेकिन क्रमिक गणना में समस्याएं आती हैं। मान लीजिए कि आपके पास तोते में 0.001 (मुक्त अनुवाद, लगभग अनुवाद) के साथ एक कार है। 10 सेकंड के बाद, मशीन 10.0 तोतों की दूरी तय करेगी। यदि हम इस गणना को फ्रेम में तोड़ते हैं, तो हमें एक पैरामीटर के रूप में एफपीएस के साथ निम्नलिखित फ़ंक्शन मिलते हैं:

>>> def get_distance( fps ):
... skip_ticks = 1000 / fps
... total_ticks = 0
... distance = 0.0
... speed_per_tick = 0.001
... while total_ticks < 10000:
... distance += speed_per_tick * skip_ticks
... total_ticks += skip_ticks
... return distance

और नुका, चलो 40 एफपीएस के लिए यात्रा की गई दूरी की गणना करने का प्रयास करें।

>>> get_distance( 40 )
10.000000000000075

एक मिनट रुको! यह 10.0 तोते नहीं है! क्या हुआ? सब कुछ सरल है ... चूंकि हमने पथ गणना को 400 फ़्रेमों में विभाजित किया है, इसलिए समन के दौरान एक महत्वपूर्ण त्रुटि संचित है। सोचिए, 100 एफपीएस पर क्या होगा?

>>> get_distance( 100 )
9.9999999999998312

वाह! त्रुटि और भी अधिक हो गई है !!! ऐसा इसलिए है क्योंकि हम 100 एफपीएस में और भी अधिक जोड़ बनाते हैं। नतीजतन, त्रुटि अधिक जमा होती है। इस प्रकार, खेल 40 एफपीएस और 100 एफपीएस पर अलग तरह से काम करेगा।

>>> get_distance( 40 ) - get_distance( 100 )
2.4336088699783431e-13

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

निष्कर्ष

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

लगातार खेल की गति और अधिकतम एफपीएस

कार्यान्वयन

हमारा पहला कार्यान्वयन, "FPS डिपेंडेंट ऑन ए कांस्टेंट गेम स्पीड", कमजोर हार्डवेयर पर समस्या है। यह FPS और गेम स्टेटस अपडेट दोनों के लैग उत्पन्न करता है। इस समस्या का एक संभावित समाधान एक निश्चित आवृत्ति पर राज्य को अद्यतन करना है, लेकिन प्रतिपादन आवृत्ति को कम करना है। इस दृष्टिकोण के लिए कार्यान्वयन कोड नीचे दिया गया है:

 const int TICKS_PER_SECOND = 50; const int SKIP_TICKS = 1000 / TICKS_PER_SECOND; const int MAX_FRAMESKIP = 10; DWORD next_game_tick = GetTickCount(); int loops; bool game_is_running = true; while( game_is_running ) { loops = 0; while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) { update_game(); next_game_tick += SKIP_TICKS; loops++; } display_game(); }

खेल को प्रति सेकंड 50 बार की निश्चित आवृत्ति पर अद्यतन किया जाएगा, और प्रतिपादन उच्चतम संभव आवृत्ति पर किया जाएगा। ध्यान दें कि यदि राज्य को अपडेट करने की तुलना में रेंडरिंग अधिक बार किया जाएगा, तो कुछ आसन्न फ्रेम समान होंगे, इसलिए वास्तव में गेम स्टेट को अपडेट करने की आवृत्ति द्वारा अधिकतम एफपीएस मूल्य सीमित होगा। कमजोर हार्डवेयर पर, स्थिति अद्यतन चक्र MAX_FRAMESKIP तक पहुंचने तक FPS घट जाएगा। व्यवहार में, इसका मतलब है कि खेल वास्तव में केवल तभी धीमा होना शुरू होगा जब प्रतिपादन एफपीएस 5 से नीचे आ जाता है (= FRAMES_PER_SECOND / MAX_FRAMESKIP)।

कमजोर लोहा

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

शक्तिशाली लोहा

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

निष्कर्ष

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

चर एफपीएस से लगातार खेल की गति स्वतंत्र

कार्यान्वयन

क्या पिछले कार्यान्वयन में सुधार करना संभव है ताकि यह कमजोर हार्डवेयर पर तेजी से काम करे और शक्तिशाली हार्डवेयर पर नेत्रहीन अधिक आकर्षक हो? खैर, सौभाग्य से हमारे लिए, हाँ, यह संभव है! खेल की स्थिति को प्रति सेकंड 60 बार अपडेट करने की आवश्यकता नहीं है। उपयोगकर्ता इनपुट, AI, साथ ही खेल की स्थिति को अपडेट करने के लिए, यह प्रति सेकंड 25 बार अपडेट करने के लिए पर्याप्त है (मैं इस बात से सहमत नहीं हूं, हमेशा नहीं, लगभग। अनुवाद।)। तो चलिए update_game को कॉल करते हैं () प्रति सेकंड 25 बार, अधिक नहीं, कम नहीं। लेकिन जब तक लोहे को खींचता है, तब तक प्रतिपादन किया जाए। लेकिन धीमी गति से प्रतिपादन राज्य ताज़ा दर को प्रभावित नहीं करना चाहिए। इसे प्राप्त करने के लिए निम्नलिखित कोड में दिखाया गया है।

 const int TICKS_PER_SECOND = 25; const int SKIP_TICKS = 1000 / TICKS_PER_SECOND; const int MAX_FRAMESKIP = 5; DWORD next_game_tick = GetTickCount(); int loops; float interpolation; bool game_is_running = true; while( game_is_running ) { loops = 0; while( GetTickCount() > next_game_tick && loops < MAX_FRAMESKIP) { update_game(); next_game_tick += SKIP_TICKS; loops++; } interpolation = float( GetTickCount() + SKIP_TICKS - next_game_tick ) / float( SKIP_TICKS ); display_game( interpolation ); }

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

प्रक्षेप की आवश्यकता क्यों है

खेल स्थिति को प्रति सेकंड 25 बार अपडेट किया जाता है। इसलिए, यदि प्रक्षेप का उपयोग नहीं किया जाता है, तो फ़्रेम को अधिकतम आवृत्ति के साथ प्रदर्शित किया जाएगा। यहां यह ध्यान दिया जाना चाहिए कि 25 फ्रेम प्रति सेकंड उतना धीमा नहीं है जितना किसी को लग सकता है। उदाहरण के लिए, फिल्मों में, फ्रेम 24 फ्रेम प्रति सेकंड की आवृत्ति पर बदलते हैं। तो 25 फ्रेम प्रति सेकंड पर्याप्त लगता है, लेकिन तेज गति वाली वस्तुओं के लिए नहीं। ऐसी वस्तुओं के लिए, आपको एक चिकनी एनीमेशन प्राप्त करने के लिए राज्य की ताज़ा दर को बढ़ाना चाहिए। बढ़ी हुई ताज़ा दर का एक विकल्प ठीक प्रक्षेप और भविष्यवाणी का संयोजन है।
* नोट perev ।: एक भौतिक वस्तु के लिए NeoAxis के इंजन में ध्वज को निरंतर टकराव का पता लगाना संभव है; मुझे संदेह है कि यह सिर्फ प्रसंस्करण है जो ऊपर वर्णित खेल चक्र के कार्यान्वयन के समान किया जाता है।

प्रक्षेप और भविष्यवाणी

जैसा कि ऊपर लिखा गया था, राज्य अपनी स्वतंत्र आवृत्ति पर अपडेट किया गया है। इसलिए, एक स्थिति संभव है जब ड्राइंग लगातार दो टिक्स के बीच शुरू होती है। मान लीजिए कि आपने 10 बार राज्य को अपडेट किया है। फिर ड्राइंग को बुलाया जाता है और इसे 10 और 11 टिक्स के बीच कहीं निष्पादित किया जाता है। इसे 10.3 का असतत समय माना जाए। नतीजतन, "प्रक्षेप" का मान 0.3 होगा। एक उदाहरण के रूप में, निम्नानुसार चलती कार की कल्पना करें:
position = position + speed;
यदि स्टेट अपडेट चक्र के 10 वें चरण में स्थिति 500 है, तो गति 100 है, तो 11 वें चरण में स्थिति 600 होगी। इसलिए रेंडरिंग के दौरान मशीन की स्थिति क्या होगी? आप बस अंतिम चरण में स्थिति ले सकते हैं, अर्थात्। 500. लेकिन अगले चरण में स्थिति की भविष्यवाणी करना और समय 10.3 के लिए प्रक्षेपित करना बेहतर है। हमें फॉर्म का एक कोड मिलता है:
view_position = position + (speed * interpolation)
इस प्रकार, मशीन 530 की स्थिति में खींची जाएगी। चर "इंटरपोलेशन" में आम तौर पर वर्तमान और अगले फ्रेम के बीच 0 से 1 सापेक्ष स्थिति का मान होता है (बेहतर समझ के लिए फिर से तैयार, लगभग।)। चिकनी एनीमेशन सुनिश्चित करने के लिए भविष्यवाणी को बहुत जटिल बनाने की आवश्यकता नहीं है। बेशक, एक स्थिति संभव है जब टकराव का पता लगाने से पहले एक वस्तु दूसरे के साथ आंशिक रूप से अंतर करती है। लेकिन, जैसा कि हमने पहले देखा, खेल की स्थिति प्रति सेकंड 25 बार अपडेट की जाती है, इसलिए रेंडरिंग कलाकृतियां केवल एक विभाजित सेकंड के लिए दिखाई देंगी (और क्या होगा यदि वस्तुओं का घनत्व अधिक है और बहुत सारे टकराव हैं? - लगभग अनुवाद। और कम संभावना के साथ उपयोगकर्ता द्वारा इस पर ध्यान दिया जाएगा।

कमजोर लोहा

ज्यादातर मामलों में, update_game () display_game () की तुलना में बहुत तेज़ चलेगा। वास्तव में, हम यह मान सकते हैं कि कमजोर हार्डवेयर पर भी, अपडेट_ गेम () फ़ंक्शन को प्रति सेकंड 25 बार कहा जाता है। इसलिए, हमारा गेम उपयोगकर्ता इनपुट को संसाधित करेगा और किसी भी समस्या के बिना भी स्थिति को अपडेट करेगा जब रेंडर प्रति सेकंड 15 फ्रेम की आवृत्ति पर किया जाता है।

शक्तिशाली लोहा

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

निष्कर्ष

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

निष्कर्ष

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

अब अपने <% place_your_game_title_here%> कोड करने के लिए मार्च करें!

संबद्ध लेख (अनुवादक से)

habrahabr.ru/blogs/silverlight/125037 - SL में खेल चक्र
habrahabr.ru/blogs/gdev/112444 - एक उल्लेख है कि यूनिटी 3 डी में प्रति गेम लूप नहीं है (क्या यह स्पष्ट रूप से छिपा हुआ है?)
habrahabr.ru/blogs/gdev/102930 - एक गेम इंजन बनाने के बारे में
habrahabr.ru/blogs/android_development/136968 - नारियल पर खेल का एक उदाहरण
gafferongames.com/game-physics/fix-your-timestep - खेलों में असतत समय के बारे में एक और लेख

खेल चक्र या इलेक्ट्रोकार्डियोगामा

खेल चक्र

निरंतर खेल की गति के आधार पर एफपीएस

कार्यान्वयन

कमजोर लोहा

उत्पादक लोहा

निष्कर्ष

चर एफपीएस खेल की गति

कार्यान्वयन

कमजोर लोहा

शक्तिशाली लोहा

निष्कर्ष

लगातार खेल की गति और अधिकतम एफपीएस

कार्यान्वयन

कमजोर लोहा

शक्तिशाली लोहा

निष्कर्ष

चर एफपीएस से लगातार खेल की गति स्वतंत्र

कार्यान्वयन

प्रक्षेप की आवश्यकता क्यों है

प्रक्षेप और भविष्यवाणी

कमजोर लोहा

शक्तिशाली लोहा

निष्कर्ष

निष्कर्ष

संबद्ध लेख (अनुवादक से)

More articles: