The Nightmare before Christmas

Improbable que unos días antes de Navidad se encuentre usted inmerso en los ajustes finales de un salvapantallas (protector de pantallas/screensaver). Su salvapantallas utiliza OpenGL para el renderizado, y corre en Windows. Flujos lógicos perfectamente sincronizados, compiladores felices, arte gráfico hermoso. Prueba A superada. Prueba B superada. El problema apareció en la prueba N. En específico, que su salvapantallas funcionó perfectamente en todas las máquinas, menos en aquella laptop con gráficos Intel. En esa máquina, triste e inexplicablemente, su salvapantallas no dispone de aceleración 3D. La máquina es capaz de aceleración 3D -mil veces comprobado-, y sin embargo, su lindo salvapantallas no puede aprovechar dicha aceleración. En esa laptop, su salvapantallas se ejecuta con una lentitud intolerable, parece un aborto en software. ¿Por qué todos los otros programas corren con aceleración 3D en esa laptop, pero su salvapantallas no? ¿Por qué? ¿Razones esotéricas? Después de todo, a nivel de ejecución, un salvapantallas es simplemente un ejecutable con extensión “scr” (obviemos, por innecesarios, los detalles sobre el procesamiento de la línea de comandos, el enlace con scrnsave.lib -si elige esa vía-, y algún otro escarmiento propio de los salvapantallas). Deseo que no pierda vitales minutos de su vida prisionero de dicha pesadilla. La razón -o sinrazón- del fiasco está aquí. Si observamos con cuidado, la única diferencia entre su salvapantallas y el resto de ejecutables que sí reciben aceleración 3D es la extensión del archivo. Alguien, en alguna parte del sistema, está detectando la extensión “scr” de nuestra aplicación y le niega la aceleración 3D. Bueno, cambie la extensión. En vez de “scr”, use “sCr” o algo así. Parece tonto -y lo es- pero funciona. De nada.

This entry was posted in programming and tagged , , , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

One Comment