Android incluye compatibilidad con gráficos 2D y 3D de alto rendimiento con Open Graphics Library (OpenGL®), específicamente, la API de OpenGL ES. OpenGL es una API de gráficos multiplataforma que especifica una interfaz de software estándar para el hardware de procesamiento de gráficos 3D. OpenGL ES es una versión de la especificación OpenGL diseñada para dispositivos incorporados. Android admite varias versiones de la API de OpenGL ES:
- OpenGL ES 2.0: Esta especificación de API es compatible con Android 2.2 (nivel de API 8) y versiones posteriores.
- OpenGL ES 3.0: Esta especificación de API es compatible con Android 4.3 (nivel de API 18) y versiones posteriores.
- OpenGL ES 3.1: Esta especificación de API es compatible con Android 5.0 (nivel de API 21) y versiones posteriores.
- OpenGL ES 3.2: Esta especificación de API es compatible con Android 7.0 (nivel de API 24) y versiones posteriores.
Precaución: Independientemente de la versión de la plataforma de Android, un dispositivo no puede admitir la API de OpenGL ES 3.0, a menos que el fabricante del dispositivo proporcione una implementación de esta canalización de gráficos. Si especificas en el manifiesto que se requiere OpenGL ES 3.0, puedes estar seguro de que esa versión estará presente en el dispositivo. Si especificas que se requiere una versión de nivel inferior, pero deseas usar funciones 3.0 (si están disponibles), debes verificar qué versión de OpenGL admite el dispositivo durante el tiempo de ejecución. Para obtener información sobre cómo hacerlo, consulta Cómo comprobar la versión de OpenGL ES.
Nota: Android admite OpenGL ES 1.0 y 1.1, pero estas versiones de la API dejaron de estar disponibles y las aplicaciones modernas no deben usarlas.
Nota: La API específica que proporciona el framework de Android es similar a la API de OpenGL ES J2ME JSR239, pero no es idéntica. Si conoces la especificación JSR 239 de J2ME, presta atención a las variaciones.
Ver también
- Cómo mostrar gráficos con OpenGL ES
- OpenGL ES
- Especificación de OpenGL ES 2.x
- Especificación de OpenGL ES 3.x
Conceptos básicos
Android admite OpenGL mediante su API de framework y el kit de desarrollo nativo (NDK). Este tema se centra en las interfaces del marco de trabajo de Android. Para obtener más información sobre el NDK, consulta la página del NDK de Android.
Hay dos clases fundamentales en el framework de Android que te permiten crear y manipular gráficos con la API de OpenGL ES: GLSurfaceView
y GLSurfaceView.Renderer
. Si tu objetivo es usar OpenGL en tu aplicación para Android, tu primer objetivo debería ser comprender cómo implementar estas clases en una actividad.
GLSurfaceView
- Esta clase es una
View
en la que puedes dibujar y manipular objetos usando llamadas a la API de OpenGL y es similar en función a unaSurfaceView
. Para usar esta clase, crea una instancia deGLSurfaceView
y agrégale tuRenderer
. Sin embargo, si deseas capturar eventos de pantalla táctil, debes extender la claseGLSurfaceView
para implementar los objetos de escucha táctiles, como se muestra en la lección de capacitación de OpenGL: Cómo responder a eventos táctiles. GLSurfaceView.Renderer
- Esta interfaz define los métodos necesarios para dibujar gráficos en una
GLSurfaceView
. Debes proporcionar una implementación de esta interfaz como una clase separada y adjuntarla a tu instanciaGLSurfaceView
usandoGLSurfaceView.setRenderer()
.La interfaz
GLSurfaceView.Renderer
requiere que implementes los siguientes métodos:-
onSurfaceCreated()
: El sistema llama a este método una vez, cuando crea elGLSurfaceView
. Usa este método para realizar acciones que deben ocurrir solo una vez, como configurar parámetros de entorno de OpenGL o inicializar objetos gráficos de OpenGL. -
onDrawFrame()
: El sistema llama a este método cada vez que se vuelve a dibujarGLSurfaceView
. Utiliza este método como punto de ejecución principal para dibujar (y volver a dibujar) objetos gráficos. -
onSurfaceChanged()
: El sistema llama a este método cuando cambia la geometría deGLSurfaceView
, incluidos los cambios de tamaño deGLSurfaceView
o la orientación de la pantalla del dispositivo. Por ejemplo, el sistema llama a este método cuando el dispositivo cambia de orientación vertical a horizontal. Usa este método para responder a los cambios en el contenedorGLSurfaceView
.
-
Paquetes de OpenGL ES
Una vez que hayas establecido una vista de contenedor para OpenGL ES con GLSurfaceView
y GLSurfaceView.Renderer
, puedes comenzar a llamar a las APIs de OpenGL con las siguientes clases:
- Clase de API de OpenGL ES 2.0
android.opengl.GLES20
: Este paquete proporciona la interfaz para OpenGL ES 2.0 y está disponible a partir de Android 2.2 (nivel de API 8).
- Paquetes de API de OpenGL ES 3.0/3.1/3.2
android.opengl
: Este paquete proporciona la interfaz para las clases de OpenGL ES 3.0/3.1. La versión 3.0 está disponible a partir de Android 4.3 (API nivel 18). La versión 3.1 está disponible a partir de Android 5.0 (nivel de API 21). La versión 3.2 está disponible a partir de Android 7.0 (nivel de API 24).
Si quieres comenzar a compilar una app con OpenGL ES de inmediato, sigue la clase Cómo mostrar gráficos con OpenGL ES.
Cómo declarar requisitos de OpenGL
Si tu aplicación usa funciones de OpenGL que no están disponibles en todos los dispositivos, debes incluir estos requisitos en el archivo AndroidManifest.xml. Estas son las declaraciones de manifiesto de OpenGL más comunes:
- Requisitos de la versión de OpenGL ES: Si tu aplicación requiere una versión específica de OpenGL ES, debes declarar ese requisito. Para ello, agrega la siguiente configuración a tu manifiesto, como se muestra a continuación.
Para OpenGL ES 2.0:
<!-- Tell the system this app requires OpenGL ES 2.0. --> <uses-feature android:glEsVersion="0x00020000" android:required="true" />
Si agregas esta declaración, Google Play restringirá la instalación de tu aplicación en dispositivos que no admitan OpenGL ES 2.0. Si tu aplicación es exclusivamente para dispositivos que admiten OpenGL ES 3.0, también puedes especificarlo en tu manifiesto:
Para OpenGL ES 3.0:
<!-- Tell the system this app requires OpenGL ES 3.0. --> <uses-feature android:glEsVersion="0x00030000" android:required="true" />
Para OpenGL ES 3.1:
<!-- Tell the system this app requires OpenGL ES 3.1. --> <uses-feature android:glEsVersion="0x00030001" android:required="true" />
Para OpenGL ES 3.2:
<!-- Tell the system this app requires OpenGL ES 3.2. --> <uses-feature android:glEsVersion="0x00030002" android:required="true" />
Nota: La API de OpenGL ES 3.x es retrocompatible con la API 2.0, lo que significa que puedes ser más flexible con la implementación de OpenGL ES en tu aplicación. Si declaras la API de OpenGL ES 2.0 como requisito en el manifiesto, puedes usar esa versión de API de forma predeterminada, verificar la disponibilidad de la API 3.x en el tiempo de ejecución y, luego, usar las funciones de OpenGL ES 3.x si el dispositivo lo admite. Para obtener más información sobre cómo comprobar la versión de OpenGL ES compatible con un dispositivo, consulta Cómo averiguar la versión de OpenGL ES.
- Requisitos de compresión de texturas: Si tu aplicación usa formatos de compresión de texturas, debes declarar los formatos que admite en el archivo de manifiesto con
<supports-gl-texture>
. Para obtener más información sobre los formatos de compresión de texturas disponibles, consulta Compatibilidad con la compresión de texturas.Si declaras los requisitos de compresión de texturas en tu manifiesto, se ocultará tu aplicación a los usuarios con dispositivos que no admitan al menos uno de los tipos de compresión declarados. Si deseas obtener más información sobre cómo funciona el filtrado de Google Play para la compresión de texturas, consulta la sección Google Play y el filtrado de compresión de texturas de la documentación de
<supports-gl-texture>
.
Cómo asignar coordenadas para objetos dibujados
Uno de los problemas básicos para mostrar gráficos en dispositivos Android es que sus pantallas pueden variar en tamaño y forma. OpenGL adopta un sistema de coordenadas cuadrado y uniforme y, de forma predeterminada, dibuja esas coordenadas en una pantalla que, por lo general, no es cuadrada, como si fuera perfectamente cuadrada.
![](https://developer.android.com/static/images/opengl/coordinates.png?authuser=5&hl=es)
Figura 1: Sistema de coordenadas predeterminado de OpenGL (izquierda) asignado a la pantalla típica de un dispositivo Android (derecha)
En la ilustración anterior, se muestra el sistema de coordenadas uniforme que se supone para un marco OpenGL (izquierda) y la manera en que estas coordenadas se asignan en realidad a una pantalla típica de dispositivo en orientación horizontal (derecha). Para resolver este problema, puedes aplicar modos de proyección de OpenGL y vistas de cámara a fin de transformar coordenadas de modo que tus objetos gráficos tengan las proporciones correctas en cualquier pantalla.
Para aplicar vistas de cámara y proyección, debes crear una matriz de proyección y una de vista de cámara, y aplicarlas a la canalización de renderización de OpenGL. La matriz de proyección vuelve a calcular las coordenadas de los gráficos para que se asignen correctamente a las pantallas de los dispositivos Android. La matriz de vista de la cámara crea una transformación que renderiza objetos desde una posición específica del ojo.
Proyección y vista de cámara en OpenGL ES 2.0 y versiones posteriores
En las APIs de ES 2.0 y 3.0, puedes aplicar la proyección y la vista de cámara agregando primero un miembro de la matriz a los sombreadores de vértices de tus objetos gráficos. Con este miembro de la matriz agregado, puedes generar y aplicar matrices de proyección y visualización de cámara a tus objetos.
- Agrega la matriz a los sombreadores de vértices: Crea una variable para la matriz de proyección de vistas y, luego, inclúyela como un multiplicador de la posición del sombreador. En el siguiente ejemplo de código de sombreador de vértices, el miembro
uMVPMatrix
incluido te permite aplicar matrices de proyección y visualización de cámara a las coordenadas de los objetos que usan este sombreador.Kotlin
private val vertexShaderCode = // This matrix member variable provides a hook to manipulate // the coordinates of objects that use this vertex shader. "uniform mat4 uMVPMatrix; \n" + "attribute vec4 vPosition; \n" + "void main(){ \n" + // The matrix must be included as part of gl_Position // Note that the uMVPMatrix factor *must be first* in order // for the matrix multiplication product to be correct. " gl_Position = uMVPMatrix * vPosition; \n" + "} \n"
Java
private final String vertexShaderCode = // This matrix member variable provides a hook to manipulate // the coordinates of objects that use this vertex shader. "uniform mat4 uMVPMatrix; \n" + "attribute vec4 vPosition; \n" + "void main(){ \n" + // The matrix must be included as part of gl_Position // Note that the uMVPMatrix factor *must be first* in order // for the matrix multiplication product to be correct. " gl_Position = uMVPMatrix * vPosition; \n" + "} \n";
Nota: En el ejemplo anterior, se define un único miembro de una matriz de transformación en el sombreador de vértices en el que se aplica una matriz de proyección combinada y una matriz de vista de cámara. Según los requisitos de tu aplicación, te recomendamos que definas miembros independientes de la matriz de proyección y de la matriz de visualización de cámara en tus sombreadores de vértices para poder cambiarlos de forma independiente.
- Accede a la matriz del sombreador: Después de crear un hook en los sombreadores de vértices para aplicar la proyección y la vista de cámara, puedes acceder a esa variable a fin de aplicar las matrices de proyección y visualización de cámara. En el siguiente código, se muestra cómo modificar el método
onSurfaceCreated()
de una implementación deGLSurfaceView.Renderer
para acceder a la variable de matriz definida en el sombreador de vértices anterior.Kotlin
override fun onSurfaceCreated(gl: GL10, config: EGLConfig) { ... muMVPMatrixHandle = GLES20.glGetUniformLocation(program, "uMVPMatrix") ... }
Java
public void onSurfaceCreated(GL10 unused, EGLConfig config) { ... muMVPMatrixHandle = GLES20.glGetUniformLocation(program, "uMVPMatrix"); ... }
- Crea matrices de proyección y visualización de cámara: Genera las matrices de proyección y
visualización que se aplicarán a los objetos gráficos. En el siguiente código de ejemplo, se muestra cómo modificar los métodos
onSurfaceCreated()
yonSurfaceChanged()
de una implementación deGLSurfaceView.Renderer
para crear una matriz de vista de cámara y una matriz de proyección según la relación de aspecto de la pantalla del dispositivo.Kotlin
override fun onSurfaceCreated(gl: GL10, config: EGLConfig) { ... // Create a camera view matrix Matrix.setLookAtM(vMatrix, 0, 0f, 0f, -3f, 0f, 0f, 0f, 0f, 1.0f, 0.0f) } override fun onSurfaceChanged(gl: GL10, width: Int, height: Int) { GLES20.glViewport(0, 0, width, height) val ratio: Float = width.toFloat() / height.toFloat() // create a projection matrix from device screen geometry Matrix.frustumM(projMatrix, 0, -ratio, ratio, -1f, 1f, 3f, 7f) }
Java
public void onSurfaceCreated(GL10 unused, EGLConfig config) { ... // Create a camera view matrix Matrix.setLookAtM(vMatrix, 0, 0, 0, -3, 0f, 0f, 0f, 0f, 1.0f, 0.0f); } public void onSurfaceChanged(GL10 unused, int width, int height) { GLES20.glViewport(0, 0, width, height); float ratio = (float) width / height; // create a projection matrix from device screen geometry Matrix.frustumM(projMatrix, 0, -ratio, ratio, -1, 1, 3, 7); }
- Aplica matrices de proyección y de visualización de cámara: Para aplicar las transformaciones de proyección y vista de cámara, multiplica las matrices y, luego, configúralas en el sombreador de vértices. En el siguiente código de ejemplo, se muestra cómo modificar el método
onDrawFrame()
de una implementación deGLSurfaceView.Renderer
para combinar la matriz de proyección y la vista de cámara creada en el código anterior y, luego, aplicarlo a los objetos gráficos que renderizará OpenGL.Kotlin
override fun onDrawFrame(gl: GL10) { ... // Combine the projection and camera view matrices Matrix.multiplyMM(vPMatrix, 0, projMatrix, 0, vMatrix, 0) // Apply the combined projection and camera view transformations GLES20.glUniformMatrix4fv(muMVPMatrixHandle, 1, false, vPMatrix, 0) // Draw objects ... }
Java
public void onDrawFrame(GL10 unused) { ... // Combine the projection and camera view matrices Matrix.multiplyMM(vPMatrix, 0, projMatrix, 0, vMatrix, 0); // Apply the combined projection and camera view transformations GLES20.glUniformMatrix4fv(muMVPMatrixHandle, 1, false, vPMatrix, 0); // Draw objects ... }
Para ver un ejemplo completo de cómo aplicar la proyección y la vista de cámara con OpenGL ES 2.0, consulta la clase Cómo mostrar gráficos con OpenGL ES.
Caras de las formas y devanado
En OpenGL, la cara de una forma es una superficie definida por tres o más puntos en un espacio tridimensional. Un conjunto de tres o más puntos tridimensionales (llamados vértices en OpenGL) tiene una cara frontal y una posterior. ¿Cómo puedes saber cuál es cuál? Buena pregunta. La respuesta tiene que ver con el devanado, o la dirección en la que defines los puntos de una forma.
![Coordenadas en
los vértices de un triángulo](https://developer.android.com/static/images/opengl/ccw-winding.png?authuser=5&hl=es)
Figura 1: Ilustración de una lista de coordenadas que se traduce en un orden de dibujo en sentido antihorario
En este ejemplo, los puntos del triángulo se definen en un orden tal que se dibujan en sentido antihorario. El orden en el que se dibujan estas coordenadas define la dirección del devanado de la forma. De forma predeterminada, en OpenGL, la cara que se dibuja en sentido antihorario es la cara frontal. El triángulo que se muestra en la Figura 1 se define de modo que mires la cara frontal de la forma (según la interpretación de OpenGL) y el otro lado sea la cara posterior.
¿Por qué es importante saber cuál es la cara frontal de una forma? La respuesta tiene que ver con una función de OpenGL que se usa a menudo y se llama eliminación de caras. La eliminación de caras es una opción para el entorno de OpenGL que permite que la canalización de renderización ignore (no calcule ni dibuje) la cara posterior de una forma, lo que ahorra tiempo, memoria y ciclos de procesamiento:
Kotlin
gl.apply { // enable face culling feature glEnable(GL10.GL_CULL_FACE) // specify which faces to not draw glCullFace(GL10.GL_BACK) }
Java
// enable face culling feature gl.glEnable(GL10.GL_CULL_FACE); // specify which faces to not draw gl.glCullFace(GL10.GL_BACK);
Si intentas usar la función de eliminación de rostros sin saber qué lados de tus formas están al frente y atrás, tus gráficos de OpenGL se verán un poco delgados o posiblemente no se mostrarán. Por lo tanto, siempre define las coordenadas de tus formas de OpenGL en un orden de dibujo en sentido antihorario.
Nota: Es posible configurar un entorno de OpenGL para tratar la cara de las manecillas del reloj como la cara frontal, pero hacerlo requiere más código y es probable que confunda a los desarrolladores experimentados de OpenGL cuando les pidas ayuda. Te recomendamos que no lo hagas.
Versiones de OpenGL y compatibilidad de dispositivos
Las especificaciones de la API de OpenGL ES 1.0 y 1.1 son compatibles desde Android 1.0. La programación de gráficos con la API de OpenGL ES 1.0/1.1 es muy diferente a usar la versión 2.0 y versiones posteriores. OpenGL ES 2.0 es compatible con todos los dispositivos Android a partir de Android 2.2 (nivel de API 8) y es la versión más antigua recomendada para aplicaciones nuevas que se desarrollan con OpenGL ES. OpenGL ES 3.0 es compatible con Android 4.3 (nivel de API 18) y versiones posteriores en dispositivos que proporcionan una implementación de la API de OpenGL ES 3.0. Para obtener información sobre la cantidad relativa de dispositivos con Android que admiten una versión determinada de OpenGL ES, consulta el panel de versiones de OpenGL ES.
Debes considerar cuidadosamente los requisitos gráficos y elegir la versión de la API que funcione mejor para tu aplicación. Para obtener más información, consulta Cómo elegir una versión de la API de OpenGL.
La API de OpenGL ES 3.0 proporciona funciones adicionales y un mejor rendimiento que la API 2.0 y también es retrocompatible. Esto significa que puedes escribir tu aplicación orientada a OpenGL ES 2.0 e incluir condicionalmente funciones de gráficos de OpenGL ES 3.0 si están disponibles. Para obtener más información sobre cómo verificar la disponibilidad de la API 3.0, consulta Cómo averiguar la versión de OpenGL ES.
Compatibilidad con la compresión de texturas
La compresión de texturas puede aumentar significativamente el rendimiento de tu aplicación de OpenGL, ya que reduce los requisitos de memoria y hace un uso más eficiente del ancho de banda de la memoria. El framework de Android proporciona compatibilidad con el formato de compresión ETC1 como función estándar, incluida una clase de utilidad ETC1Util
y la herramienta de compresión etc1tool
(ubicada en el SDK de Android en <sdk>/tools/
). Para ver un ejemplo de una aplicación para Android que usa compresión de texturas, consulta la muestra de código CompressedTextureActivity
en el SDK de Android (<sdk>/samples/<version>/ApiDemos/src/com/example/android/apis/graphics/
).
El formato ETC1 es compatible con todos los dispositivos Android que admiten OpenGL ES 2.0 o versiones posteriores.
Nota: El formato de compresión de texturas ETC1 no admite texturas con una transparencia (canal alfa). Si tu aplicación requiere texturas transparentes, debes investigar otros formatos de compresión de texturas disponibles en tus dispositivos de destino. Un método para renderizar texturas de canales alfa con ETC1 es vincular dos objetos de textura ETC1: el primero con datos de color, el segundo con datos del canal alfa y, luego, combinar los valores de las dos texturas en el sombreador de fragmentos.
Se garantiza que los formatos de compresión de texturas ETC2/EAC estarán disponibles cuando se use la API de OpenGL ES 3.0. Este formato de textura ofrece excelentes relaciones de compresión con alta calidad visual y el formato también admite la transparencia (canal alfa).
Más allá de los formatos ETC, los dispositivos Android tienen una compatibilidad variada con la compresión de texturas en función de sus chipsets de GPU y sus implementaciones de OpenGL. Debes investigar la compatibilidad con la compresión de texturas en los dispositivos a los que te orientas para determinar qué tipos de compresión debe admitir tu aplicación. Para determinar qué formatos de texturas son compatibles con un dispositivo determinado, debes consultar el dispositivo y revisar los nombres de extensión OpenGL, que identifican qué formatos de compresión de texturas (y otras funciones de OpenGL) son compatibles con el dispositivo. Estos son algunos formatos de compresión de texturas que se suelen admitir:
- Compresión de textura escalable y adaptable (ASTC): Es un formato de compresión de texturas diseñado para sustituir a los formatos anteriores. Es más flexible que los formatos anteriores debido a la compatibilidad con varios tamaños de bloque.
GL_KHR_texture_compression_astc_ldr
GL_KHR_texture_compression_astc_hdr
(alto rango dinámico)
- S3TC (DXTn/DXTC): La compresión de texturas S3 (S3TC) tiene diferentes
variaciones de formato (DXT1 a DXT5) y su disponibilidad no es tan amplia. El formato admite texturas RGB con
canales alfa de 4 bits o de 8 bits. Estos formatos se representan con el siguiente nombre de extensión de
OpenGL:
GL_EXT_texture_compression_s3tc
GL_EXT_texture_compression_dxt1
Los siguientes formatos de compresión de texturas se consideran formatos heredados y no se recomiendan para su uso en aplicaciones nuevas:
- ATITC (ATC): La compresión de texturas ATI (ATITC o ATC) está disponible en una amplia variedad de dispositivos y admite la compresión a una velocidad fija para texturas RGB con y sin un canal alfa. Este formato se puede representar con varios nombres de extensión de OpenGL, por ejemplo:
GL_AMD_compressed_ATC_texture
GL_ATI_texture_compression_atitc
- PVRTC: La compresión de texturas PowerVR (PVRTC) está disponible en una amplia variedad de dispositivos y admite texturas de 2 bits y 4 bits por píxel con o sin un canal alfa.
Este formato se representa con el siguiente nombre de extensión de OpenGL:
GL_IMG_texture_compression_pvrtc
- 3DC: La compresión de texturas 3DC (3DC) es un formato menos disponible que admite texturas RGB con un canal alfa. Este formato se representa con el siguiente nombre de extensión de OpenGL:
GL_AMD_compressed_3DC_texture
Advertencia: Estos formatos de compresión de texturas no son compatibles con todos los dispositivos. La compatibilidad con estos formatos puede variar según el fabricante y el dispositivo. Si quieres obtener información para determinar qué formatos de compresión de texturas tienen un dispositivo en particular, consulta la siguiente sección.
Nota: Una vez que decidas qué formatos de compresión de texturas admitirá tu aplicación, asegúrate de declararlos en tu manifiesto con <supports-gl-texture> . El uso de esta declaración permite filtrar por servicios externos, como Google Play, de modo que tu app se instale solo en dispositivos compatibles con los formatos que requiera. Para obtener más información, consulta Declaraciones de manifiesto de OpenGL.
Cómo determinar las extensiones de OpenGL
Las implementaciones de OpenGL varían según el dispositivo Android en términos de las extensiones de la API de OpenGL ES compatibles. Estas extensiones incluyen las compresiones de texturas, pero también suelen incluir otras extensiones del conjunto de atributos de OpenGL.
Para determinar qué formatos de compresión de texturas y otras extensiones de OpenGL son compatibles con un dispositivo en particular, haz lo siguiente:
- Ejecuta el siguiente código en tus dispositivos de destino para determinar qué formatos de compresión de texturas
son compatibles:
Kotlin
var extensions = gl.glGetString(GL10.GL_EXTENSIONS)
Java
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
Advertencia: Los resultados de esta llamada varían según el modelo del dispositivo. Debes ejecutar esta llamada en varios dispositivos de destino para determinar qué tipos de compresión se admiten comúnmente.
- Revisa el resultado de este método para determinar qué extensiones de OpenGL son compatibles con el dispositivo.
Paquete de extensiones de Android (AEP)
El AEP garantiza que tu aplicación admita un conjunto estandarizado de extensiones de OpenGL más allá del conjunto principal descrito en la especificación de OpenGL 3.1. Empaquetar estas extensiones fomenta un conjunto coherente de funcionalidades en todos los dispositivos y permite a los desarrolladores aprovechar al máximo la última generación de GPU para dispositivos móviles.
El AEP también mejora la compatibilidad con imágenes, búferes de almacenamiento de sombreadores y contadores atómicos en sombreadores de fragmentos.
Para que tu app pueda usar el AEP, su manifiesto debe declarar que se requiere el AEP. Además, la versión de la plataforma debe ser compatible.
Todas las funciones adicionales especificadas en el AEP se incluyen en la especificación básica de OpenGL ES 3.2. Si tu app requiere OpenGL ES 3.2, no necesitas el AEP.
Sigue estos pasos para declarar que se requiere el AEP en el manifiesto:
<uses-feature android:name="android.hardware.opengles.aep" android:required="true" />
Para verificar que la versión de la plataforma sea compatible con el AEP, usa el método hasSystemFeature(String)
y pasa FEATURE_OPENGLES_EXTENSION_PACK
como argumento. En el siguiente fragmento de código, se muestra un ejemplo de cómo hacerlo:
Kotlin
var deviceSupportsAEP: Boolean = packageManager.hasSystemFeature(PackageManager.FEATURE_OPENGLES_EXTENSION_PACK)
Java
boolean deviceSupportsAEP = getPackageManager().hasSystemFeature (PackageManager.FEATURE_OPENGLES_EXTENSION_PACK);
Si el método muestra el valor true, el AEP es compatible.
Para obtener más información sobre el AEP, visita su página en el registro de OpenGL ES de Khronos.
Cómo averiguar la versión de OpenGL ES
Hay varias versiones de OpenGL ES disponibles en los dispositivos Android. Puedes especificar la versión mínima de la API que requiere tu aplicación en el manifiesto, pero, al mismo tiempo, también puedes aprovechar las funciones de una API más nueva. Por ejemplo, la API de OpenGL ES 3.0 es retrocompatible con la versión 2.0 de la API, por lo que es posible que quieras escribir tu aplicación de modo que use las funciones de OpenGL ES 3.0, pero recurra a la API 2.0 si la API 3.0 no está disponible.
Antes de usar las funciones de OpenGL ES desde una versión posterior a la mínima requerida en el manifiesto de tu aplicación, esta debe verificar la versión de la API disponible en el dispositivo. Para eso, puedes usar uno de estos métodos:
- Intenta crear el contexto de OpenGL ES de nivel superior (
EGLContext
) y verifica el resultado. - Crea un contexto de OpenGL ES con compatibilidad mínima y comprueba el valor de la versión.
En el siguiente código de ejemplo, se muestra cómo verificar la versión de OpenGL ES disponible creando un EGLContext
y verificando el resultado. En este ejemplo, se muestra cómo comprobar la versión de OpenGL ES 3.0:
Kotlin
private const val EGL_CONTEXT_CLIENT_VERSION = 0x3098 private const val glVersion = 3.0 private class ContextFactory : GLSurfaceView.EGLContextFactory { override fun createContext(egl: EGL10, display: EGLDisplay, eglConfig: EGLConfig): EGLContext { Log.w(TAG, "creating OpenGL ES $glVersion context") return egl.eglCreateContext( display, eglConfig, EGL10.EGL_NO_CONTEXT, intArrayOf(EGL_CONTEXT_CLIENT_VERSION, glVersion.toInt(), EGL10.EGL_NONE) ) // returns null if 3.0 is not supported } }
Java
private static double glVersion = 3.0; private static class ContextFactory implements GLSurfaceView.EGLContextFactory { private static int EGL_CONTEXT_CLIENT_VERSION = 0x3098; public EGLContext createContext( EGL10 egl, EGLDisplay display, EGLConfig eglConfig) { Log.w(TAG, "creating OpenGL ES " + glVersion + " context"); int[] attrib_list = {EGL_CONTEXT_CLIENT_VERSION, (int) glVersion, EGL10.EGL_NONE }; // attempt to create a OpenGL ES 3.0 context EGLContext context = egl.eglCreateContext( display, eglConfig, EGL10.EGL_NO_CONTEXT, attrib_list); return context; // returns null if 3.0 is not supported; } }
Si el método createContext()
que se muestra arriba muestra un valor nulo, tu código debe crear un contexto de OpenGL ES 2.0 y volver a usar solo esa API.
En el siguiente ejemplo de código, se muestra cómo verificar la versión de OpenGL ES creando primero un contexto mínimo compatible y luego verificando la cadena de la versión:
Kotlin
// Create a minimum supported OpenGL ES context, then check: gl.glGetString(GL10.GL_VERSION).also { Log.w(TAG, "Version: $it") } // The version format is displayed as: "OpenGL ES <major>.<minor>" // followed by optional content provided by the implementation.
Java
// Create a minimum supported OpenGL ES context, then check: String version = gl.glGetString(GL10.GL_VERSION); Log.w(TAG, "Version: " + version ); // The version format is displayed as: "OpenGL ES <major>.<minor>" // followed by optional content provided by the implementation.
Con este enfoque, si descubres que el dispositivo admite una versión de API de nivel superior, debes destruir el contexto mínimo de OpenGL ES y crear un contexto nuevo con la versión de API más alta disponible.
Cómo elegir una versión de la API de OpenGL
La versión 2.0 y la versión 3.0 de OpenGL ES proporcionan interfaces de gráficos de alto rendimiento para crear juegos, visualizaciones e interfaces de usuario en 3D. La programación de gráficos para OpenGL ES 2.0 y 3.0 es muy similar, y la versión 3.0 representa un superconjunto de la API 2.0 con funciones adicionales. La programación de la API de OpenGL ES 1.0/1.1 en comparación con OpenGL ES 2.0 y 3.0 difiere significativamente y no se recomienda para aplicaciones nuevas. Los desarrolladores deben considerar cuidadosamente los siguientes factores antes de comenzar a desarrollar con estas APIs:
- Compatibilidad del dispositivo: Los desarrolladores deben tener en cuenta los tipos de dispositivos, las versiones de Android y las versiones de OpenGL ES disponibles para sus clientes. Para obtener más información sobre la compatibilidad de OpenGL en los dispositivos, consulta la sección Versiones de OpenGL y compatibilidad de dispositivos.
- Compatibilidad con texturas: La API de OpenGL ES 3.0 es la mejor compatibilidad con la compresión de texturas, ya que garantiza la disponibilidad del formato de compresión ETC2, que admite la transparencia. Las implementaciones de la API 2.0 incluyen compatibilidad con ETC1; sin embargo, este formato de textura no admite la transparencia. Para implementar la transparencia con texturas comprimidas, debes usar dos texturas ETC1 (divididas entre color y alfa) o proporcionar recursos en otros formatos de compresión compatibles con los dispositivos a los que te orientas. Para obtener más información, consulta Compatibilidad con la compresión de texturas.
Si bien la compatibilidad y la compatibilidad de texturas pueden influir en tu decisión, debes elegir una versión de la API de OpenGL en función de lo que creas que proporciona la mejor experiencia a tus usuarios.