Android, OpenGL e extensão GLSurfaceView?

12

Esta pergunta é parte técnica, parte meta, parte subjetiva e muito específica:

Sou desenvolvedor de jogos indie trabalhando no Android e, nos últimos 6 meses, lutei e finalmente consegui criar meu próprio aplicativo de jogo em 3D para Android. Então pensei em usar o SO e ajudar outras pessoas que enfrentam o Android e o openGL-ES

No entanto, a grande maioria das perguntas se refere à extensão GLSurfaceView. Eu fiz meu aplicativo inteiro sem estender GLSurfaceView(e ele funciona bem). Não vejo nenhum motivo para estender GLSurfaceViewa maioria das perguntas que me deparo.

Pior, a documentação do Android implica que você deve, mas não fornece explicações detalhadas sobre por que ou quais são os prós / contras, não estendendo e fazendo tudo através da implementação do seu, GLSurfaceView.Renderercomo eu fiz

Ainda assim, o grande volume de perguntas em que o problema tem a ver apenas com a extensão GLSurfaceViewestá me fazendo pensar se realmente há alguma razão realmente boa para fazê-lo dessa maneira, em comparação com o que eu tenho feito (e sugerindo nas minhas respostas a outras pessoas) façam).

Então, está faltando alguma coisa? Devo parar de responder perguntas enquanto isso?

Documentação do Android openGL

android opengl

— Spoon Thumb
fonte

boa pergunta que eu estou interessado sobre resposta ..

— Tofeeq

Uma razão pela qual a extensão do GLSurfaceView pode ser encontrada aqui: gamedev.stackexchange.com/questions/12629/… Sem perceber, na verdade eu já havia evitado os problemas mencionados nesta pergunta em meu próprio aplicativo, recarregando texturas etc.onResume()

— Spoon Thumb

2

Eu tenho uma extensão muito mínima para o meu GLSurfaceViewe a maior parte da sabedoria pertence à minha implementação do GLSurfaceView.Renderer. Eu tive os três motivos a seguir para usar um wrapper para GLSurfaceView:

A base GLSurfaceViewnão oferece como recuperar a Rendererinstância. Tenho várias superfícies e, quando recebo um evento de interface do usuário para uma delas, desejo passar o comando para o representante correspondente. Então, eu substituo setRenderere mantenho a referência na minha classe estendida.
GLSurfaceView.Renderernão recebe notificações para onDetachedFromWindow()ou surfaceDestroyed(). Isso causou alguns problemas na minha implementação. Minha extensão GLSurfaceViewsubstitui esses métodos e informa o mRenderer . É possível por causa do §1 .
Alguns métodos são agrupados apenas para adicionar o try { super.que ; } catch() { log(quer que seja) } . Por exemplo, queueEvent()será lançado se o Renderer não estiver definido; mas para mim, não há problema em simplesmente ignorar essas inconsistências na linha do tempo.

— Alex Cohn
fonte

Eu comecei a fazer isso também, embora a pergunta seja mais direcionada para o motivo de você colocar a lógica real de uma maneira estendida em GLSurfaceViewvez de GLSurfaceView.Renderer. Embora no ponto 1, mantenho o renderizador como uma variável em minha atividade. Em teoria, eu pode obtê-lo de qualquer lugar, lançando o contexto: ((MyActivity)view.getContext()).getRenderer(). Talvez um pouco mais perigoso como o objeto de contexto podem não ser necessariamenteMyActivity

— Colher Thumb

Tudo bem se você tiver um representante. Mas, como eu disse antes, temos muitos rendrers, e eles se conectam a diferentes SurfaceViews - uma bagunça!

— Alex Cohn

0

Pelo menos um bom motivo para estender o GLSurfaceView é poder instancia-lo diretamente de um arquivo xml de layout, assim como qualquer outro 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
fonte

1

Você pode fazer isso de qualquer maneira utilizando

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

— Colher Thumb

Bom ponto. A diferença é que, no meu exemplo, a estrutura do Android infla e configura tudo sem precisar de linhas extras de código. Seu método é mais código, mas flexível para substituir a implementação. Fora isso, os dois lados parecem semelhantes.

— Amir Uval

-1

Bem ... GLSurfaceView é, como eu tenho certeza que você notou, apenas um invólucro para o bem comum. Ele encapsula toda a funcionalidade que seria necessária para renderizar com o opengl, com a opção de incorporá-lo perfeitamente à hierarquia do Android View.

Você não forneceu sua alternativa, por isso é impossível comparar, mas espero que você tenha gerado outro encadeamento para renderização como o GLSurfaceView, ou a entrada do usuário pode ficar lenta.

Novamente: GLSurfaceView fornece um novo thread para renderização, para que você não precise se preocupar com o atraso na entrada do usuário

— Greg
fonte

2

Sim, mas GLSurfaceViewfaz isso (inicia um thread de renderização), mesmo que você não o estenda. Eu uso GLSurfaceView, mas não o estendo. Estou perguntando o que são os benefícios de estender-lo e overrriding os diferentes métodos nele ao invés de apenas ter tudo naRenderer

— Colher Thumb

welp, eu tentei :) Eu posso pesquisar mais tarde, agora também estou interessado!

— Greg