inmensia

Algunos apuntes sueltos sobre Dart, el lenguaje de programación para la web que está desarrollando Google.

Programación estructurada
Proporciona librerías, clases, interfaces, herencia simple, getters y setters, métodos estáticos, genéricos, sobrecarga de operadores, ... pero como contrapartida también permite omitir los tipos en las declaraciones.

Constructores con nombre
No permite sobrecargar los métodos, pero ofrece una solución para sobrecargar los constructores mediante generative constructors (¿constructores generativos?) utilizando una notación de punto. Útil para los contructores de conversión.

Privacidad
Los métodos y variables de instancia privados se denotan anteponiendo un guión bajo ("_") al nombre. De esta forma no hace falta consultar las declaraciones para averiguar el ámbito de aplicación. La privacidad es a nivel de librería, no de clase.

Inicialización de variables de instancia
Permite inicializar las variables de instancia directamente en la lista de parámetros de los constructores utilizando "this.".

Notación abreviada
El cuerpo de los constructores vacíos se puede omitir. De igual forma, las funciones se pueden escribir de forma abreviada utilizando la notación "=>". Esto reduce la cantidad de código a escribir y mantener.

Parámetros opcionales
Soporta parámetros opcionales, declarados mediante una notación con corchetes, y con un valor por defecto si se quiere. En las invocaciones se pueden referenciar por su nombre e incluso reordenar.

Interpolación de String
Aunque las cadenas de texto son constantes y no se pueden modificar en tiempo de ejecución, en el momento de su declaración se evalúa su contenido y se puede incluir en ellas referencias a variables e incluso bloques de código completo mediante el uso del carácter dolar y llaves.

Operador parte entera de la división
Tiene un operador "~/" que devuelve la parte entera de una división. Es un complemento al clásico operador módulo "%" que devuelve el resto de una división.

Enteros de tamaño arbitrario
Dart declara una interface num con dos clases que la implementan: double e int. El tipo double tiene un tamaño predefinido de 64 bits y se rige por el estándar IEEE 754. El tipo int no tiene ningún tamaño predefinido, sólo está restringido por la implementación y la memoria disponible en la máquina. Esto último es cuanto menos bastante curioso, y quiere decir que se le puede sumar 1 a un número entero de forma casi infinita, sin que se produzca overflow.

Relación con JavaScript
Dart se está presentando como la alternativa a JavaScript en lo referente a la programación de aplicaciones web de gran tamaño. Su objetivo no es sólo permitir desarrollar aplicaciones para su ejecución en los clientes desde un navegador, sino también en los servidores de forma independiente.

Dart trata de resolver los problemas que plantea JavaScript, como el uso de this por ejemplo. Y además de lo que es el lenguaje de programación en si mismo, también proporciona una serie de librerías completas, como hizo Java en su tiempo. Desde colecciones como arrays, listas, mapas y conjuntos, hasta soporte para realizar operaciones de entrada/salida con ficheros, uso de sockets, etc...

Ejecución
Actualmente las aplicaciones escritas en Dart se pueden ejecutar:
- Desde una línea de comandos invocando directamente la máquina virtual
- Mediante Dartium, un build específico de Chrome que incorpora la máquina virtual
- Generando una versión para JavaScript a partir del código original escrito en Dart

Errores
Dart es un lenguaje que está en desarrollo, lo que hay disponible actualmente es una versión alpha basada en una especificación que aún dista mucho de estar cerrada.

El entorno de desarrollo es prácticamente un editor, basado en Eclipse, que apenas permite realizar las operaciones más básicas con los proyectos. Un ejemplo de esto es que ni siquiera se le puede cambiar el nombre a un fichero, ni borrarlo para crear uno nuevo con el nombre corregido. Pero lo peor sin duda es que aún no se puede depurar. Lógicamente están trabajando para añadir todas estas características.

Durante mis pruebas he encontrado varios errores. He abierto las incidencias correspondientes en dartbug.com y todas las han aceptado como errores, e incluso alguno ya está corregido en el último build nocturno. Aunque creo que hay alguno que les va a llevar un poco más tiempo.

He encontrado un error que hace el código se comporte de forma distinta en función de como se escriba. ¡Me ha traído literalmente de cabeza!. Al final he decidido no continuar la migración que estaba haciendo a Dart de LZMA. El algoritmo que está implementado funciona bien cuando se genera código en JavaScript, pero nunca va a poder funcionar bien en Dart con la especificación actual del lenguaje. El motivo es que LZMA basa su funcionamiento en operaciones a nivel de bit con una aritmética de tamaño entero (32 ó 64 bits) y precisamente en Dart los enteros no tienen tamaño predefinido. Estoy por borrar el proyecto.

Hoy he liberado los fuentes de dart-lzma, una versión para Dart del algoritmo de compresión LZMA. Es un nuevo proyecto que he empezado para ver en que estado está el lenguaje y las posibilidades que ofrece. Y la verdad es que me he encontrado que está todo en general en estado absolutamente alpha, aunque ya es posible editar, compilar y ejecutar programas.

El uso de la librería es muy sencillo, basta con importarla y llamar a la función de descompresión:

Aunque Dart viene con librerías que incluyen varios tipos de streams, he decidido aislar un poco mi librería de los posibles cambios en la implementación y definir dos interfaces propias muy sencillas:

Llama la atención que en una interface haya definido un método get, pero parece que el lenguaje lo soporta.

He puesto un ejemplo completo en la página del proyecto, pero al final todo se reduce a instanciar dos objetos y llamar a una función:

La función de compresión está en desarrollo. He retrasado su desarrollo porque me ha desanimado bastante que el programa no funcione con la máquina virtual de Dart utilizando la línea de comandos. Eleva una excepción ".\vm\object.cc:7453: error: unimplemented code" por que hay código de la máquina virtual que aún no está desarrollado. La única forma de hacer las pruebas es realizando una compilación cruzada del código en Dart a JavaScript para poder llamarlo desde una página web en vez de ejecutarlo de forma nativa.

El entorno y el lenguaje tienen cosas curiosas, a ver si me animo a escribir un post con las cuatro cosas que he ido viendo.

Un vídeo de Hangar en acción.

Demo online:
http://inmensia.com/files/hangar/flight-gallery/index.html

Hoy he liberado los fuentes del último proyecto en JavaScript en el que he estado trabajando. Es un visor de modelos 3D almacenados en formato AC3D (.ac) que utiliza WebGL para renderizar. He estado utilizando modelos de aviones de FlightGear para probarlo, así que he decidido llamarlo Hangar.

He creado una pequeña página web con cuatro modelos escogidos de prueba. Tiene implementado un controlador a modo de trackball que permite rotar y ampliar los modelos utilizando el botón izquierda y la rueda del ratón. Necesita un navegador moderno como las últimas versiones de Chrome o Firefox para funcionar (Y no, IE 9 no es un navegador moderno)

El formato AC3D lo utilizan algunos programas como FlightGear, un simulador aéreo de código abierto, o Torcs, un simulador de conducción deportiva también de código abierto. Es un formato de texto plano que originalmente creó un programa de modelado 3D llamado, lógicamente, AC3D.

Mi idea era hacer algo sencillo, pero al final he acabado incorporando un montón de esas pequeñas características que pasan desapercibidas cuando funcionan bien.

AC3D
Los ficheros .ac tienen dos partes, la primera es una lista de materiales y la segunda una lista de objetos. Los materiales incluyen los típicos atributos para ambiente, emisiva, difusa, especular, brillo y transparencia. Los objetos son agrupaciones de entidades que reciben el nombre de superficies, aunque en realidad, además de polígonos, también pueden ser líneas simples o cerradas (el último punto se une con el primero). A mi me interesaban sólo los polígonos, pero al final he añadido soporte para representar las líneas también.

Los objetos están definidos de una manera jerárquica, de forma que un objeto puede tener hijos. Además, cada objeto tiene una matriz de rotación y un vector de rotación que aplica a sí mismo y a todos su hijos, por lo que hay que ir calculando la transformación resultante a medida que se baja por el árbol de descendencias.

Teselación
Debido a que para renderizar con WebGL es mejor tener las superficies divididas en triángulos, he implementado una versión en JavaScript de un algoritmo de teselación que soporta tanto polígonos convexos como cóncavos. Funcionó bastante bien casi a la primera, aunque haciendo pruebas detecté un problema con el orden en que devolvía los índices con modelos que tenían definidas las caras con los vértices en el sentido de la agujas del reloj, y que afortunadamente puede solucionar fácilmente. Me gustaría escribir en el futuro un post individual sobre este tema en particular.

Me he encontrado con modelos de todo tipo y definidos de casi cualquier forma. Al final he decidido ignorar los polígonos degenerados. Es decir, polígonos con menos de tres vértices, polígonos con coordenadas colineales, polígonos con vértices no contenidos dentro de un único plano, polígonos con aristas que se cruzan, ...

Normales
El formato del fichero no incluye normales, por lo que se calculan online mediante JavaScript. Por una parte la normal a cada superficie, para los sombreados planos. Y por otra parte la normal a cada vértice, para los sombreados más realistas.

La normal a un vértice concreto se calcula como la suma de todas las normales de todas las caras que comparten dicho vértice. Aunque a este respecto el fichero incorpora un parámetro por objeto llamado "crease". Este parámetro es un ángulo, y sirve para generar lo que habitualmente se conocen como bordes duros (hard edges). Si el ángulo que forman la normal de una cara y su vecina supera dicho parámetro entonces esa normal vecina no se tiene en cuenta para calcular la normal en el vértice compartido.

SGI
Bastantes modelos en formato AC3D utilizan texturas en formato SGI. Un formato antiguo que no soportan directamente los navegadores actuales. Una solución era transformar las texturas a .png, pero después de leer la especificación del formato me decidí a implementar también un lector de este tipo de imágenes en JavaScript, ya que el método de compresión que utilizan es un simple RLE. ¡Un proyecto dentro de otro proyecto!

Mi implementación soporta .sgi, .rgba, .rgb, .ra y .bw. Es decir, todas las combinaciones posibles, aunque he ignorado deliberadamente algunas características de la especificación, como la posibilidad de usar paletas de colores o escoger entre 8 ó 16 bits por canal. En la práctica todas las imágenes acaban siendo de cuatro canales y con 8 bits por canal en el clásico formato RGBA.

Loader
Para agilizar la carga y proceso de las texturas, que son binarias al contrario que los modelos que son de texto, he utilizado una de las nuevas características del objeto XMLHttpRequest de HTML5 que permite descargar un fichero directamente a un ArrayBuffer.

Muy útil.

Renderer
Como modelo de iluminación he utilizado una versión propia basada en el clásico de Phong con algunas modificaciones. Como los colores se me saturaban bastante debido a como están definidos por lo general los materiales he utilizado el valor de las texturas para ponderar la suma de emisiva, ambiente y difusa. De igual forma, para evitar los brillos exagerados he tomado sólo un 30% de la reflexión especular. Es más un modelo de prueba y error buscando un resultado agradable a la vista que uno realista. Es uno de mis puntos flacos.

El formato AC3D permite incluir luces en los modelos, pero las he ignorado a la hora de renderizar, utilizando en cambio una luz fija estática direccional sin factores de atenuación. Mi idea era representar modelos de objetos independientes, no escenas completas, por lo que no he encontrado sentido en incluirlas. Aparte de que acabado no fiándome de los modelos, con materiales un tanto extraños a mi parecer.

Para minimizar los cambios de estado de la tarjeta gráfica he agrupado todos los polígonos por programa, material, tipo, y todo lo que se me ha ocurrido. Por ello, a diferencia de otros proyectos anteriores, he decidido utilizar drawArrays en vez de drawElements para mi comodidad, aunque fuera a costa de repetir información al no utilizar índices.

Transparencias
Las transparencias han sido un dolor como de costumbre. Al final me he ceñido al guión. Primera pasada para los objetos opacos, con el blending desactivado. Segunda pasada para los objetos transparentes, con el blending activado y la escritura al depth buffer desactivada. Lo único que no he hecho es ordenar en profundidad, no me ha hecho falta en ninguna de las pruebas que he realizado.

Lo que me duele es que se supone, repito "se supone", que los materiales incluyen un atributo para indicar si tienen algún tipo de transparencia. Desgraciadamente esto no ocurre así en la práctica. Al final cuando algún modelo no se visualizaba correctamente, abría el fichero, localizaba el material y lo cambiaba a mano.

Esto es algo que en general creo que tendría que revisar con el objetivo de entender la manera en que interpretan los materiales programas como FligthGear o Torcs aprovechándome del hecho de que son de código abierto.

Autofit
Uno de los inconvenientes de hacer un visor genérico es que cada modelo viene posicionado y orientado según decidió su autor. Con centrarlos en el eje de coordenadas y alejarse una distancia prudencial prefijada no es suficiente, ya que depende del tamaño de cada modelo en particular. Para solventar este problema he implementado un auto-ajuste a la pantalla de los modelos basados en el tamaño de su bounding box.

De esto también me gustaría escribir un post individual en el futuro, ya que he encontrado distintas soluciones en Internet y no me he quedado del todo satisfecho con la que yo mismo he implementado.

TrackBall
Una vez dibujados los modelos lo lógico es poder interactuar con ellos. Ya había implementado anteriormente un simple controlador, cuando hice la demo de js-openctm, pero era un fake, así que esta vez he implementado un algoritmo de trackball de verdad. No quiero acordarme de las horas que habré perdido por culpa de esto. No es que no viera la solución, ¡es que no veía el problema!.

Resumiendo
¿Mucho tiempo invertido? Sí. ¿Suficiente? ¡Nunca!.

Una aproximación más práctica al problema hubiera sido utilizar un motor 3D ya existente, como el popular Three.js, y limitarme a hacer un conversor del formato .ac a algún formato que acepte el motor. Pero claro, ¡me hubiera perdido la parte más divertida!

Hará cosa de un año que me bajé los fuentes de Chrome y los estuve compilando. Muchas novedades ha habido en el navegador desde entonces, así que me he decidido a bajarme los fuentes actualizados y volver a compilarlos. Y si bien la primera vez utilice la versión 2008 Express de Microsoft Visual C++, esta vez he optado por utilizar la 2010 Express.

Esta es la secuencia de pasos que he seguido utilizando Windows 7 Ultimate 64 bits:

Instalación

1) Instalar Microsoft Visual C++ 2010 Express

2) Instalar Microsoft Windows SDK for Windows 7 and Framework .NET 4

3) Instalar Microsoft Visual Studio 2010 Service Pack 1

4) Instalar Microsoft Visual C++ 2010 SP1 Compiler Update for the Windows SDK 7.1

5) Instalar Microsoft Windows Driver Kit Version 7.1.0 en un directorio <DDK>

6) Instalar Microsoft DirectX SDK en un directorio <SDX>

7) Dar permiso de modificación y sustituir "v7.0A" por "v7.1" en los ficheros:

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\
Microsoft.Cpp.Win32.v100.props

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\v100\
Microsoft.Cpp.x64.v100.props

Configuración

8) Descargar depot_tools y descomprimir el .zip en un directorio <depot_tools>

9) Descargar chromium_tarball y descomprimir el .tar en un directorio <sources>

10) Añadir el directorio <depot_tools> al PATH del sistema

11) Ejecutar por primera vez las depot tools para actualizarlas:
    <depot_tools>\glclient

12) Editar el fichero <sources>\.glclient y añadir la url de una rama probada de los fuentes:
    "safesync_url" : "http://chromium-status.appspot.com/lkgr"

13) Actualizar los fuentes:
    <sources>\glclient sync

14) Crear la solución y los proyectos para Visual Studio 2010 Express:
    <sources>\set GYP_MSVS_VERSION=2010e
    <sources>\gclient runhooks

Compilación

15) Abrir solución de Visual Studio (ignorar mensaje de advertencia sobre properties):
    <sources>\chrome\chome.sln

16) Configurar el proyecto "chrome" como inicial

17) Añadir las siguientes rutas al principio de la lista de directorios de includes (Win32 y x64):
    <SDX>\Include

18) Añadir las siguientes rutas al final de la lista de directorios de includes (Win32 y x64):
    <DDK>\inc\atl71
    <DDK>\inc\mfc42

19) Añadir las siguientes rutas al principio de la lista de directorios de libs:
    Win32: <SDX>\Lib\x86
    x64: <SDX>\Lib\x64

20) Añadir las siguientes rutas al final de la lista de directorios de libs:
    Win32: <DDK>\lib\ATL\i386
    x64: <DDK>\lib\ATL\amd64

21) Lanzar el build sobre el proyecto "chrome"

El tiempo total en mi máquina para una compilación sólo del navegador Chrome para Win32 Debug sin los tests es de unos 40 minutos, lo que está bastante bien teniendo en cuenta la cantidad de proyectos y dependencias.

El orden de instalación que he puesto difiere un tanto de las instrucciones oficiales, pero es la mejor forma que he encontrado para evitar los errores con los que me he ido topando al instalar los distintos productos de Microsoft que necesitaba. La lista de pasos ahora la tengo clara, pero como de costumbre ha sido todo un proceso de prueba y error. Al final opté por bajarme las .ISO de cada instalación en vez de utilizar los instaladores webs, porque esperar por cada descarga cada vez era muy tedioso.

Con respecto a la instalación en particular del compilador, comentar que finalmente tuve que instalar primero el Visual C++, luego el SDK de Windows, luego el Service Pack 1 del Visual C++ y por último un parche para arreglarlo todo, aunque aún así es necesario modificar dos ficheros de manera manual, ya que se empeña en tomar la versión 7.0A del SDK de Windows en vez la más actualizada 7.1.

Finalmente, puede que sorprenda que haya tenido que instalar el SDK de DirectX, ya que este último pasó a formar parte del SDK de Windows hace tiempo, pero es necesario porque los fuentes de Chrome utilizan D3DX, que sólo está incluida en el SDK de DirectX. De igual forma, es necesario instalar el DDK porque la versión Express de Visual C++ no trae los includes y librería de ATL.

¡Feliz compilación a todos!