Android, OpenGL और GLSurfaceView का विस्तार?

Question

यह सवाल पार्ट-टेक्निकल, पार्ट-मेटा, पार्ट-सब्जेक्टिव और बहुत विशिष्ट है:

मैं एंड्रॉइड पर काम करने वाला एक इंडी गेम देव हूं, और पिछले 6 महीनों से मैंने संघर्ष किया है और आखिरकार एंड्रॉइड के लिए अपना 3 डी गेम ऐप बनाने में सफल रहा। इसलिए मैंने सोचा कि मैं SO पर आशा करूँगा और Android और OpenGL-ES के साथ संघर्ष करने वाले अन्य लोगों की मदद करूँगा

हालाँकि, अधिकांश प्रश्न विस्तार से संबंधित हैं GLSurfaceView। मैंने अपना पूरा ऐप बिना किसी विस्तार के बनाया GLSurfaceView(और यह ठीक चलता है)। मैं जितने भी GLSurfaceViewप्रश्न भर आया हूं , उनका विस्तार करने के लिए मैं कोई कारण नहीं देख सकता ।

इससे भी बदतर, एंड्रॉइड डॉक्युमेंटेशन का अर्थ है कि आपको चाहिए, लेकिन इस बात की कोई विस्तृत व्याख्या नहीं दी गई है कि पेशेवरों या विपक्षों का विस्तार नहीं हो रहा है या नहीं, अपने खुद के कार्यान्वयन के माध्यम से सब कुछ GLSurfaceView.Rendererकिया जा रहा है।

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

तो, क्या मुझे कुछ याद आ रहा है? क्या मुझे इस बीच सवालों का जवाब देना बंद कर देना चाहिए?

Android OpenGL के दस्तावेज़

Comments

अच्छा सवाल मैं जवाब के बारे में उत्सुक हूँ ..

— Tofeeq

GLSurfaceView का विस्तार करने का एक कारण यहां पाया जा सकता है: gamedev.stackexchange.com/questions/12629/… इसे साकार किए बिना, मैंने वास्तव में पहले से ही इस प्रश्न में इस विषय में बात की गई बातों को फिर से लोड करने के लिए बनावट आदिonResume()

— चम्मच थम्ब

Answer 1

मेरे पास मेरे लिए बहुत कम विस्तार है GLSurfaceView, और अधिकांश ज्ञान मेरे कार्यान्वयन के हैं GLSurfaceView.Renderer। मेरे पास रैपर का उपयोग करने के लिए निम्नलिखित तीन कारण थे GLSurfaceView:

1. आधार उदाहरण को वापस GLSurfaceViewलाने का कोई तरीका नहीं प्रदान करता है Renderer। मेरे पास कई सतहें हैं, और जब मैं उनमें से एक के लिए एक यूआई घटना प्राप्त करता हूं, तो मैं संबंधित रेंडरर को कमांड पास करना चाहता हूं। इसलिए, मैं setRendererअपनी विस्तारित कक्षा में संदर्भ को ओवरराइड करता हूं और रखता हूं।

2. GLSurfaceView.Rendererके लिए सूचनाएं प्राप्त नहीं करता है onDetachedFromWindow()या surfaceDestroyed()। इसने मेरे कार्यान्वयन में कुछ समस्याएं पैदा कीं। GLSurfaceViewइन तरीकों को ओवरराइड करने का मेरा विस्तार और mRenderer को बता देता है। यह की वजह से संभव है §1 ।

3. कुछ विधियों को केवल try { super.जो ; } catch() { log(कुछ भी जोड़ने के लिए लपेटा जाता है ) }। उदाहरण के लिए, queueEvent()अगर रेंडरर सेट नहीं है तो फेंक देंगे; लेकिन मेरे लिए, इस तरह की समयरेखा विसंगतियों को अनदेखा करना ठीक है।

Comments

मैंने ऐसा करना शुरू कर दिया है, हालांकि यह सवाल अधिक उद्देश्य से है कि आप वास्तविक तर्क को एक विस्तारित के GLSurfaceViewबजाय विस्तारित रूप में क्यों रख सकते हैं GLSurfaceView.Renderer। हालांकि बिंदु 1 पर, मैं रेंडरर को अपनी गतिविधि में एक चर के रूप में रखता हूं। सिद्धांत रूप में, मैं इसे कहीं से भी संदर्भ के कास्टिंग के द्वारा प्राप्त कर सकता हूं ((MyActivity)view.getContext()).getRenderer():। शायद थोड़ा अधिक खतरनाक है क्योंकि संदर्भ वस्तु जरूरी नहीं हो सकती हैMyActivity

— चम्मच थम्ब

यह ठीक है अगर आपके पास एक रेंडर है। लेकिन जैसा कि मैंने पहले कहा, हमारे पास कई रेंडर हैं, और वे अलग-अलग सरफेस व्यू से जुड़े हुए हैं - एक गड़बड़!

— एलेक्स कोहेन

Answer 2

GLSurfaceView का विस्तार करने का कम से कम एक अच्छा कारण यह है कि इसे सीधे किसी लेआउट xml फ़ाइल से, किसी अन्य विजेट की तरह ही तुरंत सक्षम किया जा सकता है:

    <RelativeLayout ... >
      <com.example.MyGlSurfaceView
        android:id="@+id/my_view"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
      />
     </RelativeLayout>

Comments

आप वैसे भी<android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />

— चम्मच थम्ब

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

— अमीर उवाल

Answer 3

खैर ... GLSurfaceView है, जैसा कि मुझे यकीन है कि आपने देखा है, आम अच्छे के लिए सिर्फ एक आवरण। यह सभी कार्यक्षमता को समाहित करता है जिसे ओपेंगल के साथ प्रस्तुत करना होगा, इसे एंड्रॉइड व्यू पदानुक्रम के साथ अच्छी तरह से शामिल करने का विकल्प होगा।

आपने अपना विकल्प प्रदान नहीं किया है, इसलिए तुलना करना असंभव है, लेकिन मुझे आशा है कि आपने प्रतिपादन के लिए एक और धागा दिया होगा जैसा कि GLSurfaceView करता है, या आपका उपयोगकर्ता इनपुट पिछड़ सकता है।

तो फिर से: GLSurfaceView प्रतिपादन के लिए एक नया धागा प्रदान करता है, इसलिए आपको उपयोगकर्ता इनपुट अंतराल के बारे में चिंता करने की ज़रूरत नहीं है

Comments

हां, लेकिन GLSurfaceViewक्या यह (एक प्रतिपादन धागा शुरू होता है) भले ही आप इसे विस्तारित न करें। मैं उपयोग करता हूं GLSurfaceView, लेकिन मैं इसका विस्तार नहीं करता। मैं पूछ रहा हूं कि इसका विस्तार करने से क्या लाभ हैं और इसमें अलग-अलग तरीकों को ओवरराइड करना है, जैसे कि सब कुछ होने के विपरीत हैRenderer

— स्पून थम्ब

वेल्ड, मैंने कोशिश की :) मैं बाद में इस पर गौर कर सकता हूं, अब मुझे भी दिलचस्पी है!

— ग्रेग