Más modelado.

music: MERCYFUL FATE -"Room of Golden Air"-

Por aquí dejo otra cosilla de modelado; con esto estuve liado hace unas semanas.

Hasta otra. :P

Modelando (que también es gerundio). :P

music: ALASKA Y LOS PEGAMOIDES -"Mundo Indómito"-

Mi particular "Hello World!" dentro del mundo del modelado 3D y texture mapping.

Hasta otra. :P

Refactoring, refactoring...

music: DEVO -"Beautiful World"-

...y más, y más refactoring.

Y vuelta a empezar.

Pero al fín el proyecto tiene una estructura de directorios cohesiva (y coherente). Aparte, ha quedado actualizado a DirectX SDK (june 2010).

Y ahora tocará... limpieza y más limpieza de código. En fín...

Hasta otra. :P

Bye, bye, warning C4921...!!!. :D

music: MASTODON -"Seabeast"-

La perseverancia a veces da sus frutos, ¡pardiez...!.

De nuevo, otro tema ha sido arreglado. No era un problema grave pero era algo que me estaba tocando la moral desde el principio (y de hecho, todavía me cuesta hablar en términos de pasado, como algo que ha desaparecido, que ya se ha solucionado). :P

Se trataba de una serie de warnings que aparecían durante la compilación del juego, cuyo código era C4291. Se limitaban a "aparecer", a estar ahí, dando un mensaje que hasta ahora me resultaba ilegible, cada vez que reservabas dinámicamente memoria para crear un objeto teniendo en funcionamiento el sistema de control de memory leaks. Y varias veces a lo largo de todo este tiempo me había puesto a intentar ver por qué se producían y qué hacer para que no salieran... sin éxito. Hasta ahora. : )

Y no, la solución no ha venido añadiendo al código  #pragma warning ( disable : 4291 )  :P

El asunto es: cuando activamos el sistema de control de memory leaks en el engine se realiza una sobrecarga de los operadores new y new[ ]. En concreto la sobrecarga 'Placement Form' de éstos, adoptando una cabecera así:

void* operator new      ( uint uSize, char* pszFile, uint uLine );

void* operator new[]    ( uint uSize, char* pszFile, uint uLine );

Pues bien, dado que estos son los operadores new y new[ ] que se sobrecargan, hay que hacer también las sobrecargas de delete y delete[ ] con esta misma estructura, es decir, así:

void  operator delete   ( void* p, char* pszFile, uint uLine );

void  operator delete[] ( void* p, char* pszFile, uint uLine );

La razón argumentada es que, si se crea dinámicamente un objeto y en el constructor de éste salta una excepción, se pueda liberar la memoria que había sido reservada para el objeto empleando dichas sobrecargas de delete y delete[]. Pero las únicas sobrecargas que había definidas hasta ahora eran:

void  operator delete   ( void* p );

void  operator delete[] ( void* p );

Pues... por eso daba los cansinos warnings. :P Al añadirle las otras sobrecargas de delete y delete[ ] a éstas últimas al fín han desaparecido, ¡joas, joas...!. :D

Mas información aquí.

En mi caso lo anterior nunca se va a producir pues, dada la arquitectura del engine, en los constructores de las clases no se hace nada "raro" que pueda provocar el lanzamiento de una excepción, no se hace nada más allá que inicializar a NULL, false ó 0 algunos atributos de la clase... dejando la "auténtica" inicialización del objeto en el método Init, llamado inmediatamente tras la creación del objeto, que todas las clases poseen. Por ello las nuevas sobrecargas quedan como una mera formalidad, pues no son empleadas dentro del engine (no se necesitan, y se siguen empleando las que ya había). Pero como digo siempre: El problema es no saber, y ahora que sé por qué se producía el tema, no me apetece quitarlas para no olvidarlo. XD

Hasta otra. :P

Reality, a New Beginning

music: FIGHT -"Reality, a New Beginning"-

This time, when I'm leaving... who cares where I'll go?.

I'll walk with the sunset. Out there... no one knows.

Reality, a New Beginning...

In my imagination I'm searching for my dreams.

Finding something better. More than what I've been.

Reality, a New Beginning...

New day, new tomorrow. I'm not living in the past.

Changing the illusion I'm set free... free at last.

Reality, a New Beginning...

* * * * * *

Si Madrid ya no nos quiere... enamorémonos de nuevo.

Terrenos y Mapas de Alturas

music: L7 -"Pretend We're Dead"-

( NOTA: es probable que cambie las partes en las que digo píxel por téxel, dado que, aunque lo que voy a llamar Mapa de Alturas no es una textura propiamente dicha -no se mapea en ningún modelo 3D-, el concepto de píxel parece estar semánticamente más asociado con el monitor, mientras que el de téxel lo está más con una unidad atómica, indivisible, de una imagen. Aún no estoy seguro, de momento lo dejo como TO-DO ).

En los últimos días he estado desempolvando uno de los que fueron mis programas favoritos del Máster. Con él se genera la representación visual de un terreno a partir de un Mapa de Alturas, esto es, una imagen de escala de grises (o como es mi caso, una imagen RGB a la que hemos "desatudado" el color) cuyos valores de gris (color) equivalen a una determinada "altura" en un mundo 3D; esto es, a un determinado valor positivo a la coordenada Y de cada uno de los vértices que conforman el terreno.

Así, como valores extremos del rango:

-Un pixel en el mapa de alturas que tenga un color Negro (R:0, G:0, B:0) otorgará un 0.0 como valor a la coordenada Y del vértice correspondiente a ese píxel en el terreno, vamos, en el mundo 3D.

-Y un pixel en el mapa de alturas que tenga un color Blanco (R:255, G:255, B:255) otorgará un valor máximo como valor a la coordenada Y del vértice correspondiente.

Para preparar el Mapa de Alturas se parte de una imagen a la que, mediante Photoshop , hemos quitado el color, retocado a nuestro gusto y por último escalado a un tamaño de 128x128 píxeles. La guardaremos empleando el formato Photoshop RAW (*.RAW), que no debe confundirse con imágenes RAW de cámara digital (so pena de perder un montón de días haciéndote el lío padre como me pasó a mí). :P A todo esto, debo comprobar si el nuevo GIMP 2.8 también tiene soporte para abrir imágenes Photoshop RAW.

No necesitaremos que el fichero posea una cabecera que contenga el ancho y alto de la imagen en píxeles, pero justo por ello sí tendremos que ser nosotros los que tengamos que indicar al "Objeto Terreno" el tamaño del Mapa de Alturas que le pasamos  (que como ya hemos dicho, será 128 píxeles de ancho y de largo).

A partir del Mapa de Alturas tendremos en el mundo 3D una malla poligonal cuadrada de 128x128 = 16384 vértices, dividida en (128 - 1) * (128 - 1) = 16129 sectores cuadrados contiguos, como una rejilla. Pero dado que la unidad atómica que nos interesa para renderizar es el triángulo -y no el cuadrado-, dividimos cada sector en dos triángulos rectángulos que comparten la hipotenusa. El número total de triángulos será el doble que el de sectores, esto es, 32258. : )

Por último, se crea un Vertex Buffer y un Index Buffer, y las coordenadas X,Y y Z son calculadas para cada vértice e introducidas, con la ayuda del Index Buffer, en el Vertex Buffer.

Aquí es donde entra en juego al Mapa de Alturas. Como anteriormente se ha mencionado la coordenada Y del actual vértice (del aquel que hay que generar actualmente las coordenadas, vamos) se toma consultando el valor de color del píxel correspondiente en el Mapa de Alturas; en concreto, se consultará la componente de color G de dicho píxel. Las coordenadas X y Z se generan a partir de un valor de espaciado entre sectores (un valor fijo, actualmente es 16) y de unos Offset en X y en Z: el offset en X es la mitad del ancho del Mapa de Alturas, y el Z la mitad del alto (para el caso, ambos valdrán 64).

Así, si pensamos en una rejilla o matriz 2D a cuyas filas accediéramos mediantes en índice i y a cuyas columnas accediéramos mediante el índice j, las coordenadas X,Y,Z para cada vértice 3D [i][j] se calcularían así:

Vertice3DActual[i][j].X = (i * EspaciadoEntreSectores) - (Offset_X * EspaciadoEntreSectores)

Vertice3DActual[i][j].Y = MapaAlturas[i][j].Componente_G

Vertice3DActual[i][j].Z = (j * EspaciadoEntreSectores) - (Offset_Z * EspaciadoEntreSectores)

Tras haber calculado las coordenadas de todos lo vértices se calculan las normales para los tres vértices de cada triángulo, los índices para el Index Buffer, se sitúa una cámara libre dotada de un movimiento básico de 6 grados de libertad y... estos son los resultados.

La flecha roja indicaría a grandes rasgos la posición y orientación de la cámara. Efectivamente, la última escena es un poquito "marciana". ; )

Hasta otra. :P

Retromadrid 2012

music: ANA CURRA -"Envuelta en ron"-/-"Tengo un pasajero"-

La mala noticia en 2011 fue que no habría Retromadrid ese año. La buena, que la edición de 2012 se realizaría en el Centro Matadero de Madrid... como así ha sido.

El lugar adjudicado para el evento es verdaderamente espacioso y cuenta con dos salas separadas, la principal y la de conferencias. Es probablemente el lugar más amplio en el que Retromadrid se haya realizado.

Hablaré del domingo, día 6, que fue el día que yo asistí. Las actividades principales de dicho día, aparte de la sesión de firmas por parte de nuestro incombustible Azpiri, era la ponencia Detrás de los muros de la Abadía del Crimen (yo me referiré a ella como 2.0, para diferenciarla de la de Gamefest 2011) y la mesa redonda Ocho Quilates: una historia de la Edad de Oro del software español. Título homónimo del libro que debe ya estar a punto de salir. :P

Al comienzo de Detrás de los muros de la Abadía del Crimen 2.0 se contactó por videoconferencia con J. Delcán, quien había accedido a participar pese a que en California ya debía ser bastante tarde. :P Desgraciadamente, el gran reverb que se producía mientras hablaba (no sé si era por la sala o por los altavoces) impidió que nos enteráramos de gran parte de lo que decía. Probé a situarme en varios puntos distintos de la sala, a ver si encontraba algún lugar donde le escuchase mejor... pero no sirvió. :(

¿Y qué tal fue esta versión 2.0, respecto de la anterior en Gamefest 2011?. Aunque “a grosso modo” las explicaciones en esta ocasión resultaron más atropelladas (quizás empezaron a ver que ir mal de tiempo, y aceleraron en el último tramo) respecto a la edición anterior, y por ello el resultado final de la anterior queda como algo más compacto y mejor atado, en esta segunda edición añadieron un montón de elementos complementarios muy interesantes, que hace que su visionado (cuando se suba a la red) merezca definitivamente la pena. Destáquese:

-Una demostración en tiempo real acerca de cómo se generan las letras del pergamino del principio, el que escribe un ya anciano Adso, y que parecen estar escribiéndose a mano.

-Una demostración visual sobre la IA de los NPCs (Adso, los monjes) y cómo buscan el camino a través de la Abadía para llegar al lugar donde tienen que ir en un determinado momento. Para el ejemplo se empleó a Severino y al Abad.

-También se incluyó una representación animada de Fray Guillermo caminando, realizada superponiendo los diseños en papel de éste en las diversas poses de caminar, y algunos diseños personalizados para los monjes que al final tuvieron que descartarse por limitaciones de RAM (el tronco y las extremidades de los monjes parten todos, al final, del mismo modelo... cambiando únicamente las cabezas).

-Se mostró un bloque de código/script, programado en ensamblador, para controlar parte de la lógica general del juego. No recuerdo ahora qué condición/es del juego controlaba.

Aparte, agradezco a A. Giner la inclusión de Ant Attack en la explicación preliminar de la ponencia. No recuerdo si al final le dí las gracias cuando volví a hablar con él tras acabar esta; si se me pasó, sorry, A. y... ¡¡¡MUCHAS GRACIAS!!!. : )

Y tras recibir Azpiri un MOT-premio por su trayectoria profesional comenzó la mesa redonda Ocho Quilates, en la que los invitados nos obsequiaron con otro buen montón de historias, anécdotas y curiosidades para añadir a nuestra base de conocimiento sobre aquella época que muchos sólo vivimos como jugadores incansables y programadores aficionados. :P

Ocho Quilates: una historia de la Edad de Oro del software español

Por último, añadir que este movimiento, lejos de quedarse apolillado y permanecer estático y encasillado, va evolucionando y se renueva, introduciéndose nuevos elementos. Prueba de ello es haber visto en las vitrinas de la exposición sobre videoconsolas una Xbox (es de esperar que, dentro de 5 o 10 años, veamos por ejemplo una Xbox360). O cómo, durante la propia Ocho Quilates, asomaron de forma natural temas como los smartphones o las plataformas de descarga digital.

Hasta otra. :P

Procesadores gráficos para PC

music: DECEMBER MOON -"Winter Sunset"-

Sorpresa inesperada. Ayer terminé de leer el último de los 12 capítulos de este libro, que me encontré por casualidad y del que nada sabía. Más de dos semanas non-stop, casi a capítulo por día, ¡pfiiiuuuu...!. El libro forma parte del material con el que se elabora el Curso Básico de Procesadores Gráficos (GPUs) de la Universidad de Málaga.

Aún siendo un libro de tamaño pequeño posee una información muy condensada. Da mucha más información de lo que parecía con lo que la lectura, al final, no ha resultado tan ligera y amena como esperaba. En algunos puntos se hace verdaderamente cuesta arriba, sobre todo a la hora de ponerse a hablar de parámetros y características a un nivel demasiado electrónico. Cuando empieza con que si el chip tal tiene nosecuántos millones de transistores, con nosecual distancia de integración de nosecuántos nanómetros, trabaja a una frecuencia de nosecuántos MHz y procesa nosecuántos GigaFLOPS... acabas sudando para no perder el hilo.

Esto último, junto con un enfoque más académico / teórico del que me esperaba, y la no suficiente inmersión en el funcionamiento del software de control y programas de apoyo (profiler, benchmark) serían los aspectos negativos que le veo al libro.

Por la parte positiva, destacar:

-Posee una buena explicación introductoria al modo de funcionamiento de la GPU; cuando alguien que proviene de la "Escuela von Newmann" no ha recibido dicha explicación y se enfrenta por primera vez a la programación de shaders, el choque puede ser bastante grande. Comprender que el funcionamiento de una CPU no tiene que ver con el de una GPU (circulación de instrucciones vs circulación de datos) y que un shader no es como tal un programa almacenado en memoria cuyas instrucciones se van ejecutando, sino esencialmente es una configuración de las unidades de procesamiento de la GPU para que trabajen no en su forma por defecto, sino en la que el shader especifica... partimos de una mejor base para comenzar a aprender la programación de shaders. Y dado que un shader representa una configuración y no es una ejecución de sí mismo, no lograremos una ejecución más rápida del shader programándolo directamente en el lenguaje ensamblador de la GPU. Curioso, curioso... : )

-Posee un montón de fotos, cuadros y diagramas explicativos.

-Uno de los capítulos más interesantes ha sido el de refrigeración; para los que estamos un poco pez en cuestiones  más hardware resulta muy instructivo ver cómo va poco a poco desmontando los componentes de refrigeración de la  tarjeta, identificando los distintos elementos de ésta.

-Si estamos interesados en el tema de overclocking deja muy claro, desde el punto de vista de los diferentes elementos de la tarjeta gráfica -memoria de vídeo, GPU,etc.- , cuáles son los parámetros más destacables y lo que podemos esperar al manipularlos (siempre asumiendo que, al hacerlo, acortaremos la vida útil del elemento, esto es,  de la tarjeta gráfica... con lo que si no experimentas mejoría en el rendimiento vuelve a dejarlo como estaba, campeón). :P

-Viene muy bien para repasar el pipeline gráfico, encontrando un modelo unificado de las diversas etapas. También  explica bastante bien la teoría del Tratamiento de la luz y el color, qué es el famoso HDR y los diferentes formatos  HDR existentes (haciendo especial hincapié en el OpenEXR de Industrial Light & Magic).

-Puede ayudar para aclarar conceptos que puedes estar liando. Por ejemplo, diferenciación entre BIOS, driver e interfaz  de driver. Destacar que explicará una forma para activar una ampliación de las features del interfaz de driver de nVidia que nos darán acceso a configuración de opciones avanzadas de la tarjeta (monitorización térmica, funciones  para overclocking).

-Otros temas: Descripción de técnicas SLI y Crossfire para utilizar doble tarjeta , introducción a OpenGL y sus diversos estándares (hasta 2.0), introducción al lenguaje de shading Cg y presentación de un programa ejemplo.

-etc.

Indicaré por último que el autor reserva una parte considerable de espacio para hablar de segmentación, paralelismo, Modelo de Procesamiento "Circulante" (stream) y utilización de GPU como procesador de propósito general, indicando las principales características a tener en cuenta para transformar un "programa von Newmann" en otro Circulante. Ninguna referencia a OpenCL ni a CUDA.

En resumen: un libro que puede ser un buen punto de partida para muchos campos relacionados con el mundo de las GPU, como la computación circulante o la programación de shaders. O simplemente para ponerse un poco más al día en cuestiones hardware y ayudarnos a identificar los diferentes elementos de que consta la tarjeta gráfica de nuestros ordenadores, que algunas tienen un aspecto que intimida y todo. XD

Recomendado según tu interés y nivel de conocimientos en las materias señaladas. Dejo por aquí una completa encuesta de valoración que realizaron los alumnos en septiembre de 2005.

Hasta otra. :P

P.D.: Dado que fue publicado en septiembre de 2005 resulta muy gracioso comprobar si al final se terminaron cumpliendo ó no algunas conjeturas; me temo que no, que al final las tarjetas gráficas no han terminado acoplando ventiladores a ambos lados de la tarjeta (la ATI Radeon HD 5870 de mi Mountain tiene tres ventiladores -como otras muchas-, pero todos toditos por el mismo lado). :P

Hacia una Broad-Phase Collision Detection

music: INKUBUS SUKKUBUS -"Trinity"-

He terminado de hacer un refactoring bastante duro al Pong que implicaba cambiar la perspectiva que tenía hacia otra más intuitiva y útil. Desde el punto de vista del juego todo se ve igual, pero internamente todo el juego ha sufrido una rotación horizontal de 90º en sentido horario. Gracias a esto, es ahora el eje Z positivo el que apunta hacia dentro de la pantalla, y no el X como hasta ahora. Al estar empleando un sistema de coordenadas Left-handed, ahora el eje X positivo apunta hacia la derecha del jugador, y el eje Y verticalmente hacia arriba.

Con esto, puedo pasar ya a integrar una Broad-Phase Collision Detecion, algo que aún no poseía el sistema de Collision Detection & Response. Entendía que no tenía sentido hacer esto hasta adecuar la perspectiva del juego. Debo hablar de otro libro, pero ya lo haré más adelante.

Por otra parte y, tras haber estado colaborando durante todo el año 2011, he decidido dejar el proyecto Quimera. Guardaré un magnífico recuerdo de esta experiencia y de la gente que he conocido ahí, a quienes ya he explicado las razones de mi baja en el proyecto. ¡Seguid así, chicos!. :D

Hasta otra. :P

Masters of Doom

music: MÖTLEY CRÜE -"Kickstart My Heart"-

( NOTA: dada la naturaleza del texto que hoy nos ocupa, mi imparcialidad y mi objetividad estarán seriamente condicionadas; estais avisados ). :P

Desde que supe de su existencia tenía claro que, tarde o temprano, este libro acabaría en mis manos. Por imperativo moral. No obstante, desconfiaba del contenido (así como también lo hice de las muchas reseñas, en la contraportada y las primeras dos páginas, que lo ponen por las nubes). Pero la implicación en él por parte de las personas involucradas en la historia y un trabajo de elaboración, por parte del escritor, que ha llevado un total de seis años me han hecho pensar: ¡joder, algo de veracidad debe tener el libro, ¿no?!.

Lo que aquí podemos leer viene a ser, otra vez, la eterna historia de Estados Unidos de América: la tierra de las oportunidades. De cómo el(los) Onassis de turno, tras unos años de duro sacrificio y trabajo, pasa de ser un pelagatos y un don nadie a ser el millonario que marca la tendencia, y de lo cojonudo que es el Sueño Americano.

¿Alguien quiere volver otra vez a escuchar esa mierda?. Depende...

Imaginad ahora una historia de ordenadores "pedidos prestados"(a nadie), transportados en medio de la noche a una lakehouse, y devueltos a la empresa de origen antes de que cierto jefe con apellido de sonido ligeramente eslavo se enterara. De jornadas maratonianas de trabajo aderezadas con ingentes cantidades de pizza, soda y Diet Coke. De un trepidante viaje que va desde Shreveport (Lousiana) hasta Madison (Winsconsin) para "finalizar" en Mesquite (Tejas). De teclados y ratones estampados contra una pared, puertas destrozadas a base de hachas de batalla, torneos y partidas interminables de Deathmatch en los que "Suck it down!" era el menor de los calificativos (una droga verdaderamente potente, como ciertas strippers pensaron, y todo indica que no andaban mal encaminadas). XD

Esas son sólo algunas aventurillas de ese grupo de jóvenes "de pelo largo". En más de una ocasión he soltado una carcajada cómplice y condescendiente.

Y todo ello aderezado con una banda sonora en la que no faltan grupos como Judas Priest, Metallica, Nine Ich Nails, GWAR, Dokken o Mötley Crue. Algunos sólo como sonido de fondo para los protagonistas. Otros como participantes más o menos activos de la historia.

Bueno, pues todo esto y mucho más... está aquí.

Porque esta es la historia de id Software. La historia los Dos Johns y del resto de gente que, alrededor de ellos, se involucró en la que fue la época que supuso el antes y el después en el mundo de los videojuegos. He preferido no mencionar a nadie más porque al acabar de leer el libro te das cuenta que, aquí... o todos o ninguno. Y la lista se haría interminable. También se tratará la historia de Ion Storm (no podía ser de otra forma), y habrá un epílogo y un afterword.

¿Recomendado?. ¡Compra o muere, amigo!. : )

Y una vez leído, escucha , observa y vuelve a escuchar.

Hasta otra. :P