Epopeia Demosystem 1.2: El sistema

Esta es la segunda parte de una serie de tres sobre el sistema de demos Epopeia de rgba. En esta parte tratamos de explicar qué hace el sistema de demos y cómo funciona.

Cómo funciona el sistema

En la figura 1 podéis ver un diagrama de la organización lógica del sistema, con algunos submódulos. Los elementos principales son los siguientes:

1. El sistema de demos (Epopeia)
2. Plugins
3. Script de la demo
4. El programa principal

Veremos cada componente por separado.

El sistema de demos

Figura 1. Esquema general de Epopeia demosystem 1.2

El objetivo final del demosys es ofrecer un entorno de ejecución para la demo.

Este entorno de ejecución debe tener una interfaz exterior lo más independiente posible de la plataforma y sistema operativo. Todo aquello que pueda depender de la plataforma debería ser abstraido por el sistema y todo aquello que construyamos sobre el mismo debe ser independiente de plataforma, bien en su forma final (el script) o a nivel de código fuente (plugins).

También es muy importante que el sistema sea su vez genérico y flexible. No es deseable que se presuman cosas (uso de OpenGL, ...) y tampoco que la forma de hacer las cosas limite lo que se pueda hacer en los plugins o en el script, cercenando el resultado final: la demo.

A nivel de almacenamiento "físico" cada una de las partes se guarda como un archivo: hay un archivo por cada plugin y plataforma, un archivo para el script, uno para el sistema de demos (una librería dinámica, veremos las razones en el apartado de plugins) y otro para el programa principal (el ejecutable).

Internamente, el demosystem tiene varios subsistemas o módulos:

• Subsistema gráfico: se encarga de inicializar el modo/la ventana gráfica con las propiedades indicadas. En nuestro caso concreto, crea una ventana OpenGL de las dimensiones elegidas en el menu de inicio y establece el modo de pantalla completa si asi se le indica. Cada vez que acabemos de pintar un frame se lo indicaremos para que lo muestre en pantalla.
• Subsistema de sonido: se encarga de reproducir la música (módulo u ogg) y de proveer de timers de sincronización.. Para la sincronización de ejecución de los comandos usa el timer dado por el Fmod. Para el resto de acciones o animación de parametros usa un timer del sistema.
• Subsistema de teclado/interacción: está bastante ligado al subsistema gráfico y provee del control de teclas especiales; ESC para salir de la demo y otras teclas especiales de ayuda durante el montaje de la demo.
• Módulo compilador: interpreta el script y lo traduce a un formato interno.
• Módulo intéprete de runtime: ejecuta la demo leyendo del formato interno que ha generado el compilador.
• Módulo de carga de plugins: carga los plugins que añaden al sistema la capacidad de hacer "cualquier" cosa.

Plugins

Gracias a los plugins el sistema de demos es capaz de realizar cosas que ni hubiesemos sospechado que pudiese hacer durante el diseño del mismo.

Puesto que el sistema de demos solo es capaz de realizar tareas fundamentales como reproducir música, controlar el teclado o inicializar y volcar frames a pantalla, necesitamos una forma de "enseñarle" a hacer cosas más interesantes (fundamentalmente efectos gráficos, aunque no exclusivamente): desde un simple limpiado de pantalla a color negro hasta la carga de una animación 3D con texturas, cámaras, ... y su posterior renderización. Para esto usamos los plugins.

Un plugin de Epopeia es una librería de enlace dinámico (.DLL en win32 o .so en unix) con unos puntos de entrada predefinidos. Si tenéis alguna demo de rgba desempaquetada veréis que hay archivos .epl (plugin win32) y .epx (plugin Linux).

Cada uno de los plugins se enlaza con la librería dinámica del demosystem para que tenga acceso a la API del mismo. Cuando el sistema carga un plugin, realiza algunas llamadas a través de los puntos de entrada del plugin; este a su vez, usando el API de Epopeia introduce las extensiones contenidas en el plugin en el entorno de ejecución de la demo.

Un plugin puede realizar una o varias de las siguientes tareas:

• Introducir nuevos tipos de efectos en el sistema. Por ejemplo un efecto fuego. Los efectos los referenciaremos como clases en el script.
• Introducir nuevas funciones en el sistema para poder usarlos en el script. Por ejemplo la función trigonométrica sin().

El script de la demo

El script es la pieza central de la demo. En el indicamos cuando deben empezar los efectos y cuando acaban; cual es el orden de renderización de los efectos; cuales son los parámetros de cada efecto como texturas, colores, trayectorias o velocidades; cuando se deben cargar cosas desde el disco duro, etc.

El script lo que nos permite es parametrizar acciones que modificarán el estado de ejecución del sistema de demos. Al principio el sistema consta de:

• Una lista temporizada de comandos vacía
• Una lista de efectos vacía
• Una lista ordenada de efectos a renderizar vacía (lista de renderizado)
• Una música pausada en el segundo 0

A través del script, podemos ir dando de alta comandos temporizados. Un comando temporizado simplemente es una acción que se ejecutará en un momento concreto, por ejemplo en el segundo 5 de la canción.

Cuando el sistema de demos compile y traduzca el script, lanzará el intérprete que se encargará de reproducir la demo hasta el final.

La mejor manera de entender cómo funciona el script es con un ejemplo:

Inicialización

Fondo fondo_negro();

Esa sentencia del script lo que hace es crear un objeto/efecto llamado fondo_negro e introducirlo a la lista de efectos. Para ello, un plugin han tenido que dar de alta la clase de efecto Fondo, sino tendríamos un error de compilación. En este momento se harán las cargas necesarias del disco, así como precálculos y demás.

Mostrar un efecto

At(0.0);
	fondo_negro.Start(1000);

Ahora lo que hacemos es indicar que en el segundo 0.0, el efecto fondo_negro debe comenzar, o lo que es lo mismo, pasar a la lista de renderizado, con una profundidad de 1000. El sistema renderiza los efectos desde el fondo a la superficie, de forma que cuanta mayor sea la profundidad antes renderizará ese efecto, y por lo tanto más oculto quedará en la imagen final, puesto que habrá efectos que se rendericen encima suyo.

Dejar de mostrar un efecto

At(300.0);
	fondo_negro.Stop();

Esto indicaría que en el segundo 300 se debe dejar de renderizar el efecto fondo_negro, quitándolo de la lista de renderido.

Tras leer los comandos anteriores, el compilador habrá generado una lista de comandos con 3 elementos, el primero se ejecutará antes del segundo 0, el segundo en el 0 y el tercero en el 300.

El ejecutable

Finalmente, el programa ejecutable de la demo se encarga de preparar toda la base. El menu de inicio de las demos no está incluido en el sistema demos, sino que se pone en el ejecutable. El ejecutable se enlaza con la librería dinámica del demosystem y transmite los parámetros de inicio a través de la API del demosys.

El ejecutable también inicializa algunos otros elementos, como el sistema de empaquetamiento de ficheros, etc.

---

En el próximo y último capitulo, veremos cómo funciona internamente el sistema de demos. Veremos más en detalle el compilador y el intérprete con sus capacidades, y cómo se implementan para obtener la máxima flexibilidad.