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.