Tras dos días agotadores, voy a hacer un pequeño post resumen de lo que he aprendido en el cursillo hasta el momento.

Para empezar me reafirmo en la apreciación que tengo de Jesús de Santos: es un tío normal. Sabe de lo que habla y tiene experiencia, pero no va de gran promesa del software español que, en mi opinión, ese tipo de gente ya hay de sobra.

Aunque el cursillo sea estrictamente de aprender a diseñar motores, realmente Jesús nos explica como ha hecho su motor, lo cual no está mal porque tiene un tufillo a motor comercial que uno no encuentra en sus equivalentes OpenSource. Además es un motor moderno, no como los sempiternos Ogre e Irrlicht que se encuentran estancados en un diseño hecho en la era de la fixed-pipeline.

El viernes se hizo incapié en el sistema de reflexión, fundamental a la hora de hacer el binding en Python y a la hora de inferir para utilizar los smart pointers comodamente y sin casts por todos los lados. También se explicó un sistema de serialización sencillito, aunque efectivo.

Por último vimos el motor funcionando (aunque sin renderizar nada). La idea es que el motor envía mensajes de depuración a una aplicación “consola” que los recibe, de forma que se pueden controlar ciertos aspectos del motor de manera remota. Esta aplicación consola es independiente del motor, así que se mantiene en ejecución escuchando en un puerto concreto.

Evidentemente, la consola permite enviar mensajes para que el motor haga cosas, aunque de momento no permite más que lanzar aplicaciones y pedir ciertos datos. Aún así, resulta muy útil, sobre todo teniendo en cuenta que al utilizar un lenguaje de alto nivel interpretado como Python, todo lo que sean ayudas a la depuración son bienvenidas.

El segundo día se centró en la abstracción del renderizador gráfico y su implementación en DirectX9. El concepto principal fue el cómo prácticamente todos los datos se almacenan en buffers, para hacer modificaciones de forma secuencial y aprovechar cada llamada a función al máximo.

Por ejemplo, los cambios de renderstate o asignaciones de parámetros a los shaders se pueden poner en una lista de comandos, de forma que hacemos una especie de Display Lists de OpenGL pero en este otro contexto. Dichos buffers de comandos se ejecutan del tirón así que podemos acumular ahí todos los parámetros que necesitemos modificar (por ejemplo, renderstates) y ejecutar el buffer para aplicarlos. Parece una cosa muy sencillita, y lo es, pero tras ver un par de ejemplos de uso me pareció una muy buena idea.

Quizás, puestos a quejarme de algo, lo que hemos visto ahora es más propio de un middleware que de algo que se pueda llamar motor. Pero todavía queda mucho cursillo, y la verdad es que he aprendido mucho estos dos días, sobre cómo organizar a bajo nivel un motor ya que a alto nivel (grafos de escena, etc.) es relativamente sencillo y es algo que veremos en los próximos días.

Además, me gusta que se vaya al grano con código REAL de su motor y no ejemplos teóricos. Ahí se ve claramente todo. Aunque quizá sea un cursillo que requiere ciertos conocimientos previos que quizá no todos los asistentes tengan. Pero ya se avisaba en la descripción del cursillo. Yo de momento, estoy contento con lo poco que llevamos visto y seguro que mejora en los siguientes días.

Ahora bien, ¿qué nos van a mandar como práctica final del cursillo? El viernes que viene terminará el suspense (espero).