गेम को 60fps पर कैसे काम करें

समस्या की कल्पना करें: आपके पास एक खेल है, और आपको 60 हर्ट्ज मॉनिटर पर 60 एफपीएस पर काम करने की आवश्यकता है। आपका कंप्यूटर तेजी से रेंडर करने और अपडेट करने के लिए पर्याप्त समय ले रहा है, इसलिए आप vsync चालू करें और अपना गेम लूप लिखें:

while(running) { update(); render(); display(); } 

बहुत आसान है! अब खेल 60 एफपीएस पर काम करता है और सब कुछ घड़ी की कल की तरह चलता है। हो गया। इस पोस्ट को पढ़ने के लिए धन्यवाद।


खैर, जाहिर है, सब कुछ इतना अच्छा नहीं है। क्या होगा अगर किसी के पास एक कमजोर कंप्यूटर है जो 60fps प्रदान करने के लिए पर्याप्त गति से गेम को प्रस्तुत नहीं कर सकता है? क्या होगा अगर किसी ने उन शांत नए 144 हर्ट्ज मॉनिटर में से एक खरीदा? क्या होगा अगर वह ड्राइवर सेटिंग्स में vsync को बंद कर दे?

आप सोच सकते हैं: मुझे कहीं समय मापने और सही आवृत्ति के साथ अपडेट प्रदान करने की आवश्यकता है। यह काफी सरल है - बस प्रत्येक चक्र में समय जमा करें और हर बार अपडेट करें यह एक सेकंड के 1/60 से अधिक होता है।

 while(running) { deltaTime = CurrentTime()-OldTime; oldTime = CurrentTime(); accumulator += deltaTime; while(accumulator > 1.0/60.0){ update(); accumulator -= 1.0/60.0; } render(); display(); } 

हो गया, कहीं भी आसान नहीं है। वास्तव में, गेम का एक गुच्छा होता है जिसमें कोड अनिवार्य रूप से इस तरह दिखता है। लेकिन यह गलत है। यह समय को समायोजित करने के लिए उपयुक्त है, लेकिन झटके (हकलाना) और अन्य बेमेल चीजों के साथ समस्याओं की ओर जाता है। इस तरह की समस्या बहुत आम है: फ्रेम एक सेकंड के 1/60 पर प्रदर्शित नहीं होते हैं; यहां तक ​​कि जब vsync चालू होता है, तो उनके प्रदर्शित होने के समय में हमेशा थोड़ा शोर होता है (और OS टाइमर की सटीकता में)। इसलिए, ऐसी स्थितियाँ होंगी जब आप एक फ्रेम रेंडर करते हैं, और गेम का मानना ​​है कि फिर से अपडेट करने का समय अभी तक नहीं आया है (क्योंकि बैटरी एक छोटे से अंश को पीछे छोड़ रही है), इसलिए यह सिर्फ उसी फ्रेम को फिर से दोहराता है, लेकिन अब खेल फ्रेम के लिए देर हो चुकी है, इसलिए यह दोगुना हो जाता है। अद्यतन। यहाँ चिकोटी है!

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

---

फजी समय

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

इस तरह से यह अपडेट कोड अब 62 एफपीएस पर ("गेम" काम कर सकता है) दिखता है, लेकिन फिर भी हर बार कदम उठाता है जैसे कि यह 60fps पर है। मुझे समझ में नहीं आता है कि इसे सीमित क्यों किया जाए ताकि बैटरी का मान 0 से नीचे न जाए, लेकिन बिना यह कोड काम नहीं करता है)। आप इसे इस तरह से व्याख्या कर सकते हैं: "खेल को एक निश्चित कदम के साथ अद्यतन किया जाता है, यदि 60fps से 62fps के अंतराल में प्रदान किया जाता है":

 while(accumulator > 1.0/62.0){ update(); accumulator -= 1.0/60.0; if(accumulator < 0) accumulator = 0; } 

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

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

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

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

हाल ही में अपने टाइमर कोड के माध्यम से, मैंने कुछ अजीब देखा। बैटरी को विस्थापित किया गया था, प्रत्येक फ्रेम को 1/60 सेकंड से थोड़ा अधिक समय लगा, इसलिए समय-समय पर खेल को लगा कि फ्रेम के लिए देर हो चुकी है, और एक दोहरा अपडेट किया। यह पता चला कि मेरा मॉनिटर 59.94 हर्ट्ज की आवृत्ति के साथ काम करता है, न कि 60 हर्ट्ज का। इसका मतलब यह था कि प्रत्येक 1000 फ्रेम को उसे "पकड़ने" के लिए एक डबल अपडेट करना था। हालांकि, यह ठीक करने के लिए बहुत सरल है - बस अनुमेय फ्रेम आवृत्तियों के अंतराल को बदलें (60 से 62 तक नहीं, बल्कि 59 से 61 तक)।

 while(accumulator > 1.0/61.0){ update(); accumulator -= 1.0/59.0; if(accumulator < 0) accumulator = 0; } 

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

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

मॉनिटर सिम्युलेटर

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

मॉनिटर सिम्युलेटर दृश्य पर दिखाई देता है। यह "गंदा और तेज़" कोड है जिसे मैंने "मॉनिटर ऑपरेशन" का अनुकरण करते हुए लिखा था, और अनिवार्य रूप से मुझे संख्याओं का एक गुच्छा दिखा रहा था जो प्रत्येक परीक्षण किए गए टाइमर की स्थिरता का विचार देता है।

उदाहरण के लिए, सरलतम टाइमर के लिए, लेख की शुरुआत से निम्नलिखित मान प्रदर्शित होते हैं:

20211012021011202111020211102012012102012[...]
TOTAL UPDATES: 10001
TOTAL VSYNCS: 10002
TOTAL DOUBLE UPDATES: 2535
TOTAL SKIPPED RENDERS: 0
GAME TIME: 166.683
SYSTEM TIME: 166.7

सबसे पहले, प्रत्येक के लिए कोड प्रदर्शित होता है vsync पिछले vsync के बाद खेल चक्र के लिए "अपडेट" की संख्या की संख्या। ठोस 1 के अलावा कोई भी मान एक चिकोटी तस्वीर की ओर ले जाता है। अंत में, कोड संचित आँकड़ों को प्रदर्शित करता है।

59.94-हर्ट्ज मॉनिटर पर "फजी टाइमर" (60–62fps के अंतराल के साथ) का उपयोग करते समय, कोड निम्नलिखित प्रदर्शित करता है:

111111111111111111111111111111111111111111111[...]
TOTAL UPDATES: 10000
TOTAL VSYNCS: 9991
TOTAL DOUBLE UPDATES: 10
TOTAL SKIPPED RENDERS: 0
GAME TIME: 166.667
SYSTEM TIME: 166.683

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

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

GAME TIME: 166.667
SYSTEM TIME: 169.102

इसीलिए जब vsync को अक्षम किया जाता है, तो आपको एक सख्त टाइमर पर स्विच करने की आवश्यकता होती है, अन्यथा ये विसंगतियां समय के साथ जमा हो जाती हैं।

अगर मैं रेंडरिंग टाइम को .02 पर सेट करता हूं (यानी, "एक फ्रेम से अधिक" रेंडरिंग के लिए आवश्यक है), तो मुझे एक चिकोटी मिल जाएगी। आदर्श रूप से, खेल का पैटर्न 202020202020 जैसा दिखना चाहिए, लेकिन यह थोड़ा असमान है।

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

 while(accumulator >= 1.0/61.0){ simulate_update(); accumulator -= 1.0/60.0; if(accumulator < 1.0/59.0–1.0/60.0) accumulator = 0; } 

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

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

अलग प्रतिपादन

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

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

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

 while(running){ computeDeltaTimeSomehow(); accumulator += deltaTime; while(accumulator >= 1.0/60.0){ previous_state = current_state; current_state = update(); accumulator -= 1.0/60.0; } render_interpolated_somehow(previous_state, current_state, accumulator/(1.0/60.0)); display(); } 

तो, प्राथमिक। समस्या हल हो गई है।

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

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

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

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

अपने इंजन में, मैं सिर्फ एक विकल्प देता हूं। यदि आपके पास 60 हर्ट्ज मॉनिटर और एक तेज़ कंप्यूटर है, तो vsync सक्षम के साथ लॉकस्टेप का उपयोग करना सबसे अच्छा है। यदि मॉनिटर में एक गैर-मानक ताज़ा दर है, या आपका कमजोर कंप्यूटर लगातार 60 फ्रेम प्रति सेकंड रेंडर नहीं कर सकता है, तो फ़्रेम इंटरपोल को सक्षम करें। मैं इस विकल्प को "अनलॉक फ़्रैमरेट" कहना चाहता हूं, लेकिन लोग सोच सकते हैं कि इसका सीधा सा अर्थ है "यदि आपके पास अच्छा कंप्यूटर है तो इस विकल्प को सक्षम करें।" हालाँकि, इस समस्या को बाद में हल किया जा सकता है।

दरअसल, इस समस्या के आसपास एक विधि है।

चर समय कदम अद्यतन

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

 while(running) { deltaTime = CurrentTime()-OldTime; oldTime = CurrentTime(); update(deltaTime); render(); display(); } 

समय के साथ कोई विषमता नहीं। कोई अजीब प्रक्षेप प्रतिपादन। सब कुछ सरल है, सब कुछ काम करता है।

तो, प्राथमिक। समस्या हल हो गई है। और अब हमेशा के लिए! बेहतर परिणाम हासिल करना असंभव है!

अब खेल तर्क को अनियंत्रित समय के साथ काम करना सरल है। यह सरल है, बस इस कोड को प्रतिस्थापित करें:

 position += speed; 

इस पर:

 position += speed * deltaTime; 

और निम्नलिखित कोड बदलें:

 speed += acceleration; position += speed; 

इस पर:

 speed += acceleration * deltaTime; position += speed * deltaTime; 

और निम्नलिखित कोड बदलें:

 speed += acceleration; speed *= friction; position += speed; 

इस पर:

 Vec3D p0 = position; Vec3D v0 = velocity; Vec3D a = acceleration*(1.0/60.0); double f = friction; double n = dt*60; double fN = pow(friction, n); position = p0 + ((f*(a*(f*fN-f*(n+1)+n)+(f-1)*v0*(fN-1)))/((f-1)*(f-1)))*(1.0/60.0); velocity = v0*fN+a*(f*(fN-1)/(f-1)); 

... तो रुको

यह सब कहां से आया?

अंतिम भाग को सचमुच मेरे इंजन के सहायक कोड से कॉपी किया गया है, जो "घर्षण-सीमित गति के साथ वास्तव में सही, फ्रेम दर-स्वतंत्र गति" करता है। इसमें थोड़ा सा कचरा (इन गुणा और भाग 60) है। लेकिन यह पिछले टुकड़े के लिए एक चर समय कदम के साथ कोड का "सही" संस्करण है। मैंने वुल्फराम अल्फा के साथ एक घंटे से अधिक समय तक इसका पता लगाया।

अब वे मुझसे पूछ सकते हैं कि ऐसा क्यों नहीं करते:

 speed += acceleration * deltaTime; speed *= pow(friction, deltaTime); position += speed * deltaTime; 

और यद्यपि यह काम करने लगता है, वास्तव में ऐसा करना गलत है। आप इसे स्वयं देख सकते हैं। DeltaTime = 1 के साथ दो अपडेट करें, और फिर एक अपडेट deltaTime = 2 के साथ करें, और परिणाम अलग-अलग होंगे। आमतौर पर हम खेल के लिए संगीत कार्यक्रम में काम करते हैं, इसलिए ऐसी विसंगतियों का स्वागत नहीं है। यह शायद एक अच्छा पर्याप्त समाधान है, यदि आप यह सुनिश्चित करने के लिए जानते हैं कि डेल्टा हमेशा लगभग एक मूल्य के बराबर होता है, लेकिन फिर आपको यह सुनिश्चित करने के लिए कोड लिखना होगा कि कुछ निरंतर आवृत्ति पर अपडेट किए जाते हैं और ... हाँ। यह सही है, अब हम सब कुछ करने की कोशिश कर रहे हैं "सही मायने में।"

यदि इस तरह का एक छोटा सा टुकड़ा राक्षसी गणितीय गणनाओं में सामने आता है, तो अधिक जटिल गति पैटर्न की कल्पना करें जिसमें कई अंतःक्रियात्मक वस्तुएं भाग लेती हैं, और जैसे। अब आप स्पष्ट रूप से देख सकते हैं कि "सही" समाधान अवास्तविक है। अधिकतम जो हम प्राप्त कर सकते हैं वह एक "मोटा अनुमान" है। आइए अब इसके बारे में भूल जाएं, और मान लें कि हमारे पास वास्तव में गति कार्यों का एक "वास्तव में सही" संस्करण है। महान, सही?

नहीं, वास्तव में। यहाँ समस्या का एक वास्तविक जीवन उदाहरण है जो मैंने बॉम्बरबॉट्स में इसके साथ किया था। एक खिलाड़ी लगभग 1 टाइल उछाल सकता है, और खेल 1 टाइल में ब्लॉकों की ग्रिड में होता है। एक ब्लॉक पर उतरने के लिए, चरित्र के पैर ब्लॉक की ऊपरी सतह से ऊपर उठने चाहिए।


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


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

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

---

निष्कर्ष

अब आप जानते हैं कि गेम को 60fps की निरंतर आवृत्ति पर कैसे काम करना है। यह मामूली रूप से सरल है, और किसी और को इसके साथ कोई समस्या नहीं होनी चाहिए। इस कार्य को जटिल बनाने वाली कोई अन्य समस्याएँ नहीं हैं।