Cambios y nuevo destino!
Buenas a tod@s! Más vale tarde que nunca. Han sido meses complicados, nuevamente cambios de trabajo y familia han impedido invertir más que unas pocas horas semanales a este proyecto personal.
No obstante, hay grandes cambios que anunciar al respecto, ya que tenía muchos commits acumulados en 2023 de ideas y propósitos que me ayudarían a ejecutar con éxito Project DarkHeaZ y se habían retrasando por falta de tiempo. Vamos a hacer un pequeño repaso de los cambios más destacados para los que siguieran la evolución del código en GitHub:
- Abrazamos OpenGL4 en lugar de nuestro propio render (si, renunciamos a nuestros orígenes xD)
- Incluimos el concepto de escena, con su persistencia y carga.
- Incorporamos LUA como lenguaje de scripting
- Utilizaremos ImGui en su versión docking para la GUI del IDE.
1) OpenGL4
Quizás el cambio más significativo en lo relativo al código. Tras discutirlo con varias personas, y enfrentarme a inmumerables problemas (que realmente iban solucionándose adecuadamente), te das cuenta que estás tú sólo reinventando la rueda, lo cual es divertido, pero no si tienes prisa y ya has satisfecho la cuota de aprendizaje. Por tanto y tras varios experimentos, decidí migrar el código a OpenGL4. Gracias a la simplicidad del diseño y a una buena organización de objetos, en apenas un més esto estaba satisfecho. Toda la funcionalidad transcrita a OpenGL, realmente supuso eliminar casi un 50% del código general del proyecto, ya que nos evitamos realizar decenas de tareas (clipping, etc). Además eliminamos toda la capa de OpenCL que ya disponíamos, al dejar de ser necesaria.
Había supuesto renunciar a los orígenes, pero ya estaba subido a un carro que me permitía al menos, reutilizar shaders hechos por la comunidad, además de un incremento lógico en performance. Desde un principio supe que un pipeline absolutamente programado, por mucha GPU que utilizase, sería menos eficiente (hay papers de NVidia que lo demustran), pero el reto en aquel momento era ese. Daros cuenta que hay algoritmoso chipeados directamente (stages completas con las que no puedes competir) por lo que la ganancia era esperada.
2) Incluimos el concepto de escena, con su persistencia y carga.
Bien, te has currado un motor 3D en C++, puedes mover, rotar, escalar, etc etc. Incluso tienes un primitivo concepto de escena que has preparado para tu juego…sin embargo… jaque! Terminarás colgándote de una soga, cansado de compilar tu aplicación para probar las mil y una settings que necesitarás ajustar. Intentarás crear soluciones intermedias (léase ir añadiendo propiedades hardcodeadas en código) que te permitirán ahorrarte la compilación, pero … jaque de nuevo….requerirán reiniciar el juego…
Es fácil entrar en una espiral antiproductiva. Por eso decidimos rápidamente y antes de enfrentarnos a estos problemas de disponer de una flexible y estable capacidad de guardar y recuperar escenas, al fin y al cabo es un concepto muy utilizado en muchos motores, no es casualidad. Podremos utilizar este nuevo marco de escena en multitud de escenarios (cada nivel del juego será una escena, el menú será una escena… etc)
3) Incorporamos LUA como lenguaje de scripting
Con un argumentario muy similar al punto anterior. Necesitarás poder dotar de comportamientos absolutamente a medida objetos en tu pantalla. Aunque es cierto que puedes “hardcodear” en C++, todo esto, salvo que tengas las ideas muy claras desde el principio, te verás compilando tu aplicación infinidad de veces nuevamente.
Incorporar un sistema de scripting sobre el motor, para que sea capaz de acceder a todas las funcionalidades de la API supone matar dos pájaros de un tiro. Dejas al developer la capacidad (y responsabilidad) de gestionar sus propios objetos en un entorno de ejecución virtual (la máquina virtual de LUA) y por otro lado ganas una capacidad de reutilización gigantesca al poder reutilizar los scripts que ya dispones en otros objetos.
Esto sumado a la capacidad de ‘attachar’ scripts al vuelo, sin reiniciar el motor supone un incremento en el flujo de trabajo brutal. Explicaremos este sistema en su propio artículo próximamente.
4) Utilizaremos ImGui en su versión docking para la GUI del IDE
Este punto se explica muy fácil. Es sencillamente genial, se ajusta perfectamente a las necesidades del engine, aunque no se corresponde con la rama oficial, tras probarlo durante semanas me ha parecido suficientemente estable.
La cantidad de opciones que empieza a tener el motor son grandes y necesitamos un sistema extensible y sencillo para ir extendiéndolo. ImGui me sigue pareciendo una opción genial para este tipo de proyectos.
Resumen
Brakeza3D deja de ser un motor que se preocupe por hacer a mano todas las funcionalidades gráficas, para adoptar OpenGL, pero ganará peso como un sencillo y extensible IDE de trabajo para crear videojuegos 3D.