बैश के लिए ओपनजीएल बाइंडिंग

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

तो अब मेरा स्वीकारोक्ति:DeLorean डैशबोर्ड में Perl ग्राफ़िक्स जिसका वर्णन मैंने My DeLorean रन Perl  में किया है बैश परियोजना के लिए मेरे ओपनजीएल के साथ एक इतिहास साझा करें। एक मजेदार और विडंबनापूर्ण मोड़ में, मैंने मूल रूप से फ्रोजन बबल को देखने के बाद 13 साल पहले प्रोजेक्ट शुरू किया था और मेरी तकनीकी संवेदनाओं से नाराज था कि किसी ने पर्ल में रीयल-टाइम वीडियो गेम लिखा था। उस समय, मेरी प्राथमिक भाषा सी ++ थी, और मैं वीडियो गेम उद्देश्यों के लिए ओपनजीएल का अध्ययन कर रहा था। मैंने अपने दोस्तों को घोषित किया कि केवल एक चीज बदतर होगी अगर यह 3 डी हो और बैश में लिखा हो। विचार को ज़ोर से कहने के बाद, यह मुझे उत्तेजित करता रहा, और अंततः मैंने इसे रीयल-टाइम ग्राफिक्स के लिए पर्ल का उपयोग करने की "भयानकता" को एक-एक करने का प्रयास करने का फैसला किया।

बैश का विस्तार

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

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

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

OpenGL तत्काल मोड

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

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

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

मैं ओपनजीएल एपीआई की उत्पत्ति के बारे में अधिकार के साथ बात नहीं कर सकता, लेकिन यह बहुत स्पष्ट लगता है कि यह स्ट्रीमिंग के विचार के आसपास बनाया गया है, शायद एक्स 11 डिस्प्ले प्रोटोकॉल के साथ संगत होने के लिए, बल्कि इसलिए भी कि यह एक अच्छा विचार है। इसलिए, अधिकांश ओपनजीएल फ़ंक्शंस का रिटर्न वैल्यू नहीं होता है, अन्य एपीआई के विपरीत जहां प्रत्येक फ़ंक्शन कॉल एक स्थिति देता है जो आपको ऑपरेशन का परिणाम बताता है। यदि आप एक OpenGL फ़ंक्शन की कल्पना करते हैं जैसे कि glVertex3f(1,2,3) एक प्रिंट स्टेटमेंट के रूप में जो एक पाइप पर तीन नंबर लिखता है, आपको एक बहुत अच्छा विचार मिला है कि यह पर्दे के पीछे कैसे काम करता है। वास्तव में, बैश बाइंडिंग के लिए, मैं सचमुच glVertex 1 2 3 . लिखता हूं पाइप के ऊपर जब glVertex 1 2 3 निष्पादित किया जाता है। बैश स्क्रिप्ट बिना किसी विचार के चलती है कि क्या इसके ग्राफिक्स कमांड कुछ भी इरादा के अनुसार कर रहे हैं।

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

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

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

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

प्रदर्शन सूचियां

सौभाग्य से, मूल ओपनजीएल एपीआई में कुछ कैशिंग तंत्र हैं, और उनका उपयोग करना आसान है। वे मोटे तौर पर इस क्रम में काम करते हैं:

"अरे ओपनजीएल, मैं चाहता हूं कि आप दूरस्थ छोर पर ऑब्जेक्ट 37 बनाएं"

"यहाँ वस्तु 37 का वर्णन करने वाला कुछ डेटा है"

"अगले रेंडरिंग चरणों में ऑब्जेक्ट 37 का उपयोग करें"

इसे और भी आसान बनाने के लिए, बैश बाइंडिंग आपको संख्याओं के बजाय नामों का उपयोग करने देती है।

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

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

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

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

मैंने इसे 12 साल पहले प्रकाशित क्यों नहीं किया?

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

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

मेरे पास इस परियोजना को बग फिक्स से अलग करने की कोई योजना नहीं है, लेकिन मुझे लगा कि यह कम से कम उन लोगों के लिए उपयोगी हो सकता है जो ओपनजीएल की अवधारणाओं को सीखना चाहते हैं या किसी के पास खाली समय है और एक कयामत लिखने की तीव्र इच्छा है M4 में क्लोन।

आनंद लेना! और इस लिंक को अग्रेषित करने में मज़ा लें, अन्यथा कोई भी आप पर विश्वास नहीं करेगा।