Android, OpenGL und die Erweiterung von GLSurfaceView?

12

Diese Frage ist teils technisch, teils meta, teils subjektiv und sehr spezifisch:

Ich bin ein Indie-Game-Entwickler, der an Android arbeitet, und in den letzten 6 Monaten habe ich gekämpft und es endlich geschafft, meine eigene 3D-Game-App für Android zu entwickeln. Also dachte ich, ich würde auf SO setzen und anderen helfen, die mit Android und OpenGL-ES zu kämpfen haben

Die allermeisten Fragen beziehen sich jedoch auf die Verlängerung GLSurfaceView. Ich habe meine gesamte App ohne Erweiterung erstellt GLSurfaceView(und sie läuft einwandfrei). Ich sehe überhaupt keinen Grund GLSurfaceView, mich auf die meisten Fragen zu beschränken, auf die ich stoße.

Schlimmer noch, die Android-Dokumentation impliziert, dass Sie es sollten, gibt aber keine detaillierte Erklärung, warum oder was die Vor- / Nachteile sind und nicht alles zu erweitern und zu tun, indem Sie Ihre eigenen implementieren, GLSurfaceView.Rendererwie ich es getan habe

Die Fülle von Fragen, bei denen das Problem ausschließlich in der Erweiterung GLSurfaceViewbesteht, lässt mich jedoch fragen, ob es tatsächlich einen guten Grund gibt, dies so zu tun, als ich es bisher getan habe (und meine Antworten anderen vorzuschlagen machen).

Also, fehlt mir etwas? Sollte ich in der Zwischenzeit aufhören, Fragen zu beantworten?

Android openGL-Dokumentation

android opengl

— Löffel Daumen
quelle

schöne Frage, ich bin gespannt auf Antwort ..

— Tofeeq

Ein Grund, warum GLSurfaceView erweitert werden sollte, ist hier zu finden: gamedev.stackexchange.com/questions/12629/… Ohne es zu merken, bin ich den in dieser Frage angesprochenen Problemen in meiner eigenen App bereits ausgewichen, indem ich Texturen usw. neu geladen habeonResume()

— Spoon Thumb

2

Ich habe eine sehr minimale Erweiterung für meine GLSurfaceView, und der größte Teil der Weisheit gehört zu meiner Implementierung von GLSurfaceView.Renderer. Ich hatte die folgenden drei Gründe, einen Wrapper zu verwenden GLSurfaceView:

Die Basis GLSurfaceViewbietet keine Möglichkeit, die RendererInstanz zurückzugewinnen. Ich habe mehrere Oberflächen, und wenn ich ein UI-Ereignis für eine davon erhalte, möchte ich den Befehl an den entsprechenden Renderer übergeben. Also überschreibe ich setRendererund behalte die Referenz in meiner erweiterten Klasse.
GLSurfaceView.RendererErhält keine Benachrichtigungen für onDetachedFromWindow()oder surfaceDestroyed(). Dies verursachte einige Probleme bei meiner Implementierung. Meine Erweiterung von GLSurfaceViewüberschreibt diese Methoden und teilt dem mRenderer dies mit . Es ist wegen §1 möglich .
Einige Methoden werden nur umbrochen, um try { super.was auch ; } catch() { log(immer hinzuzufügen ) }. Zum Beispiel queueEvent()wird ausgelöst, wenn der Renderer nicht gesetzt ist. Für mich ist es jedoch in Ordnung, solche Inkonsistenzen auf der Zeitachse einfach zu ignorieren.

— Alex Cohn
quelle

Ich habe auch damit begonnen, obwohl die Frage eher darauf abzielt, warum Sie die eigentliche Logik GLSurfaceVieweher in eine erweiterte als in eine GLSurfaceView.Renderer. In Punkt 1 behalte ich den Renderer als Variable in meiner Aktivität. In der Theorie kann ich es von überall erhalten , indem Sie das Kontext Gießen: ((MyActivity)view.getContext()).getRenderer(). Vielleicht ein bisschen gefährlicher, da das Kontextobjekt nicht unbedingt sein mussMyActivity

— Spoon Thumb

Es ist in Ordnung, wenn Sie einen Renderer haben. Aber wie gesagt, wir haben viele Darsteller, die mit verschiedenen SurfaceViews verbunden sind - ein Durcheinander!

— Alex Cohn

0

Mindestens ein guter Grund für die Erweiterung von GLSurfaceView besteht darin, dass es wie jedes andere Widget direkt aus einer Layout-XML-Datei instanziiert werden kann:

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

— Amir Uval
quelle

1

Sie können das trotzdem tun, indem Sie

<android.opengl.GLSurfaceView  		android:id="@+id/graphics_glsurfaceview1"  		android:layout_width="fill_parent"  		android:layout_height="fill_parent" 	/>

— Spoon Thumb

Guter Punkt. Der Unterschied ist, dass in meinem Beispiel das Android-Framework alles aufbläst und einrichtet, ohne dass zusätzliche Codezeilen erforderlich sind. Ihre Methode ist mehr Code, aber flexibel, um die Implementierung zu ersetzen. Davon abgesehen scheinen sich beide Wege zu ähneln.

— Amir Uval

-1

Nun ... GLSurfaceView ist, wie Sie sicherlich bemerkt haben, nur ein Wrapper für das Gemeinwohl. Es kapselt alle Funktionen, die man zum Rendern mit opengl benötigt, und bietet die Möglichkeit, es gut in die Android View-Hierarchie zu integrieren.

Sie haben Ihre Alternative nicht angegeben, so dass ein Vergleich unmöglich ist, aber ich hoffe, Sie haben einen anderen Thread zum Rendern erzeugt, wie dies bei GLSurfaceView der Fall ist, da Ihre Benutzereingaben möglicherweise verzögert werden.

Also nochmal: GLSurfaceView stellt einen neuen Thread zum Rendern bereit, sodass Sie sich nicht um die Verzögerung von Benutzereingaben kümmern müssen

— Greg
quelle

2

Ja, aber GLSurfaceViewmacht das (startet einen Rendering-Thread), auch wenn Sie ihn nicht erweitern. Ich benutze GLSurfaceView, aber ich verlängere es nicht. Ich frage mich, welche Vorteile es hat, wenn man es erweitert und die darin enthaltenen Methoden außer Kraft setzt, anstatt einfach alles imRenderer

— Löffel zu haben. Thumb

welp, ich habe es versucht :) Vielleicht schaue ich später mal rein, jetzt interessiert es mich auch!

— Greg