EPOPEIA Demosystem v1.2
enlar/rgba
Copyright Eneko Lacunza 2004. Se publica este documento al dominio público, permitiendo su copia, distribución y modificación libre.
Los objetivos del sistema son los siguientes:
La motivación principal para crear el sistema fue principalmente el 1º, aunque el 2º punto es muy interesante. La idea es conseguir que la creación de efectos e infraestructura para una demo sea lo más industrial posible.
Cuando se crea un efecto, éste pasa por diferentes estados, algunos de los cuales pueden ser:
Las diferencias entre versiones o estados del mismo efecto pueden consistir en varios elementos:
Debemos tratar de simplificar y aislar los efectos de estos problemas, de forma que desde el primer estado de prueba de concepto, sea posible incorporar el efecto en cualquier estado de la cadena con el mínimo esfuerzo posible, donde idealmente el paso sea automático y exento de trabajo.
Por último, aislar los efectos y el montaje de la demo de la plataforma de ejecución permitirá que la demo se pueda portar fácilmente y que se pueda colaborar mejor entre el equipo de desarollo de las producciones, especialmente si en el equipo hay individuos que usan diferentes sistemas.
El sueño de todo coder es tener algo para que los grafistas de su grupo puedan trasladar a la pantalla lo que tienen en mente sin que uno tenga que estar a su lado cambiando líneas de código y recompilando cada detalle.
Para esto hace falta un sistema con el que el diseñador pueda dirigir la demo de la manera más sencilla y potente posible.
La sencillez podría incluir elementos como que el diseñador no tenga que saber C, C++ o el lenguaje elegido para la programación de la demo; que no tenga que saber recompilar fuentes; que no necesite un entorno de desarrollo (ni compilador...) instalado; que el montaje se haga de forma gráfica; que se pueda añadir funcionalidad y efectos al sistema mediante plugins separados que los coders puedan preparar independientemente; etc.
Respecto a la potencia, los elementos a considerar son la posibilidad de extender el sistema sin cambiar (compilar) el núcleo, máxima sencillez para un mínimo de problemas, posibilidad infinita de amplización de efectos, capacidad de control total sobre la secuencia y montaje de partes de la demo, etc.
Las primeras decisiones a la hora de empezar a implementar Epopeia fueron las siguientes:
Para evitar errores y trabajo en el proceso de desarollo e inclusión final de efectos y otros elementos como motores 3D, es necesario que desde el principio consideremos estos efectos como unidades independientes, bloques con los que podemos construir demos, como si de ladrillos se tratara.
Para conseguir esto, el sistema de demos debe tener un sistema de plugins mediante el cual podamos enchufar los bloques al sistema para hacer la demo.
Al crear un efecto, lo creamos directamente como plugin y hacemos las pruebas mediante un script del demosystem mínimo que demuestre las posibilidades del efecto y permita comprobar fallos y corregirlos. Esto permite pulir el efecto, a la vez que podemos enseñarlo al resto del equipo de desarrollo y adicionalmente, estos pueden directamente irlo incorporando en la producción sin más esfuerzo que incluir el código script necesario para parametrizar cuando comienza, acaba, etc. y añadir el fichero de plugin.
De esta forma, ¡tenemos un efecto que, desde el primer momento de su creación, es posible incorporar a una producción sin compilar ni modificar ni una línea de código, ni necesita ninguna otra ayuda de un coder!
Debemos aislar lo máximo posible el control del entorno de ejecución de lo que verdaramente es la demo. Para conseguirlo, debemos aislar lo mejor posible:
En nuestro caso, se opta por adoptar OpenGL como el sistema gráfico estándar, de forma que la inicialización del entorno de renderización corre a cargo del sistema de demos, y los efectos pintan usando comandos OpenGL. También hay infraestructura para usar framebuffer (apenas testeada o usada).
El sistema de sonido se aisla de forma que solo se indica el fichero de música y cuando empieza y acaba.
El sistema asimismo provee del timing necesario a los efectos de 2 formas diferentes, dependiendo de la necesidad de precisión y granularidad requerida para la sincronización y movimiento.
Por último, el sistema se encarga de gestionar las llamadas de interfaz de usuario (tecla ESC, teclas auxiliares para avance, etc. durante el montaje) de forma que los efectos no tienen que controlar nada. No queremos bucles while(!key_pressed()) nunca más! :)