Perl 5 के डिज़ाइन और "ग्लू लैंग्वेज" के रूप में इसकी उपयुक्तता का वर्णन करने वाले मेरे पिछले लेख में, मैंने उल्लेख किया था कि मैंने पहले Bash के लिए OpenGL बाइंडिंग्स लिखी थीं। यह शायद बिना किसी सबूत के कहने के लिए बहुत अविश्वसनीय बयान था, इसलिए मैं अपनी हार्ड ड्राइव के धूल भरे कोनों में वापस गया, इसे खोदा, इसे थोड़ा ताज़ा किया, फ़ॉन्ट सपोर्ट में सुधार किया, डॉक्यूमेंटेशन लिखा, और इसे अपनी साइट और GitHub पर प्रकाशित किया। (इसे पहली बार अनुभव करने के लिए आपको Bash और OpenGL सपोर्ट दोनों वाले सिस्टम की आवश्यकता होगी, लेकिन यहाँ एक वीडियो है।)
तो अब मेरा स्वीकारोक्ति: My DeLorean runs Perl में वर्णित DeLorean डैशबोर्ड में Perl ग्राफिक्स मेरे OpenGL for Bash प्रोजेक्ट के साथ एक इतिहास साझा करते हैं। एक मजेदार और विडंबनापूर्ण मोड़ में, मैंने मूल रूप से 13 साल पहले इस प्रोजेक्ट को Frozen Bubble को देखने और अपनी तकनीकी संवेदनाओं को आहत होने के बाद शुरू किया था कि किसी ने Perl में एक रियल-टाइम वीडियो गेम लिखा था। उस समय, मेरी प्राथमिक भाषा C++ थी, और मैं वीडियो गेम उद्देश्यों के लिए OpenGL का अध्ययन कर रहा था। मैंने अपने दोस्तों को घोषित किया कि केवल एक चीज जो बदतर होगी वह होगी यदि यह 3D होती और Bash में लिखी गई होती। इस विचार को जोर से कहने के बाद, यह मुझे कुरेदता रहा, और मैंने अंततः इसे "अवेसनेस" में Perl का उपयोग करके रियल-टाइम ग्राफिक्स के "भयानकता" को एक-अप करने के लिए एक कोशिश देने का फैसला किया।
Bash का विस्तार
Bash में OpenGL सपोर्ट जोड़ने का सबसे सीधा तरीका सोर्स कोड को बदलना और प्रत्येक OpenGL फंक्शन को शेल "बिल्टइन" के रूप में जोड़ना होगा; हालांकि, केवल वही लोग इसका अनुभव कर पाएंगे जो Bash का एक कस्टम संस्करण इंस्टॉल करने के इच्छुक हैं, और शायद कोई भी ऐसा नहीं करना चाहेगा। यह "Bash तरीके" से चीजें करने की भावना में भी नहीं लग रहा था।
फिर मैं एक क्लाइंट-सर्वर के विचार के साथ आया, जहां प्रत्येक OpenGL फंक्शन को पथ में इंस्टॉल किया जाएगा और एक क्लाइंट को आमंत्रित करेगा जो एक OpenGL सर्वर से जुड़कर उस फंक्शन को निष्पादित करने के लिए एक संदेश डिलीवर करेगा। यह एक आनंददायक रूप से "भयानक" समाधान होता, लेकिन चाहे मैंने चीजों को कितना भी अनुकूलित किया, यह अभी भी मेरे लिए समग्र लक्ष्य में सफल होने का दावा करने के लिए बहुत धीमा था।
अंत में, मैं एक डिज़ाइन पर बस गया जहां मेरे पास एक "OpenGL इंटरप्रेटर" प्रक्रिया होगी जो standard-in पर OpenGL कमांड्स पढ़ेगी और किसी भी उपयोगकर्ता इनपुट इवेंट्स को standard-out पर लिखेगी। फिर एक Bash स्क्रिप्ट इस इंटरप्रेटर को पाइप्स से जुड़ा शुरू कर सकती है, और प्रत्येक OpenGL कमांड एक Bash फंक्शन हो सकता है जो पाइप पर लिखता है। जब मैं इस पर था, मैंने अपनी दक्षता ट्रिक्स का पूरा बैग डालने का फैसला किया और कुछ स्टैटिकली कंपाइल्ड हैश टेबल्स और रेड-ब्लैक ट्रीज़ के साथ सादे C में इंटरप्रेटर लिखना।
OpenGL इमीडिएट मोड
OpenGL विवरण वही हैं जहां यह प्रोजेक्ट DeLorean डैशबोर्ड प्रोजेक्ट के साथ प्रतिच्छेद करना शुरू करता है। पहले, मैं एक कदम पीछे हटूंगा और OpenGL API का पुनर्कथन करूंगा।
OpenGL एक ऐसा प्रोग्राम लिखने के बारे में है जो 3D निर्देशांकों और टेक्सचर्स के संदर्भ में अपने ग्राफिक्स की योजना बनाता है, फिर उस डेटा को ग्राफिक्स कार्ड पर शिप करता है ताकि इसे 2D स्क्रीन पर रेंडर किया जा सके। वास्तव में सरल होने के लिए, स्क्रीन के उस क्षेत्र का वर्णन करने के लिए गणित का एक सेट है जिसे पेंट किया जा रहा है, और उस क्षेत्र में प्रत्येक पिक्सेल के रंग का वर्णन करने के लिए गणित का एक सेट है।
सबसे आम ऑपरेशन एक वर्चुअल 3D स्पेस में एक त्रिकोण के तीन कोनों का वर्णन करना है, OpenGL को यह पता लगाने दें कि वह 2D स्क्रीन पर कहां लैंड करता है, फिर इसे उस क्षेत्र में एक 2D छवि खींचने के लिए कहें, शायद किसी अन्य छवि के साथ संयुक्त या कुछ ब्राइटनेस गणनाओं द्वारा परिवर्तित। प्रोग्राम का मुख्य लूप बफर को पोंछकर, हर पॉलीगॉन को प्लॉट करके जो देखा जा सकता है, और इसे स्क्रीन पर भेजकर वीडियो का एक फ्रेम उत्पन्न करता है। यदि आप इस पूरे स्टंट को 16 मिलीसेकंड या उससे कम में पूरा करते हैं, तो आप 60 फ्रेम प्रति सेकंड बनाए रख सकते हैं और अच्छे फ्लूइड ग्राफिक्स प्राप्त कर सकते हैं।
मैं OpenGL API की उत्पत्ति के बारे में अधिकार के साथ नहीं बोल सकता, लेकिन यह काफी स्पष्ट लगता है कि यह स्ट्रीमिंग के विचार के आसपास बनाया गया है, शायद X11 डिस्प्ले प्रोटोकॉल के साथ संगत होने के लिए, लेकिन यह भी सिर्फ इसलिए क्योंकि यह एक अच्छा विचार है। तो, अधिकांश OpenGL फंक्शन्स का रिटर्न मान नहीं होता है, अन्य APIs के विपरीत जहां प्रत्येक फंक्शन कॉल एक स्टेटस लौटाता है जो आपको ऑपरेशन के परिणाम के बारे में बताता है। यदि आप OpenGL फंक्शन जैसे glVertex3f(1,2,3) को एक प्रिंट स्टेटमेंट के रूप में कल्पना करते हैं जो तीन नंबरों को एक पाइप पर लिखता है, तो आपको इस बात का काफी अच्छा अंदाजा है कि यह पर्दे के पीछे कैसे काम करता है। वास्तव में, Bash बाइंडिंग्स के लिए, मैं सचमुच glVertex 1 2 3 को पाइप पर लिखता हूं जब glVertex 1 2 3 निष्पादित होता है। Bash स्क्रिप्ट अंधे चलती है, बिना किसी अंदाजे के कि इसके ग्राफिक्स कमांड्स इरादे के मुताबिक कुछ कर रहे हैं या नहीं।
वर्षों में OpenGL API के कई बड़े रिवीजन हुए हैं, और लोग अपनी किताबों में "रिटेन्ड" बनाम "इमीडिएट" मोड्स के बारे में पूरे अध्याय लिखते हैं, लेकिन यह सब दो अवधारणाओं पर उबलता है:
- प्रत्येक फ्रेम में वह सारा डेटा पाइप पर पुनः भेजना धीमा है, इसलिए आइए उनमें से कुछ को दूसरे छोर पर कैश करें।
- हम बिल्ट-इन गणित से हर किसी की जरूरतों को कभी पूरा नहीं कर सकते, इसलिए आइए लोगों को अपने स्वयं के कस्टम गणित का वर्णन करने के लिए एक भाषा दें।
कहा जा रहा है, जबकि नए OpenGL APIs द्वारा पेश किया गया कैशिंग और कस्टम गणित बहुत अधिक कुशल हैं और निश्चित रूप से टॉप-टियर वीडियो गेम्स के लिए आवश्यक हैं, वे सेट अप और काम करने (और सीखने) के लिए भी अधिक प्रयास लेते हैं और शायद शौकीनों के लिए अधिक नुकसान than good करते हैं। वे उन्नत ग्राफिक्स इफेक्ट्स या हाई-डिटेल मॉडल्स नहीं कर रहे हैं तो अनावश्यक भी हैं।
तो, यद्यपि Bash OpenGL बाइंडिंग्स केवल "डिप्रेकेटेड" API से निपटते हैं, मैं अभी भी लोगों को शिक्षा और टिंकरिंग उद्देश्यों के लिए इसे देखने के लिए प्रोत्साहित करता हूं।
डिस्प्ले लिस्ट्स
सौभाग्य से, मूल OpenGL API में कुछ कैशिंग तंत्र हैं, और वे उपयोग में आसान हैं। वे मोटे तौर पर इस क्रम के साथ काम करते हैं:
"अरे OpenGL, मैं चाहता हूं कि आप रिमोट एंड पर ऑब्जेक्ट 37 बनाएं"
"यहाँ ऑब्जेक्ट 37 का वर्णन करने वाला कुछ डेटा है"
"अगले रेंडरिंग चरणों में ऑब्जेक्ट 37 का उपयोग करें"
इसे और भी आसान बनाने के लिए, Bash बाइंडिंग्स आपको नंबरों के बजाय नामों का उपयोग करने देती हैं।
ऑब्जेक्ट का पहला मुख्य प्रकार टेक्सचर है, जहां आप एक 2D छवि को ग्राफिक्स कार्ड में लोड करते हैं और फिर पॉलीगॉन्स को इससे "पेंट" करते हैं। दूसरा "डिस्प्ले लिस्ट" है, जहां आप OpenGL कमांड्स का एक अनुक्रम रिकॉर्ड करते हैं, फिर उन्हें वापस चलाते हैं जैसे कि वे एक सिंगल OpenGL कमांड हों।
डिस्प्ले लिस्ट्स एड-हॉक प्रोटोटाइपिंग के लिए बहुत अच्छी हैं। आप सरल वर्टेक्स कमांड्स का उपयोग करके अपने 3D (या 2D) मॉडल का वर्णन करने वाले कुछ पॉइंट्स प्लॉट कर सकते हैं, फिर उन पॉइंट्स के अनुक्रम को डिस्प्ले लिस्ट के रूप में रिकॉर्ड कर सकते हैं, और अब आप उस मॉडल को एक सिंगल कमांड के साथ रेंडर कर सकते हैं।
इस शक्ति के उदाहरण के लिए, Examples डायरेक्ट्री में Robot.sh देखें। यह स्टार्टअप पर रोबोट के शरीर के प्रत्येक सेगमेंट के लिए एक डिस्प्ले लिस्ट बनाता है, और चलते समय, यह रोबोट को रेंडर करने के लिए प्रति फ्रेम केवल 58 लाइनों का टेक्स्ट उत्सर्जित करता है। Bash 58 लाइनों का टेक्स्ट 16 मिलीसेकंड में काफी आसानी से जनरेट कर सकता है (यह 12 साल पहले भी कर सकता था), इसलिए डेमो सामान्य हार्डवेयर पर पूर्ण गति से चलने में सक्षम था।
डिस्प्ले लिस्ट्स प्राथमिक ट्रिक हैं जिसे मैं DeLorean डैशबोर्ड सॉफ्टवेयर में उपयोग कर रहे Perl ग्राफिक्स पर ले गया। Perl फंक्शन कॉल्स C की तुलना में थोड़े महंगे हैं, विशेष रूप से OpenGL 1.4 जैसे फंक्शन-हेवी API के लिए, लेकिन चीजों को डिस्प्ले लिस्ट्स में संयोजित करके, Perl को प्रति वीडियो फ्रेम ज्यादा काम नहीं करना पड़ता। यदि मैंने इस ट्रिक को Bash प्रोजेक्ट के लिए नहीं सीखा होता, तो Perl प्रोजेक्ट लगभग उतना सफल नहीं होता।
मैंने इसे 12 साल पहले प्रकाशित क्यों नहीं किया?
हालांकि मैं Bash में कुछ फैंसी एनिमेशन डेमो बनाने में सक्षम था, मेरा वास्तविक लक्ष्य इसके साथ एक पूरा गेम बनाना था। मैं पुराने फ्लाइट-सिम गेम Terminal Velocity का क्लोन बनाने का लक्ष्य बना रहा था, और मैं एक स्पेसशिप तक पहुंच गया जो क्यूब्स के क्षेत्र के माध्यम से उड़ सकता था (Examples में Flight.sh देखें), लेकिन अगली समस्या टकराव का पता लगाना थी। Bash में उपलब्ध प्रिमिटिव्स ग्लोबल "एसोसिएटिव array" वेरिएबल नामों और array वेरिएबल्स के हैं (हालांकि वर्जन 4 में अब एसोसिएटिव-array वेरिएबल्स हैं), और सभी गणित पूर्णांक हैं। जबकि मैं फिक्स्ड-पॉइंट इंटीजर गणित में 3D मैट्रिक्स रोटेशन को खींचने में सक्षम था, टकराव का पता लगाना लागू करना बहुत बड़ी बाधा की तरह लग रहा था। मैं अपने फ़ॉन्ट API से भी संतुष्ट नहीं था। इन समस्याओं के समाधानों पर विचार करते हुए, प्रोजेक्ट धीरे-धीरे मेरी सूची से गिर गया।
यह वह जगह है जहां मैंने निष्कर्ष निकाला (जैसा कि मैंने लिखा था), "Bash एक भयानक ग्लू लैंग्वेज है।" जबकि यह प्रोजेक्ट एक मजाक (या शिक्षा उपकरण, शायद) के रूप में शुरू और समाप्त हुआ, Perl में वही प्रोग्राम स्टाइल वास्तविक एप्लिकेशन्स के लिए काफी उपयोगी साबित हुआ। अगर मैंने 13 साल पहले Frozen Bubble को अधिक गंभीरता से लिया होता, तो मैं Perl पर, मेरी अब-पसंदीदा भाषा, पर एक हेड स्टार्ट प्राप्त करने में सक्षम हो सकता था।
मेरे पास बग फिक्स के अलावा इस प्रोजेक्ट को बढ़ाने की कोई योजना नहीं है, लेकिन मुझे लगा कि यह कम से कम OpenGL की अवधारणाओं को सीखने के इच्छुक लोगों या बहुत खाली समय और M4 में Doom क्लोन लिखने की प्रबल इच्छा वाले किसी व्यक्ति के लिए उपयोगी हो सकता है।
आनंद लें! और इस लिंक को फॉरवर्ड करने में मज़ा लें, अन्यथा, कोई आप पर विश्वास नहीं करेगा।
