24/08/2001

- En primer lugar perdir perdón a las personas que siguen de forma más o menos regular esta página, ya que he estado dos semanas sin actualizar. La primera no fue nada buena ya que se me pasó volando al tener que reconstruir buena parte de la forma en la que los subsistemas se inicializaban. ¿La causa?. Un mal planteamiento en el diseño. Los que llevan siguiendo el proyecto recordarán que a comienzos de año comenté que había perdido unos dos meses de trabajo al haber planteado mal algunas cosas. Bueno, pues esta era una de ellas y se me ha llevado ahora una semana sólo para encontrarme yo cómodo con la aproximación a utilizar para solucionar ese problema de diseño. Afortunadamente, ya estoy siendo productivo otra vez.

- Esta semana la he empleado para integrar la carga de áreas, objetos de escenario, personajes y paredes desde archivo. Daros cuenta que esto ya forma parte de CrisolBuilder. Al final los cambios en la forma de trabajar con CrisolBuilder, con respecto a lo que hay ahora documentado, van a ser notables pero para mejor, ya que veréis que se facilitiará la "programación" de dicho contenido. En cuanto esté seguro que la forma de CrisolBuilder es definitiva (ahora ya sí que os aseguro que estoy trabajando sobre código definitivo para esta herramienta) actualizaré el documento de diseño, de tal modo que las siguiente beta que se publique pueda ser modificada por todos vosotros consultando el documento de diseño. Naturalmente, conforme vaya pasando el tiempo las especificaciones podrán aumentar pero nunca cambiar lo que ya haya establecido.

- Va a hacer falta un editor, aunque sea muy primitivo, para crear escenarios. Se pueden definir los perfiles de personajes y animaciones a mano perfectamente (bueno, es algo pesado pero asimilable). Ahora bien, definir un escenario a mano tiene dos graves inconvenientes:

Que es una tarea tremendamente pesada para llevar a cabo a mano (y, en consecuencia, sensible a errores).
Que la carga de un escenario desde un archivo de texto es lenta a la larga. Este ultimo inconveniente es salvable ya que estoy programando estructuras de datos que actúen de caché para no tener que ir una y otra vez a disco (estas son las búsquedas más lentas).

La idea es que dicho editor cargara todos los ficheros de perfiles que el diseñador haya creado a mano y que luego, con esa informacion, el diseñador pueda ir colocando instancias a los perfiles con el editor sobre el escenario (los ficheros de perfiles son ficheros de texto en donde se asocia un identificador a un tipo de entidad, por ejemplo, SOLDADO_OSCURO, y junto a dicha entidad se definen todos los atributos de la misma, su nombre, los eventos que tiene activos, etc, etc. Luego, en el escenario, cuando queramos colocar una entidad de ese tipo bastará con poner su nombre. Sería como crear una instancia a ese perfil).
Lo que está claro es que antes de poder hacer el editor el motor tiene que estar acabado o muy avanzado, asi que mientras tanto se trabajara a mano que es completamente válido para realizar pruebas.

- Ya recibí el libro sobre la construcción de lenguajes script: "Writing Compilers and Interpreters". Es muy buen libro y estoy muy satisfecho con la compra (lo recomiendo a todos los programadores que tengan que construir un compilador). Va a ser fundamental para que pueda acabar el proyecto, pues usa una aproximación para nada academíca y se esfuerza en enseñarte a construir un compilador sin aburrirte en mil y un aspectos teóricos (para eso esta el libro "Compiladores, principios y técnicas"). Es interesante también porque programa un analizador léxico y sintáctico en lugar de acudir a Lex y Yacc. Personalmente voy a utilizar estas dos herramientas (porque son más eficientes y me ahorrarán trabajo) pero estoy haciendo la lectura de la implementación que está realizando el autor para no utilizarlas. Otro de los puntos a favor es que es un código modular (el mismo autor lo presenta también así) y está escrito en C++. Como único punto en contra citar que no es el mejor código que he leido. No me gustan algunas aproximaciones que utiliza (pasa de largo de las STL, se apoya de forma excesiva en variables globales, no hay espacios de nombres, etc) aunque son perdonables pues el código base fue escrito en 1995 y se nota el uso importante del C que se daba por esas fechas embebido en el C++.

11/08/2001

- En estos momentos me encuentro trabajando a tope para cambiar el modelo de carga actual a otro completamente modificable. Este será el primer paso para hacer el motor mucho más abierto y flexible. Por el momento ya tengo creado el soporte necesario para trabajar con ficheros del estilo .ini que me van a permitir también configurar, además del motor en su inicio, otros aspectos como la disposición de interfaz, plantillas de animación, etc. Esto significará que cuando se publique la siguiente beta, los diseñadores ya podrán comenzar a trabajar cambiando gráficos, disposición en pantalla y demás en archivos que estén en formato de texto.

- CrisolBuilder, debido al punto anterior, sufre pequeñas variaciones en su concepto. En lugar de ser un programa que se encargue de generar codigo una vez que se hayan definido todos los ficheros sobre lo que actúa, va a ser mucho más flexible ya que permitirá trabajar de forma independiente con los distintos archivos. Debemos de tener en cuenta que su misión fundamental será la de pasar los ficheros de texto con los contenidos especificados a ficheros binarios. El motor, internamente, podrá trabajar tanto con ficheros de texto como con ficheros binarios. En general, se preferirá trabajar con ficheros de texto cuando se esté diseñando y probando cosas y con ficheros binarios cuando se tengan datos definitivos. Los ficheros binarios serán muchos más rápidos para la carga, ocuparán menos y no serán sensibles a modificaciones externas (si bien, los ficheros de texto se podrán hacer inaccesibles empaquetándolos).
Para que os hagáis una idea, el subsistema gráfico se configura ahora desde el exterior así:


[GraphicSystem]
; Seccion destinada a los valores del subsistema grafico
; Variables:
; * GraphicDevice -> Device a utilizar. Poner siempre el valor 0 si el equipo
;   posee una unica tarjeta grafica. Si tuviera una tarjeta 2D y otra 3D, poner 1.
; * 3DIDDeviceType -> ID del tipo de dispositivo 3D a utilizar. Los posibiles
;   valores seran: 0 (Tarjeta TNT), 1 (Cualquier otra tarjeta 3D), 2 (Uso de
;   las capacidades MMX) y 3 (Trabajo en software). 
;   En general se deseara utilizar la opcion 1.
; * VideoWidth -> Ancho de la resolucion de video.
; * VideoHeight -> Alto de la resolucion de video.
; * VideoBpp -> Bpp del sistema de video. Usar siempre el valor 16.
; * NumBackBuffers -> Numero de buffers secundarios para hacer el intercambio
;   de paginas (1 es DobleBuffer).
; * VSync -> Flag para indicar espera por retrazado. Si mayor que 0 intercambio
;   sincronizado. En caso contrario sin sincronizado.
 GraphicDevice = 0
 3DIDDeviceType = 1
 VideoWidth = 640
 VideoHeight = 480
 VideoBpp = 16
 NumBackBuffers = 1
 VSync = 1
End

Esta sección, está dentro de un archivo de texto llamado CrisolEngine.ini.

- Para los que estén interesados en la siguiente beta, decir que en princpio va a tardar en llegar. Poseerá muchísimos avances (espero) y los gráficos serán completamente distintos.

- El tema relacionado con la construcción del lenguaje script se lo voy a confiar al libro Writing Compilers and Interpreters de Ronald Mak. Por lo que he podido averiguar, es un libro muy práctico, que es justamente lo que yo necesito, y bastante bueno. Espero que durante este mes me llegue para poder ponerme cuanto antes a leerlo. De todos modos, sigue habiendo mucho trabajo que hacer en otros frentes.

06/08/2001

- Ya estoy de vuelta de las minivacaciones que me he tomado. La verdad es que ahora mismo tengo un gran lio encima de la mesa entre mensajes retrasados, páginas webs por visitar y revisión del punto en donde deje el motor. Espero, no obstante, organizarme hoy lunes para poder comenzar a trabajar el martes. Esta etapa de trabajo ya debe de estar orientada a la creación de un motor abierto y dispuesto a recibir todo tipo de modificaciones desde el exterior. Esto también implicará el trabajo más complicado de todos los que he realizado hasta ahora pues tendré que vérmelas con la creación de un lenguaje script embebido sin poseer mucha documentación.

- Querría dar las gracias a Yannis Deliyannis por colocar en las noticias de su portal sobre motores isométricos una reseña a Crisol. Podéis encontrar el portal en http://www.isometrix.org/