Estoy escribiendo un renderizador multiplataforma. Quiero usarlo en Windows, Linux, Android, iOS.Render multiplataforma en OpenGL ES
¿Cree que es una buena idea evitar la abstracción absoluta y escribirla directamente en OpenGL ES 2.0?
Por lo que sé, debería ser capaz de compilarlo en PC con OpenGL estándar, con solo un pequeño cambio en el código que maneja el contexto y la conexión al sistema de ventanas.
¿Cree que es una buena idea evitar la abstracción absoluta y escribirla directamente en OpenGL ES 2.0?
Sus principales dificultades con esto serán las partes de la especificación ES 2.0 que en realidad no son las mismas que OpenGL 2.1.
Por ejemplo, simplemente no puede empujar sombreadores ES 2.0 a través de un compilador GLSL 1.20 de escritorio. En ES 2.0, utilizas cosas como especificar la precisión; esos son constructos ilegales en GLSL 1.20.
puede sin embargo #define alrededor de ellos, pero esto requiere un poco de intervención manual. Deberá insertar un #ifdef en el archivo fuente del sombreado. Hay trucos de compilación de sombreadores que puede hacer para que esto sea un poco más fácil.
De hecho, debido a que GL ES utiliza un conjunto completamente diferente de extensiones (aunque algunas son espejos y subconjuntos de extensiones GL de escritorio), es posible que desee hacerlo.
Todos los sombreadores GLSL (de escritorio o ES) deben tener un "preámbulo". La primera cosa sin comentarios en un sombreador debe ser una declaración #version. Afortunadamente para ti, la versión es la misma entre el escritorio GL 2.1 y GL ES 2.0: #version 1.20. El problema es qué sigue: la lista #extension (si corresponde). Esto habilita las extensiones necesarias para el sombreador.
Dado que GL ES utiliza diferentes extensiones desde el escritorio GL, necesitará cambiar esta lista de extensiones. Y dado que las probabilidades son buenas, necesitará más extensiones GLSL ES que las extensiones de desktop GL 2.1, estas listas no serán solo correlaciones 1: 1, sino listas completamente diferentes.
Mi sugerencia es emplear la capacidad de dar a los sombreadores GLSL varias cadenas. Es decir, sus archivos de shader reales no incluyen ningún elemento de preámbulo. Ellos solo tienen las definiciones y funciones reales. El cuerpo principal del sombreador.
Cuando se ejecuta en GL ES, tiene un preámbulo global que colocará en el comienzo del sombreador. Tendrás un preámbulo global diferente en el escritorio GL. El código se vería así:
GLuint shader = glCreateShader(/*shader type*/);
const char *shaderList[2];
shaderList[0] = GetGlobalPreambleString(); //Gets preamble for the right platform
shaderList[1] = LoadShaderFile(); //Get the actual shader file
glShaderSource(shader, 2, shaderList, NULL);
El preámbulo puede también incluir una plataforma específica #define. Definido por el usuario por supuesto. De esta forma, puede #ifdef codificar para diferentes plataformas.
Existen otras diferencias entre los dos. Por ejemplo, mientras que la función de carga de textura de ES 2.0 válida llama a , funciona bien en el escritorio GL 2.1, no necesariamente será óptima. Las cosas que se cargarían bien en las máquinas de Big-Endian, como todos los sistemas móviles, requerirán algunas sacudidas del controlador en las máquinas de escritorio little-endian. Por lo que es posible que desee tener una forma de especificar diferentes parámetros de transferencia de píxeles en GL ES y desktop GL.
Además, existen diferentes conjuntos de extensiones en ES 2.0 y desktop GL 2.1 que usted querrá aprovechar. Si bien muchos de ellos intentan reflejar el uno al otro (OES_framebuffer_object es un subconjunto de EXT_framebuffer_object), puede encontrarse con problemas similares "no del todo subconjunto" como los mencionados anteriormente.
Gracias por su respuesta exhaustiva.¿Entonces crees que será mejor crear algún tipo de abstracción de renderizador OpenGL? Por ejemplo, puedo tener una textura representada por la clase Texture2D. Esta clase contendría cosas comunes a ambas especificaciones, pero la implementación de algunas cosas sería diferente. – runnydead
@hubrobin: No necesita ser tan abstracto. Solo necesita un código específico de plataforma en lugares específicos. Ahora, si tiene como objetivo GL 3.3 en lugar de 2.1, entonces necesitará mucha más abstracción. –
No quiero admitir más funciones en la PC. Entonces, ¿básicamente estás diciendo que es factible? – runnydead
En mi humilde experiencia, el mejor enfoque para este tipo de requisitos es desarrollar su motor en un sabor C puro, sin capas adicionales en él.
Soy el desarrollador principal del motor PATRIA 3D, que se basa en el principio básico que acabamos de mencionar en términos de portabilidad y lo hemos logrado desarrollando la herramienta en bibliotecas estándar básicas.
El esfuerzo para compilar su código y luego en las diferentes plataformas es muy mínimo.
El esfuerzo real para portar toda la solución se puede calcular en función de los componentes que desee incorporar a su motor.
Por ejemplo:
Estándar C:
motor 3D
juego de lógica
juego AI
Física
+
interfaz de ventana (GLUT, EGL, etc) - depende de la plataforma, de todos modos podría ser GLUT para el escritorio y EGL para dispositivos móviles.
de interfaz humana - depende de la portabilidad, Java para Android, OC para iOS, sea cual sea la versión de escritorio
gerentede sonido - depende de los portar
Los servicios de mercado - depende de la
portarDe esta manera, puede reutilizar el 95% de sus esfuerzos de forma transparente.
hemos adoptado esta solución para nuestro motor y hasta ahora realmente vale la pena la inversión inicial.
¿Has escuchado a Kivy? Es un lenguaje de programación multiplataforma de código abierto para Linux, Windows, MacOSX, Android e IOS que representa todas sus vistas en OpenGL (http://kivy.org). El lenguaje también incluye su propio kit de herramientas de widgets. Solo pensé en tirar eso porque existe la posibilidad de que no quieras reinventar la rueda si ya existe una solución y quizás aún no la hayas descubierto. – trusktr
Si tiene Android o iOS, intente buscar "Kivy" en Play Store o App Store para ver ejemplos de su uso. – trusktr