¿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.

Sobre los problemas de PSeInt en Mac OS

Desde hace meses venía recibiendo reportes de usuarios de PSeInt en Mac advirtiendo que una vez iniciado el editor, no se abrían ni la ventana de ejecución, ni el editor de diagramas de flujo (o sea que era completamente inútil). Y era un problema que no podía reproducir yo mismo, así que me era muy difícil de analizar, mucho más de corregir. Finalmente la semana pude hacerlo, encontré una solución que publiqué hace unos pocos días. Pero esto destapó viejos problemas en mi modelo de desarrollo para Mac OS; problemas que ya conocía y sabía que eran un bomba de tiempo.

Deshacer y rehacer con menos riesgos

Me pasa muchas veces, cuando estoy programando algo suficientemente complicado como para no tener claro de entrada cual es la mejor solución, que a lo largo de la sesión escribo y borro varias alternativas. Y muchas veces ocurre, que después de probar la enésima versión sin éxito me doy cuenta de que en realidad la mejor era la primera, la tercera, o alguna de las anteriores, para el caso da igual.

Sin embargo, como ninguna versión funcionaba lo suficientemente bien de entrada, ninguna fue commiteada al repo, así que probablemente ya no las tengo... ¿o si?

Combinando plantillas en ZinjaI

Muy lentamente, la variedad de complementos para ZinjaI va creciendo. La mayoría de ellos corresponden a bibliotecas como GLUT, wxWidgets, OpenCV, SFML, SQLite, etc. Entre otras cosas, lo principal que provee la biblioteca es una configuración de las opciones de compilación y enlazado lista para poner un proyecto en marcha en tres clicks. Esto sería probablemente lo más difícil de reemplazar para muchos usuarios. No me simpatiza, pero las consultas que recibo me demuestran que muy pocos se toman el tiempo de entender qué hacen realmente el compilador y el IDE por debajo; y se limitan a usar la configuración que viene con la plantilla como caja negra... mientras funcione.

ZinjaI+GIT y scripts de bash con interfaz gráfica

Iba a empezar describiendo lo maravilloso que es git, pero voy a dar eso por sentado e ir al grano: ¿cómo es que en ZinjaI no hay ninguna funcionalidad específica de integración con git? Antes de que se ilusionen, les adelanto que no, no estoy trabajando en eso. Peeeero... además de justificar mi no, en este post les cuento cómo integrar igual algunas acciones habituales.

Participando en el CodeJam con ZinjaI

El fin de semana pasado comenzó el Google Code Jam, ese contest online de programación que organiza Google. Pero este año cambiaron un poco las reglas de la mano de un cambio grande en el entorno sobre el cual se desarrolla. Eso hizo que sea un poquito más incómodo desarrollar las soluciones desde mi IDE preferido. Acá les cuento cómo acomodar ZinjaI para que el "workflow" durante el contest sea algo más fluido, dado que a partir de la 1er ronda la cosa es por tiempo, se pone ajustada, y cada segundo cuenta.

Organización de los archivos de un proyecto (parte 2)

En en el post anterior comenté sobre los motivos para organizar los archivos de un proyecto de una forma más estructurada que la que ofrece ZinjaI al crear un proyecto, y sobre una estructura de subcarpetas más o menos habitual en proyectos medianos. Ahora toca ver cómo adaptar el proyecto de ZinjaI a esta nueva organización.

Organización de los archivos de un proyecto (parte 1)

Casi todas las plantillas de proyecto de ZinjaI crean una única carpeta en la que los fuentes, el archivo de proyecto y eventuales extras van juntos, y solo se separan en una subcarpeta (debug/release) los archivos generados en la compilación. Esto es lo más directo para empezar, y funciona bien cuando es un proyecto pequeño.

Pero cuando los binarios empiezan a requerir archivos de datos/recursos, el proyecto crece y tenemos varias decenas de fuentes, la arquitectura se complejiza y empezamos a dividir en módulos o bibliotecas, etc; entonces esa organización se vuelve engorrosa, la carpeta del proyecto, una ensalada; y hay que hacer algo al respecto.

La mayoría de los alumnos no considera esto hasta que es demasiado tarde, simplemente por falta de experiencia (o al menos eso me pasó a mí y lo aprendí por las malas).

¿Qué va en el instalador?

Supongamos que hicimos una aplicación con ZinjaI, y ahora la queremos distribuir. No vamos a pretender que cualquier usuario que quiera usar la aplicación deba instalar ZinjaI, los complementos y conseguirse el código fuente, ¿no? ¿No? ¿Nooo? !NO! Lo razonable es armar un instalador que copie en el sistema del usuario el ejecutable de nuestra aplicación y cualquier otra cosa que esta necesite. De eso habla este post; de cómo generar ese ejecutable y cómo determinar qué más necesita.

MinGW64 disponible como complemento para ZinjaI

Finalmente logré hacerme un poco de tiempo para completar la compilación de las bibliotecas de la sección complementos con mingw64, y empaquetar todo, también al mismísimo compilador. Dejó aquí instrucciones para instalar y usar esto, junto con algunas aclaraciones importantes para quienes no tengan del todo claro qué implica el cambio de compilador.

Nota obvia: Este post es solo para quienes utilizan ZinjaI en Windows; ya que en GNU/Linux el compilador no depende de ZinjaI, sino de la distribución de GNU/Linux que se use.

Release vs. Debug

He visto cosas que ustedes no creerían: programadores haciendo benchmarks de código sin optimizar, generando instaladores con ejecutables en modo debug, desdoblando loops a mano, haciendo inlining mediante copy-paste, distribuyendo los .o y olvidándose los dlls, rayos-C++ brillar en la oscuridad cerca de la puerta de Tannhäuser... Y hablo de alumnos avanzados de la carrera, hasta algunos egresados.

Pensaba en escribir un post sobre cómo distribuir un programa generado con ZinjaI (mayormente sobre qué va en el instalador), pero inmediatamente noté que un punto importante era de esto de compilar en modo "release"... y entonces me parece mejor aclarar ese punto antes de continuar, y dejar lo del instalador para la próxima.