क्या सभी खेल प्रत्येक फ्रेम को खींचकर बनाए गए हैं?


60

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

मेरा सवाल यह है कि क्या यह तरीका एकमात्र ऐसा है जिसका उपयोग एनिमेशन और गेम बनाने के लिए किया जाता है। ऐसा लगता है कि यह थोड़ा अक्षम है। मैं यह भी नहीं समझता कि यह तरीका 3 डी गेम के लिए कैसे काम करेगा । क्या कोई इसे और अधिक विस्तार से बता सकता है?


टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
जोश

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

जवाबों:


68

बहुत पुराने खेलों में एक तकनीक का उपयोग किया जाता है जहाँ केवल एक फ्रेम के उन हिस्सों को फिर से तैयार किया जाता है जो उस फ्रेम पर बदल जाते हैं। मुझे याद है, खेल "लिटिल बिग एडवेंचर" इस ​​तकनीक (1994) का उपयोग करता है। लेकिन आप देख सकते हैं कि गेम में अधिकांश समय एक स्थिर कैमरा है। केवल जब आप दृश्य क्षेत्र से बाहर निकलते हैं तो दृश्य फिर से प्रकट होता है। यदि आप खेल खेलते हैं तो आप उस फ्रेम में एक छोटे अंतराल को भी नोटिस करेंगे। आधुनिक गेम इंजन के साथ आधुनिक GPU पर, चीजें बदल गई हैं। प्रत्येक फ्रेम पर सब कुछ फिर से तैयार किया गया है। रेंडरिंग तकनीक के आधार पर, चीजों को कई बार प्रस्तुत किया जा सकता है। जब आप इसे सही ढंग से उपयोग करते हैं तो GPU की कंप्यूटिंग शक्ति अविश्वसनीय रूप से उच्च होती है। लेकिन पुन: उपयोग हो रहा है। उदाहरण के लिए एक इंजन केवल हर 5 वें फ्रेम में छाया मानचित्र को अद्यतन करने का निर्णय ले सकता है। या जब तक प्रकाश स्रोतों में कोई परिवर्तन नहीं होता तब तक प्रकाश व्यवस्था अपडेट नहीं की जाती है।


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

12
बहुत पुराना .. १ ९९ ४ ... अब मैं बूढ़ा महसूस कर रहा हूँ ...
अलसेदर

4
गेमिंग के मामले में @alseether पुराना है। याद रखें कि हम केवल 20 ~ 30yrs में 8-बिट पिक्सेल ब्लब्स से फोटो-रियलिज्म (यदि पूर्व में लाइव एक्शन नहीं हैं तो फोटो-रियलिज्म) में चले गए।
जेरेड स्मिथ

16

नहीं।

कम से कम यदि आप 70 के दशक के पुराने खेलों को शामिल करते हैं जो वेक्टर डिस्प्ले का उपयोग करते हैं।

उदाहरण के लिए, व्यापक रूप से ज्ञात गेम क्षुद्रग्रह, जो मूल रूप से वेक्टर डिस्प्ले के लिए विकसित किया गया था, जो स्क्रीन पर ग्राफिक्स रेंडर करने का एक मौलिक अलग तरीका है।

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

https://en.wikipedia.org/wiki/Vector_monitor

आधुनिक दिन के ग्राफिक्स रेखापुंज के लिए बहुत अधिक 100% बने हैं, जो परिभाषा के अनुसार हर फ्रेम को प्रदर्शित करने के लिए ग्राफिक्स बफर की सामग्री लिखते हैं।


7
वेक्टर डिस्प्ले में स्पष्ट रूप से "फ्रेम" भी नहीं होता है।
हॉब्स

2
@hobbs सही है, जो "एक फ्रेम ड्राइंग द्वारा सभी खेल बना रहे हैं" के जवाब के बाद से मेरा जवाब अभी भी सही है? "नहीं, फ्रेम के आधार पर सभी खेल भी नहीं होते हैं।"
सैंडी चैपमैन

1
हालाँकि, एक गहन अर्थ में, प्रश्न सभी दृश्य वस्तुओं को बार-बार खींचने के बारे में था, न कि केवल उन वस्तुओं को ले जाने के लिए, और अधिकांश वेक्टर प्रदर्शित करता है कि उत्तर अभी भी "हाँ" है (छवि भंडारण ट्यूब एक अपवाद होगा)
szulat

@szulat एक तरह से सच है, लेकिन निष्पक्ष होने के लिए, यह अभी भी अंतराल में नहीं दिखता है जहां प्रदर्शन काला है। यह केवल स्क्रीन पर दृश्यमान वस्तुओं को ताज़ा करता है। यानी क्षुद्रग्रहों में, यह केवल जहाज और शेष क्षुद्रग्रहों को स्क्रीन पर फिर से दिखाता है।
सैंडी चैपमैन

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

11

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

... यह तरीका 3 डी गेम के लिए कैसे काम करेगा ...

3 डी अंतरिक्ष में तत्व लगातार बने रहते हैं, ग्राफिक्स इंजन फिर से आपकी स्क्रीन पर छवि को किसी भी बदलाव के लिए फिर से जोड़ देगा (कैमरा आंदोलन आदि)।

[१] ... उदाहरण के लिए अगर आप अपना खुद का इंजन [२] लिखते हैं जैसे कि ओपनगेल जैसी कोई चीज। उस मामले में भी आप फ्रेम के बीच लगातार चीजों को स्टोर करेंगे।

[२] जो आपके वर्तमान कौशल स्तर पर कोई विकल्प नहीं है।


क्या आपके पास "अपनी मशीन पर ग्राफिक्स प्रोसेसर वास्तव में जमीन से प्रत्येक फ्रेम की गणना करेगा" का समर्थन करने के लिए संदर्भ हैं?
Kromster

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

@ यह जिस तरह से थोपा गया है, उससे कई पड़ोसी जवाबों में कई बिंदुओं का खंडन करते हैं।
क्रॉमास्टर

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

मुझे भी यकीन नहीं है कि "स्क्रीन को साफ़ करना होगा" के लिए एक संदर्भ क्या होगा, लेकिन एक संदर्भ यह है कि डूम में एक फ्रेम कैसे प्रस्तुत किया जाता है: adriancourreges.com/blog/2016/09/09/doom-2016- ग्राफिक्स-अध्ययन ; मत भूलो कि मध्यम उच्च अंत ग्राफिक्स कार्ड प्रति सेकंड एक खरब गणना, कई हजार प्रति पिक्सेल का प्रबंधन करने में सक्षम होना चाहिए।
pjc50

2

संक्षिप्त उत्तर: नहीं।

लम्बी कहानी:

जब मैंने स्कूल में कुछ गेम प्रोग्रामिंग सीखी, तो हमें निम्न कार्य करना सिखाया गया:

तय करें कि हम गेम में एफपीएस दर क्या चाहते हैं (उदाहरण के लिए 30)।

कुछ कोड लिखें जो प्रत्येक अंतराल के लिए एक काउंटर को जोड़ता है (30 एफपीएस के लिए 33 मिसे)। यह कोड गेम लूप के साथ समवर्ती रूप से चलता है।

फिर गेम लूप जो गेम के लिए गणना करता है (गेम स्टेट अपडेट) प्रत्येक फ्रेम के लिए एक ही काउंटर को 1 से कम कर देगा। लेकिन ग्राफिक्स की गणना और स्क्रीन पर ड्राइंग केवल तभी किया जाएगा जब काउंटर शून्य पर हो।

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

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

अधिकांश समय, गेम आपको अपेक्षित दर पर अपडेट करता रहेगा, लेकिन "लैगी" दिखाई देगा क्योंकि आप स्क्रीन पर प्रत्येक अपडेट नहीं देखेंगे। यह पूरे खेल को धीमा करने के लिए बेहतर हो सकता है क्योंकि आप इसे स्क्रीन पर प्रत्येक अपडेट को आकर्षित करने के लिए मजबूर करते हैं।

यह सब C ++ और कोई गेम इंजन, और न ही ग्राफिक्स कार्ड के साथ किया गया था। सब कुछ एक ही कोर सीपीयू पर चला गया। हमने 2d ग्राफिक्स के लिए कुछ पुस्तकालयों का उपयोग किया है।


1
मुझे खेल "गोल्डन एक्स" याद है। जब 8086 पर खेला गया गेमप्ले धीमी था और उदाहरण के लिए 286 पर खेले जाने वाले मैच की तुलना में बहुत आसान था जहां चीजें तेजी से बढ़ीं। सिर्फ आपकी जानकारी के लिए।
akostadinov

0

इससे पहले कि कोई कह सकता है कि क्या वीडियो गेम हर फ्रेम को "ड्रॉ" करता है, पहले यह निर्धारित करना आवश्यक है कि "ड्रा" का मतलब क्या है। निश्चित रूप से कई वीडियो गेम हैं निश्चित रूप से खरोंच से बिटमैप को इकट्ठा करके सभी हर फ्रेम को नहीं खींचते हैं; वास्तव में, कई गेमिंग प्लेटफ़ॉर्म कभी भी पूर्ण बिटमैप को इकट्ठा नहीं करते हैं

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

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

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


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

1
@doppelgreener: प्रत्येक फ्रेम "ड्राइंग" की धारणा थोड़ा अस्पष्ट है। प्रत्येक फ्रेम को उत्पन्न करने के लिए कुछ न कुछ आवश्यक होता है, लेकिन कई तरीके हैं जो सीपीयू और हार्डवेयर द्वारा विभाजित किए जा सकते हैं। कुछ तरीकों की आवश्यकता होती है कि सीपीयू स्क्रीन के कुछ हिस्सों के साथ भी हर फ्रेम पर शामिल हो जो एक फ्रेम और अगले के बीच एक ही दिखाई देते हैं, जबकि अन्य नहीं। हालांकि किसी भी LCD या CRT गेम के लिए अंततः यह आवश्यक होगा कि प्रत्येक गैर-रिक्त फ्रेम में कुछ आउटपुट [E-paper या फ्लिप-डॉट डिस्प्ले का उपयोग करने वाले खेल] नहीं हो सकते हैं, आवश्यक क्रियाओं को "ड्राइंग" माना जा सकता है या नहीं।
सुपरकैट

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

-11

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


9
यह पूछे गए सवाल के खिलाफ भी कोई मतलब नहीं है .. मुझे लगता है कि आपने कुछ और के लिए "फ्रेम" को भ्रमित किया है ... क्या आप संभवतः एक कहानी बोर्ड के तत्वों के साथ भ्रमित हो रहे हैं? ओपी विशेष रूप से प्रतिपादन
ट्रॉट्सकी 94
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.