Esta questão é parte técnica, parte meta, parte subjetiva e muito específica:
Sou um desenvolvedor de jogos indie Estou trabalhando no Android e, nos últimos 6 meses, tive dificuldades e finalmente consegui fazer meu próprio aplicativo de jogo 3D para Android. Então, pensei em pular no SO e ajudar outras pessoas que lutam com o Android e openGL-ES
No entanto, a grande maioria das perguntas está relacionada à extensão de GLSurfaceView. Fiz todo o meu aplicativo sem estender GLSurfaceView (e funciona bem). Não consigo ver nenhum motivo para estender GLSurfaceView para a maioria das perguntas que eu encontro.
Pior, a documentação do Android sugere que você deve, mas não dá uma explicação detalhada de por que ou quais são os prós / contras versus não estender e fazer tudo através da implementação de seu próprio GLSurfaceView.Renderer como eu fiz
Ainda assim, o grande volume de perguntas em que o problema está puramente relacionado com a extensão de GLSurfaceView está me fazendo pensar se realmente existe algum motivo realmente bom para fazer isso dessa maneira em comparação com a maneira como tenho feito (e sugerindo em minhas respostas que os outros façam).
Então, há algo Estou faltando? Devo parar de responder a perguntas enquanto isso?
Documentação openGL do Android
Comentários
Resposta
Tenho uma extensão mínima para meu GLSurfaceView, e a maior parte da sabedoria pertence à minha implementação de GLSurfaceView.Renderer. Eu tive os três motivos a seguir para usar um wrapper para GLSurfaceView:
-
A base
GLSurfaceViewnão oferece nenhuma maneira de recuperar a instânciaRenderer. Tenho várias superfícies e, quando recebo um evento de interface do usuário para uma delas, quero passar o comando para o renderizador correspondente. Portanto, substituosetRenderere mantenho a referência em minha classe estendida. -
GLSurfaceView.Renderernão recebe notificações paraonDetachedFromWindow()ousurfaceDestroyed(). Isso causou alguns problemas à minha implementação. Minha extensão deGLSurfaceViewsubstitui esses métodos e permite que o mRenderer saiba. É possível devido a § 1 . -
Alguns métodos são agrupados apenas para adicionar
try { super.qualquer coisa; } catch() { log(seja o que for) }. Por exemplo,queueEvent()irá lançar se o Renderizador não estiver definido; mas para mim, está OK simplesmente ignore essas inconsistências da linha do tempo.
Comentários
- I ' também começamos a fazer isso, embora a questão seja mais direcionada a por que você pode colocar a lógica real em um
GLSurfaceViewestendido em vez deGLSurfaceView.Renderer. Ainda no ponto 1, mantenho o renderizador como uma variável em minha atividade. Em teoria, posso obtê-lo de qualquer lugar lançando o contexto:((MyActivity)view.getContext()).getRenderer(). Talvez um pouco mais perigoso, pois o objeto de contexto pode não ser necessariamenteMyActivity - ' tudo bem se você tiver um renderizador. Mas, como eu disse antes, temos muitos renderizadores e eles se conectam a diferentes SurfaceViews – uma bagunça!
Resposta
Pelo menos um bom motivo para estender GLSurfaceView é poder instanciá-lo diretamente de um arquivo xml de layout, assim como qualquer outro widget:
Comentários
- Você pode fazer isso de qualquer maneira usando
<android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" /> - Bom argumento. A diferença é que no meu exemplo o framework 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, as duas maneiras parecem semelhantes.
Resposta
Bem … GLSurfaceView é, assim como eu claro que você percebeu, apenas um invólucro para o bem comum. Ele encapsula todas as funcionalidades que seriam necessárias para renderizar com opengl, tendo a opção de incorporá-lo bem com a hierarquia de visualização do Android.
Você não forneceu sua alternativa, por isso é impossível comparar, mas espero que você tenha gerado outro thread para renderizar como GLSurfaceView faz, ou sua entrada do usuário pode demorar.
Então, novamente: GLSurfaceView fornece um novo thread para renderização, então você não precisa se preocupar com o atraso da entrada do usuário
Comentários
- Sim, mas
GLSurfaceViewfaz isso (inicia um thread de renderização) mesmo que você não ' não o estende. Eu usoGLSurfaceView, mas não ' para estendê-lo. Eu ' estou perguntando quais são os benefícios de estendê-lo e substituir os diferentes métodos nele em oposição a apenas ter tudo noRenderer - bem, eu tentei 🙂 Posso ver isso mais tarde, agora também estou interessado!
onResume()