2010-07-11 14 views
16

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

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

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

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

मध्यम जमीन कहां है? मैं ओपनजीएल का उपयोग करना सीखूंगा जबकि एक ही समय में उचित यूनिट परीक्षण कर रहा हूं?

उत्तर

7

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

Here's a great article टीडीडी, गेम्स और ओपनजीएल के बारे में।

2

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

0

What is the best way to debug OpenGL? पर एक नज़र डालें; इस प्रश्न के उत्तर में उल्लिखित टूल कुछ प्रकार के परीक्षण संभव बना देंगे, खासकर GLIntercept (एक ओपनजीएल फ़ंक्शन कॉल इंटरसेप्टर) आगे की जांच के लिए एक बहुत ही रोचक विकल्प/प्रारंभिक बिंदु की तरह लगता है।

3

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

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

उदाहरण के लिए, मैं एक ओपन कॉल लपेटो जाएगा,

नहीं, यह इसके लायक नहीं है।

या कार्यों को पूरा करने के आधार पर उन्हें उच्च स्तरीय कार्यों में समूहित करें?

यह भावना "बनावट" के निर्माण के लिए कुछ कॉल/वर्गों लिखने के लिए बनाता है, "जाल", "शेडर कार्यक्रम", वर्दी स्थान प्राप्त करने के लिए स्वत: जिस तरह से किसी तरह का हैं (अगर आप shaders का उपयोग करें), हो सकता है ओपनजीएल संसाधनों (यानी glDelete *** के साथ या glIsTexture जैसे कार्यों के साथ) के स्वचालित रिलीज के लिए कुछ कक्षाएं, लेकिन यह सब कुछ है। आम तौर पर, आपको अतिरिक्त अवशोषण/कक्षाएं नहीं पेश करनी चाहिए, जब तक कि उनकी आवश्यकता न हो - क्योंकि यह बिना किसी लाभ के अतिरिक्त काम होगा।

3

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

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

1

लोगों का एक बहुत सोचने के लिए ग्राफिक्स पारंपरिक TDD/unittesting से अभेद्य होते हैं लगते हैं। यह सच नहीं है।

टीडीडी के आस-पास के मुद्दे ये हैं कि छवियां हमेशा बिल्कुल समान नहीं होंगी। एंटीअलाइजिंग सेटिंग्स जैसी चीजें (जिन्हें ड्राइवर सेटिंग्स द्वारा ओवरराइड किया जा सकता है)। अलग-अलग GPUs एक ही छवि को प्रस्तुत करने के बीच अंतर (बहुभुज अवांछित आदेश और ऐसे)। साथ ही जैसे आपका गेम विकास की चीजों के माध्यम से जाता है जैसे मैश और बनावट बदल सकते हैं या tweaked हो सकता है।

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

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

मैं क्या कर अपने विंडोइंग प्रणाली से अपने प्रतिपादन उत्पादन decoupling है की सिफारिश करेंगे। इसका मतलब है कि 'बनावट के लिए प्रस्तुत करें' या फ्रेमबफर ऑब्जेक्ट्स का उपयोग करें। यह व्यूपोर्ट्स और यूआई/एचयूडी ओवरले जैसी चीजों को करने में भी मदद करता है।

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

यह मॉड्यूलर दृष्टिकोण टीडीडी से बाहर निकलने वाली चीज है, यह आपके रेंडरर को अपने स्वयं के प्रस्तुतकर्ताओं को भी दे सकता है (शायद आप एक स्काईबॉक्स अलग से करना चाहते हैं, या किसी गेम में सुरक्षा मॉनीटर पर एक तस्वीर, प्रतिबिंब, छायाचित्र और इतने पर)। आप देशी डेस्कटॉप पर एक अलग रिज़ॉल्यूशन पर आसानी से प्रस्तुत कर सकते हैं (जो टीडीडी में एक निश्चित रिज़ॉल्यूशन सेट करने के लिए उपयोगी है और सरल संचालन के लिए 32x32 की तरह कुछ हो सकता है, लेकिन एंड्रॉइड जैसे उपकरणों के लिए भी उपयोगी है जहां संकल्प तय किए गए हैं और जीपीयू की अलग-अलग क्षमताएं हैं। नेक्सस 10 अपने एक्सडीपीआई में अपना गेम प्रस्तुत करने के लिए पर्याप्त नहीं है? इसे स्केल करें। लिनक्स/एक्सओआर के साथ भी मदद करता है जो हमेशा आपको GPU के सभी संकल्पों को सेट करने की अनुमति नहीं देता है, हालांकि अब कुछ समस्याएं कम हैं)।

एक बार जब आपका एफबीओ हो, तो कुछ फ़ंक्शंस पिक्सेल रंग क्वेरी करने के लिए करें। फिर आप अपने सभी बुनियादी परिचालनों से पूछ सकते हैं। क्या आपके मेष सही ढंग से प्रस्तुत करते हैं? झसे आज़माओ। एक सफेद त्रिकोण के साथ एक जाल बनाओ और पूछें कि आप किस स्थिति में सफेद दिखने की उम्मीद करेंगे और उस त्रिकोण को चित्रित करते समय काला रहना चाहिए। 1x1 विंडो में 1x1 त्रिकोण को% 50 को तिरछे रूप से कवर करना चाहिए ताकि परीक्षण पिक्सेल किनारे और बीच के दोनों किनारों, खिड़की की सीमाओं और पॉइंट बिट्स के पास हो। अगला combine two triangles into a rectangle और इसे स्क्रीन भरना चाहिए, अब सभी पिक्सेल सफेद होना चाहिए। अब इसे कैमरे से दूर ले जाने का प्रयास करें और जांचें कि सीमाएं काले हैं लेकिन केंद्र सफेद है, 1.0x1.0 आयत 1.0x1.0 विंडो में 1.0x पर एक साथ है, आप सीमाओं के बारे में देखने के लिए कुछ सरल ज्यामिति लागू कर सकते हैं खत्म होना चाहिए Test with a different color। एक बहुआयामी घन और परीक्षण रोटेशन के साथ एक और जटिल जाल बनाओ। एक परीक्षण सामान्य नक्शा बनाओ।

आप एक क्षेत्र को प्रतिपादित करके रोशनी का परीक्षण करने में सक्षम हो सकते हैं और बाईं तरफ दाएं तरफ से चमकदार जांच कर सकते हैं और यदि आप दूसरी तरफ एक और प्रकाश जोड़ते हैं तो वे समान हैं (बस सभी पिक्सेल जोड़ें बाएं और दाईं ओर सभी पिक्सल और त्रुटि के मार्जिन के भीतर तुलना करें)। प्रकाश चमक बढ़ाएं और देखें कि पिक्सल की मात्रा बढ़ जाती है या नहीं। आप एक फ्लैट विमान पर एक विशिष्ट बिंदु पर अपेक्षित रंग को काम करके प्रकाश एल्गोरिदम का परीक्षण कर सकते हैं। आप देख सकते हैं कि स्पेक्ट्रल हाइलाइटिंग अपेक्षित क्षेत्र में सबसे तेज है। आपके सामान्य/बंप मैपिंग make a test texture के लिए।

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

संबंधित मुद्दे