Esta pregunta es en parte técnica, en parte meta, en parte subjetiva y muy específica:

Soy un desarrollador de juegos independientes. trabajando en Android, y durante los últimos 6 meses he tenido problemas y finalmente logré crear mi propia aplicación de juegos 3D para Android. Así que pensé en utilizar SO y ayudar a otros que luchan con android y openGL-ES

Sin embargo, la gran mayoría de las preguntas se relacionan con la extensión de GLSurfaceView. Hice mi aplicación completa sin extender GLSurfaceView (y funciona bien). No veo ninguna razón para extender GLSurfaceView por la mayoría de las preguntas con las que me encuentro.

Peor aún, la documentación de Android implica que debe hacerlo, pero no da una explicación detallada de por qué o cuáles son los pros / contras frente a no extender y hacer todo mediante la implementación de su propio GLSurfaceView.Renderer como hice yo

Aún así, el gran volumen de preguntas en las que el problema tiene que ver con la extensión de GLSurfaceView me hace preguntarme si realmente hay una buena razón para hacerlo de esa manera en comparación con la forma en que lo he estado haciendo (y sugiriendo en mis respuestas a otros que lo hagan).

Entonces, ¿hay algo ¿Estoy perdido? ¿Debería dejar de responder preguntas mientras tanto?

Documentación de Android openGL

Comentarios

  • buena pregunta, estoy interesado en la respuesta ..
  • Una de las razones por las que extender GLSurfaceView se puede encontrar aquí: gamedev. stackexchange.com/questions/12629/… Sin darme cuenta, en realidad ya eludí los problemas de los que se habló en esta pregunta en mi propia aplicación al volver a cargar texturas, etc. onResume()

    • Responder

    Tengo una extensión mínima para mi GLSurfaceView, y la mayor parte de la sabiduría pertenece a mi implementación de GLSurfaceView.Renderer. Tenía las siguientes tres razones para usar un contenedor para GLSurfaceView:

    1. La base GLSurfaceView no proporciona ninguna forma de recuperar la instancia Renderer. Tengo varias superficies y cuando recibo un evento de IU para una de ellas, quiero pasar el comando al renderizador correspondiente. Por tanto, anulo setRenderer y mantengo la referencia en mi clase extendida.

    2. GLSurfaceView.Renderer no recibe notificaciones para onDetachedFromWindow() o surfaceDestroyed(). Esto causó algunos problemas en mi implementación. Mi extensión de GLSurfaceView anula estos métodos y permite que mRenderer lo sepa. Es posible gracias a § 1 .

    3. Algunos métodos solo están ajustados para agregar try { super. lo que sea ; } catch() { log( lo que sea ) }. Por ejemplo, queueEvent() lanzará si Renderer no está configurado; pero para mí, está bien simplemente ignore tales inconsistencias en la línea de tiempo.

    Comentarios

    • I ' También comencé a hacer esto, aunque la pregunta está más dirigida a por qué podría poner la lógica real en un GLSurfaceView extendido en lugar de GLSurfaceView.Renderer . Aunque en el punto 1, mantengo el renderizador como una variable en mi actividad. En teoría, puedo obtenerlo desde cualquier lugar lanzando el contexto: ((MyActivity)view.getContext()).getRenderer(). Quizás un poco más peligroso ya que el objeto de contexto puede no ser necesariamente MyActivity
    • Está ' está bien si tiene un renderizador. Pero como dije antes, tenemos muchos reproductores, y se conectan a diferentes SurfaceViews, ¡un desastre!

    Respuesta

    Al menos una buena razón para extender GLSurfaceView es poder instanciarlo directamente desde un archivo xml de diseño, como cualquier otro 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>

    Comentarios

    • Puedes hacerlo de todos modos usando <android.opengl.GLSurfaceView android:id="@+id/graphics_glsurfaceview1" android:layout_width="fill_parent" android:layout_height="fill_parent" />
    • Buen punto. La diferencia es que en mi ejemplo, el marco de Android infla y configura todo sin necesidad de líneas adicionales de código. Su método es más código, pero flexible para reemplazar la implementación. Aparte de eso, ambas formas parecen similares.

    Respuesta

    Bueno … GLSurfaceView es, como yo seguro que lo has notado, solo una envoltura para el bien común. Encapsula toda la funcionalidad que uno necesitaría para renderizar con opengl, teniendo la opción de incorporarlo muy bien con la jerarquía de vistas de Android.

    No proporcionaste su alternativa, por lo que es imposible comparar, pero espero que haya generado otro hilo para renderizar como lo hace GLSurfaceView, o su entrada de usuario podría retrasarse.

    De nuevo: GLSurfaceView proporciona un nuevo hilo para renderizar, por lo que no tiene que preocuparse por el retraso de entrada del usuario

    Comentarios

    • Sí, pero GLSurfaceView hace eso (inicia un hilo de renderizado) incluso si no ' t extenderlo. Utilizo GLSurfaceView, pero no ' lo extiendo. Yo ' estoy preguntando qué beneficios hay al extenderlo y anular los diferentes métodos que contiene en lugar de tener todo en el Renderer
    • bueno, lo intenté 🙂 Podría investigarlo más tarde, ¡ahora también estoy interesado!

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *