Existe la tendencia entre los programadores que se dedican a los videojuegos, de considerarse poco menos que top-guns del desarrollo. Tiene bastante gracia ya que visto en la distancia, la tecnología en desarrollo de juegos no avanza tanto. No negaré que es un trabajo muy especializado y sí tiene una componente importante de presión y fechas de entrega draconianas. Claro que cualquiera que haya empezado en una consultoría desde los puestos de programador nos da sopas con honda a cualquiera que se dedique a esto de los jueguitos.

Dicho en plan titular, vista por separado, la gestión de los datos del World of Warcraft es mucho más impresionante que su render, incluso que la carga (sin tiempos de carga) del mapa, según se avanza por él. Según me han ido contando Blizzard se sostiene encima de unos soberbios montajes de Oracle, no quiero ni imaginarme lo que costarán los seguros al año, ni lo que cobrarán esos aburridos programadores de bases de datos, que resulta que están haciendo el juego.

Una vez he lanzado este canto a la igualdad y la concordia entre las distintas familias de programadores, dejad que os diga en qué se distingue un programador de videojuegos de un desarrollador de aplicaciones serias. En los detalles. En los malditos y minúsculos detalles. En que cuando alguien pulse ahí se oiga click y el menú se desplace con una hermosa fluidez. En que los reflejos del jefe maestro sobre el agua sean físicamente correctos. En que la velocidad que el joystick transmite al personaje siga una curva de Hermite. Y lo que es aún peor: el programador de videojuegos fogueado se distingue del verde precisamente en la cantidad de detalles que puede anticipar a la producción y con los que prepara su código.

Qué semana más rarita ha salido en esta parte del mundo mundial. Sólo un par de detalles para poner en situación al incauto lector:

Portal

Esta semana me he lanzao a la piscina y he comprado The Orange Box. Tened cuidad si os da la ventolera de ir a un centro-mail, mail-center, mail-foobar o como leches se llame ahora el garito. Un dependiente normal de esas cadenas no va a saber qué venderos si pedís “la caja naranja”, no sabe si hay que pagar o no para jugar en Steam (no, no hay que pagar), … en fin, no conoce el género que tiene y probablemente le importe un huevo.

Mi primer contacto con Portal fue a través de Yahtzee Croshaw, en su columna de video-crítica-animada semanal en The Escapist Magazine: conocida por el simpático nombre de Zero Punctuation [1] Como cabe imaginar a tenor del nombre, el tipo no se anda por las ramas: masacra cada juego que pilla. Llevo unos meses bastante mosqueado con la critica de videojuego en general y probablemente será carne de artículo más pronto que tarde. Hay que ver sus videos siempre hasta el final y no perderse la delirante sección de disculpas que tiene al final, donde pueden encontrarse maravillas como perdi mi corazón por un soldado del espacio.

No creo que tenga que decir que Portal es fabuloso. O quizá sí: Portal es fabuloso. ¡Larga vida al companion cube!

Bluetooth

Y ahora hablemos un poco de trabajo ^_^. A causa de un problemilla con el servidor de cauterized.net [2] No he podido destilar mis penurias profesionales por este canal. Lamentablemente para todos, ahora vuelve a ser posible darlos la lata con todo esto ¡yipes! La versión ultra-resumida de todo esto es que me ha tocado montar un prototipo capaz de comunicar un teléfono móvil con un PC a través de bluetooth y luego, enganchar el PC a internet. De algún modo la idea es darle a un usuario la capacidad de conectar servicios web a su teléfono a través del PC.

Por supuesto, todo el tinglado tiene que funcionar desde el terminal más churrero de Nokia (ie: Series 40) hasta en sus zapatófonos más rutilantes. Mejor no hablar de otras compañías porque los Motorolas que yo conozco dan por saco desde que los enciendes hasta que los tiras a una pecera llena de calimocho, sólo para desembalar tu viejo y querido 8310; podría mencionar los Sony-Ericsson, unas peacho-máquinas que me han sorprendido mucho.

Y debéis entender que no estoy hablando como usuario, no me quejo del color de los botones, ni de los efectos de sonido, ni de las malditas animaciones de transición entre elementos del menú: dejemos que eso lo hagan los lUsers. No. Únicamente hablo de la maldita programación en Java, sí ya sabéis:
write once debug everywhere! El mismo instalable no funciona igual en dos dispositivos. Y no estoy hablando de nada en particular. Un condenado juego 2D basado en sprites totalmente estandar en su programación Java NO FUNCIONA en un Motorola. Peta. Pasa. Se despelota en tu jeta. Y eso, jode. Por supuesto si la implementación de java en lo tocante a pixel-blitting difiere mejor ni imaginar qué pasará en zonas más dependientes aún del hardware (pongamos la cámara[3]) ó el Bluetooth[4]

Pero no todo son quejas por los teléfonos móviles, no ¡También tengo para los PC! De entrada a nadie en mi oficina se le ocurrió la maravillosa idea de desarrollar todo este tinglado en Linux. Eso redujo en algo mis penurias. Sin embargo no he dejado de sorprenderme por lo complicado que es trabajar con Bluetooth sobre un PC. Aunque no pude dedicarle demasiado tiempo, no he encontrado un modo de acceder desde ningún lenguaje a capa alguna de bluetooth. C++ ó C# ni siquiera por VB.

Así que tuve que buscar una vueltilla al asunto, para empezar, tenía que crear un servicio bluetooth al que el teléfono pudiese conectarse. Eso es posible hacerlo empleando un puerto serie de tipo servidor en el PC. Incluso en este punto hay dificultades ya que el driver que viene de serie con XP-SP2 es particular, digamos es especial. En la oficina tuvimos que reinstalar el bluetooth unas 15 veces hasta dar con los drivers de Belkin, probablemente heredados de un Win-2K o cualquier cosa de ese estilo. Mucho más completos y con un comportamiento mejor.

El puerto serie creado espera dos conexiones: por un lado se conecta la aplicacion en PC y por el otro el teléfono. Puesto que todo el resto del código lo tengo desarrollado en Java no me pareció una buena idea emplear otro lenguaje de programación y seguí por el mismo camino. Sin embargo Java y los puertos serie tienen una relación delicada, con un poco de suerte encontré RXTX. Biblioteca que empleo para conectar a puertos serie con bastante buen resultado.

Después vienen toda una catarata de pegas e inconvenientes. Los dispositivos deben estar emparejados y el puerto serie creado en el PC es un servicio. Lo que implica que puede desactivarse, anularse, borrarse, etc. Por si esto fuera poco además no depende de la aplicación que debe buscar cada vez los números de puerto. Una vez está en marcha es bonito ver la conexión. No me imagino a un usuario dando todos los minúsculos y minuciosos pasos que hay que dar para llegar a conectar ambos dispositivos.

Al final todo el montaje se apoya en un protocolo muy sencillo por paquetes de tamaño fijo. Donde cada paquete va armado con un checksum y varios números de serie. Esta capa de comunicaciones es la misma que empleo durante las etapas multiplayer del juego. Así que hurra por el desacoplamiento. Es, en realidad, la segunda vez que tengo que programar una pila completa de comunicaciones. Siempre es bonito y muchas veces complicado. Se trata de una aplicación naturalmente paralela. Aún es más: tiene que ser paralela o los bloqueos de esperas la pondrán de rodillas.

En lo tocante a multi-thread los teléfonos se comportan razonablemente bien siempre que uno no se dedique a crear y destruir constantemente hilos. Probablemente ese es el gran problema del sonido, necesitan un hilo propio y la implementación natural de “crear bajo demanda” resulta cara en memoria, en fragmentación y es terriblemente lenta.

En fin, espero que las webs de los proyectos estén arriba pronto para poder engancharlas desde estas páginas y que podais reiros conmigo de todo el montaje. Buena semana.

–
1. Os dejo el link a su videocrítica de The Orange Box. Tiene ya bastantes y todas merecen la pena. Yo tengo que verlas tres o cuatro veces para terminar de entender qué dice en muchas ocasiones. Merece la pena, porque es de los pocos críticos que conoce que no se toma demasiado en serio el negocio ^_^
2. Gracias por repararlo, os echábamos de menos
3. Algunos teléfonos tienen cámara pero no es controlable por Java, especialmente en los Serie 40, otros fingen que tienes control y luego no te devuelven imagen alguna, los foros de los fabricantes están llenos de amargas críticas al respecto.
4. Rechinar de dientes cada vez que pronuncio esa palabreja.

Esta semana no ha sido la mejor, por así decirlo, ni en mi curro (a pesar de avances importantes en recortar los consumos de memoria, tanto globalmente como dinámicamente) ni en desarrollos en casa. Sin embargo una nueva utilidad ha aparecido en mi radar: la extensión Subversion para el visual studio: ankhsvn. La estoy probando un poco y ha funcionado bien. No creo que llegue al nivelazo de la integración con sourcesafe, pero para entornos híbridos o con sistemas basados en unix puede ser útil.

Un pequeño resumen de la semana incluye:

1. Hemos probado el modo multiplayer de Guitar Hero 2 y terminar convencido de que no está mal, aunque el diseño de niveles no está pensado para jugar dos personas.

2. Mi DS ha vuelto a la vida y he probado el Metroid Fusion. Me ha llamado mucho la atención, junto al Castlevania: harmony of dissonance. Si alguno dispone de una DS ó una GBA hará bien en conseguir las dos joyas y jugarlas a fondo.

3. Como técnico de fin de semana sigo poco a poco volviendo a C++ y, para continuar con mi batalla por los formatos, he empezado a trabajar en la carga de ficheros .X manualmente. Las funciones de ayuda incluidas con las DX-utils facilitan mucho la vida a la hora de cargar mallas y “cosas normales”, pero qué pasa si por ejemplo quieres cargar una ruta, un mogollón de vectores, o cualquier otro elemento que no sea necesariamente rendeable: pues que tienes una situación en ciernes XD

He incorporado a la barra lateral, en la sección DirectX algunos enlaces a toymaker que he encontrado muy útiles para empezar a entender qué leches estaba haciendo cuando cargaba un fichero .X
También me ha resultado muy útil el foro de gamedev.

Algunas cosas a tener en cuenta son:
1. Es necesario precargar los templates sobre la estructura básica del fichero.
2. Al ser un desarrollo clásico de Microsoft, no todos los recursos son fáciles de alcanzar ni mucho menos,

#include "rmxftmpl.h" // Incorpora los templates precompilados
#include "rmxfguid.h" // Constantes de identificación de frame


El código de trabajo con ficheros de tipo X sera necesariamente muy recursivo y empezará con algo como:

LPD3DXFILE p_file = NULL;
D3DXFileCreate(&p_file);
p_file->RegisterTemplates(
D3DRM_XTEMPLATES,
D3DRM_XTEMPLATE_BYTES);
LPD3DXFILEENUMOBJECT p_xFileObject = NULL;
p_file->CreateEnumObject(
"Media\\file.x",
D3DXF_FILELOAD_FROMFILE,
&p_xFileObject);

Cualquier búsqueda en gamedev con alguna de las funciones que aparecen en los snippets anteriores os llevarán directos a ayudas y consultas completas.

Antes de entrar a currar a mi actual compañía y que la vorágine de cambiar de tecnología (DX/C++ –> MIDP/J2ME) me sorbiese hasta el tuétano había pillado la sana costumbre de regurgitar mis inmodestas opiniones por este canal. He visto algo que me ha llamado muchísimo la atención y tengo ganas de dejarlo por escrito y no olvidarme.

El ejemplo en cuestión se llama ContentStreaming. Como hace más tiempo de la cuenta que no machaco mi C++ estoy intentando digerirlo aún. Lo que sí os puedo anticipar es qué puntos trata:

1. Cacheado de recursos
2. Mapeado de ficheros en memoria en Windows
3. Carga anticipada
4. Multi-threading

Esencialmente este ejemplo te pone en la pista de las técnicas básicas para los modernos engines sin tiempos de carga. Parte de un fichero que genera proceduralmente de 3.3GBs y luego irá cargando según vaya necesitando rendear zonas del mundo en cuestión.
Mi intención es estudiar el ejemplo e ir posteando por este canal los resultados de la autopsia. Ya veremos cómo sale la cosa, o si se tuerce interferido por otras prioridades.

De vuelta al trabajo de fin de semana: sigo a castañas con problemas de formatos y conversiones entre ellos. Pero esta vez he decidido lurkear entre los foros de XNA sobre MOD y he llegado a algunas desoladoras aunque esperables conclusiones:

El soporte que da Softimage a través de MOD y XSI a DirectX es poco menos que un chiste[1]. Como ya venía diciendo en posts anteriores la exportación geométrica funciona bien, y la salida de coordenadas UV es directamente de chiste. No quiero ni imaginarme lo que ha de ser tratar de sacar animaciones del paquete. Dejaremos las animaciones para más adelante (que será otra odisea criminal)

Sin embargo, sí hay una solución y como siempre, desde el lado más gamberro del 3D: ¡blender! Blender dispone de un exportador out-of-the-box que funciona correctamente al generar .X

Efectivamente el procedimiento incluye pasar por .OBJ para llegar hasta el objetivo, quedando algo así:

1. Se genera todo el contenido sobre XSI + GIMP + nVidia texture tools + …
2. Se exporta a .obj
3. Se abre el .obj con Blender
4. Se exporta a .X

Este procedimiento es algo rústico, ya lo sé. Pero abre la puerta a generar contenido para .X sin necesidad de machacar ninguna versión de MAX; MOD es gratuíto y Blender es libre, y, si realmente te apetece se puede obtener todo el material desde Blender sin necesidad de pasar por la herramientita de XSI, lo que posiblemente sea la mejor opción al estar MOD severamente modificado y resulta en el ahorro de un cambio de formato con todas las pegas que esto tiene.

–
1. No he probado la versión 6.5 pero que no me vengan con hostias: las limitaciones al exportado eran severísimas: un sólo canal de textura por punto (clúster, para ser exactos), que luego había que escalar en las 2 coordenadas por -1.

Antes o después te toca subirte las mangas y ponerte todo ciego a mover punticos, aristas y caras; más o menos con toda tu buena intención y un poco de ayuda de Digital Tutors. La idea inicial, modelar algo vagamente orgánico, por ejemplo un insecto común: una libélula. Bien, tomé algunas referencias por la web, fotos y demás y me lancé al tema con mi mejor intención:

Es importante destacar que no soy grafista, ni mucho menos artista 3D. Así que la considero un lograzo, dado el tiempo que puedo dedicarle y lo especializado del asunto. Pero aquí, justo cuando tenía el modelo en ese estado, me dio un jamarazo y me decidí a probar el modelo sobre el visor de DirectX[1] Lo que me obligaba a emplear el exportador por defecto que tiene XSI (v.5.11) para sacar mallas a .X.

Por supuesto la geometría exporta más o menos bien, el problema más evidente viene del mapeado de texturas, cualquier parecido con la intención inicial del creador del modelo es pura coincidencia:

El modelo en XSI (a la derecha) tiene alas de madera y cabeza de leopardo[2] , se ve correctamente en el viewport DX9 construido dentro del propio XSI (situación que me hace creer que la cagué en algún paso intermedio probando el pintado de mip maps del artículo anterior y por eso se despelotaron las UVs)

No soy el único que se ha quejado de este exportador, y parece que la solución habitual pasa por no emplearlo en absoluto: se va a .OBJ y luego hacia .X empleando algún miembro de la familia Deep Exploration. En este mismo instante me estoy planteando otros modos de llevar mis pequeños abortos tridimensionales hacia algún render en tiempo real.

Resulta que Softimage está trabajando muy duro para darnos un empujoncito a los chicos que pretendemos ganarnos la vida con tiempo real tienen dos líneas principales de exportado que me llaman la atención: COLLADA y XNA [3]. La porra del XNA es que supone más madera, un entorno gestionado, un brinco más de lenguaje de programación, otra piedrita al montón de movidas que aprender en el poco, poquísimo tiempo libre del que dispongo últimamente.

–
1. Que viene de serie con el SDK así que lo tienes fijo.
2. Malditos pinceles por parches: dominan mi mente XD!
3. Y espero por nuestro bien que su exportador de .X en las versiones nuevas, sobre todo en la 6.5 le haga algo de justicia a los modelos

Ya lo dicen muchos: leer es malo porque da ideas. Y las ideas, pues ya se sabe, a veces, nos llevan a follones ^_^. Hace bastantes meses leí un paper,, que describía cómo en muchas ocasiones dejamos pasar buenas oportunidades de afinar nuestro render empleando recursos gratuitos[1] del pipeline. Y ya algo menos crípticamente, describía que se pueden editar los niveles de MIP para mancharlos de colores, parece evidente, pero es más potente y flexible de lo que parece.

El ejemplo del artículo era realmente bueno: supongamos que queremos rendear una chimenea cubierta por una finísima capa de hollín. Cuando la miramos directamente, es decir: perpendicularmente, podemos ver el cemento del que está hecha, quizá ennegrecido, pero vemos claramente el gris. Sin embargo, conforme alejamos la vista y observamos zonas más alejadas del tubo, este es progresivamente más y más negro. En un shader, podríamos emplear el ángulo que forma el punto de vista y la superficie para, empleando por ejemplo una textura degradada de un sólo píxel de ancho, obtener un factor de ennegrecimiento, eso es como mínimo un producto dot más una consulta de textura y probablemente una suma ponderada con respecto al color computado para el material base [2]. Lo que quizá sea demasiado para una maldita chimenea, que en realidad está ahí sólo como decorado, etc. etc.

El articulista proponía un camino lateral para obtener el mismo efecto. ¡Usar la cadena de MIPMap! Es decir: pintar de negro los MIPs más profundos, de modo que el filtrado nos dé ese oscurecimiento, sin necesidad de emplear más ranuras de shader: ¡todo pasa por la textura! Okydoky, echando memoria, recuerdo cómo era todo aquello y me digo: mañana de domingo, … no hay resaca a la vista, c’mon, lets do it!

Empecemos por la chimenea, algo suave y redondeado, … un cilindrito!

Vale, aprovechando que también estoy intentando pulir un poquito mi XSI, hago yo mismo el modelado[3], el mapeado UV y me monto una textura inicial. Y aquí es donde viene el problema: no tengo photoshop! Y tampoco tengo ganas de machacar ninguna versión, he decidido mantener algo más a ralla el volumen de software de origen oscurete que consumo: el GIMP tendrá que valer.

A esto, hay que añadir otra situación: me es físicamente imposible (por tiempo) aprender en profundidad muchas más cosas ahora, así que debo mantenerme en DirectX. Esto me lleva a usar DDS preferentemente ya que luego podré usar todas las demás herramientas que Hasefrocht incluye en su mastodóntico SDK.

OK, recapitulando: DDS + MIPMap y todo sobre XSI PERO no hay photoshop, esto va a ser divertido[4]!

Lo primero que se necesita es bajar el SDK de Microsoft, eso es más que evidente. Luego hay que hacerse con las tools de texturas de nVidia, que podéis bajar del site de: nVidia Texture tools. Todo es recomendable y el mundo de las texturas es gigantesco, pero lo único necesario es el paquete DDS Utilities. Con todo instalado se tira para alante y:

1. Se crea la textura difusa base y se deja bien guardada.
2. La textura base carece de MIPs así que hay que crearlos, para eso Microsoft nos ofrece una herramientita: Texconv.exe con la que podemos batchear una conversión a DDS más la creación de los MIP chains:

texconv -m 6 -f R8G8B8 -ft DDS tex_cilinder.png

Codigo que genera 6 niveles de MIP en RGB de 24 bits desde tex_cilinder.png.

3. Ok, tenemos los MIPs pero no podemos editarlos, al menos no fácilmente ya que no disponemos de photoshop. Aquí entra la utilidad de nVidia[5], en particular:

detach tex_cilinder separa el DDS inicial en toda la cadena de MIPs, es incómodo, pero vamos, se puede automatizar empleando un .bat, ó si dispones de una consola de verdad en tu sistema, pues miel sobre ojeras.

4. En este punto tenemos un puñao de ficheros que no podemos editar, de nuevo empleando las nVidia DDS tools:

readDXT tex_cilinder_00.dds tras lo cual tendremos TGAs, que sí puede editar GIMP.

Yo hice algo tan tontorrón como esto:

Como veis el mip inicial es más o menos plano y luego meto dos cambios muy muy cantosos para poder verlos fácilmente en el render.

5. En este punto hay que hacer el camino inverso TGA –> DDS y luego, recomponer el MIP chain:

texconv -m 1 -f R8G8B8 -ft DDS tex_cilinder_01.tga Notar que se le pide un mipchain de longitud 1

6. y para terminar, recomponer el MIP chain sobre un DDS:

stitch tex_cilinder

Y se termina obteniendo una textura en DDS con los MIP maps modificados. Ya con ese material volví hacia XSI y compuse un árbol de render sobre DX muy sencillo, sin shaders programables y con una simple textura, activé el filtro MIP y listo: como veis, las UVs se fueron de baras directamente, lo que me molestó muchísimo. Además no he encontrado un modo sencillo de crear un render de aspecto plano, es decir, con luz ultra-blanca desde cualquier punto, acabaré componiéndolo en un zeider…

La coña de esta técnica es que funciona. Es curioso verla en marcha, … llama la atención, impresiona, sobre todo porque el MIP-mapping suele ser un punto del render que solemos ignorar, simplemente está ahí y fuera.

El tortuoso camino de la conversión de texturas

Bien, el numero de pasos que hay que dar para editar un MIP-Chain es ridículo, pero de momento no se me ha ocurrido nada mejor (legalmente), si se me llega a ocurrir algo os lo haré saber, como siempre.

–
1. Sí, ya sé que lo único gratuito es no ejecutar absolutamente nada.
2. Lo que en sí mismo no significa nada: en una 8800 GTX te-la-suda!
3. Soy 1337, ¡he logrado modelar un cilindro! ¡Chúpate esa Baena!
4. Entre otras cosas porque la versión 5.0.x de XSI se da cada castaña con DirectX de alucinar. Se mete unos crashes por desconectar nodos de texturas que son de terror. Esperemos que la versión 6.5.x arregle y reenfoque todo el asunto.
5. Que viene con dos PDFs de ayuda, así que no incluyo ningún link para documentar.

Una nota muy muy breve acerca de esa vía de trabajo. Como muchos sabréis, estoy empezando a trabajar algo más en serio con XSI, modelado, un poquito de UV, algo de materiales, etc. Uno de mis objetivos es terminar pillándole el aire a toda la suite antes de que la versión 6.5 más MOD barran como de un plumazo el entorno de desarrollo de juegos.

Ha habido bastantes problemas, entre otros:
1. Reinstalación de las CG tools
2. Actualización de DX a la versión de agosto de 2007 (DX9)
3. Inclusión de sendos paths para pillar una librería DLL [1] que ha terminado estando en /XSI/Application/bin, en realidad esto era evidente pero resulta raro que el programa no se encuentre DLLs en la raíz del ejecutable, cosas que pasan.

Al final y mientras pruebo el funcionamiento del HLSL, que funciona, he encontrado incorrecciones en la guía de XSI (lo que me confirman los profesionales de la zona que es harto normal)

Tan pronto encuentre algún camino razonable para avanzar lo compartiré por aquí.

–
1. Sí, uso XP para esto XD

Antes de la mudanza de los blogs de cauterized probablemente escribí por aquí acerca de algunos grupillos y artistas que me habían descubierto por ahí. Lo más seguro es que entre ellos estuviese Bonobo.

Los conciertos de música moderna son difíciles de entender (al menos para mi) vas a un sitio atestado con una acústica muy mala donde el sonido se amontona. En los conciertos a los que he ido sólo he logrado escuchar al baterista, o sólo al guitarra ó una cacofonía metálica. Muy pocas veces la voz. Me resulta extraño, ¿será un tema técnico? ¿Será intencional? ¿Será el guaraná?

Y paseando por la calle, encontramos un cartelito que anunciaba Bonobo en la plaza Quintana. Un cartel enano. Una promoción mínima. Esto es Compostela, amigos! No había ido nunca a un concierto con DJ y el tipo me gusta mucho en su trabajo de estudio, así que nos presentamos ahí. Mi primera sorpresa fue que estaba acompañado por un tipo que se hacía llamar input select VJ. Y todo el sarao empezó a las 2230, nos fuimos de ahí a eso de la 0130 y recién terminaba el asunto. Me gustó mucho, lástima de frio para ser agosto. En mitad de aquello y pensando pensando me di cuenta de que no era la primera vez que estaba con un VJ. El hackmeeting de Sevilla incluyó fiesta y videos también.

Bonobo sonó cañón, quizá algo duro hacia el final, pero muy bien, Input select estuvo algo irregular, ¿quizá se le hizo muy largo el asunto? Por aquí podeis ver una reel de VJ.

Fuimos con una amigueta a verlo, espero que me pase un linkito a su flickr y pueda añadirle una foto a este articulo.

Llevo unos días interesado en insectos. En plantas pequeñas, en charcas. Intento explorar una idea acerca de un pequeño simulador de vuelo arcade con alguno de esos elementos. Me pego las horas libres pensando en libélulas, en hierba, en juncos. Así que observo las plantas con mucha más atención, cómo se mueven con el viento, qué pasa cuando algo las toca, …

Y, con este recién redescubierto interés por lo vegetal, volviendo de Vigo por la AP-9 he visto mi primer incendio y no hablo de fuego en la lejanía, sobre una colina, no. Hablo de fuego ahí delante, justo en la mediana de un carril de incorporación, con bomberos y voluntarios de protección civil cruzando la autopista mientras los civiles refrenan el tráfico.

Da bastante respeto. Las llamas se elevan rápido y el olor es fuerte. No quiero ni imaginarme cómo fue el verano del año pasado, con toda la zona en llamas. Entiendo que en verano los incendios son lo normal. Sin embargo son reales y dan un miedo que te cagas XD