¡Habemus editor!

Diciembre 2, 2006

Imagen 8.png

Llevo un montón de tiempo sin escribir nada, vaya. Me he dedicado a implementar la parte del editor de transparencias y bueno, faltan muchas cosas todavía pero creo que el camino elegido da resultados rápidamente. No me arrepiento de la cantidad de trabajo que ha resultado crear un toolkit, la verdad.

Por fin Cabaret tiene un editor con el que podemos crear diferentes objetos, moverlos, organizarlos y editarlos. El editor de textos no es muy bueno, pero algo es algo. Por otro lado hay una ventana “inspector” (rollito mac) que presenta las propiedades de los objetos que vas seleccionando y, bueno, creo que va mas o menos bien. Por otro lado hay un nuevo menú para ver la presentación a pantalla completa y el organizador de la presentación parece que va bien (había un pequeño bug tonto pero ya está solucionado).

Mas cosas. He creado un álbum de flickr donde hay unos pantallazos de todo esto, no son muy espectaculares pero creo que muestran cómo va la aplicación. Están en

http://www.flickr.com/photos/voiser/sets/72157594401882791/

Lo próximo creo que será empezar con las transiciones.

No me gustan las transiciones tipo vídeo BBC (Bodas, Bautizos y Comuniones), es decir, ese rollo Powerpoint cutre con cortinillas y persianas, o textos dando vueltas o cosas así. Trataré de que sean lo más sencillas, fundidos alpha y algo de movimiento pero no demasiado. Había pensado en que sean plugins, eso está claro, pero no sé si enfocarlo como “plugin de Cabaret” o “plugin de la presentación de Cabaret”. Me gusta la idea de que el plugin viaje con el paquete de la presentación, pero no sé no sé… si uso Mac y otro señor usa Linux tendré que darle sus plugins compilados o algo así. He leído que es muy fácil utilizar scripts de Python en un programa C++, quizá sea la solución :)

Voy a indagar.

Forjeando que es gerundio

Noviembre 9, 2006

Imagen 1.png

La señorita Kidman me ha dicho que le gusta mucho Cabaret y que quería aparecer en una foto. Me he hecho el remolón pero al final me ha convencido :)
Hoy en Madrid es fiesta y ha sido un día productivo. Desde la última visita han aparecido unas cuantas características:

  • El fondo de las transparencias cuenta, además de los degradados, con un bitmap. Ambos elementos se pueden superponer o usar uno para colorear el otro. En la foto de arriba se puede apreciar esto último: la señorita Kidman está en escala de grises, pero la foto se colorea con un degradado de rojos. Colorear una foto de Kidman con colores fríos debe ser pecado.
  • El escalado de las texturas se hace mediante mipmaps, de forma que la calidad visual mejora considerablemente. Me ha sorprendido mucho lo bien que funcionan los mipmaps al agrandar una imagen: ¡los textos realmente no parecen escalados! Las imágenes no aparecen pixeladas ni nada de eso, una gozada.
  • Ha aparecido una nueva ventana titulada ‘vista previa’ que muestra la colección de transparencias de la presentación (en la jerga del código de Cabaret, el conjunto de ‘escenas’ que hay en el ‘paquete’). Por ahora no es más que una vista previa, pero se usará para organizar las escenas (copiar, pegar, etc).

El otro día conseguí, por fin, subir cosas al repositorio de Subversion, más que nada para aprender porque hay que ver lo mal que se me dan estas cosas…. Conseguí localizar un cliente de SVN medianamente decente y la verdad es que tiene muy buena pinta. No me gusta mucho usar la terminal para estas cosas. En realidad trato de evitar la terminal… :$

El caso es que en mi cachito de forja.rediris.es hay un poco de código de Cabaret. Se puede leer y estudiar y, por supuesto, mejorar. Imagino que no hay acceso anónimo para escritura, pero de alguna forma se podrá solucionar, digo yo. Ya dije que de SVN no tengo mucha idea…

El escritorio de Cabaret

Noviembre 4, 2006

Imagen 1
Los ánimos recibidos para atacar el proyecto (¡gracias chicos!) me han motivado para crear un pequeño toolkit. En este momento consta de:

  • un escritorio (ni dos ni tres :P )
  • ventanas
  • sliders (esas barritas horizontales con los que cambias un valor numérico)
  • etiquetas
  • una barra de menu

El aspecto está a medio camino entre el pantallazo de Aperture y el escritorio de Gnome. Aun quedan muchas cosas por hacer, pero bueno, la prueba de concepto está ahí y se puede usar aunque, claro, por ahora sólo funcionan cuatro cosas… :)

Escogiendo toolkits

Noviembre 1, 2006

Una vez que tenemos el motor para…

  1. Representar texturas en polígonos OpenGL
  2. Renderizar fuentes TrueType en una textura OpenGL

… podemos continuar. El siguiente paso representa una difícil elección y es escoger un toolkit que nos ayude a crear una interfaz gráfica. Un poco de inspiración:

http://www.professional.co.at/Apple/Bilder/05/aperture/aperture_screen.jpg

(Debería salir una foto de Aperture, un software desgraciadamente cerrado y demasiado caro) Este pantallazo lo resume todo: no se trata de tener un tema bonito en GTK sino de que los controles sean parte de un espacio OpenGL, renderizados por OpenGL. GTK o Qt no ayudan a esto, ya que son toolkits orientados al escritorio que contienen un widget donde se puede dibujar con OpenGL. En definitiva, las soluciones anteriores permiten ‘empotrar’ un espacio OpenGL en una ventana, mientras que lo que pretendemos es todo lo contrario.

Así pues se plantean varias alternativas. En http://www.mathies.com/glfaq/GLToolkitFAQ.html podemos ver una lista de proyectos muy interesantes: toolkits para desarrollo a alto y bajo nivel y cosas así. La parte que más nos interesa en este momento es el apartado V, en el que se enumeran varios toolkits realmente interesantes.

Sin embargo, ninguno me ha gustado. ¿Por qué? Porque los que mejor pinta tienen son semejantes a GTK o Qt, es decir, OpenGL es sólo una parte del toolkit. En definitiva, no creo que con estos toolkits se pueda crear un espacio de trabajo como el del pantallazo anterior.

Así que sólo queda una opción: crearnos un toolkit.

Cabaret, por tanto, se construirá sobre un toolkit propio y completamente nuevo. Este toolkit estará diseñado para crear aplicaciones como la del pantallazo anterior, en las que la pantalla completa se convierte en un espacio de edición sobre el que flotan los diferentes paneles de herramientas. Los paneles serán pequeñas ventanas que contendrán controles como botones, slides, entradas de texto y quzá algo más. Además, para que este toolkit sea reutilizable hay que diseñarlo bien, tener una buena jerarquía de objetos y un buen control de los eventos. Los controles se pintarán mediante el motor que ya hemos creado para pintar texturas y textos, de forma que aprovecharemos el código ya creado y, por cierto, hará que el toolkit pueda tener diferentes temas.

Tiene buena pinta…

El Problema Fundamental

Octubre 29, 2006

El problema fundamental que tenemos que resolver es ser capaces de mostrar fuentes y dibujos mediante OpenGL.

GLUT permite mostrar un conjunto fijo de fuentes en pantalla, así que no nos vale, porque las transparencias necesiitan diferentes fuentes y tamaños. Existen bibliotecas como FTGL que permiten renderizar fuentes truetype mediante polígonos, lo cual en principio puede parecer una buena idea pero no lo es. ¿Por qué?

La razón es que muchas tarjetas aceleradoras no permiten dibujar polígonos con antialias. Sorprendente pero cierto. Las ATI que montan los powerbook, como es mi caso, no lo permiten, ni siquiera los últimos supermodelos de la marca.  Y las fuentes tienen que tener antialias. Existe una solución que se suele utilizar para estos casos y es FSAA, Full Scene Antialias. En realidad FSAA es un poco chapucero: en lugar de antialias lo que se hace es utilizar el buffer de acumulación (un “sumador de imágenes”) para acumular una imagen renderizada con ligerísimas variaciones del punto de vista. De esta forma se superponen varias imágenes ligeramente desplazadas, lo cual produce un suavizado en todos los bordes de la imagen resultante.

Para muestra un botón. En cualquier caso, me parece una solución a medias, porque si bien nos reduce la complejidad para renderizar las fuentes (utilizando FTGL por ejemplo) nos obliga a hacer algo inherentemente complejo. Y fuera de lugar, para qué engañarnos. O sea: no me gusta esa solución.

La típica solución para estos casos es renderizar las fuentes en bitmaps y utilizarlos como texturas de polígonos OpenGL. Esta solución aporta dos grandes ventajas:

  1. Fuentes de tanta calidad como tu renderizador de fuentes te permita.
  2. El mismo motor para mostrar las texturas en polígonos se puede aprovechar para las imágenes, o sea, matamos dos pájaros de un tiro.

Está claro que la limitación de la calidad está en el punto 1, ya que pintar un polígono con una textura es sencillo y queda muy bien. La biblioteca para crear imágenes por antonomasia es libgd. Y es realmente buena. Renderiza fuentes TrueType2 con antialias y queda fenomenal. Además se puede aprovechar para importar imágenes, o sea que todo son ventajas. La cosa está clara.