Desde el punto de vista de Flex, esto no supone un gran problema ya que por defecto el framework está dotado de un sistema que permite crear una interfaz líquida con muy poco esfuerzo. Pero si hablamos de Flash, no existe un mecanismo que nos ayude a adaptar nuestra película a cualquier resolución.

Diseño líquido vs diseño estático

Mientras que en html se han acuñado muchos términos a la hora de hablar de los diseños (fijo, estático, flexible, líquido, fluido, elástico…), en flash, básicamente, podemos hablar que un site tiene un diseño líquido o estático.

En un diseño líquido el contenido se posiciona en función del tamaño del navegador. El programador debe decidir elemento por elemento si está anclado, si se ha de reescalar, reposicionar, etc. Y dependiendo de la complejidad del site puede ser un trabajo realmente complejo y tedioso.

Por contra, en el diseño fijo le damos un alto y un ancho a nuestra película y todos los elementos quedan ubicados de manera absoluta. Aunque a nivel de diseño y de programación es comodísimo, el problema estriba en que si alguien accede con una resolución mucho mayor verá la página pequeña desperdiciando mucho espacio, y si es menor se generarán barras de scroll que pueden dificultar la experiencia y la navegación.

Se elija uno u otro, siempre hay que decidir qué resolución mínima tendrá nuestra web.

Resolución mínima

Una de las primeras tareas que deberíamos hacer cuando empezamos un proyecto es decidir qué resolución mínima usaremos, o dicho de otra manera, a partir de que resolución de pantalla nuestros usuarios verán el contenido sin problemas. Hace unos años el estándard era 800×600, encontrándose ahora normalmente en 1024×768.

Aún tratándose de una web líquida, es recomendable fijar un mínimo para que los elementos no queden apelotonados cuando el navegador se reduce demasiado.

El problema

De manera más o menos consciente, cualquier site está pensado para trabajar con una resolución mínima, pero el gran problema es que mucha gente se olvida de las resoluciones inferiores. La razón de escoger medidas es ofrecer garantías de que una web será visualizada correctamente en la mayoría de los casos, pero en aquellos que no se pueda, todo el contenido debe seguir siendo igualmente accesible.

Nota: en este contexto, accesible hace referencia a que el contenido se puede ver/clicar, no hablo de accesibilidad web.

Y este problema no está asociado únicamente a nuevos programadores o gente inexperta. Sin ir más lejos, aquí hay dos ejemplos sacados del FWA (ambos recientes, nada de buscar en el 2006):

• http://www.energylab.tv
• http://www.harrypottertweet.com

En el primero de ellos reescalan el contenido, pero si tu resolución es de 800x600px se corta y no se puede acceder al menú inferior de opciones. En el segundo, con la misma resolución, no se puede acceder al botón para detener el audio.

En ambos casos, los programadores decidieron que la resolución mínima de sus webs sería de 1024×768, pero han descartado al resto. Detectando que la medida del navegador era inferior y añadiendo un scroll vertical posibilitarían que todo el mundo pudiera acceder a todos los elementos.

Un ejemplo de lo impredecible de la web

Muchas veces nos creemos con derecho a descartar a x usuarios pensando que son una minoría, como cuando empezamos a dejar de lado a los usuarios con monitores de 800×600, pensando que una altura de 600px nunca más se daría.

Pues bien, un tiempo después empieza a proliferar un pequeño ordenador llamado netbook, cuya resolución estándard es de 1024×600. En los últimos 3 años, mientras que la venta de ordenadores cae de manera incremental, el crecimiento de los netbooks lleva un ritmo que nadie era capaz de predecir.

Yo, en mi netbook, ¿por qué no puedo navegar la web de energylab? ¿o porqué no puedo detener el volumen en la de harrypotter?

No caigamos en la demagogia fácil de las minorías, en la que alguien pudiera decir “Pues no uses Flash entonces, que hay unos cuantos que no tienen el plugin”. Cualquiera, en función de objetivos, es libre de escoger la tecnología que mejor se ciñe a su propósito, así como la resolución. Si un artista considera que la resolución mínima para ver bien sus pinturas ha de ser de 1920×1050, perfecto. Pero si descarta las inferiores muchos sólo verán parte de la pintura, mientras que si habilita el scroll dará la posibilidad a todo el mundo de verla íntegra.

Eligiendo una resolución

Un error frecuente a la hora de elegir la resolución es pensar que el tamaño del swf puede ser el mismo. Se elige siempre una resolución de pantalla, pero a estas medidas hay que restar otros elementos como el menú del sistema operativo y el tipo de navegador, teniendo en cuenta además la configuración de éstos (con/sin favoritos, barras de estado, barras alternativas como la de Google, Yahoo, etc). Horizontalmente apenas afecta, pero verticalmente bastante.

Yo, a día de hoy, suelo plantear las webs con una resolución mínima de 1024×768. Esto se traduce en un tamaño de 996×578 para mis películas flash. Los 28px que resto horizontalmente lo hago contemplando la posibilidad de que se genere scroll vertical de sistema, mientras que los 90px que pierdo de altura corresponden a la configuración de un Firefox estándard en un sistema Windows.

Nota: a excepción de Chrome que cuenta con una interfaz muy limpia, el resto de navegadores cuentan con menús similares, así como los distintos sistemas operativos, que tienen un menú principal.

Como es imposible tener una medida que encaje en todas las combinaciones, es preferible dejar unos cuantos píxels de margen. A veces, por intentar ajustar demasiado se genera un scroll mínimo de 3 o 4 píxels que ensucia más que ayuda.

Así pues, 996×578 es el tamaño mínimo que garantizo para que una web se vea correctamente. Si el navegador tiene menos espacio para mostrar, se generará scroll de sistema.

Nota: hay gente que prefiere utilizar un scroll propio en flash. Yo no soy muy partidario para este caso concreto.

Swffit

Para no tener que lidiar directamente con javascript, existe una utilidad llamada swffit que permite fijar las medidas mínimas y máximas de tu película y se encarga de todo: mostrar el scroll cuando es necesario, reescalar la película para que ocupe todo el tamaño disponible, centrar la película, etc. Imprescindible.

Resumiendo

Los que trabajamos con Flash estamos acostumbrados a ver como la gente lo ataca por distintas razones. El tema de las resoluciones es una de ellas. Y con razón.

Resulta difícil de creer que programadores que hacen piezas tan espectaculares como para ganar un Favourite no tengan en cuenta este punto. Por no hablar de todos aquellos que “aprenden flash en 2 días” y venden webs al vecino.

Si queremos quitarle la razón a los detractores de Flash, tanto los diseñadores como los programadores debemos hacer las cosas bien, y esto pasa por empezar con las cosas básicas.

5 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2009

A pesar de que dicha librería funciona perfectamente, lo hace todo mediante sockets, cosa que añade un grado (o varios, según el caso) de dificultad. Como para el proyecto de IKEA no íbamos sobrados de tiempo, no le di más vueltas y la utilicé, pero me quedó la espinita de si no había maneras más sencillas de hacerlo, y desde entonces he estado mirando todo lo relacionado con el tema de envíos desde Flash. Este artículo recoge y explica distintas soluciones que he ido encontrando.

Empezaremos con el caso más sencillo, que es enviar una imagen desde Flash al servidor.

Enviar una imagen con AS3

En AS3 contamos con la clase URLRequest, que combinándola con otros métodos para hacer envíos, permite mandar datos como texto, como variables o como binario. Así pues, se puede pasar cualquier archivo como binario, pero para ello primero hay que codificarlo. En el caso de un jpg o un png, podemos utilizar la librería de Adobe as3corelib, que cuenta con las clases JPGEncoder y PNGEncoder, y a partir de un BitmapData (el formato interno de Flash para almacenar datos de una imagen) te genera un ByteArray con la información.

Como ejemplo vamos a crear una imagen a partir de un movieclip que tenemos en el escenario y a enviarla a un php para que la muestre:

Descargar ejemplo

Nota: para que funcione el ejemplo, tanto el swf como el php se deben encontrar en el mismo dominio.

El código del ejemplo está comentado aunque es bastante sencillito, y la única tarea realmente dura la hace la clase JPGEncoder. Vamos a echar un vistazo a las partes relevantes:

Se toma un "pantallazo" dibujando el movieclip en un bitmapData

Se crea un objeto JPGEncoder. El parámetro indica la calidad de la imagen (sobre 100). Se codifica el bitmapData y se asigna a un byteArray.

El tipo de cabecera indica que se trata de un archivo binario

Se crea un objeto URLRequest que contiene toda la información referente al envío. El parámetro data es que el que contiene la foto codificada, y el parámetro vFoto el nombre que le queramos asignar (no es obligatorio).

En este ejemplo se manda abrir el php en una ventana en blanco, pero lo normal sería utilizar un objeto URLLoader para enviar la información y procesar el resultado.

Por último, el php se encarga de recibir la imagen y mostrarla por pantalla.

Nota: como son operaciones que mucha gente busca, en el php he incluido una rutina para guardar el archivo en el servidor y otra que da la opción de descargar el fichero al disco duro.

Limitaciones de este método

Para cosas muy sencillas el ejemplo anterior es perfecto, pero normalmente, cuando se envía un archivo se suele acompañar también de variables que contienen información. Al asignar a la propiedad data el byteArray, perdemos todas las opciones de adjuntar un objeto con dicha información.

Un "truquillo" sería enviar la foto mediante POST y aprovechar la url para pasar variables por GET, igual que hemos hecho con el nombre del archivo. Por ejemplo:

De todas formas, no es el sistema más limpio, y mejor usarlo como un recurso puntual para pasar pocos parámetros (aunque no tiene nada que ver con el mito de los 256 caracteres).

Lo ideal es poder hacer un envío multipart, igual que se hace con los formularios html o como lo hace la propia clase de AS3 FileReference. Y buscando buscando, di con una clase que sirve perfectamente para el propósito...

Enviando una imagen y datos mediante la clase UploadPostHelper

La clase UploadPostHelper te permite pasar un nombre de archivo, un ByteArray y un Object y devuelve otro ByteArray con todo el contenido codificado que podemos enviar como data.

Descargar ejemplo

El uso sigue siendo muy sencillo: la mayoría de pasos del ejemplo anterior son los mismos, y UploadPostHelper hace todo el trabajo sucio de forma transparente:

En la segunda linea vemos que se establece el contentType como multipart. El boundary es un string que se genera en cada envío aleatoriamente y sirve para delimitar las diferentes partes del envío. En la cuarta linea es donde se llama al método getPostData, que nos devuelve un array con todos los datos pasados.

Se manda y... ya tenemos nuestro envío multipart. ¿Fácil, no?

Mandando varios archivos

Y aunque el método anterior sirve para el 90% de los casos, para rizar el rizo, ya sólo falta poder enviar varios archivos a la vez, cosa que no hace UploadPostHelper, pero sí la librería basada en sockets (as3httpclientlib).

Como no vi nada similar pensé en modificar la clase UploadPostHelper, ya que el trabajo duro estaba hecho, y lo único que falta es permitir añadir nuevas partes, pero para mi sorpresa, mientras me documentaba, he encontrado a alguien que ha escrito una clase con el mismo objetivo hace sólo dos días :)

El post en cuestión es este: http://blog.inspirit.ru/?p=139 y el ejemplo es bastante claro, así que no redundaré para no hacer esto más largo.

Resumiendo

A medida que las capacidades de Flash Player crecen, cada vez es más corriente generar imágenes en el mismo player, y también aumenta la necesidad de poder exportarlas. Pero el tema no se reduce sólo a jpgs, sino también a otro tipo de archivos como pdf, zip o mp3.

Gracias a la potencia de AS3 y al esfuerzo de muchas personas que crean todo tipo de librerías y utilidades, llevar a cabo esta tarea se convierte en un paseo, pero detrás hay un trabajo realmente complejo (sólo hay que echar un vistazo a dichas clases).

Con este artículo espero haber allanado un poco el camino por si alguna vez te tienes que enfrentar con el tema.

14 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2009

Los puntos que voy a explicar me parecen igual de válidos si se trabaja solo, pero obviamente la repercusión es mucho menor porque no afecta a nadie más. Y con trabajar en equipo no me refiero sólo a dos o más personas simultáneamente, sino también aquellos desarrollos que un día empieza uno y luego ha de continuar otro.

Separar código fuente y archivos finales

Hace no muchos años era frecuente ver proyectos como el siguiente

donde los fla, html, xml, jpg, etcétera convivían mezclados. Y también era normal que allá donde hubiera un fla estuviera su correspondiente swf. Evidentemente, esto no facilita nada la navegación por el proyecto ni poder mover el directorio de producción entre diferentes servidores. Y no todo el mundo ha conseguido desprenderse de este viejo hábito.

A no ser que sea un proyecto muy pequeño (un banner o similar), es imprescindible contar con carpetas separadas para el código fuente y para los archivos finales. Yo suelo utilizar como nomenclatura src y bin, o también source y deploy.

Bibliotecas ordenadas

¿Hay alguien que no odie abrir un fla y encontrarse cientos de símbolos desperdigados en la biblioteca? En todos los años que llevo utilizando Flash he visto muy poca gente que le dedique tiempo a ordenar coherentemente la librería.

El sistema que suelo utilizar es un árbol de carpetas con la misma estructura que siguen los movieclips en la linea de tiempo. Me gusta porque al tener una relación 1 a 1 es facilísimo encontrar cualquier elemento y navegar por la biblioteca como si fuera el escenario, aunque por contra obliga a generar demasiadas carpetas y niveles y hay que ser muy exhaustivo.

Tampoco me desagrada ordenar por grupos lógicos (por ejemplo, una carpeta para el "Panel de Login", otra para el "Menú de navegación", etc) siempre y cuando no haya demasiado contenido. En ese caso, prefiero añadir más directorios intermedios.

Código en timeline y en la clase

Normalmente intento reducir al mínimo el código en linea de tiempo, aunque tampoco me opongo en rotundo (a veces es mejor picar 2 o 3 instrucciones en un frame que no generar una clase nueva).

También en algunas ocasiones hay que poner código en frames en movieclips que cuentan con su propia clase. Cuando un mc tiene una clase asociada ésta se ejecuta en el primer frame, así que, por ejemplo, no podemos escuchar un TextInput que se encuentra en el frame 5. Tendremos que esperar hasta alcanzar dicho frame para poder referenciarlo. Hay que tener mucho cuidado con esto porque puede hacer el seguimiento muy difícil al estar divido el código en 2 sitios.

A mi parecer, lo más "limpio" es dispachar eventos notificando en que punto nos encontramos, e intentar que el framecode no se encargue de hacer demasiadas tareas.

Se haga lo que se haga, es muy importante comentar tanto en el frame como en la clase, indicando quién hace qué, porque sino te puedes volver realmente loco.

Instanciando desde la biblioteca

Me parece genial que en AS3 ya no se utilice más attachMovie y que siempre haya que generar nuevas instancias con el operador new. De todas maneras, la ventaja de attachMovie era que inmediatamente sabías que se utilizaba una instancia de la biblioteca, y ahora no. En este caso, me parece más que interesante comentar indicando que la clase se encuentra en la librería.

Y de manera contraria, me parece también necesario comentar al inicio las clases que tienen un movieclip o un sprite asociado, ya que sino lo sabes puedes perder mucho tiempo buscando en el resto de clases quién instancia cuando resulta que simplemente se ha arrastrado un elemento al escenario.

NO declarar instancias del escenario automáticamente

Ya hace tiempo dediqué un extenso apartado a explicar en que consiste esta opción que nos facilita Flash CS3 y cómo funciona internamente:

Básicamente nos permite no tener que declarar en nuestra clase propia los movieclips que se han añadido manualmente al escenario. Personalmente me parece un error, ya que luego no sabes de dónde salen los objetos, y crea muchísima más confusión si el código no es tuyo.

Siempre, al principio de cada clase, declaro todos los objetos del escenario:

así, de un vistazo se sabe qué instancias se encuentran en el fla, y además habilita el código de autocompletado en editores como FlashDevelop.

Activar modo estricto

Como ya sabemos, ActionScript cuenta con dos modos para compilar un programa: el modo estricto y el modo estándar. En modo estricto el compilador resuelve los errores tanto en tiempo de compilación como en tiempo de ejecución, con lo que nos proporciona mucha más información si algo no funciona como debería.

Uno de los mayores problemas del modo estricto es que muchas de las fallas que detecta no son errores "reales", simplemente es que el compilador no tiene información suficiente sobre qué está pasando y no nos deja continuar. Es aquí donde entra la tediosa tarea de castear objetos. Otras veces el problema puede ser tan insignificante como usar dos veces una variable en una función (la típica i en un for).

Hay programadores que optan por desactivar esta opción evitándose este tipo de errores. Aunque al principio se puede pensar que se gana tiempo, nada más lejos de la realidad: cuesta muchísimo más encontrar errores tontos (del tipo llamar a una función que no existe o pasar un número incorrecto de argumentos) que ser minucioso con el código que se escribe.

Siempre pongo el paralelismo de las variables en AS1 cuando no se tipaban: era mucho más cómodo no tener que decir si una propiedad era un String o un Int, pero en cuanto uno se acostumbra los beneficios son muchísimos más. No me imagino a nadie que programe en AS3 que no utilice el tipado. Lo mismo debería ocurrir con el modo estricto.

Resumiendo

En el título del post hablo de "consejos" porque entiendo que no todo el mundo estará de acuerdo con que los puntos son tan importantes, pero para mí, van a ser un requisito en futuros proyectos en que trabaje con más gente.

Me parece que seguir estas pautas no supone un gran sacrificio, y realmente pueden ahorrar mucho mucho tiempo a otras personas.

14 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Emulando el sistema de cinematografía, basado en proyectar fotogramas de forma rápida y sucesiva para lograr la sensación de movimiento, FutureSplash incorporaba una linea de tiempo en la que se podía dibujar frame a frame para reproducir luego la película.

Un año más tarde, ese revolucionario programa fue adquirido por Macromedia y nació Flash 1.0, para acabar evolucionando actualmente en Flash CS3, de la mano de Adobe. Y por sorprendente que parezca, nueve versiones después, la filosofía para generar animación se ha mantenido intacta.

Al margen de la animación tradicional en linea de tiempo, la otra forma de generar animación es mediante código, y en ActionScript sí que ha ido evolucionando el tema:

• En Flash 5 se introdujo el archiconocido enterFrame.
• En Flash MX nos obsequiaron con setInterval (lo recuerdo como una gran novedad).
• Y ya en AS3, se ha apostado por la clase Timer como sucesora de setInterval.

Así pues, en Flash 5, para animar mediante código se utilizaba enterFrame, pero con la introducción de setInterval la comunidad empezó a dividirse entre partidarios y detractores de uno y otro sistema. Es fácil encontrar discusiones en blogs, foros y listas sobre este tema, y personalmente he perdido la cuenta de cuantas veces he debatido sobre ello.

En este artículo vamos a estudiar la clase Timer (setInterval está desaconsejada, pero la lógica se puede aplicar igualmente) y el evento enterFrame, con la esperanza de poder definir cuándo es mejor usar una u otra.

EnterFrame

Flash Player cuenta con un motor interno que ejecuta un frame tras otro de forma continua, incluso en películas que no tienen linea de tiempo o que están detenidas. El evento enterFrame está sincronizado con el framerate de la película y se lanza cada vez que el motor alcanza un nuevo frame.

Los frames se cuentan por segundos (fps), y desde el IDE admite el siguiente rango de valores: 0.01 a 120. En AS3 se puede establecer por primera vez el framerate vía código, permitiendo aumentar el valor hasta 1000 fps.

Cualquier objeto que descienda de DisplayObject se puede suscribir (y desuscribir) a un evento enterFrame, pero no se tiene ningún control sobre él, se genera de forma natural en cada película.

Timer

Como comentaba, la clase Timer es una novedad de AS3. Nos permite crear un objeto que periódicamente llama a una función, pero en vez de estar ligado a la velocidad de la película, lo hace definiendo un intervalo de tiempo. De esta manera podemos indicar que un objeto se mueva cada 5 milésimas, 5 segundos o 5 minutos.

A un objeto Timer, junto con la frecuencia, se le puede indicar cuantas veces se debe ejecutar (por ejemplo, llamar a una función 5 veces cada medio segundo), y además cuenta con métodos start, stop y reset para controlarlo y con eventos que indican cada vez que se dispara la función o cuándo se ha completado un ciclo de llamadas.

Una persona sin experiencia en ActionScript a la que se le plantearan los dos mecanismos elegiría utilizar la clase Timer, dada todas las ventajas que aporta sobre enterFrame. Pero para sacar conclusiones, antes hay que conocer los mecanismos internos que tiene Flash Player para actualizar la pantalla.

Actualizando la pantalla

Hace ya alguna semanas escribí un post titulado El sistema de renderizado del Flash Player. Ese post estaba pensado inicialmente para explicarlo en este apartado, pero debido a lo extenso que estaba quedando decidí hacer un artículo al margen. Sino lo has leído o no lo tienes fresco, es aconsejable imprescindible que le eches un vistazo antes de continuar.

Como recordatorio nos quedaremos con esta imagen:

Procesamiento de 1 frame a 1 fps con un evento EnterFrame

Al entrar en un frame se dispara el evento enterFrame, después se ejecuta el código del frame y se espera hasta que que llega la hora de renderizar la pantalla.

Un error muy común

Uno de los errores frecuentes que cometen muchos programadores (y no sólo novatos) es utilizar un Timer porque pueden poner valores muy bajos y hacer así más comprobaciones por segundo.

Por ejemplo, un clásico, utilizarlo para comprobar colisiones entre objetos:

Con la necesidad de saber inmediatamente cuándo los dos objetos se están tocando, lo comprobamos mil veces por segundo.

Este pensamiento conlleva dos grandes problemas:

1. Ninguna máquina te va a dar un rendimiento suficiente con un valor tan bajo.
2. Aunque la máquina lo diera, sería inútil, ya que el renderizado de pantalla depende del framerate.

Para mayor claridad, vamos a estudiar estos dos problemas en apartados independientes.

Problema 1

Un objeto Timer, a pesar de funcionar independientemente del framerate, depende en todo momento de la velocidad de procesamiento de la máquina, y es por eso que no es capaz de garantizar el valor asignado.

Por ejemplo, pongamos un caso perfecto en que tenemos puesto durante 10 segundos un Timer a 1 milisegundo: realizaría 10.000 llamadas a una función. Si esta película la ponemos en un ordenador que esté ocupado por otros programas, quizá sólo sea capaz de realizar 6.000 llamadas en el mismo tiempo.

Como no podemos garantizar el rendimiento, es importante no forzar la cpu con valores muy bajos. He aquí una tabla de valores en milisegundos y su correspondencia en fps:

Como podemos ver, valores por debajo de 10 ms son prohibitivos. Cuanto mayor sea el número de milisegundos mejor podremos garantizar el equilibrio de nuestra película en distintos ordenadores.

Problema 2

Imaginemos un hipotético caso en que nuestra máquina es capaz de procesar a 1 milisegundo y simulemos el ejemplo en que dos bolas colisionan:

Película a 1 fps y comprobación de colisión mediante Timer a 1 milisegundo

Los objetos están ligados al motor central del swf, así que en cada frame se procesa el código y se actualiza la pantalla. Por otro lado, de forma independiente, con un Timer vamos comprobando si hay colisión. Es muy fácil ver que estamos haciendo miles de comprobaciones inútiles. E incluso en el frame 3, dónde por fin el Timer detecta la colisión, aunque a nivel de código se haya procesado en el milisegundo 1, no va a tener representación visual hasta el milisegundo 1000 (después del ciclo de renderizado).

El mismo código coordinado con enterFrame nos hubiera dado 1 colisión de 4 comprobaciones, en vez de 1 de 4000.

Siempre que se ejecute código que tenga una representación por pantalla, si lo hacemos en un enterFrame estamos asegurando que tenemos una relación 1 a 1 entre la ejecución y la visualización en un frame.

Nota: para ejemplificar el problema de los valores bajos en un Timer, he escogido la situación más exagerada: 1 fps y 1 milisegundo. De todas formas, con otros valores más reales, como 24 fps y 10-20 milisegundos, la cantidad de recursos desperdiciados sigue siendo muy grande.

Solucionando los problemas

Ya hemos visto que para solucionar el problema 1 no debemos utilizar valores que fuercen excesivamente la máquina: hay que valorar la cantidad de código que se procesa en el listener del Timer, durante cuánto tiempo, si la película ya está consumiendo recursos...

Para el segundo punto, hay una solución que ya comenté en el artículo del render: el método UpdateAfterEvent, que se puede invocar en las clases MouseEvent, KeyboardEvent y TimerEvent, y que fuerza al player a actualizar la pantalla. Su uso sería así:

Hay que notar que no sirve de nada utilizar este método si los objetos se siguen moviendo con el framerate de la película. En el ejemplo de la colisión, lo único que conseguiríamos es hacer las mil comprobaciones por segundo y refrescar la pantalla otras mil veces, pero si las bolas se mueven a 1fps lo único que conseguimos es empeorar todavía más el rendimiento de la película.

En cambio, si procesamos el código de movimiento en el listener del Timer y lo acompañamos con updateAfterEvent, tendremos un movimiento muy fluido.

Pero como suele pasar, una ventaja en un lado conlleva una desventaja en otro. En este caso, la fluidez del Timer más el update significa aumentar el número de ciclos de refresco de pantalla así como el número de ejecuciones del código, por lo que hay que usarlo prudentemente.

Flash Player funciona con framerate

A estas alturas parece obvio decirlo, pero Flash Player funciona bajo el compás que marca el framerate. Por ello, hay que tener en cuenta que si contamos con animación en linea de tiempo, sincronizar animación con código en un enterFrame es automático, pero hacerlo con un Timer es imposible.

Si tenemos una película que corre a 50 fps, una animación en el timeline de 500 frames y un enterFrame activado, en el caso ideal se recorren los 500 frames en 10 segundos lanzado 500 eventos enterFrame. Si el framerate no fuera real (ver apartado "Framerate real" en el artículo anterior) y bajara por ejemplo a 25 fps, la película tardaría 20 segundos en ejecutarse, pero en el frame 228 se lanzaría el evento 228, y en 446 el 446, con lo que siempre tendremos sincronizada nuestra animación con nuestro código.

Sin embargo, debido a la naturaleza del Timer, aunque podamos limitar el número de eventos a 500 repeticiones y calcular el tiempo para que coincida con los 10 segundos que tardará el timeline, en cuanto la máquina no dé el valor exacto (que virtualmente es siempre), nuestro frame número 50 no corresponderá con el evento TIMER número 50.

Internet está poblada de películas Flash (animaciones, juegos, sites...) que no funcionan bien en todas las máquinas debido a que los programadores no tuvieron en cuenta este punto tan básico.

La dependencia del Timer

Unos apartados más arriba comentaba que el Timer funciona al margen del framerate, pero... ¿es esto cierto?. Para comprobarlo podemos crear una película a 120 fps y copiar el siguiente código en el primer frame:

Este código crea una bola en el escenario y mediante un Timer la mueve 1 pixel hacia la derecha cada 50 milisegundos un total de 100 veces. En otras palabras, pasados 5 segundos (100x50) la bola se habrá movido 100 pixels. Si ejecutamos veremos que realmente sucede así. ¿Pero qué sucede si en el mismo código cambiamos el framerate a 1 fps?

Al ejecutar la película comprobamos 3 cosas:

1. La bola continúa desplazándose 100 pixels (correcto)
2. Debido al bajo framerate y que el renderizado ocurre cada segundo, el movimiento no es suave, sino que se visualiza a saltos (correcto)
3. La bola tarda bastante más de 5 segundos en recorrer los 100 pixels (¿?)

Las dos primeras sentencias son lógicas, pero la tercera no debería serlo. Aunque por pantalla no se reflejen los cambios, el Timer debería procesarse en 5 segundos, ¿no? Pues no, porque incluso los Timers tienen dependencia del framerate. La limitación consiste en que un Timer sólo puede dispararse como máximo 10 veces por cada ciclo de renderizado. Si nos fijamos en esta segunda prueba, la bola ha realizado exactamente 10 saltos antes de completar el recorrido, debido a que una película a 1fps puede alcanzar como máximo los 100 ms.

Sabiendo esto podríamos concluir con otra tabla entre el valor del framerate y la dependencia que crea en el Timer:

Así pues, los valores que vimos en la primera tabla, realmente están supeditados a esta norma. Otra razón de peso para no poner valores muy bajos en el Timer.

El consumo de memoria

No hay que olvidar que con cada objeto Timer que se crea, se está reservando memoria, al contrario que con enterFrame, que no crea un nuevo objeto, sino que guarda una tabla de objetos suscritos.

Si creamos una clase ObjetoAnimado cuyo motor principal es la clase Timer, y luego creamos mil instancias de ObjetoAnimado, generaremos un consumo de memoria muy elevado, por lo que hay que tener cuidado cuando se trabaje con muchas instancias de la clase Timer.

Nota: Esto puede evitarse centralizando el código. En la segunda parte de este artículo se tratara este recurso.

Timer negatifo, nunca positifo

Leído lo leído, va a resultar que la clase Timer sólo da problemas, y tampoco es así. El hecho de que esta clase funcione en relación al tiempo la hace especialmente útil, por ejemplo, realizando tareas cada ciertos periodos, ya que en caso de hacerse en un enterFrame resultarían repetitivas.

En el caso de la animación, la gran ventaja del Timer es que puede actuar independientemente sobre distintos objetivos, dándonos mucha más libertad que con enterFrame, en el cuál la velocidad es fija para toda la película (aunque en AS3 se pueda variar en tiempo de ejecución, sigue afectando a todos los elementos). Además, combinándolos con updateAfterEvent() se puede conseguir animaciones más fluidas.

Para sacarle el máximo provecho, sólo hay que entender su naturaleza y sus limitaciones.

Resumiendo

Como programadores, es un deber optimizar al máximo nuestros desarrollos, y en cualquier lenguaje visual, optimizar el código es un arte. A pesar de que año tras año la velocidad de procesamiento de los ordenadores aumenta, la memoria disponible cada vez es mayor, la AVM (ActionScript Virtual Machine) es más potente, etc. es frecuente ver swf que agotan los recursos del Player.

En ActionScript, un buena compresión del evento enterFrame y la clase Timer (combinado con el sistema de renderizado del Player), nos abre una gran puerta a desarrollar mejores programas. Con este artículo, espero haber puesto las bases de esa compresión, y allanar el camino para saber cuándo se debe utilizar uno u otro.

Dejo pendiente un segundo artículo en esta serie donde explicaré casos reales de uso, y en función de mi experiencia, mostraré cuál es la mejor manera de abordar el problema.

9 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Debido a que ActionScript es un lenguaje 100% visual, tener un conocimiento profundo de este proceso nos ayudará a la hora de escribir y optimizar nuestro código, y evitará que cometamos errores normalmente difíciles de detectar.

En este artículo veremos cómo funciona.

El sistema de renderizado del Flash Player

El sistema de actualización de pantalla de Flash Player es automatizado y no hay forma de controlarlo.

Su funcionamiento interno está estrechamente ligado a la línea de tiempo de una película: se alcanza un frame, se ejecuta su código y se procesa la imagen. Incluso películas generadas sólo con código, sin ningún frame, o películas compiladas en Flex, que no cuenta con linea de tiempo, están gobernadas por el mismo mecanismo. A efectos del runtime de Flash, ejecuta cada película como si tuviera una linea de tiempo infinita.

El periodo de tiempo para visualizar cada frame viene marcado por el framerate del swf, que se mide en frames por segundo (fps).

Para hacernos mejor una idea, vamos a crear una serie de casos y a apoyar la explicación con gráficos y ejemplos.

Caso 1

Empecemos con una película con el framerate a 1 segundo, con código en el primer fotograma que crea contenido gráfico. Supongamos que Flash Player tarda 200 milisegundos en procesar el código, y que tarda 200 milisegundos más en hacer una actualización de la pantalla. El proceso sería el siguiente:

Procesamiento de 1 frame a 1 fps

Así pues, la cabeza lectora alcanza el primer fotograma y empieza a ejecutar el código. Una vez que ha acabado la pantalla no se actualiza inmediatamente, ya que el refresco viene determinado por el framerate, que está puesto a un segundo. Se entra en un tiempo de espera. Cuando se cumple el ciclo del framerate se procede a actualizar la pantalla, acción que tampoco es inmediata. Una vez que el Flash Player ha conseguido dibujar todo el contenido por pantalla, salta a un nuevo frame y vuelve a empezar el proceso.

Caso 2

Ahora imaginemos que la porción de código del frame es considerable y el programa tarda 1500ms en realizar dicha ejecución. ¿Qué sucede cuando se cumple el ciclo del framerate y no se ha procesado todo el código? Pues que el renderizado no se efectuará, se pondrá a la cola hasta que el código haya sido procesado.

El runtime de Flash nunca interrumpe la ejecución de código para actualizar la pantalla.

Podemos demostrarlo con un sencillo ejemplo. Tenemos una película con 5 frames y un framerate de 1 segundo. El quinto fotograma tiene un script que, en función de si está o no activo el checkbox, genera un bucle 9 mil millones de veces con el único objetivo de ralentizar el procesador.

Descargar ejemplo

Si el checkbox está activado al entrar en el frame 5, Flash Player comienza a ejecutar código que no puede procesar antes del ciclo del framerate, por lo que la pantalla no se actualiza y vemos durante más tiempo el número "4".

Nota: cada swf tiene un tiempo máximo para ejecutar un script. Si se supera, aparece el famoso mensaje de "Un script de esta película está provocando que el Reproductor de Flash se ejecute lentamente".

En AS3 está documentado como el error #1502: "El tiempo de ejecución del script ha superado el tiempo de espera predeterminado de 15 segundos".
El valor del tiempo se puede configurar en las propiedades de publicación.

Caso 3

Pasemos ahora a una película con un sólo frame (hay que recordar que aunque sólo haya un frame o esté pausado, a efectos del runtime es como si hubiera una linea de tiempo infinita). En este frame se añade un listener al stage para escuchar un evento MouseEvent.CLICK, y con cada click se pinta una redonda en la posición del puntero. El framerate del swf está puesto a 0.4 (dos segundos y medio). Es notable la diferencia de tiempo desde que se ejecuta el código hasta que se dibujan las redondas en pantalla.

Descargar ejemplo

Si pensamos en el gráfico del "caso 1" sabemos que el código que registra el listener se ejecuta al principio, y que a cada ciclo se renderiza la pantalla. Pero... ¿cuándo se ejecuta el código asociado al evento click? Veamos otro gráfico más detallado.

Procesamiento de 1 frame a 1 fps

Cuando se entra en "Tiempo de espera", cualquier código generado como resultado de un evento (de mouse, de teclado, de un Loader, ...) se ejecuta en este periodo y se muestra en pantalla en el siguiente ciclo.

Debido al exagerado framerate utilizado en este ejemplo, en cada frame se puede generar varias veces código para pintar los puntos, y en "Tiempo de renderizado" se actualizan todas a la vez.

Caso 4

Añadamos un simple botón al ejemplo anterior. Probemos a hacer algunos clicks para dibujar puntos y acto seguido rollover sobre el botón.

Descargar ejemplo

Curiosamente, al hacer rollover se dibujan inmediatamente los puntos, aunque no hayan pasado los 2'5 segundos del framerate. Esto es así porque ciertos eventos pueden forzar al Flash Player a renderizar la pantalla. Como en este caso, cada vez que se interactúa con un botón se indica al runtime que debe actualizar la pantalla para reflejar el cambio de estado del mismo. Esta actualización no afecta únicamente al objeto, sino a todos los que están esperando para ser procesados.

Al margen de los botones, acciones como pasar el puntero sobre un Sprite o usar el tabulador entre cajas de texto también fuerzan a renderizar.

Y aún hay más, porque mediante el método updateAfterEvent, que muchos recordaréis de versiones anteriores de ActionScript, podemos indicar al Player que actualice la pantalla. En AS3 se puede invocar en las siguientes clases: MouseEvent, KeyboardEvent y TimerEvent.

En el ejemplo anterior, sin modificar el framerate, añadamos un updateAfterEvent al evento click y veremos como se pintan los puntos sin demora.

Descargar ejemplo

Así pues, podemos hablar de dos categorías a la hora de renderizar:

• La que se genera a intervalos regulados por el framerate
• La que se genera bajo demanda de ciertos eventos

Al principio del artículo comentaba que el sistema de actualización de pantalla de Flash Player era automatizado. El hecho de poder usar updateAfterEvent no cambia nada, ya que realmente este método no actualiza la pantalla directamente, sólo indica al runtime la necesidad de hacerlo. Sin en el momento de la petición se encontrara ejecutando código no lo interrumpiría.
Es importante recordar que el renderizado siempre está gobernado internamente.

Caso 5

Veamos ahora un último ejemplo para entender como encaja el evento enterFrame en este rompecabezas.

En AS3 se puede definir un evento enterFrame en cualquier objeto del tipo display object (se encuentre o no en la displayList) y obviamente está sincronizado con el framerate de la película. Una vez definido, este evento se dispara cuando la cabeza lectora alcanza un nuevo fotograma, y lo hace antes de ejecutar cualquier código.

Procesamiento de 1 frame a 1 fps con un evento EnterFrame

Así pues, se alcanza un nuevo frame, se dispara un Event.ENTER_FRAME y se ejecuta el código asociado, acto seguido se ejecuta el código del frame y finalmente se entra en tiempo de espera hasta el siguiente renderizado.

Es importante notar que una vez que se dispara un Event.ENTER_FRAME lo hace a todos los objetos que están suscritos, aunque estén en diferentes líneas de tiempo, y se ejecuta siempre el código asociado de todos antes que el código del frame.

Para ejemplificar lo comentado, dejo un fla que define varios enterFrame en diferentes momentos y con código en cada frame. En la ventana de output se puede ver el orden de ejecución.

Descargar ejemplo

Comprobación de renderizado

En los gráficos que hemos visto, una vez pasado el "tiempo de espera" se entraba directamente en el "tiempo de renderizado". Esto no es exactamente así.

Al finalizar el tiempo de espera se evalúa si ha habido cambios "visuales" desde el último frame. Si hay nuevos datos que dibujar o modificar, se procede a actualizar la pantalla, pero si el contenido del último frame y del actual son visualmente idénticos no se entra en "tiempo de renderizado". De esta manera, el runtime evita hacer operaciones innecesarias.

Además, Flash Player sólo renderiza las zonas sensibles al cambio, no hace un update de toda la pantalla. Al conjunto de las zonas que hay que pintar se le llama "regiones de dibujo", conocido en inglés como "redraw region". Si miramos en el menú contextual cuando ejecutamos una película en el IDE (o en una versión debug), veremos la siguiente opción:

y al activarla encontraremos una serie de rectángulo rojos, que son las zonas que el Flash Player ha dibujado en el último render.

Framerate real

Durante todo el artículo hemos dicho varias veces que el framerate marca los ciclos en los que hay que actualizar la pantalla. Aunque esto es verdad, el framerate que le indicamos a nuestra película no suele alcanzarse la mayoría de veces, ya que en función de factores internos (la complejidad del código a ejecutar) y externos (la potencia de la máquina en la que se ejecuta Flash), el número de frames por segundo será menor al indicado. La cantidad de frames que es capaz de procesar el Flash Player en un segundo se conoce como framerate real.

Para mis experimentos utilizo una clase muy simple que cuenta los frames reales que se procesan en un segundo y los muestra por pantalla. Un ejemplo de su uso:

Descargar ejemplo

El ejemplo está puesto a 31 fps. Lo primero que hay que tener en cuenta es que por el hecho de correr una película en un navegador ya pierde 4 o 5 frames. A medida que vayamos pintando el framerate real cada vez irá bajando más y más, debido a la carga de procesamiento. Hay que advertir que si dejamos de interactuar, el framerate se recupera aproximadamente a los valores iniciales, ya que en ese momento no se procesa código y debido a que no hay cambios visuales el Flash Player no pasa por el proceso de renderizado.

Nota: la clase FPS da un valor aproximado de la cantidad de fps. Se debe utilizar únicamente para depurar ya que no limpia sus recursos.

Para acabar, veamos un resumen con todos los puntos claves del artículo.

Resumiendo

Flash Player cuenta con un sistema basado en frames para procesar código, y éste se combina con un motor de renderizado para dibujar los gráficos en pantalla.

La frecuencia de dicho procesamiento viene marcada por el framerate del swf.

El proceso de renderizado es automatizado.

Flash Player nunca interrumpe la ejecución de código para actualizar la pantalla.

Hay dos tipos de situaciones que desencadenan el renderizado: la que se genera a intervalos regulares marcados por el framerate y la que se genera tras la petición de ciertos eventos.

Cada vez que se alcanza un frame se sigue este proceso:

• Se dispara un evento ENTER_FRAME en caso de estar definido.
• Se ejecuta en código asociado al enterFrame.
• Se ejecuta el código del frame actual.
• Se entra en un modo de espera hasta que toque renderizar la pantalla.
• Si durante la ejecución de código anterior se ha definido eventos, se recogen y procesan en este tiempo de espera.
• Una vez cumplido el ciclo del framerate se procede a una comprobación: si ha habido cambios gráficos se renderiza, sino, se salta al siguiente frame.

Una vez iniciada una película, el Flash Player la trata como si tuviera una linea de tiempo infinita, no se deja de ejecutar hasta que se descarga.

El framerate asignado a una película no suele cumplirse, siempre suele ser menor debido a factores como la cantidad de código a ejecutar, la complejidad de éste, la potencia del ordenador, los recursos del sistema operativo, etc.

17 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Con 2 años de desarrollo a las espaldas y 3 versiones Beta, cualquier persona que se mueva en el mundillo web sabe de que va el tema. Sin embargo, AIR no afectará sólo a los desarrolladores, sino que va a suponer también un gran impacto en los usuarios.

Si has estado de viaje en otro planeta, esperas que tu cliente entienda porqué necesita invertir en AIR, o quieres que tu abuela no se sienta desplazada en las comidas, este artículo es para ti.

¿Qué es AIR?

AIR son las siglas de Adobe Integrated Runtime, un entorno que permite ejecutar las aplicaciones AIR.

Cuando hablamos de una aplicación AIR hablamos de un programa de escritorio, igual que Windows Media Player, Photoshop o WinZip. Son programas que te descargas, instalas y ejecutas directamente sobre el sistema operativo.

AIR se construye sobre el Flash Player.

¿Cómo funciona AIR?

Para establecer una analogía, pensemos en una película Flash (.swf), que para verla es necesario tener instalado el Flash Player, o un archivo Word (.doc), que para abrirlo es necesario tener instalado Microsoft Word. Adobe AIR funciona igual: necesitas instalarlo primero para poder ejecutar sus aplicaciones.

AIR se instala como un programa más en nuestro ordenador, y actúa como una capa entre el sistema operativo y la aplicación que queremos instalar (representada por un paquete con extensión .air).

Las aplicaciones son multiplataforma, por lo que una única versión funcionará igual en todos los sistemas.

Actualmente hay versiones de AIR para Windows y Mac, y se espera para finales de año la versión de Linux.

Adobe AIR es gratuito y se puede descargar en http://get.adobe.com/air/
Una vez descargado, basta con ejecutar, aceptar la política de uso y en unos segundos lo tendremos instalado.

Es importante notar que AIR no se encuentra con el resto de programas ya que no se puede ejecutar (únicamente es un contenedor para las aplicaciones AIR). Sin embargo, a nivel de instalación/desinstalación funciona como cualquier otro programa.

¿Cómo se instalan las aplicaciones AIR?

Una vez que tenemos instalado AIR, instalar una aplicación es tan fácil como descargar, ejecutar y aceptar un par de cuadros de dialogo.

Uno de los cuadros que pueden llamar la atención es este:

Hay que tener en cuenta que las aplicaciones de escritorio pueden comprometer la estabilidad del sistema, ya que acceden a ficheros del ordenador, se conectan a internet, etc. Es por eso que Adobe ha incluido esta pantalla de advertencia, que contiene información del creador de la aplicación y nos indica el estado de dos opciones que determinan el nivel de confianza:

• Publisher Identity, o identidad del creador. Para validar esta opción, Adobe obliga a que la aplicación posea un certificado digital, que se consigue mediante empresas especializadas que hacen una auditoría del programa.
• System Access, o sistema de acceso. Relativo al nivel de acceso sobre el sistema de ficheros y a internet.

No es necesario tener validadas estas dos opciones para instalar un programa, es más, la segunda opción suele aparecer siempre como "Unrestricted". Además, conseguir un certificado no es barato, con lo que muchos particulares no firmarán sus desarrollos. Simplemente es una medida de concienciación para no instalar programas cuya fuente sea desconocida.

Una vez que tenemos nuestra aplicación AIR la podemos ejecutar como cualquier otra.

Nótese la pestaña de programa e incluso su icono en el systray.

Un buen sitio para empezar a descubrir programas es el Adobe Exchange.

¿Qué ventajas tiene AIR?

• Es multiplataforma. Los desarrolladores sólo se preocupan de programar una versión que funcionará igual en todos los sistemas, que se traduce en llegar a más gente en menor tiempo y con menor coste.
• Admite múltiples entornos para desarrollo: Ajax, HTML, Flex y Flash. Cualquier cosa que se pueda hacer en la web, se puede hacer en el escritorio.
• La interfaz es completamente personalizable, aunque también puede adoptar el estilo de las ventanas del sistema operativo.
• Es gratuito.

¿Por qué AIR?

Durante los últimos 10 años hemos asistido al crecimiento imparable de Internet. A medida que Internet llegaba a más lugares y a más gente, se iban popularizando las aplicaciones web: sistemas informáticos que se encuentran en servidores web y que se acceden normalmente por medio de navegadores como Firefox o IExplorer. Aplicaciones como el webmail, los blogs, Flickr o Youtube son hoy nuestro pan de cada día.

Pero actualmente estamos asistiendo a una nueva corriente que propone un modelo mixto: tener las aplicaciones en el escritorio y que éstas aprovechen lo mejor de la web.

Quizá el caso que mejor ejemplifica este modelo sea el cliente de correo. Todos tenemos una cuenta de gmail, hotmail, yahoo, etc. que consultamos vía web, pero para trabajar solemos tener configurado un cliente como Outlook o Thunderbird. Por comodidad y rapidez utilizamos un aplicación de escritorio, y accedemos a Internet puntualmente (para recibir y enviar el correo).

Otras ejemplo podría ser Microsoft Messenger que, a pesar de tener una versión web, el 99% de la gente utiliza como aplicación de escritorio.

Si nos ponemos a pensar en el software que tenemos en nuestro ordenador nos daremos cuenta de la cantidad de programas que siguen este paradigma: antivirus, clientes FTP, reproductores, clientes P2P... algunos utilizando Internet como base y otros puntualmente.

Esto es lo que proponer Adobe mediante AIR: llevar las aplicaciones web al escritorio.

¿Por qué ahora?

La idea no es nueva: Macromedia tenía en mente esta situación desde el 2001, pero por aquella época había problemas insalvables como el rendimiento de las aplicaciones, la falta de potencia de los lenguajes, inconsistencia de los navegadores... y por si esto fuera poco, la crisis del puntocom acabó de paralizar todo.

Así que siguieron trabajando esperando una nueva época. Ésta se vio reflejada con la llegada de la Web 2.0 y la revolución que supuso. En este momento, Adobe ya contaba con el Flash Player 9 y ActionScript 3.0, con el enorme salto de calidad que suponía.

Ahora sí, ha llegado el momento de saltar al escritorio.

¿Es AIR el futuro?

Una persona estrechamente relacionada con Adobe me comentó hace un año una cosa que me costó bastante de creer: la razón principal por la que Adobe adquirió Macromedia fue el interés que tenía por hacerse con Apollo (nombre anterior de AIR). Teniendo Macromedia la gallina de los huevos de oro, léase Flash, y otros programas líderes como Dreamweaver y Flex, etc. cuesta creer que su gran objetivo fuera este.

Otro dato a tener en cuenta son los movimientos del resto de compañías que, con algunas diferencias, también se embarcan en la lucha por el escritorio y por las RIAs (Rich Internet Application):

• Microsoft con su SilverLight
• Mozilla con Prism
• Google con Gears
• Java con JavaFX

Está claro que el futuro de las aplicaciones tiene una linea marcada, y ahora sólo queda ver quién jugará mejor las cartas. AIR, sin duda, ya cuenta con un par de ases en la manga.

19 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Vamos a jugar!!

Pintando pixels

Existen varios métodos para trabajar con los pixels de un bitmapData, pero las operaciones básicas para manipular el valor de un pixel son: getPixel(), setPixel(), getPixel32() y setPixel32().

GetPixel y getPixel32 se encargan de leer el valor de un pixel, con la diferencia de que el primero se utiliza en las imágenes opacas mientras que el segundo permite leer el canal alpha del pixel. De la misma forma, con setPixel establecemos el color de un pixel sin transparencia y con setPixel32 el de uno que sí la soporte.

Si se utiliza getPixel o setPixel (versión de 24 bits) en un imagen que soporta transparencia, el canal alpha se establece en FF (totalmente opaco), y si se utiliza la versión de 32 bits en una imagen que no soporta canal alpha, el canal alpha se ignora.

La sintaxis de los métodos es muy simple: sólo hay que pasar las coordenadas del pixel y, en el caso que haya que pintarlo, un color:

Vamos a ver algunos ejemplos.

Nota: no voy a poner el código entero para que el post no crezca demasiado, sólo las porciones más significativas. Los ejemplos se pueden descargar y el código fuente está comentado.

Ejemplo 1 (Paint)

Un Paint muy sencillo para mostrar los métodos getPixel y setPixel. Selecciona un color de la paleta con un click y pinta sobre el canvas con otro click. Para ilustrar mejor lo que es establecer un pixel no se puede pintar de forma continua.

Descargar ejemplo

Para este ejemplo se crean dos bitmaps (con sus correspondientes bitmapData): uno para crear la paleta de colores y otro para poder pintar. Para crear cada uno de los colores de la paleta, se utiliza el método fillRect(), que sirve para rellenar de un color un rectángulo (como el bote de pintura). Ninguno de los bitmaps soporta el canal alpha, así que se utilizan colores de 24 bits. También recordar que la clase bitmap no puede recibir eventos, por lo que se crean 2 sprite como contenedores.
El método para coger el color es:

y el método para pintar:

Sencillo, ¿no?

Ejemplo 2 (Spray)

Otro ejemplo donde se puede pintar con una herramienta tipo spray:

Descargar ejemplo

Aunque ya hemos visto lo fácil que es pintar un pixel, si se hace de uno en uno es una tarea muy lenta, por eso se suele utilizar otros métodos como el de este ejemplo.

La función pintar() se ejecuta en un enterFrame. Si se puede pintar, cogemos las coordenadas del mouse y pintamos 25 pixels por frame, generando el efecto de spray. La variable que controla si se puede pintar (_pintar_activo) se pone a true cuando dejamos presionado el botón izquierdo del mouse y se pone a false al soltarlo.

La clase Random es una clase propia que cuenta con varias utilidades para obtener números y puntos aleatorios. En este caso, el método obtenerPuntoCirculo() acepta un objeto de la clase Point y un radio, y devuelve otro Point que pertenece al área del círculo.

Para limpiar el canvas se utiliza esta función:

Al pasar el parámetro rect del mismo bitmapData, se pinta toda la superficie del color pasado, borrando todos los pixels que se habían pintado antes.

Ejemplo 3 (Linea)

Y otro ejemplo muy simple para pintar una línea.

Descargar ejemplo

En este caso se crea un bitmap transparente de color negro, pero con el canal alpha muy bajo (0x11000000). Hay dos variables que controlan las posiciones en x e y. En cada ciclo del enterFrame se pinta un pixel y se aumenta la variable de x.

Al aumentar _posx en 1 pixel cada vez tenemos una línea continua, pero si lo hiciéramos en 2 o 3 píxeles tendríamos una linea punteada, por ejemplo.

Controlando los pixels

El problema de los ejemplos que hemos visto hasta ahora es que conseguimos pintar, pero no tenemos ningún control de nuestros pixels una vez que los pintamos. Al fin y al cabo, pintar es sólo coger un pixel de un bitmapData y cambiarlo de color, realmente no existe ningún objeto que podamos manipular. ¿Cómo hacer, por ejemplo, si queremos pintar de una forma irregular?

La clave para esto es crear un objeto realmente, así podemos manipularlo a nuestro antojo y cuando sea necesario, coger su posición (x,y) y pintar ahí un pixel.

Para ello nos creamos una nueva clase, Pixel. Nuestra clase Pixel no tiene porqué extender de nada, ya que sólo la vamos a utilizar como un objeto que movemos donde queremos, pero no necesitamos una representación visual de él. Una versión muy simple para pintar una linea, como en el ejemplo 3, podría ser así:

Creamos un Pixel pasando una posición x, y (el num únicamente es para generar un nombre que podemos utilizar para identificarlos: pixel_0, pixel_1, etc). Cada vez que llamemos a su método mover() aumentamos la variable x en un pixel. Si luego accedemos a dicha variable (que es pública), podemos pintar un pixel en esa posición.

Hay que tener en cuenta que x e y son variable de la clase, no son las variables x e y que se heredan de la clase DisplayObject y que indican las coordenadas de un clip en el escenario. Se podía utilizar cualquier nombre, como posx y posy.

Vamos a ver un ejemplo donde se genera un movimiento algo más complicado. Se trata de crear un ángulo, darle una fuerza de salida al Pixel y aplicarle gravedad.

Ejemplo 4 (Explosión)

Con dicho movimiento, generamos una especie de explosión con cada click.

Descargar ejemplo

En este caso creamos un bitmapData completamente transparente, new BitmapData(ANCHO, ALTO, true, 0). Al hacer click se crean 50 objetos Pixel, y se almacenan en un array.

Hay que tener en cuenta que cuando se manipulan pixels se suele hacer con varios cientos o miles. La mejor forma es meterlos en un array, ya que es muy fácil recorrerlo después y aplicarles acciones, como en este caso:

Con este mecanismo, ahora sí tenemos control sobre todos nuestros pixels. Además de moverlos individualmente, podemos saber cuándo están fuera de pantalla para limpiar recursos, o guardar otras propiedades en la clase Pixel, como un color individual para cada uno.

Como no hemos creado una variable de clase para cada pixel, la única referencia que existe se encuentra en el array. Para poder borrar un pixel sólo hemos de quitar su posición en el array, de esta manera se queda sin referencia y el recolector de basura se encargará de eliminarlo de la memoria (mirar el código fuente y los comentarios).

La clase Pixel no está comentada, ya que sólo hay que entender que cuenta con unas variables que almacenan la posición. Explicar el movimiento angular no es el objetivo del ejemplo.

Fundiendo los pixels

Por ahora llevamos un buen camino: sabemos cómo manipular los pixels individualmente, como crearlos almacenándolos en un array, como gestionarlos a la vez y cómo pintar el recorrido en nuestro bitmapData. El problema que nos encontramos es que a medida que vamos pintando más y más, nuestro bitmapData queda lleno de pixels y se vuelve inservible para cualquier propósito que no sea dibujar.

Una técnica muy vistosa es crear un fade en cada pixel, así lo vamos degradando hasta que sea invisible. Pero claro, nuestro pixel sólo es un puntito de color que no cuenta con una propiedad alpha como si fuera un Sprite o un MovieClip. La solución pasa por aplicar el fade a todo el bitmapData, mediante un objeto ColorTransform y su propiedad alphaMultiplier.

Ejemplo 5 (Explosión Fade)

Click para generar la explosión con fade.

Descargar ejemplo

Usando esta técnica el ejemplo cambia por completo y gana bastantes enteros. Veamos el código añadido.

Primero creamos una variable de clase para el objeto ColorTransform:

En el constructor indicamos la cantidad de alfa (de 0 a 1):

Por último, en nuestro enterFrame lo aplicamos:

Con esta última línea, lo que estamos haciendo es que en cada frame le damos a nuestro bitmapData una transparencia de 0.9, y al hacerlo de manera tan continuada acaba fundiendo lo que hemos dibujado. Por otro lado, como estamos continuamente pintando sobre nuestro bitmap siempre vemos algo en pantalla.

Si el valor de alphaMultiplier es bajo (por ejemplo, 0.7), apenas veremos nada, ya que el fundido se producirá demasiado rápido. Por el contrario, si nuestro valor se acerca a 1 (por ejemplo, 0.98), el objeto ColorTransform tardará demasiado en fundir la imagen.

Descárgate el ejemplo y prueba diferentes combinaciones entre el número de pixels que genera cada click, el valor de alphaMultiplier y el número de frames de la película para entender la relación entre los elementos.

Importante: para utilizar esta técnica el bitmapData debe tener la propiedad transparent a true, ya que si la imagen es opaca el fundido se verá reflejado sobre la misma.

Generando pixels indefinidamente

En más de una ocasión nos interesará generar partículas continuamente sin que el usuario tenga que interactuar. Un ejemplo podría ser crear la estela de un cometa o simular los propulsores de un cohete, o simplemente para obtener un efecto visual.

La idea es tan simple como garantizar que siempre haya un número mínimo de pixels en pantalla: para ello debemos eliminar los que se encuentren fuera de los límites y generar nuevos.

Para que resulte más claro, vamos a trabajar sobre un ejemplo

Nota: para no consumir recursos innecesarios, los ejemplos de este tipo sólo funcionarán cuando el cursor esté dentro del swf.

Ejemplo 6 (Cascadas)

Con las técnicas explicadas anteriormente, aquí tenemos una cascada de pixels. Al salir del área visible se generan nuevas partículas y el ciclo nunca se interrumpe.

Descargar ejemplo

Para ello añadimos dos nuevas variables de clase:

La primera indica el número de pixels máximo que puede haber en pantalla, y la segunda el número de pixels por frame que se han de generar en caso que no se haya superado el número máximo.

Dichas variables se utilizan en el enterFrame:

Miramos la longitud del array, y si es menor que el número de partículas, entramos en el bucle. En vez de crear una partícula por frame, este for nos permite generar un número elevado. Si no lo hiciéramos así, las partículas dependerían siempre del framerate de la película, y normalmente no podríamos conseguir muchas a la vez.

Por último, en el enterFrame, por cada pixel, se ejecuta este linea:

Es imprescindible comprobar continuamente la posición del pixel para poder eliminarlo y generar nuevos. Evidentemente, en función del tipo de experimento, habrá que comprobar otros límites para eliminarlo.

Nótese que el número de pixels máximo nunca es exacto, ya que si hemos fijado un valor de 400 y tenemos en pantalla 392, al entrar en el bucle nos generará 20 más teniendo un total de 412. Esto no es significativo ya que se eliminan y crean con mucha rapidez. Lo importante es tener un valor que nos sirva visualmente sin influir excesivamente en el rendimiento.

Nótese también que si el número de pixels máximo es muy elevado y el de los pixels por frame no lo es, nunca se alcanzará el máximo. En el código, al final de la función del enterFrame, hay un trace que indica la longitud del array. Es bueno ir mirándolo hasta conseguir ajustar las cantidades.

Por último, comentar que cuando se juegan con partículas es muy importante tener en cuenta el rendimiento, ya que es muy fácil colapsar la CPU a partir de ciertos valores. Por eso en mis experimentos siempre utilizo un medidor de frames por segundo, que es el recuadro azul que se ve en el ejemplo. Utilizándolo se puede comprobar si nuestra película está rindiendo a un nivel aceptable. Todos estos swf tiene un framerate de 31, y en navegador es frecuente que bajen hasta los 24-26. Recomiendo usar siempre uno para tareas de depuración (en general con cualquier desarrollo que consuma muchos procesos). La clase es FPS y se encuentra en el paquete com.llops.utils.

Aplicando filtros: Glow

Como siempre, los filtros nos permiten crear efectos visuales muy potentes. En el tema que nos ocupa, el que mejor casa con la programación pixel es el filtro Glow. Este filtro nos permite crear una pequeña aureola de cualquier color alrededor del pixel, y a la vez le podemos aplicar blur para suavizar los puntos. Se utiliza normalmente para generar brillos, y la intensidad aumenta al concentrar partículas en un mismo punto.

Ejemplo 7 (Cascadas Glow)

Nuestra cascada de antes era algo sosa, vamos a ver como queda con un simple glow.

Descargar ejemplo

La diferencia con el ejemplo anterior es notable. Los pixels ya no son planos y el resultado es mucho más vistoso.

Los filtros se aplican sobre el bitmap directamente, en el formato de array. Lo único que hay que hacer es importar la clase flash.filters.GlowFilter y crear uno:

Aunque tiene más parámetros, los 4 primeros son los principales. Con ellos indicamos el color, la transparencia, y el blur en x y en y.

Nota: no poner un blur mayor que 12, ya que tiende a desvanecerse y no se aprecia.

Para ver los resultados con distintas combinaciones, en el código he puesto algunos colores y dos variables para el color interior y el del glow. Puedes hacer tus pruebas:

Y aquí va otro ejemplo, este con más intención:

Ejemplo 8 (Lava)

Simulación de un río de lava. Se rebaja la velocidad de los pixels para acumularlos y se aumenta el blur del glow.

Descargar ejemplo

Podríamos decir que da bastante el pego :)

¿Todavía hay más?

Pues aún queda un truquillo más que puede dar mucho juego: el parámetro blendMode de DisplayObject, que consta de 14 modos. El resultado final de cada modo depende mucho del color del bitmap, las capas adyacentes, etc., pero en general, algunos modos como ADD, DIFFERENCE o INVERT suelen ofrecer posibilidades interesantes. Considéralo un efecto avanzado que puede requerir bastantes pruebas hasta dar con un resultado convincente.

Basta con una sola línea para utilizarlo:

Y la verdad es que siempre habrá mucho más: se le pueden añadir filtros de desplazamiento, ruido, interacción con el usuario, generación aleatoria de color... en definitiva, un sinfín de posibilidades. Sólo hace falta tener ganas de experimentar.

Y para acabar

Todos los ejemplos que he puesto hasta ahora han tenido una finalidad didáctica, así que no han sido muy espectaculares. De todas maneras, para los exigentes, y sin meterme en código complejo, dejo un último experimento que personalmente me gusta mucho ;)

Ejemplo 9 (Conexiones)

Combina los métodos descritos: transparencia, fade, glow, blendMode...

Descargar ejemplo

Resumiendo

AS3 es uno de los lenguajes (sino el que más) que permite exprimir al máximo el concepto de "programación creativa", y la programación orientada a pixel da buena prueba de ello.

En este tercer artículo he intentado poner algunas herramientas encima de la mesa, y ahora depende de cada uno utilizarlas a su manera. Soy un fan de este tipo de experimentos, así que si programas algo relacionado me encantará verlo :)

También me gustaría remarcar la idea que hasta ahora no hemos jugado con imagen, sino con bitmaps creados de cero, que son simples recuadros de color. Es fácil imaginar las posibilidades al añadir fotografía...

En cuanto a esto, decir que mi intención era escribir un par de artículos más sobre estos temas, pero he de reconocer que estoy un poco saturado de tanto pixel, y me apetece hacer cosas nuevas. Así que de momento, haré una pausa indefinida en esta serie. Espero que lo visto hasta ahora haya sido de interés.

11 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Nota: Sino leíste la primera parte de la serie, te recomiendo que le eches un vistazo antes de seguir.

La clase BitmapData, como su nombre indica, representa los datos de un bitmap, o lo que es lo mismo, almacena todos los pixels de una imagen. Esta representación solamente existe en memoria. Por otro lado, la clase Bitmap es un envoltorio para BitmapData, y permite manipular la imagen como objeto visual.

Pero... ¿por qué utilizar dos clases? ¿No sería más fácil una única clase encargada de manipular la imagen? Tratemos este punto antes de seguir con la sintaxis.

Arquitectura de BitmapData y Bitmap

Aunque las dos clases se encuentran en el paquete flash.display, BitmapData no pertenece a la Display List. Si echamos un vistazo a las clases que conforman la lista de visualización, podemos comprobar que sólo Bitmap hereda de DisplayObject, y por tanto es la única que se puede representar en pantalla:

Gracias a esta separación, las operaciones que se realizan con los pixels de una imagen no entran en el motor de renderizado del Flash Player, evitando tener que redibujar constantemente el contenido, cosa que pasa con los vectores. En este concepto se basa la técnica de cachear a bitmap (cacheAsBitmap).

Hasta la llegada de Flash8, un gran número de experimentos se veían frustrados por el bajo rendimiento del player cuando se dibujaban muchos vectores en pantalla. Estos problemas desaparecieron en el momento en que se pudieron agrupar estos vectores y pasarlos a una única imagen, liberando completamente al procesador de esta dura tarea.

Y la otra gran ventaja de esta separación es que distintos objetos Bitmap pueden utilizar el mismo BitmapData. De esta manera, podríamos tener una representación rotada, otra escalada, etc. y sólo consumiría la memoria de una imagen.

Visto así, es una buena idea tener separadas ambas clases: una para manipular los datos de la imagen y otra para manipular el objeto en pantalla.

No está de más observar que Bitmap no hereda de InteractiveObject, con lo que no puede recibir eventos de teclado ni de ratón. Si queremos que esto sea así, deberemos reparentar nuestro objeto en un Sprite o MovieClip. Por otro lado, en caso de utilizar imágenes externas, deberemos cargarlas mediante un objeto Loader, que sí extiende InteractiveObject.

Sintaxis de BitmapData y Bitmap

BitmapData permite crear una imagen de cero o manipular una existente.

Nota: de momento nos centraremos en las imágenes creadas por código, que son simples rectángulos de color. En otro capítulo veremos cómo cargar imágenes o utilizarlas desde la librería.

La firma del constructor es:

Los dos primeros parámetros especifican el ancho y alto que tendrá nuestro objeto. El tercer valor indica si la imagen soporta transparencia por pixel, es decir, si la imagen tendrá canal alfa. Por defecto tiene. El último corresponde al color de la imagen, por defecto blanca.

Es importante recordar los siguiente puntos:

• Una vez creada la imagen, no se pueden cambiar su anchura y altura
• Si creamos la imagen opaca (transparent = false), el canal alfa del color será ignorado (por ejemplo, 0x55FFFFFF)
• El Player renderiza más rápido las imágenes que no soportan transparencia, así que si no es necesaria, mejor forzar el parámetro a false.

Así pues, para crear una imagen azul, opaca y de 100x100 pixels escribiríamos:

En este punto, tenemos nuestra imagen creada, pero solo existe en memoria, no podemos representarla visualmente (aunque ya podemos manipular sus pixels, aplicarle filtros, etc). Para ello, debemos crear un objeto Bitmap que la contenga. Veamos su constructor:

El primer parámetro que nos pide es un objeto BitmapData, así que pasándolo ya tenemos asociados los datos en memoria al contenedor (¿fácil, no?). El segundo y tercer argumento controlan el ajuste de pixel y el suavizado al escalarse. En la gran mayoría de los casos no son relevantes, así que nos olvidaremos de ellos.

Si añadimos algunas líneas más ya tendremos nuestra imagen en pantalla:

También es posible asociar el BitmapData al Bitmap mediante la propiedad bitmapData de este último:

Aquí hay un pequeño ejemplo donde se crean cuatro bitmaps de 60x40 con distintos valores en la transparencia y color. Si tienes alguna duda en este punto, te aconsejo que descargues el ejemplo y pruebes distintas combinaciones.

Descargar ejemplo

Hay que tener claro que los dos primeros valores hexadecimales determinan la transparencia, pero siempre que transparent sea true. Para crear una imagen completamente transparente se puede utilizar 0, que es lo mismo que 0x00000000.

Limitaciones de los bitmaps: los 2880 pixels

Si alguna vez has mirado alguna documentación o artículo sobre BitmapData, casi seguro que habrás visto una advertencia sobre que no se pueden crear imágenes con un ancho o alto superior a 2880 pixels. Esta limitación está puesta para que las películas no consuman excesiva memoria RAM, ya que una imagen de esas dimensiones consume aproximadamente 32 MB.

¿Y de dónde sale esta cantidad?

Pues como comentamos en el primer capítulo, un pixel tiene 4 bytes de información (1 byte por cada canal). Si tenemos una imagen de 2880x2880, tenemos 8.294.400 pixels, y al multiplicar por 4 tenemos que nuestra imagen consume una memoria de 33.177.600 bytes. Si lo dividimos entre 1024 (1KiloByte) tenemos 32.400 KB, y si lo volvemos a dividir entre 1024 tenemos 31'64 MB.

Personalmente, creo que los 2880 es una medida más que suficiente, y casi nunca necesitaremos una imagen de esas dimensiones. Aún así, hay que tener en cuenta que los bitmaps consumen mucha memoria, por eso hay que ser cautos cuando los utilicemos. Como referencia, una imagen de 100x100 consume cerca de 40 KB, una de 500x500 prácticamente 1 MB, y una de 1000x1000 3'8 MB.

Resumiendo

Como hemos visto, crear imágenes es una tarea muy sencilla. Sólo es importante entender cómo funciona el color (que lo vimos anteriormente) y saber que éste viene marcado por el booleano que indica si se soporta transparencia o no.

También es bueno comprender las ventajas que aporta tener las clases separadas y la limitación del tamaño de un bitmap.

Al final, este capítulo también ha sido más teórico de lo que en un principio tenía en mente. Y aunque prefiero asentar conceptos que considero importantes antes que correr mucho, no olvido que dije que me centraría en la manipulación de pixels. Así pues, el próximo artículo lo dedicaré enteramente a jugar con los pixels, y mostraré algunas técnicas para crear efectos bastante interesantes. Prometido ;)

6 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

La programación bitmap es uno de los temas más extensos y complejos que se pueden encontrar en AS3. Por otro lado, también es uno de los temas más apasionantes de este lenguaje, y merece la pena invertir horas en su aprendizaje.

El mayor problema que me encontré cuando decidí aprender sobre esta temática es la poca información que existe al respecto (poca en inglés, y prácticamente nula en español), así que al final, la mayoría de cosas que aprendí fue en base a experimentación y a invertir días enteros intentando descifrar códigos que encontraba por la red. Espero con estos artículos cubrir un poco el vacío existente en este campo. Vamos allá.

Nota: antes de sumergirnos en el código, es muy importante comprender cómo se componen las imágenes y los pixels, por eso he preferido dedicar este primer capítulo a la teoría de estos temas.

Introducción

La clase BitmapData permite trabajar con la información de una imagen. Fue introducida por Macromedia en Flash 8, y junto ella un nuevo abanico de posibilidades para manipular imágenes, añadir filtros, etc. Fue probablemente uno de los añadidos más importantes del lenguaje hasta la fecha.

Cabe recordar que Flash siempre ha sido una herramienta que trabaja con vectores, y hasta la llegada de Flash 8 apenas se podía hacer nada con las imágenes. Todo se reducía a poder cargarlas dinámicamente.

Veamos un poco esto dos formatos.

Vectores vs mapa de bits

Un vector es un gráfico que se construye en base a una descripción matemática. Los vectores trabajan con primitivas básicas como puntos, líneas y círculos. Por ejemplo, para dibujar una línea se necesita un punto inicial (x0,y0) y un punto final (x1,y1). La información que haya entre estos los puntos es generada en base a una ecuación.

Debido a esta forma de trabajar, un vector se puede escalar tanto como se desee sin perder calidad (se ve igual de nítido siempre), ya que lo único que se hace es alejar o acercar los puntos que conforman la figura. Esto permite tener archivos tan grandes como se quiera sin que aumente el peso del mismo, ya que siempre baraja la misma información.

Por el contrario, una imagen o mapa de bits (bitmap en inglés), es una cuadrícula de valores de color. Cada celda representa un pixel, que es la menor unidad en la que se descompone una imagen. Una imagen de 20x20 pixels tiene 400 valores de información, describiendo cada uno un color. En cuanto se intenta escalar un bitmap, el pixel se convierte en un rectángulo mayor y la imagen se distorsiona (se ve pixelada). El peso de una imagen depende entonces del tamaño de la misma, ya que a mayor tamaño mayor número de pixels y mayor número de información para guardar.

Pero no todo son desventajas para los bitmaps. Para imágenes complejas, se necesitarían tantos vectores para describir la figuras y colores que el tamaño resultante del archivo sería mucho mayor. Además, al tener que calcular las ecuaciones para dibujar el vector, todo el trabajo recae en el procesador del ordenador, con lo que la CPU se puede resentir de manera notable. Esto ha sido muy corriente en Flash, cuando veíamos animaciones espectaculares que se ralentizaban en ordenadores menos potentes.

Para más información sobre estos formatos, como siempre, a la wiki.

Valores de color

Como ya hemos dicho, un pixel es un minúsculo cuadrado de color. Es muy importante entender bien cómo se compone el color para poder trabajar con las imágenes, así que intentemos asimilar bien los siguientes conceptos.

Nota: aunque intentaré explicarlo lo más detallado posible, asumo que el lector tiene un conocimiento básico del sistema binario y hexadecimal.

En ActionScript el color se representa como un entero de 32 bits (4 bytes), y esto nos proporciona un rango de 4.294.967.296 (2^32) valores. Cada uno de estos 4 bytes representa un canal de color: 3 de ellos son los colores primarios: rojo, verde y azul, lo que se conoce en inglés como RGB (red, green, blue), y el cuarto representa la transparencia o color Alfa. La intensidad de cada color viene determinada por un valor comprendido entre 0 y 255. La intensidad total es 255 mientras que 0 representa la ausencia de color.

Este rango no es aleatorio. De 0 a 255 significa que existen 256 valores, que es el número que obtenemos si elevamos 2^8.
8 son los bits que hay en cada canal, o lo que es lo mismo, el byte de cada canal. Cada color en ActionScript tienes 32 bits o 4 bytes.

La intensidad en los colores RGB combinada forma las diferentes gamas de colores, mientras que la intensidad en el canal Alpha proporciona la transparencia. Así pues, con los 3 bytes (24 bits) de RGB tenemos un rango de 16.777.216 de valores (2^24), y a cada uno de estos valores le podemos dar 256 niveles de transparencia.

Al formar un color, se empieza por el canal alfa, seguido del rojo, verde y azul:

• Alfa: bits del 24 al 31
• Rojo: bits del 16 al 23
• Verde: bits del 8 al 15
• Azul: bits del 0 al 7

Por ejemplo, una representación del color azul puro sería:
Alfa = 255, Rojo = 0, Verde = 0, Azul = 255

En binario quedaría como sigue:
11111111 - 00000000 - 00000000 - 11111111 -> 32 bits

Y en decimal tendríamos el valor:
4.278.190.335

Es evidente que un número así no es muy fácil de recordar, por eso cuando hablamos de colores web se trabaja en formato hexadecimal. Un número hexadecimal comprende los 10 números de nuestro formato decimal más 6, de ahí que se conozca como base16:
0-1-2-3-4-5-6-7-8-9-A(10)-B(11)-C(12)-D(13)-E(14)-F(15)

Para indicar que es hexadecimal, se utiliza el prefijo 0x.
Algunos ejemplos de números hexadecimales (se multiplica por 16 por ser su base):

0x00 representa 0 -> 0*16 + 0*1 = 0 + 0 = 0

0x15 representa 21 -> 1*16 + 5*1 = 16 + 5 = 21

0x6A representa 106 -> 6*16 + 10*1 = 96 + 10 = 106

0xFF representa 255 -> 15*16 + 15*1 = 240 + 15 = 255

Entendiendo cómo funciona, es fácil deducir que un número hexadecimal de 32 bits se representa como 4 pares de valores hexadecimales:

0x FF FF FF FF
prefijo alfa rojo verde azul

Finalmente, ya podemos ver que nuestro color azul se representaría como:
0xFF0000FF

Esta nomenclatura es mucho más intuitiva y nos ayuda a leer e interpretar fácilmente una gran variedad de colores.

Para acabar de asimilar perfectamente estos conceptos, he credo un pequeño selector de color en el que se pueden modificar por separado los valores de cada canal y leer los resultados en formato decimal y hexadecimal.

Descargar ejemplo

Vamos a fijarnos en algunas cosas:

• Cuando los colores primarios (RGB) tienen el valor 0, el color es negro puro
• Cuando los colores primarios (RGB) tienen el valor 255, es blanco puro
• Un color sólo es opaco cuando el canal alfa tiene el valor 255. Cualquier otro valor nos proporciona un color transparente.
• Si los 4 canales están a 255, vemos que el número decimal es 4.294.967.295, y si le sumamos el 0 inicial tenemos el rango de colores de ActionScript que comentábamos al principio: 4.294.967.296
• El modelo RGB se basa en la síntesis aditiva, por eso la suma de los colores puros dan estos otros colores:
  - Rojo y Verde = Amarillo (0x FF FF FF 00)
  - Rojo y Azul = Púrpura (0x FF FF 00 FF)
  - Verde y Azul = Cyan (0x FF 00 FF FF)

Por último, indicar que en AS3 los colores se representa con el tipo de dato uint, que es un entero de 32 bits sin signo (siempre es positivo). Al no admitir valores negativos, el valor máximo es el doble que el de un tipo int, que admite 32 bits con signo.

Rango uint: de 0 a 4,294,967,295 (2^32-1)
Rango int: de -2,147,483,648 (-2^31) hasta 2,147,483,647 (2^31-1).

Un color se declararía así:

Colores sin transparencia

Hay que advertir que en la mayoría de los casos, cuando manipulamos objetos en ActionScript, el canal alfa no se modifica mediante el color, sino mediante la propiedad alpha (que define DisplayObject). Por ejemplo, cuando utilizamos el método beginFill de la propiedad graphics, vemos que la firma es

beginFill (color:uint, alpha:Number = 1.0):void

Aunque el tipo del color sea uint, se ignora la transparencia, ya que se aplica mediante su propiedad alpha. Si queremos que el color sea rojo, es lo mismo usar 0xFFFF0000 que 0xFF0000. Si tiene 4 pares hexadecimales, el primer par no se tiene en cuenta.

Veamos un ejemplo donde pasamos un canal alpha semitransparente, con valor 0x55. Al probar este código, vemos que el rojo es completamente opaco, ya que el canal alfa se ha ignorado:

Esta es la razón por la que al definir colores en CSS, en Graphics, etc. se utilizan colores de 3 pares hexadecimales (0xFF0000). Como norma general, sólo se utiliza el canal alpha cuando trabajamos con bitmaps que admiten transparencia.

Resumiendo

Aunque la teoría siempre es pesada, un buen entendimiento de estos conceptos es clave para manipular las imágenes. El siguiente capítulo será más divertido, ya que nos meteremos de lleno en las clases Bitmap y BitmapData.

14 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Este artículo es menos técnico que los anteriores, pero dado que el cambio es bastante significativo (ya no se utiliza más attachMovie) merece la pena tratarlo.

Desde flash 5, cuando queríamos utilizar un símbolo de la librería de manera dinámica, le dábamos un nombre de identificador y con "attachMovie" lo vinculábamos a nuestra película. En flash 8, además, teníamos un campo para asociar el clip a una clase de ActionScript 2.

Panel de vinculación de Flash 8

Para cualquier programador actionscript, la sintaxis de attachMovie le resultará tan familiar como engorrosa. Gracias a Dios, en Flash CS3 esto ha pasado a mejor vida.

Utilizando clips de la biblioteca en CS3

Como ya hemos comentado en los artículos anteriores, en AS3 todo se traduce a clases, así que si queremos utilizar un clip que tenemos en nuestra librería tenemos que crear una nueva clase. Vamos a verlo paso a paso.

Dibujamos una bola en el escenario de Flash y la transformamos a MovieClip (F8). En la biblioteca, seleccionamos nuestro MovieClip y buscamos la opción de Linkage.

Librería y panel de vinculación de Flash CS3

Marcamos el checkbox Export for ActionScript y se activan dos campos de texto. En el primero ponemos BolaClass, que será el nombre de nuestra clase. El segundo, como el nombre indica, es la clase de la cual hereda (podemos usar la clase base que queramos, lo veremos luego). De momento dejamos MovieClip. Al darle OK veremos que aparece el siguiente mensaje:

A definition for this class could not be found in the classpath, so one will be automatically generated in the SWF file upon export.

Flash nos advierte que no encuentra BolaClass en su ruta de clases, así que generará una clase automáticamente al exportar. Al igual que pasa con el document Class, cuando Flash CS3 necesita una clase y no la encuentra la genera él mismo. El mismo mensaje aparece si le damos al check verde o al lápiz.

Ahora que ya tenemos el clip exportado para ActionScript podemos crear bolas dinámicamente. El código es más fácil, limpio e intuitivo que attachMovie.

Dándole un comportamiento a nuestra clase

Si queremos dotar de comportamiento a nuestro clip, podemos escribir la clase nosotros en vez de dejar que lo haga automáticamente el compilador. De esta manera, tendremos el aspecto lógico y gráfico ligados.

Por ejemplo, vamos a hacer que nuestra bola, cada x segundos, desaparezca de su posición y aparezca en una nueva. Para ello creamos una nueva clase llamada BolaClass en la misma carpeta que tenemos el fla. El código podría ser algo así:

Una vez lista la clase, probemos a crear varias bolas en el escenario, por programación o arrastrándolas directamente desde la biblioteca. Ya tenemos nuestro clip con su comportamiento específico:

Descargar ejemplo

Cabe resaltar, que ahora que tenemos nuestra clase, si abrimos el panel de vinculación y le damos al check verde veremos este mensaje:

The definition for this class was found at [ruta de la clase]

en vez del mensaje anterior donde nos decía que generaría la clase él mismo. Y si clicamos en el lápiz Flash nos abrirá el .as en el IDE.

Utilizando nuestra propia clase base

Como hemos dicho antes, al margen de los símbolos por defecto, podemos utilizar cualquier tipo de clase como base (siempre que tenga coherencia). Por ejemplo, en nuestro ejemplo de la bola, la clase base podría haber sido perfectamente Sprite.

Pero la herencia no se limita sólo a las clases nativas de Flash, sino que pueden ser propias. Esto es útil cuando queremos dotar de comportamiento a múltiples objetos.

Sobre el ejemplo de la bola, imaginemos que queremos que otros objetos como un cuadrado y un triángulo tengan su comportamiento (cambiar de posición mediante un fundido). Una opción sería generar una clase para cada objeto. ¿Pero qué pasa si tengo 20 tipos de objetos diferentes? ¿Y si en vez de ser una clase sencilla son cientos de líneas? En este caso es más útil aislar el comportamiento y que lo utilicen todos los objetos. Vamos a verlo:

1. Creamos una clase: Fundido.as
   El código es el mismo que el utilizado en BolaClass, así que sólo tenemos que cambiar el nombre de la clase y el nombre del constructor.
2. Igual que hicimos con la bola, creamos dos MovieClips más, un cuadrado y un triángulo.
3. En el panel de vinculación, le damos los siguientes nombres respectivamente: BolaClass, CuadradoClass y TrianguloClass (las clases no deben existir, dejamos que las cree el compilador)
4. En el campo de la clase base, ponemos Fundido.
   
5. Añadimos al escenario los clips y probamos la película.

Descargar ejemplo

Tipo de símbolos para exportar

Para acabar, vamos a ver los tipos de símbolos que utiliza Flash CS3. Decíamos que el parámetro Base class viene dado por el tipo de símbolo que utilizamos. Cuando convertimos a símbolo, Flash nos da estas opciones:

• MovieClip - utiliza la clase base flash.display.MovieClip
• Button - utiliza la clase base flash.display.SimpleButton
• Graphic - no se puede utilizar de manera dinámica, por lo tanto no está disponible para exportar.

Además, a través de la opción de importar, podemos generar dos tipos más de contenido para utilizar de manera dinámica:

• Imágenes - hereda de flash.display.BitmapData
• Audio - hereda de flash.media.Sound

Tipo de símbolos que se pueden usar en la librería de manera dinámica

El funcionamiento es exactamente igual para todos: definimos un nombre de clase y mediante new la instanciamos. La única clase base que tiene una peculiaridad es BitmapData. Si le damos a nuestra imagen el nombre ImagenClass y probamos a crear una mediante new veremos este error:

1136: Incorrect number of arguments.  Expected 2.

Esto es debido a que el constructor de esta clase espera dos parámetros: anchura y altura. Aunque en teoría debería ser la anchura y altura de la imagen, conque le pasemos un número (negativo, decimal, con 20 cifras...) es suficiente. El compilador sobreescribe con los valores correctos (sí, no tiene mucho sentido).
El código sería similar a este:

Resumiendo

Con la llegada de AS3 todo gana en coherencia, y no sólo en cuanto a código se refiere. También ha obligado a Flash CS3 a cumplir en este sentido, y ahora utilizar nuestros clips de biblioteca de manera dinámica es tan fácil como darle un nombre de clase (que además no estamos obligados a crear) e instanciarla mediante el operador new.

Además, con la posibilidad de utilizar una clase base para nuestros objetos, gana fuerza la opción de herencia frente composición, aunque en muchos casos seguirá siendo preferible ésta última.

6 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2007