Actualización de PSeInt: las mejoras que se ven

Ya escribí en lineas generales sobre los problemas y las soluciones de la actualización de wx en PSeInt y ZinaI. Ahora seguramente vendrán cada tanto posts con detalles de cosas más particulares. Nuevas funcionalidades, o nuevos problemas específicos de alguno de los dos que valga la pena comentar. En este, el detrás de escena de las dos diferencias más notorias en la última versión de PSeInt: las anotaciones, y los operadores unicode.

Finalmente, el paso a wx3 y unicode en Zinjai y PSeInt

Hace años que me quejo de mí mismo por estar atado a la versión 2.8.12 en modo ansi de wxWidgets. Siempre decía que el cambio a las versiones 3.x, junto con el paso al modo unicode, requería muuucho trabajo. Necesario, sí, pero demasiado para el poco tiempo que disponía. El problema de macOS y los 64bits me obligó a concretar en parte la tan postergada migración de PSeInt. Quedaron conviviendo ambas versiones, y de a poco la versión 3 fue ganando terreno. Sin embargo, culpa de estos cambios aparecieron errores nuevos, algunos bastante notorios.

Un volante virtual para GNU/Linux

En épocas de aislamiento obligatorio hay que invertir el tiempo libre en casa. No es que tenga más tiempo libre, solo que funciona distinto. Entre las cosas que empecé (o que volví) a hacer a cambio de las que temporalmente no puedo está jugar videojuegos. Tenía desde hace años una deuda pendiente con el fantástico Grand Prix 4 de Geoff Crammond. El problema fue que mi viejo joystick comenzó a fallar a mitad del campeonato. En un simulador, es muy importante que la entrada sea analógica; el teclado degrada mucho la experiencia. Y tenía que resolverlo sin salir de casa.

La docencia, el paso del tiempo y el sentido común

Como todos los años, cuando están por empezar las clases, paso por una etapa de introspección durante la preparación de ese primer contacto con los nuevos ingresantes. Ya llevo casi 15 años "enseñando". Y ya he pasado también más de 15 "aprendiendo", la mayoría de ellos formalmente entre las carreras de grado y posgrado. ¿Quiere decir esto que soy un gran docente? ¿Que la tengo reee-clara en esto de la educación? Terminantemente NO! Hacerlo muchas veces no implica hacerlo bien si no hay mejora entre una y otra vez, si se repiten todos los años los mismos errores.

Reduciendo las dependencias de PSeInt en GNU/Linux

Así como me vi obligado a repensar el "paquete" de PSeInt para macOS a raíz del problema de los 64bits; tuve problemas similares en GNU/Linux. Para empezar, una de las principales bibliotecas del sistema que necesito ya no aparece en todas las distribuciones. Por seguir, una nueva que agregué por el tema del renderizado de texto también trajo sus problemas.

Renderizado de Texto en el Editor de Diagramas de Flujo

Encontré casi por casualidad una idea para renderizar fuentes con OpenGL aparentemente mucho mejor que la que venía usando en el editor de diagramas de flujo de PSeInt (psdraw). Mi sorpresa fue grande. Conocía el concepto, pero no implementado de esta forma. Para esa aplicación (texto), resulta muuuy simple y los resultados son muy buenos.

Los desafíos de portar PSeInt a macOS Catalina (3/3): Los últimos detalles

Ya conté los problemas y soluciones para poner en marcha un toolchain para las nuevas versiones de macOS, y la migración del código de wx 2 ansi a wx 3 unicode, en GNU/Linux. Solo me faltaba combinar todo esto para ver si andaba en macOS, si tenía un paquete para publicar en el sitio. Por supuesto que no anduvo a la primera. He aquí los últimos detalles de esta historia.

Los desafíos de portar PSeInt a macOS Catalina (2/3): PSeInt vs. wxWidgets

Siguiendo con la serie de problemas y soluciones relacionados a la compilación de PSeInt para macOS Catalina, ahora toca hablar de la relación entre PSeInt y la biblioteca wxWidgets. Resumiendo: PSeInt estaba escrito para una versión muuuy vieja de wx; y además cuando lo empecé había dos formas de compilar wx, y PSeInt usaba la que ya casi no existe. Por esto, aún teniendo un toolchain nuevo que puede compilar una wx nueva, el código de PSeInt requirió de muchísimos cambios y ajustes.

Los desafíos de portar PSeInt a macOS Catalina (1/3): El Toolchain

Finalmente PSeInt anda (eso parece) en macOS de 64bits! Las versiones anteriores eran de 32bits, y la novedad en macOS Catalina es que ya no acepta aplicaciones de 32bits. Las versiones previas de macOS habían empezada a avisar que en cualquier momento esto iba a suceder. Pensé que esperarían más tiempo, pero no, pasó, y PSeInt no estaba listo.

¿Por qué? ¿No es simplemente recompilar todo con otras banderas? Resulta que no, que tenía vaaarios problemas. El primero de ellos era obtener acceso fácil (automatizable con scripts) y permanente (no una mac prestada, algo que tenga siempre en mi propio sistema) a un toolchain adecuado.

Reviviendo una vieja funcionalidad de ZinjaI

En algunos prácticos de computación gráfica les damos a los alumnos programas que implementan algo visto en teoría para que experimenten: a) cambiar cosas, predecir el resultado y validar la predicción; b) pensar un resultado, deducir qué hay que cambiar, y validar la deducción; o c) si todavía no pueden predecir ni deducir nada, cambiar al azar y observar para desarrollar una primer intuición de qué hace cada cosa. Entonces, quiero programas donde sea fácil y rápido cambiar cosas.

Podemos empezar por decir que para cambiar el estudiante debe modificar el código, pero eso puede hacer que el loop de retroalimentación sea lento y tedioso. El plan B es programar alguna interfaz; pero como usamos bibliotecas muy simples (como FreeGLUT), no hay widgets o similares. Las alternativas parecen ser: a) programar controles propios, pero entonces es más código accesorio para ensuciar el ejemplo; b) usar mejores bibliotecas, pero entonces agregamos otra dependencia. Pues bien, ZinjaI viene al rescate con una tercera opción.

¿Será Vulkan un "reemplazo" para OpenGL?

Abrir una ventana y dibujar un triangulo. Uno feo, uno cualquiera, liso o vacío, da igual. ¿Cuán complicado puede ser? En C o C++, con GLUT y OpenGL 1.x, me van unas 40 lineas de código. Parece mucho para un simple triangulito, ¿no? Creo que en Basic me llevaba 4 instrucciones... y mi primera tortuga lo hacía en 6.

Pues verán que no es tanto cuando les cuente que con GLFW + OpenGL 3.x me llevó casi 200 lineas (y sin contar los shaders)... Pero eso tampoco es tanto: Con Vulkan pasé las 900 antes de dar a luz al 1er triángulo... ¿Es Vulkan una API terrible?

Solo se que se muy poco

Hace ya más de 13 años que "doy clases" en la universidad. Empecé como ayudante cuando era alumno y de a poco creo que fui creciendo. Hasta ahora formalmente siempre era JTP/ayudante de otros titulares. Este año, cuando empiece "Computación Gráfica", será la 1era vez que estaré como máximo responsable de una materia.

Estoy en la cátedra desde hace varias cursadas, y el titular anterior nos daba muchísima participación, así que podría decir que estoy preparado. Además, él había pensado y repensado mucho el armado de la materia, no era solo seguir un libro, así que parto de una muy buena base como para lograr un dictado más que decente. Peeeero....

Dos libros negros

Hacia rato que quería escribir sobre lo [poquito] que hice en las vacaciones. Van a ser dos posts relacionados a la computación gráfica, pero muy diferentes. En este les voy a contar sobre dos lecturas muy particulares: el Libro Negro de la Programación Gráfica, de Michael Abrash; y el Libro Negro del Motor de Juegos del DOOM, de Fabien Sanglard. Siempre digo que me gustaría que las carreras de informática incorporaran una materia "Historia". Si no conocen a Michael Abrash, o a John Carmack, están reforzando mi premisa.

Arrancando (tarde) el 2019

Después de un largo silencio retomo la actividad en el blog, y comienzo con las releases y posts de 2019.

**beep**ing Anti-Virus

Advertencia: Estoy muy muy enojado.

Este año tuve que dedicarle muchísimo más tiempo a combatir el problema de los falsos positivos por malware en los instaladores de ZinjaI y PSeInt, que a desarrollar nuevas funcionalidades o a corregir otros problemas más importantes. Y por falso positivo entiéndase un Anti Virus increíblemente estúpido (o sea, casi cualquiera) afirmando la presencia de malware donde NO LO HAY.