Archivo por años: 2011

FBZX vuelve a la carga

Estos meses estoy trabajando como loco, así que poco tiempo he tenido para corregir cosas. Tengo una cola de mejoras pendientes para Devede que crece día a día, pero hasta que tenga lista la primera versión del nuevo proyecto no me quiero poner con otra cosa.

Pese a todo, he sacado un poco de tiempo para corregir un pequeño bug en el sistema de sonido de FBZX: al utilizar ALSA no definía el tamaño del buffer, sino que asumía que el asignado por defecto era adecuado. Hace unos años funcionaba porque ese valor era de unos 4Kbytes, pero algo han hecho (al menos en Ubuntu) y lo han aumentado mucho, por lo que el emulador iba a trompicones (utiliza el sistema de sonido para ajustar la velocidad). Con OSS o PulseAudio funciona bien, por eso el error pasó desapercibido. La nueva versión 2.4.2 lo corrige.

Entre signos anda el juego

Una de las frases preferidas de mi madre es Está el viejo muriendo, y está aprendiendo; y como en la gran mayoría de los refranes, hay una grandísima verdad oculta en ella.

Y es que estos días estoy peleándome con el micro ARM de un TomTom, y me encontraba con que el código que iba perfectamente en mi PC daba un fallo rarísimo en el GPS: al imprimir el carácter ‘/’ no lo hacía bien; pero sólo ese, el resto los renderizaba perfectamente. Después de mucho depurar, descubrí que el fallo era debido, nada menos, que al signo de una variable. Y es que, a pesar de utilizar el mismo compilador (GCC) para ambos casos, resulta que un char a secas en PC es signed, como todo el mundo asume, pero en ARM es unsigned, por lo que un valor que tenía que ser -1 se convertía en 255 (la segunda parte del problema es que luego operaba con ese valor y con otro de 32 bits, con lo que, al añadirle los 24 bits restantes, no expandía el bit de signo). Una vez añadido el modificador correspondiente, todo pasó a funcionar perfectamente.

Así pues, nunca deis por supuesto el signo de una variable. Consejo de amigo.