Puedes encontrar el artículo aquí: http://goo.gl/jFz3z. En él encontrarás una introducción a la programación en paralelo usando la tecnología CUDA de NVIDIA y unos screenshots que tomé con un programa que escribí específicamente para ayudar a exponer los conceptos tratados en el artículo.

Si lo deseas, puedo dejar un link a todo el código fuente del artículo, utilizado para realizar los benchmarks. Tan solo déjame un comentario.

Enjoy!

Ceibal-Chess en Español de Uruguay

• Mejor Integración con Sugar.
• Internacionalización, soporte para Español e Inglés.
• Mejoras Visuales*

Mejor Integración con Sugar

La nueva versión hace uso del excelente paquete “sugargame” para mejorar significativamente la integración entre Pygame y Sugar.

La Beta 3 permite acceder al Marco y terminar/reanudar la Actividad desde la Vista Personal. También se resuelve el problema de “ícono muerto” en el escritorio tras ejecutar Ceibal-Chess, el cual prevenía que la Actividad pudiera iniciarse dos veces consecutivas.

Internacionalización

Ceibal-Chess soporta ahora internacionalización de Strings y la nueva versión se distribuye con soporte para los idiomas Español e Inglés. Contribuciones para otros idiomas serán bienvenidas, si alguien se encuentra interesado.

Ceibal-Chess debería detectar automáticamente el idioma en el cual se encuentra la plataforma y seleccionar su propio idioma en función de dicho entorno. En caso de que un entorno no sea soportado, se revertirá a Inglés automaticamente.

Mejoras Visuales

Ceibal-Chess incluye un efecto de transición entre estados del tablero (mediante Alpha Blending). Este efecto requiere Pygame 1.8 o superior. En plataformas donde se dispone de Pygame 1.7, este efecto se encontrará dehabilitado y un mensaje será escrito en el Log.

Descarga

Pasos para XO:

1. Remover la Actividad “Ajedrez”, si esta se encuentra instalada y reiniciar Sugar (Ctrl + Alt + Erase).
2. Iniciar la Actividad “Navegar”, dirigirse a http://www.ceibaljam.org y hacer click en “Descargas”.
3. Identificar la fila correspondiente a “Ceibal-Chess” y descargar el bundle “ajedrez.xo”. Una vez descargado, seleccionar “Abrir” en el navegador.

Pasos para otras plataformas (Windows, Linux, Mac con Python y Pygame):

1. Iniciar el navegador Web e ingresar la siguiente dirección: http://www.algorithmia.net/software/download.py?dl=ceibal-chess-beta.zip
2. Descomprimir el zip y dirigirse al Directorio “ceibal-chess-beta3″.
3. Ejecutar el script “main.py”.

Reportar Errores

Como siempre, su feedback es invaluable para corregir problemas y asegurarnos que Ceibal-Chess se encuentre en un buen estado para alcanzar la versión 1.0.

Para reportar errores, por favor utilizar el siguiente formulario: http://code.google.com/p/ceibal-chess/issues/list

Algo que me tenía bastante confundido era cómo dibujar los polígonos que tenían mapeada una textura de cielo de la forma en que se veían en el juego. Finalmente, lo que decidí hacer fue simplemente eliminar todos estos polígonos y dibujar una Skybox acorde a las dimensiones de la bounding box del mapa.

Rendering del cielo en base2.bsp.

Para renderizar el cielo desarrollé un nuevo Shader que elimina la porción de traslación de la matriz ModelView, haciendo que el cielo se encuentre “infinitamente” lejano. A nivel de mapeo de texturas, utilicé CLAMP_TO_EDGE para ocultar las aristas de la Skybox. El efecto es bastante sorprendente: incluso sabiendo dónde se ubican las aristas, resulta difícil notar las caras interiores de la Skybox.

Cuarto de exteriores en base1.bsp, renderizado con su cielo.

Cuarto final en base1.bsp. Notar el cielo a través de las ventanas y el techo.

Cuarto escondido en base1.bsp, renderizado con Lightmaps.

Quienes jugaron Quake 2 recordarán la psicodelia típica de los mapas, lo cual distingue mucho la apariencia visual del Quake 2 de la del Quake original. Esto se debe a que los Lightmaps de Quake 2 son imágenes RGB de 24 bits por pixel, permitiendo mapear no solo sombras y sombreado, sino también colores sobre los polígonos. Esto se utiliza mucho en los cuartos de exteriores, donde se quiere expresar la hostilidad de la atmósfera del planeta Strogg, y para implementar luces cromáticas.

Cuarto exterior en base1.bsp renderizado con sus Lightmaps.

A nivel de implementación el Lightmap es simplemente otra textura que debe mapearse sobre los polígonos junto con la proveniente del archivo WAL. Para combinar ambas texturas utilicé multitexturing y escribí un Shader que multiplica los texel provenientes de cada una de las dos imágenes en tiempo de ejecución.

Prefusionar el Lightmap con la textura difusa hubiese sido más rápido, sin embargo, esto no fue una opción dado que cada polígono tiene su propio Lightmap asociado, a diferencia de las texturas difusas, las cuales son compartidas entre varios polígonos.

La dificultad más grande que enfrenté para esta tarea fue calcular las coordenadas de textura del polígono en el Lightmap (las cuales son distintas de las coordenadas utilizadas para la textura difusa). Tras bastante ensayo y error, terminé encontrando la fórmula correcta en los foros de GameDev.net, aquí. Mil gracias al autor del post, realmente esta fórmula no se encuentra por ningún lado y buscarla en el código fuente del Quake 2 es una tarea muy tediosa.

Finalmente, a modo de comentario, los Lightmaps agregan muchísimo realismo al renderer, sin embargo, tienen un costo asociado. En particular, al existir un Lightmap por polígono, para un mapa de aproximadamente 9.500 polígonos (como base1.bsp), esto implica que tendremos 9.500 texturas más, aumentando un poco el consumo de memoria de video, pero -más importante- obligándonos a realizar más llamadas a glBindTexture en cada cuadro, realmente perjudicando el framerate. Existen varias estrategias para intentar resolver este problema, alguna de las cuales intentaré tras terminar de mejorar el aspecto visual de los mapas.

A continuación dejo algunas capturas realizadas con el renderer. Nótese el realismo agregado a la escena, sobre todo comparando con el post anterior, en el cual solo mapeábamos texturas. Para generar estas imágenes, modifiqué la proyección perspectiva a una más “suave”. Creo que la matriz actual es más parecida a la utilizada por el Quake 2.

Finalmente, notarás que el cielo sigue roto, afortunadamente tengo alguna idea para desarrollar un Shader especial para el cielo que permita renderizarlo como en el Motor original de Quake 2.

Hasta la próxima!

Cuarto Final de base1.bsp, con el ascensor a la Installation (base2).

Cuarto de inicio en base1.bsp. Notar que el cielo no se renderiza bien debido a que no dispone (aún) de su propio shader.

Primer mapa del Juego, renderizado desde la posición de inicio del jugador con mapeo de texturas.

La ventaja de soportar los archivos PAK originales del juego es que ahora puedo cargar los recursos del juego directamente desde ahí (incluso los mapas BSP), sin necesidad de previamente extraerlos.

Comenzemos estudiando la paleta de colores. La paleta se encuentra dentro del PAK bajo el nombre “pics/colormap.pcx”. Para poder acceder a su contenido es necesario cargarla en memoria desde el PAK como un BLOB. Este BLOB es una imagen codificada en PCX, y es necesario descomprimirla para poder utilizarla como una matriz de colores.

Luego, cada WAL correspondiente a un polígono es referenciado mediante su nombre y ruta dentro del PAK. Los WAL consisten principalmente en un header que determina, entre otras cosas, las dimensiones de la imagen y el offset donde comienzan los datos. Los datos a leer son exactamente w*h bytes a partir de offset[0]. Estos datos son una matriz de índices a la paleta de colores. Afortunadamente, estos datos no se encuentran codificados de ninguna forma y pueden utilizarse directamente para indexar la paleta de colores.

A modo de comentario, cada índice leído es exactamente un byte de tamaño, por lo cual los WAL en teoría no pueden referenciar más de 256 colores distintos en la paleta. Consecuentemente, uno esperaría que la paleta sea exactamente de 256*3 bytes, sin embargo, esto no es así. Quizás otros aspectos del motor utilizan la misma paleta y por eso existen colores que en principio no podrán ser referenciados.

Una vez que tenemos el WAL y la paleta, la textura se crea fusionándolos en una matriz de colores RGB. Esto se puede hacer de dos formas: se puede suministrar la paleta a OpenGL y luego crear una textura compuesta por índices, o bien, se puede fusionar la paleta con el WAL manualmente por Software y suministrar texturas 2D ya preparadas a OpenGL.

El primer enfoque tiene la ventaja de que se ahorra mucha memoria de video, ya que por cada textura, necesitamos almacenar solamente 1/3 de los datos que necesitaríamos para almacenar colores RGB (más la paleta una única vez). Por otro lado, este enfoque es más difícil de configurar a nivel de OpenGL (yo no logré hacerlo andar), requiere que la implementación de OpenGL soporte la extensión ARB_imaging y es más lento en tiempo de ejecución, ya que OpenGL deberá fusionar la paleta con los índices por cada cuadro. A su vez, OpenGL no soporta paletas del tamaño de la del Quake 2 e, incluso si lo hiciera, deberíamos convertir todas nuestras matrices de índices a dimensiones potencias de 2.

El segundo enfoque resuelve todos estos problemas al costo de consumir más memoria de video. Personalmente elegí este segundo enfoque, al costo de saber que probablemente mi renderer tenga problemas de performance en placas de video con poca RAM (64 MB?).

Si w,h son las dimensiones del archivo WAL, “textura” es una matriz de w*h*3 bytes, “indx” el i-ésimo índice del archivo WAL y “paleta” la paleta de colores, la forma de fusionar manualmente la paleta con los índices en un array es mediante la siguiente operación:

textura[i*3+0] = paleta[indx*3+0];
textura[i*3+1] = paleta[indx*3+1];
textura[i*3+2] = paleta[indx*3+2];

Donde i es un contador en el intervalo [0, w*h), y teniendo cuidado de no leer fuera del espacio de memoria de la paleta. Es válido referenciar colores fuera de la paleta, si bien los WAL de Quake 2 no parecen hacerlo. Si esto llegase a pasar, se deberá forzar el valor a negro (0x0).

La paleta se asume es un array unidimensional de la forma R,G,B, R,G,B, ... Es por esto que la forma en que se indexa la paleta es tal que el índice 0 corresponde a los primeros 3 bytes (0,1,2), el índice 1 corresponde a los siguientes 3 (3,4,5) y así sucesivamente.

Una vez creada nuestra textura RGB, la cargamos a OpenGL y ésta queda pronta para ser utilizada.

El último detalle a tener en cuenta es la diferencia entre los sistema de coordenadas de textura de Quake 2 y de OpenGL. Quake 2 utiliza un sistema de coordenadas en píxels, mientras que OpenGL utiliza un sistema normalizado. Para solucionar esta diferencia es necesario (tras calcular las coordenadas u,v de textura), dividir u y v entre el ancho y largo de la textura respectivamente. Esto no necesariamente producirá coordenadas en el intervalo [0,1], lo cual es esperable, ya que muchas de las texturas en Quake 2 deben dibujarse con Tiling.

Sin más detalles, les dejo a continuación un par de screenshots nuevos, esta vez con la iluminación deshabilitada pero con texturas mapeadas con filtrado bilineal.

Cuarto de Ambiente Exterior en Base 1, con mapeo de texturas. Notar los Triggers puestos en el cuarto para disparar eventos en el Juego y como el cielo se ve "raro" al dibujarlo como cualquier otro polígono.

Cuarto escondido en Base 1.

Casualmente me encontré hace algunos días esta CheatSheet que llegaba a la portada del Programming Reddit.

Lua CheatSheet - Lua es un lenguaje muy parecido a Python!

Me pareció un excelente recurso para rápidamente hacerse con una buena impresión del lenguaje. ¡Muchas gracias al autor en CoffeeGhost!

Primer mapa del Juego, renderizado desde la posición de inicio del jugador.

El formato es relativamente simple de leer ya que básicamente se trata de un conjunto de blobs con un directorio. Esto hace que sea extremadamente sencillo de levantarlo desde C o C++.

La mayor dificultad con la que me encontré consistió en dar un formato a estos datos que sea razonable para enviarlos a OpenGL en forma eficiente (recordemos que es un formato del ’97). Particularmente, a mi gusto, existe demasiada “distancia” entre las hojas del Árbol BSP que contienen geometría y los detalles de la misma, debiendo atravesar varias tablas para llegar desde una hoja que se sabe visible hasta las coordenadas de los vértices que componen todos sus polígonos.

Finalmente se me ocurrió una forma de transformar todos los polígonos para evitar el tener que estar saltando entre 6 tablas cada cuadro a dibujar : )

El renderer dispone de un sistema de iluminación muy básico, con luces direccionales y brillo especular.

Los próximos pasos que me gustaría realizar serían implementar el mapeo de texturas (idealmente leyendo los archivos .wal originales del juego desde el paquete .pak) y el descartado de geometría mediante el cálculo del PVS.

Les dejo algunos screenshots.

Cuarto de "Exteriores" en base1.bsp

Cuarto de inicio del segundo mapa (base2.bsp).

Por suerte Google Books provee una forma fácil de embeberlo en un iframe. Lo dejo a continuación.