¿Cómo funciona?

VNVM es un sistema formado por dos partes fundamentales:

• Código C++ genérico (Squirrel + librería para trabajar con compresiones, gráficos (blits, shaders y efectos), audio, vídeo y fuentes + SDL/SMPEG/SDL_Image/SDL_Mixer/SDL_ttf/OpenGL/OpenGL|ES)
• Código Squirrel con la implementación de los engines

¿Por qué esta separación?

El port que hice inicialmente del DiviDead estaba hecho íntegramente en C. Era rápido y no requería mucha memoria, así que se pudo portear a otras muchas plataformas. Trabajar en C suele ser bastante poco productivo. Especialmente siendo una sola persona. Hubieron muchos muchos problemas con memory leaks y muchas chapuzas para evitar usar memoria dinámica. El engine del DiviDead era relativamente sencillo, pero engines más complicados supondrían un mayor problema.

Debido a esto y a que en general casi toda la potencia se iba en descomprimir las imágenes, renderizar los gráficos y reproducir el sonido y que la parte encargada del motor del juego en sí (incluyendo decodificación de opcodes) requería muy poca potencia al ser todo muy de alto nivel, decidí que igual eso se podía pasar a un lenguaje de scripting.

Me interesaba un lenguaje de scripting que aunque fuese relativamente rápido, diese prioridad a las funcionalidades y que estuviese hecho en C/C++. Si sirviese D hubiese elegido MiniD, que es un gran lenguaje de scripting, con bindeos mágicos y con multitud de funcionalidades. Pero como tenía que ser C o C++ me acabé decantando por Squirrel. Squirrel es un lenguaje de scripting con sintaxis similar a C y bastante rico en funcionalidades manteniendo una base muy ligera. De hecho en 12 archivos de C++ tienes el compilador y la máquina virtual y sin dependencia alguna. Y con 8 archivos más de C++ tienes una librería estándar básica (algo limitada, pero suficiente para cosas básicas y extensible). Es un lenguaje de scripting de tipado dinámico. Soporta clases, delegados, co-rutinas, excepciones y GC + refcounting.

Además soporta anotaciones para clases y métodos lo que es de gran utilidad en la decodificación de opcodes de los engines:

</ id=0x40, format="P2222", description="Adds an option to the map_option list" />
static function MAP_OPTION_ADD(pointer, x1, y1, x2, y2)
{
	this.map_options.push({pointer=pointer, x1=x1, y1=y1, x2=x2, y2=y2});
}

DiviDead originalmente usaba una resolución de 640x480. Resolución adecuada para DreamCast por ejemplo o adaptando bastante también para PSP (480x272).

Planteando el port de YumeMuriKusuri vi que usar SDL en la PSP se quedaba bastante corto. El engine del YumeMiruKusuri pedía a gritos usar OpenGL y Shaders. Además de que el juego ya utilizaba una resolución de 800x600. Aún con todo hice el port, enfocándome en sacar adelante las funcionalidades del juego ignorando un poco todo lo que podía hacer el engine. Salió adelante la cosa. Pero igual que con el dividead: memoryleaks. Al final no saqué el port. Y ya después de mucho tiempo en el que he ido trabajando en algunos ratos libres cada bastante tiempo, me ha dado por liberar el proyecto en googlecode.

Mientras escribo esto el nuevo engine ya permite pasarse el Yume Miru Kusuri (aunque sin guardar ni cargar), usa OpenGL y shaders (aunque casi todas las funcionalidades están implementadas también en SDL básico excepto los shaders de los cuales haré una implementación en SDL más adelante).