Android, OpenGL i rozszerzenie GLSurfaceView?

12

To pytanie jest częściowo techniczne, częściowo meta, częściowo subiektywne i bardzo szczegółowe:

Jestem niezależnym twórcą gier pracującym na Androidzie i przez ostatnie 6 miesięcy miałem problemy i wreszcie udało mi się stworzyć własną aplikację do gier 3D na Androida. Pomyślałem więc, że wskoczę na SO i pomogę innym zmagającym się z Androidem i openGL-ES

Jednak zdecydowana większość pytań dotyczy rozszerzenia GLSurfaceView. Zrobiłem całą aplikację bez rozszerzania GLSurfaceView(i działa dobrze). Nie widzę żadnego powodu, aby rozciągać się GLSurfaceViewna większość pytań, które napotkałem.

Co gorsza, dokumentacja Androida sugeruje, że powinieneś, ale nie zawiera szczegółowego wyjaśnienia, dlaczego lub czym są zalety / wady, a nie przedłużanie i robienie wszystkiego poprzez wdrożenie własnego, GLSurfaceView.Renderertak jak ja

Mimo to sama liczba pytań, w których problem dotyczy wyłącznie rozszerzenia, GLSurfaceViewsprawia, że ​​zastanawiam się, czy rzeczywiście istnieje jakiś naprawdę dobry powód, aby zrobić to w ten sposób w porównaniu do sposobu, w jaki to robiłem (i sugerując w odpowiedziach dla innych do zrobienia).

Czy jest coś, za czym tęsknię? Czy w międzyczasie powinienem przestać odpowiadać na pytania?

Dokumentacja openGL Androida

Łyżka Kciuk
źródło
fajne pytanie, zależy mi na odpowiedzi.
Tofeeq,
Jednym z powodów, dla których rozszerzenie GLSurfaceView można znaleźć tutaj: gamedev.stackexchange.com/questions/12629/... Nie zdając sobie z tego sprawy, właściwie już omijałem problemy omawiane w tym pytaniu w mojej własnej aplikacji, ponownie ładując tekstury itp.onResume()
Spoon Thumb

Odpowiedzi:

2

Mam bardzo minimalne rozszerzenie dla siebie GLSurfaceViewi większość mądrości należy do mojej implementacji GLSurfaceView.Renderer. Miałem następujące trzy powody, dla których warto użyć opakowania GLSurfaceView:

  1. Baza GLSurfaceViewnie umożliwia odzyskania Rendererinstancji. Mam wiele powierzchni, a gdy otrzymuję zdarzenie interfejsu użytkownika dla jednej z nich, chcę przekazać polecenie do odpowiedniego mechanizmu renderującego. Zastępuję setRendereri zachowuję referencję w mojej rozszerzonej klasie.

  2. GLSurfaceView.Renderernie otrzymuje powiadomień dotyczących onDetachedFromWindow()lub surfaceDestroyed(). Spowodowało to pewne problemy z moją implementacją. Moje rozszerzenie GLSurfaceViewzastępuje te metody i informuje mRenderer . Jest to możliwe dzięki §1 .

  3. Niektóre metody są owinięte tylko dodać try { super.cokolwiek ; } catch() { log(cokolwiek) } . Na przykład queueEvent()wyrzuci, jeśli moduł renderujący nie jest ustawiony; ale dla mnie OK jest po prostu ignorować takie niespójności na osi czasu.

Alex Cohn
źródło
Zacząłem też to robić, choć pytanie bardziej dotyczy tego, dlaczego możesz umieścić logikę w rozszerzonym, GLSurfaceViewa nie rozszerzonym GLSurfaceView.Renderer. Chociaż w punkcie 1 zachowuję renderer jako zmienną w mojej działalności. Teoretycznie można uzyskać z dowolnego miejsca poprzez odlewanie kontekst: ((MyActivity)view.getContext()).getRenderer(). Być może nieco bardziej niebezpieczne, ponieważ obiekt kontekstu niekoniecznie musi byćMyActivity
Spoon Thumb
W porządku, jeśli masz jeden renderer. Ale jak powiedziałem wcześniej, mamy wiele rendererów i łączą się one z różnymi SurfaceViews - bałagan!
Alex Cohn
0

Co najmniej jednym dobrym powodem do rozszerzenia GLSurfaceView jest możliwość utworzenia go bezpośrednio z pliku XML układu, tak jak każdy inny widget:

    <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
źródło
1
Możesz to zrobić w każdym razie, używając<android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
Spoon Thumb
Słuszna uwaga. Różnica polega na tym, że w moim przykładzie system Android napompowuje i konfiguruje wszystko bez potrzeby stosowania dodatkowych wierszy kodu. Twoja metoda jest bardziej kodowa, ale elastyczna do zastąpienia implementacji. Poza tym oba sposoby wydają się podobne.
Amir Uval,
-1

Cóż ... GLSurfaceView jest, jak jestem pewien, zauważyłeś, tylko opakowaniem dla wspólnego dobra. Zawiera wszystkie funkcje, które należałoby renderować za pomocą opengl, z opcją ładnego włączenia go w hierarchię widoku Android.

Nie podałeś swojej alternatywy, więc nie można jej porównać, ale mam nadzieję, że stworzyłeś inny wątek do renderowania, tak jak robi to GLSurfaceView, lub twoje dane wejściowe mogą być opóźnione.

Więc jeszcze raz: GLSurfaceView zapewnia nowy wątek do renderowania, więc nie musisz się martwić opóźnieniem wprowadzania danych przez użytkownika

Greg
źródło
2
Tak, ale GLSurfaceViewrobi to (uruchamia wątek renderujący), nawet jeśli go nie rozszerzysz. Używam GLSurfaceView, ale nie przedłużam. Pytam, jakie są korzyści z rozszerzenia go i zastąpienia różnych metod w nim zawartych, zamiast po prostu posiadania wszystkiego wRenderer
Spoon Thumb
welp, próbowałem :) Mogę zajrzeć później, teraz też jestem zainteresowany!
Greg