Parece que estoy incubando algo. Espero que sea un simple resfriado y no una gripe. En este momento, después de tomarme una aspirina, ya estoy mejor, por eso aprovecho para añadir una nueva entradilla aquí.

Hace unos días, mientras ultimaba la nueva versión de DeVeDe, encontré un molesto bug en el widget Gtk.FileChooserButton; en concreto en el método set_filename(). Cuando el usuario pulsa el botón Propiedades para cambiar las propiedades de una película (tasa binaria, resolución…), uso ese método para rellenar dicho FileChooserButton con la ruta completa del archivo correspondiente; sin embargo, a veces (no siempre) fallaba, quedando el widget vacío. Tras hacer varias pruebas llegué a la conclusión de que era totalmente aleatorio: no dependía de la longitud del nombre, ni del directorio en que se encontrase, ni del número de niveles… el mismo archivo a veces aparecía correctamente en el widget y otras veces no. Con Ubuntu 7.04 (que usa GTK 2.10) dicho fallo no ocurría (que yo recordase, al menos).

Dado que no tenía claro si el error estaba en GTK o en los bindings para Python (PyGTK), durante el fin de semana hice un pequeño programa de prueba en C. El resultado es que, efectivamente, el error es de GTK. Además probé el mismo código en una Ubuntu 7.04 y, tal y como sospechaba, no falla (por lo que vi en la lista de cambios de GTK 2.10 a 2.12, los desarrolladores hicieron muchas mejoras en la clase FileChooser). El problema realmente gordo es que todos los intentos por esquivar el problema han fallado, lo que significa que mientras no lo corrijan, DeVeDe no funcionará correctamente 🙁

De momento he notificado el bug y he añadido una nota en la FAQ de DeVeDe. Mañana o pasado (cuando la cabeza deje de darme vueltas) publicaré la nueva versión.

Mi caja actual tiene un pequeño fallo de diseño: el conector frontal de USBs está muy cerca de la salida de auriculares, por lo que no puedo conectar a la vez los cascos y mi reproductor de MP3 para grabar cosas en él. Sin embargo, un poco más separada está la conexión de micrófono, por lo que se me ocurrió hacer un par de puentes para que el sonido salga por ésta, y así no tener problemas. Llevaba tiempo queriendo hacerlo, pero hasta hoy no saqué ganas.

¿Y qué tiene que ver ésto con el título? Bueno, la última vez que usé un soldador para hacer alguna chapucilla propia fue hace casi dos años, cuando amplié la memoria de mi Z88, y es también la primera vez que lo uso desde que me independicé. Volver a cogerlo, aunque fuese para algo tan sencillo, ha sido realmente agradable. No te das cuenta de lo mucho que echas de menos hacer algo hasta que lo vuelves a hacer y disfrutas. Llevo tanto tiempo concentrado en mi trabajo y en mis proyectos de programación que tengo la electrónica completamente abandonada.

Después de ésto quiero hacer algún proyectillo nuevo, pero antes tengo que comprar una mesa adecuada. ¿Por qué no hay un Ikea cerca cuando lo necesitas?

Parece que no ha bastando con usar la versión del SVN de Mplayer/Mencoder para solucionar los problemas: al generar DVDs en formato PAL, en algunos casos lo hace en blanco y negro, amén de otros pequeños problemas.

Ante ésto he preferido curarme en salud y he retrocedido a la versión 0.99pre8; para ser más exactos, la que venía en Ubuntu Edgy. Dicha versión funcionó siempre razonablemente bien.

Para evitar más problemas de dependencias, he preferido empaquetar sólo los ejecutables en un tar.bz2, e incluir un script que sustituya los que ya haya en el sistema por los «nuevos». Esto lo hace, además, compatible con cualquier distribución, y no sólo con Ubuntu.

Actualización: por petición popular he añadido otro paquete con Mplayer/Mencoder para 64 bits.

Parafraseando a Germán Poo, la llegada de la nueva Ubuntu Feisty no es para montar una fiesta, precisamente. La razón es que la versión que trae de Mencoder (la 1.0-rc1, actual versión estable) tiene un fallo al codificar el sonido, con lo que DeVeDe es completamente inútil.

El bug lleva tiempo coleando, y la única solución en estos momentos parece ser utilizar la versión en desarrollo, sacada del SVN (en mi web, por despiste y costumbre, hablo de CVS. ¡Perdón, perdón!). Como una cosa es hacer un sudo ./install, que cualquiera lo hace, y otra muy distinta bajarse fuentes de un SVN y descubrir qué bibliotecas son necesarias para compilar un programa tan complejo como MPlayer/Mencoder, he decidido hacer yo mismo un paquete .deb con la versión del SVN del 14 de abril de 2007, compilada sobre Feisty, para que los usuarios no queden atados.

Comentaba en mi anterior entrada «¿Termoqué?» la dificultad que estaba teniendo para encontrar un disipador adecuado para mi nuevo equipo. Y no es para menos: paso mucho tiempo delante de la pantalla y lo último que quiero es una turbina de avión destrozándome el oído.

Después de muchas pruebas y mediciones (de tamaño: la nueva caja tiene un travesaño que limita la altura del disipador) me decanté por un Zalman CNPS8000. Este disipador tiene un tamaño adecuado para entrar en la caja y es muy silencioso (a baja velocidad, claro). El único defecto es que la regulación de velocidad es manual. Afortunadamente mi nueva placa es una ASUS con tecnología Q-Fan. Este sistema, propio de ASUS, permite a la BIOS controlar la velocidad de giro de cualquier ventilador (no tiene por qué tener cable de control de velocidad) en base a la temperatura de la CPU, exactamente igual que hacía mi viejo Artic Cooling. El resultado es justo el que quiero: trabajar con mi ordenador disfrutando en todo momento del máximo silencio posible, y sin tener que preocuparme de si el procesador se puede estar sobrecalentando.

Cuando era joven me gustaba jugar al UFO: Enemy Unknown. En él, tu misión consistía en defender a la tierra del ataque de diversas hordas alien, creando bases, investigando nuevas tecnologías, capturando naves y fabricando nuevas armas. El juego tenía dos modos: uno de pura estrategia, en el que se controlan las distintas bases y se decide qué temas se investigan, qué dispositivos se fabrican, qué nuevos soldados o científicos se contratan, etc. También es este modo se detectan los ovnis y otras amenazas y se pueden lanzar ataques contra ellos.

El otro modo, al que se pasa cada vez que se derriba un ovni o se llega a una ciudad atacada o base alienígena, está basado en un sistema de combate por turnos. En él debes localizar a todos los aliens que hay y matarlos o capturarlos. Si lo consigues, te haces con toda la tecnología que hayan dejado, la cual se puede investigar (para replicarla) o vender (para ganar más dinero).

El juego era endiabladamente bueno, y gracias a sus excelentes gráficos e increíble música conseguía sumergirte de lleno en la historia, así como hacerte dar más de un respingo cuando, en alguna fase de combate por turnos, aparecía de pronto uno de los aliens y atacaba a tus hombres.

Todo ésto viene a cuento porque hace tres días me reencontré UFO: Alien Invasion, un remake del UFO original basado en el motor gráfico del Quake 2. Ya lo había visto hace un año, pero de aquella sólo estaba lista la parte de las misiones de combate. Ahora, sin embargo, toda la mecánica de estrategia está lista también, así como la música, y sólo falta pulir algunos detalles, añadir la UFOpaedia (u OVNIpedia) e implementar el hilo conductor de la historia original. Estuve jugando estos días y el resultado no puede ser mejor.

En la página hay versiones para Windows y para Linux, estas últimas en forma de paquete .DEB (para Debian testing e inestable). En Ubuntu, en principio no se puede instalar porque el paquete depende de la libasound2 versión 1.0.12 o superior, mientras que Ubuntu dispone de la versión 1.0.11. Sin embargo, basta con bajarse la libasound de Debian (añadiendo también, si es necesaria, la libasound2-dev de Debian) e instalarlas con DPKG.

Hace unos días me pasaron un enlace a un libro titulado Designing analog chips. Este libro, disponible en formato PDF, fue escrito por Hans Camenzind. Para los que no le conozcan, diré que es el diseñador de uno de los más famosos cirtuitos integrados analógicos (situado justo después del amplificador operacional): el 555.

El libro comienza con una introducción teoría básica de los semiconductores y su funcionamiento en los principales componentes analógicos (diodo, transistor bipolar, FET…). A continuación entra de lleno en el tema de la simulación dedicándole un capítulo entero, y ya sin más dilación comienza a explicar los principales montajes analógicos: espejos de corriente, amplificadores operacionales, temporizadores…

Estoy empezando a leerlo con calma, pero después de echarle un ojo por encima debo reconocer que tiene una pinta impresionante. Lo más interesante es que se centra sobre todo en el aspecto práctico, y además mediante un lenguage muy asequible que lo hace todavía más interesante.

Creo que hace unos años habría matado por tener este libro, cuando me tuve que enfrentar a Dispositivos Electrónicos (1 y 2) y a Electrónica Analógica.

Llevo una temporada pensando en cambiarme de ordenador. A fin de cuentas, un Durón a 1’3GHz es algo que ya empieza a estar obsoleto. Por otro lado debo reconocer que en el fondo es un capricho, pues salvo porque los vídeos de YouTube van algo justitos, el resto me va perfectamente; por eso mi intención era no gastarme mucho dinero.

Decidí tirar por un Sempron 3000+, pues las últimas versiones tienen soporte de 64 bits y, al estar fabricados con tecnología de 90nm, disipan muy poco, y como soy un fanático del silencio es algo que me viene genial, pues eso significa menor velocidad en el ventilador del disipador. Por supuesto eso implicaba un ventilador termorregulado, similar al modelo de Artic Cooling que tengo ahora, el cual ajusta su velocidad automáticamente en función de la temperatura del procesador.

¡Cual sería mi sorpresa al encontrarme con que no hay disipadores termorregulados para AMD! Bueno, miento: supuestamente, los disipadores que vienen de fábrica con el propio procesador sí son termorregulados, de manera que al combinarlo con la tecnología Cool’n’Quiet se consigue una reducción efectiva del ruído. Pero los disipadores de terceros, como Zalman o Termaltake, parecen dividirse solamente en dos categorías: velocidad regulada manualmente (son disipadores muy poco más grandes de lo normal y que incluyen un potenciómetro para que ajustes tú mismo la velocidad) o «de bajo ruido» (disipadores gigantescos con ventiladores que funcionan a baja velocidad, pero siempre a la misma). No tienen ninguno termorregulado (o, al menos, yo no he encontrado ninguno).

Así pues, sólo tengo tres opciones, y todas tienen inconvenientes, en concreto:

• El disipador «de fábrica»: no se hasta qué punto será silencioso, sobre todo si tenemos en cuenta que algunas placas de Asus incorporan una tecnología que monitoriza la temperatura del procesador y baja aún más la velocidad del ventilador (bajándole el voltaje).
• El disipador de ajuste manual: ni de coña. En pleno siglo XXI no pienso ajustar yo mismo la velocidad cuando es algo que se puede hacer automáticamente y por muy poco dinero. Además, un elemento mecánico como un potenciómetro es mucho menos fiable que un componente 100% electrónico, como es un sensor de estado sólido.
• El disipador «de bajo ruido»: no sirve cualquier placa ni cualquier caja, pues pueden tener diámetros de hasta 15 cm y podrían tropezar con algún condensador. Además suelen pesar más de 600 gramos, cuando las especificaciones de AMD indican que el disipador no debería superar los 450 gramos; esto puede ser un problema al trasladar el equipo en un coche, por ejemplo.

Probablemente lo que haga sea probar el disipador «de fábrica», y si veo que no me convence ir a por uno «de bajo ruido».

Los Pentium 4, por su parte, han resuelto ésto de otra manera: según leí en Tom’s Hardware hace tiempo (lo siento, no tengo el enlace) las últimas versiones llevan ventiladores con cuatro hilos en lugar de tres, usándose el cuarto para controlar la velocidad de giro desde la propia placa (supongo que basándose en la temperatura medida por el sensor interno del procesador). De todas maneras, un Core Duo se sale de presupuesto, y un Prescott se calienta demasiado, así que será AMD.

Como habreis notado, la web, el blog y mi correo han estado caídos durante una semana entera por culpa de una mudanza de mi hoster. Afortunadamente parece que ya vuelve a funcionar todo, así que aprovecharé para sacar una copia de seguridad de las entradas (que los servidores los carga el diablo }:-)

Hace muchos años, cuando aún usaba regularmente mi querido Spectrum, conocí un juego que me impactó: Elite. El juego fue uno de los primeros -si no el primero- en usar gráficos en tres dimensiones para las partes del espacio. Por supuesto eran gráficos simples, formados únicamente por líneas, sin texturas en las caras, pero utilizaba un algoritmo (bastante simple) para borrar las caras posteriores, lo que producía la ilusión de que las naves y estaciones eran sólidas.

¿Y a qué viene ésto? Pues a que hace unos días encontré Oolite, un clon del Elite original escrito en Objective C y que utiliza OpenGL para la parte gráfica.

La mecánica del juego es la misma: comprar barato en una estación espacial, vender caro en otra, y en el viaje entre ambas defenderte de las naves que te ataquen, al más puro estilo arcade. Al igual que en el juego original también se puede vivir del contrabando, de la minería de asteroides, o directamente del saqueo. La gran diferencia, aparte de los gráficos mejorados, es que los enemigos son más listos que antes, y ahora, además, el universo ya no gira en torno a tí, sino que te puedes encontrar con grupos de mercaderes que van a su bola, policía galáctica más atenta a lo que les ocurre a otras naves, grupos organizados de piratas que lo mismo te atacan a tí como a otros…

El resultado es una gran recreación del juego original, pero actualizado a los nuevos tiempos. Aunque no es el primer intento: hace un año ya había encontrado Elite – The new kind. Este programa fue creado directamente a partir del código original del juego para el BBC modelo B, aunque luego se le añadieron algunas mejoras visuales, como por ejemplo gráficos con caras coloreadas, lo que hacía que las naves fuesen realmente sólidas. Sin embargo esa versión no me acabó de enganchar, en buena parte porque de aquella no tenía joystick, y controlar una nave como ésta desde teclado no es sencillo.