में क्रॉस-प्लेटफ़ॉर्म रेंडरर मैं एक क्रॉस-प्लेटफ़ॉर्म रेंडरर लिख रहा हूं। मैं इसे विंडोज, लिनक्स, एंड्रॉइड, आईओएस पर उपयोग करना चाहता हूं।ओपनजीएल ES
क्या आपको लगता है कि पूर्ण अमूर्तता से बचने और इसे सीधे ओपनजीएल ES 2.0 में लिखना अच्छा विचार है?
जहां तक मुझे पता है कि मैं इसे मानक ओपनजीएल के खिलाफ पीसी पर संकलित करने में सक्षम होना चाहिए, जिसमें कोड में केवल एक छोटे से बदलाव हैं जो खिड़की प्रणाली के संदर्भ और कनेक्शन को संभालते हैं।
क्या आपको लगता है कि पूर्ण अमूर्तता से बचने और इसे सीधे OpenGL ES 2.0 में लिखना अच्छा विचार है?
इसके साथ आपकी सिद्धांत कठिनाइयों ईएस 2.0 विनिर्देश के उन हिस्सों से निपट रही हैं जो वास्तव में ओपनजीएल 2.1 के समान नहीं हैं।
उदाहरण के लिए, आप डेस्कटॉप जीएलएसएल 1.20 कंपाइलर के माध्यम से ईएस 2.0 शेडर्स को नहीं फेंक सकते हैं। ईएस 2.0 में, आप परिशुद्धता निर्दिष्ट करने जैसी चीजों का उपयोग करते हैं; वे जीएलएसएल 1.20 में अवैध संरचनाएं हैं।
आप हालांकि #define उनके आसपास हैं, लेकिन इसके लिए कुछ मैन्युअल हस्तक्षेप की आवश्यकता है। आपको शेडर स्रोत फ़ाइल में #ifdef डालना होगा। शेडर संकलन चालें हैं जो आप इसे थोड़ा आसान बनाने के लिए कर सकते हैं।
दरअसल, क्योंकि जीएल ईएस एक्सटेंशन के एक पूरी तरह से अलग सेट का उपयोग करता है (हालांकि कुछ डेस्कटॉप जीएल एक्सटेंशन के दर्पण और सबसेट हैं), तो आप ऐसा करना चाहेंगे।
प्रत्येक जीएलएसएल शेडर (डेस्कटॉप या ईएस) को "प्रस्तावना" होना चाहिए। एक शेडर में पहली गैर-टिप्पणी की बात #version घोषणा की आवश्यकता है। सौभाग्य से आपके लिए, संस्करण डेस्कटॉप जीएल 2.1 और जीएल ईएस 2.0: #version 1.20 के बीच समान है। समस्या यह है कि अगला क्या आता है: #extension सूची (यदि कोई है)। यह शेडर द्वारा आवश्यक एक्सटेंशन सक्षम बनाता है।
चूंकि जीएल ईएस डेस्कटॉप जीएल से विभिन्न एक्सटेंशन का उपयोग करता है, इसलिए आपको यह एक्सटेंशन सूची बदलनी होगी। और चूंकि बाधाएं अच्छी हैं, आपको डेस्कटॉप जीएल 2.1 एक्सटेंशन की तुलना में अधिक जीएलएसएल ES एक्सटेंशन की आवश्यकता होगी, ये सूचियां केवल 1: 1 मैपिंग नहीं होंगी, लेकिन पूरी तरह से अलग सूचियां होंगी।
मेरा सुझाव है कि जीएलएसएल शेडर्स को कई तार देने की क्षमता को नियोजित करना है। यही है, आपकी वास्तविक शेडर फ़ाइलें कोई प्रीम्बल सामग्री नहीं है। वे केवल वास्तविक परिभाषाएं और कार्य हैं। शेडर का मुख्य निकाय।
जीएल ईएस पर चलते समय, आपके पास एक वैश्विक प्रस्ताव है कि आप शेडर की शुरुआत से चिपकेंगे। डेस्कटॉप जीएल में आपके पास एक अलग वैश्विक प्रस्ताव होगा। कोड इस तरह दिखेगा:
GLuint shader = glCreateShader(/*shader type*/);
const char *shaderList[2];
shaderList[0] = GetGlobalPreambleString(); //Gets preamble for the right platform
shaderList[1] = LoadShaderFile(); //Get the actual shader file
glShaderSource(shader, 2, shaderList, NULL);
प्रस्तावना भी शामिल कर सकते हैं एक प्लेटफ़ॉर्म-विशिष्ट #define। पाठ्यक्रम की उपयोगकर्ता परिभाषित। इस तरह, आप विभिन्न प्लेटफार्मों के लिए #ifdef कोड कर सकते हैं।
दोनों के बीच अन्य अंतर हैं। उदाहरण के लिए, वैध ES 2.0 बनावट अपलोडिंग फ़ंक्शन कॉल करते समय डेस्कटॉप जीएल 2.1 में ठीक काम करेगा, वे आवश्यक रूप से इष्टतम नहीं होंगे। ऐसी चीजें जो सभी मोबाइल सिस्टम जैसी बड़ी-अंत मशीनों पर जुर्माना अपलोड करती हैं, उन्हें छोटी-छोटी डेस्कटॉप मशीनों में ड्राइवर से थोड़ा सा झुकाव की आवश्यकता होगी। तो आप जीएल ईएस और डेस्कटॉप जीएल पर विभिन्न पिक्सेल स्थानांतरण पैरामीटर निर्दिष्ट करने का एक तरीका चाहते हैं।
इसके अलावा, ईएस 2.0 और डेस्कटॉप जीएल 2.1 में एक्सटेंशन के विभिन्न सेट हैं जिनका आप लाभ लेना चाहते हैं। जबकि उनमें से कई एक-दूसरे को दर्पण करने का प्रयास करते हैं (OES_framebuffer_object EXT_framebuffer_object का उप-समूह है), आप उपर्युक्त वर्णित समान "समान सबसेट नहीं" जैसे मुद्दों को दूर कर सकते हैं।
आपके संपूर्ण उत्तर के लिए धन्यवाद।तो आपको लगता है कि किसी प्रकार का ओपनजीएल रेंडरर अबास्ट्रक्शन बनाना बेहतर होगा? उदाहरण के लिए, मैं Texture2D कक्षा द्वारा प्रदर्शित एक बनावट बना सकता हूं। इस वर्ग में दोनों विनिर्देशों के लिए सामान्य चीजें होंगी, लेकिन कुछ चीजों का कार्यान्वयन अलग होगा। – runnydead
@ हबोबिन: इसे उस सारणी की आवश्यकता नहीं है। आपको विशेष स्थानों पर बस कुछ प्लेटफ़ॉर्म-विशिष्ट कोड की आवश्यकता है। अब, यदि आप 2.1 के बजाय जीएल 3.3 को लक्षित कर रहे हैं, तो आपको एक अमूर्तता की अधिक आवश्यकता होगी। –
मैं पीसी पर और अधिक सुविधाओं का समर्थन नहीं करना चाहता हूं। तो आप मूल रूप से कह रहे हैं, कि यह करने योग्य है? – runnydead
मेरे विनम्र अनुभव में, इस तरह की आवश्यकताओं के लिए सबसे अच्छा तरीका अपने इंजन को एक शुद्ध सी स्वाद में विकसित करना है, जिसमें कोई अतिरिक्त परत नहीं है।
मैं पैट्रिआ 3 डी इंजन का मुख्य डेवलपर हूं जो आपके द्वारा पोर्टेबिलिटी के मामले में अभी उल्लेख किए गए बुनियादी सिद्धांत पर आधारित है और हमने इसे बुनियादी मानक पुस्तकालयों पर टूल विकसित करके हासिल किया है।
विभिन्न कोडों पर आपके कोड को संकलित करने का प्रयास बहुत ही कम है।
पूरे समाधान को बंद करने के वास्तविक प्रयास की गणना उन घटकों के आधार पर की जा सकती है जिन्हें आप अपने इंजन में एम्बेड करना चाहते हैं।
उदाहरण के लिए:
स्टैंडर्ड सी:
इंजन 3D
खेल तर्क
खेल ऐ
भौतिकी
+
विंडो इंटरफेस (भरमार, EGL आदि) - मंच पर, वैसे भी निर्भर करता है डेस्कटॉप और मोबाइल उपकरणों के लिए EGL के लिए भरमार हो सकता है।
ह्यूमन इंटरफ़ेस - पोर्टिंग
बाजार सेवाओं पर निर्भर करता है - - पोर्टिंग पर एंड्रॉयड, आईओएस के लिए ओसी, जो कुछ भी संस्करण डेस्कटॉप
ध्वनि प्रबंधक के लिए जावा निर्भर करता है, पोर्टिंग
इस तरह, आप अपने प्रयासों का 95% एक निर्बाध तरीके से फिर से उपयोग कर सकते हैं।
हमने अपने इंजन के लिए इस समाधान को अपनाया है और अब तक यह प्रारंभिक निवेश के लायक है।
क्या आपने किवी सुना है? यह लिनक्स, विंडोज, मैकॉक्स, एंड्रॉइड और आईओएस के लिए एक ओपन सोर्स क्रॉस-प्लेटफार्म प्रोग्रामिंग भाषा है जो ओपनजीएल (http://kivy.org) में इसके सभी विचार प्रस्तुत करता है। भाषा में इसके स्वयं के विजेट टूलकिट भी शामिल हैं। मैंने सोचा कि मैं वहां से बाहर फेंक दूंगा क्योंकि एक संभावना है कि यदि आप पहले से मौजूद हैं तो शायद पहिया का पुन: आविष्कार नहीं करना चाहेंगे और शायद आपने इसे अभी तक नहीं खोजा है। – trusktr
यदि आपके पास एंड्रॉइड या आईओएस है, तो इसका उपयोग करने के उदाहरण देखने के लिए Play Store या App Store में "Kivy" की खोज करने का प्रयास करें। – trusktr