Los puntos tratados son los siguientes:

• Estructura de directorios para un proyecto ActionScript con FlexBuilder y FlashCS3
• Creación del proyecto, propiedades y classpath
• Main class (FlexBuilder) y Document class (Flash CS3)
• Diferencias básicas a la hora de compilar
• Propiedades de documento
• Alineación del Stage
• Uso de librerías de símbolos

La razón es sencilla. Estamos arraigados a Flash hasta la médula, y nos cuesta cambiar nuestras maneras, que buenas o malas, siempre nos han funcionado.

Con este post me gustaría aclarar dudas que se plantean a cualquier flashero con poca o mediana experiencia a la hora de afrontar un PROYECTO ACTIONSCRIPT con otra cosa que no sea FlashCS3.

¿Qué es FlashCS3?

Eso ya lo sabemos todos, pero básicamente es una herramienta que nos permite generar una aplicación en formato swf, en la que podemos diseñar, crear símbolos gráficos, incrustar o cargar imágenes, videos, sonidos, tipografías, etc, e interactuar con ellos mediante código ActionScript. Es una herramienta completa y para muchos tiene todo lo necesario para desarrollar. Con ella podemos también dibujar, crear efectos y diseñar. Trabaja en formato vectorial, pero además nos permite generar contenidos multimedia.
Nunca nos han hecho falta herramientas externas para desarrollar un proyecto. Flash nos daba todo lo esencial. Podemos escribir código y almacenar todos los símbolos gráficos necesarios dentro de un solo .fla, publicamos y ya tenemos nuestra web, juego, cd multimedia (o vete tú a saber) funcionando.
Lo que quiero decir con todo esto, es que es una forma válida de hacer las cosas aunque existan otras “distintas” (por llamarlo de alguna manera).

¿Qué es Flex, qué es FlexBuilder y qué tienen que ver con Flash?

Existe mucha confusión a la hora de hablar de Flex, o editar código con Flex. A ver, lo primero de todo: Flex no es FlexBuilder, y muchas veces cuando se habla de Flex, en realidad se refieren a FlexBuilder, pero como tiene incluida la palabra “Flex” la gente se equivoca.

Flex es simplemente un FRAMEWORK orientado al desarrollo de RIA´S. Hablando en plata, es una “herramienta” que nos da la facilidad de desarrollar ciertos tipo de cosas, en concreto las RIAS. ¿Qué es una RIA? ya estás tardando en leer este artículo de wikipedia que lo explica genial. Hagamos lo que hagamos con Flex, al final lo que generamos es lo mismo que Flash, un archivo SWF con nuestra aplicación. Por lo tanto Flex solo es una manera de desarrollar Flash y ambos no son cosas distintas, todo es plataforma Flash.

Flex se basa en componentes que implementan mucha funcionalidad básica y avanzada. Funcionalidad necesaria para cualquier aplicación, y que nos costaría muchas horas desarrollar con Flash. Ya que en Flash, a parte de sus componentes, lo tenemos que hacer todo a mano, es mucho más “artesano”. Por poner algún ejemplo, estamos hablando de sistemas de navegación, posicionamiento en pantalla, diseños líquidos, deep linking, validación de formularios, comunicación con bases de datos, Flash remoting, servicios web, y un largo etcétera que Flash no incorpora por defecto.
Y en difinitiva es eso, una ayuda para desarrollar, que también tiene sus limitaciones. En Flex no se diseña ni se dibuja, ni se anima en línea de tiempo. Por eso los diseñadores están lejos de usarlo. Pero si alguna vez has tenido que programar un proyecto medianamente grande, seguro que entenderás perfectamente las ventajas que comento.
Para dejar algo “bonito” en Flex se usan métodos como el skineado de componentes, adjuntar hojas de estilo CSS, etc. Nos da menos libertad para crear efectos visuales, pero nos facilita la vida en otros sentidos. Además, dentro de una aplicación Flex podemos incrustar cualquier cosa hecha con Flash. Desde assets gráficos hasta aplicaciones enteritas.

No se trata de si debemos utilizar Flex o Flash, sino de qué es lo mejor para el proyecto que acaba de caer en nuestras manos. No hay un método universal y creo que nunca lo habrá. Pero eso ya es un debate muy famoso, y cada uno que forme sus propias opiones al respecto. Yo tengo la mía.

Para crear una aplicación Flex solo son necesarias dos cosas:

1. código fuente (ActionScript)
2. un compilador (mxmlc), que interpreta el código y genera el archivo binario SWF ( lo mismo que hace Flash al publicar)

Aunque solo con esas dos cosas suelen trabajar los muy frikis, ya que funciona a través de línea de comandos (sí, la pantallita negra con código matrix). Lo más sencillo es usar una herramienta que haga transparente ese proceso…

Y ahora toca hablar de FlexBuilder, que simplemente es herramienta para desarrollar Flash, propiedad de Adobe, con varias utilidades muy interesantes y que está basado en Eclipse, (un IDE de desarrollo).

FlexBuilder facilita la vida a la hora de programar, nos da pistas sobre el código, y muchas veces lo genera automáticamente con atajos de teclado y otras artimañas varias.
Con él podemos crear aplicaciones basadas en el framework de Flex del que hablábamos antes, o aplicaciones Flash basadas en simple ActionScript de toda la vida (solo AS3 por cierto). Hay que tener muy en cuénta estos dos conceptos, porque son dos cosas distintas. En el lado que nos toca, hablaré solo de la segunda.

Con FlashCS3 podemos escribir código en el panel de ActionScript incorporado, u organizar nuestro código en clases externas al .fla, en forma de archivos .as.
Si en el panel de propiedades especificamos la “Document Class”, al publicar, Flash leerá e interpretará todo el código de dicha clase y sus dependencias. Se puede combinar código de las clases con código en línea de tiempo, u optar por utilizar solo una de las dos. Normalmente, en una aplicación totalmente orientada a objetos, en la linea de tiempo hay poco código, y se suele referir a acciones básicas (esto es discutible, lo se).

El editor de código de FlashCS3 es lo más inutil y frustrante que puedas usar, ya que es poco intuitivo, y está exento (casi) de cualquier tipo de ayuda si no te sabes todo de memoria (métodos y propiedades de objetos, etc). Por eso muchos optan por usas editores externos para el código. Existen varios, como por ejemplo Eclipse FDT, Flash develop, FlexBuilder, TextMate, etc. Y sí, incluyo FlexBuilder.

Podemos usar FlexBuilder (o cualquiera de los citados) para programar un proyecto ActionScript, y después compilar con FlashCS3, es perfectamente viable. Para ello solo hay que crear un proyecto con las clases que FlashCS3 usa para publicar, en concreto la “Document Class”. De esa manera hacemos las cosas como siempre, tenemos línea de tiempo, una librería con todos los símbolos que nos de la gana, podemos hacer fuegos artificiales… y por fuera tenemos un editor de código que nos ayuda muchísimo en la tarea de programar.

Por otro lado, podemos “deshacernos” de FlashCS3 en la tarea de compilar o publicar. ¿Cómo? Pues por ejemplo en FlexBuilder, nos basta con especificar la tan nombrada “Document Class” o “clase de aplicación”. Y entonces al compilar el proyecto ocurriría lo mismo, todo empezaría a funcionar a través de esa clase y sus dependencias.

¿Cuál es la diferencia entre FlexBuilder (o similares) y FlashCS3?

Esto puede llegar a ser muy discutible y muy subjetivo, pero las diferencias más importantes según mi opinión son las siguientes:

FlashCS3: tenemos disponible y “visible” la librería sin necesidad de hacer el pino puente.
FlexBuilder: no hay librería visible incorporada y que podamos manejar, pero sí podemos crear una librería con Flash y usarla desde FlexBuilder.

FlashCS3: Podemos diseñar y dibujar como nos plazca, para crear símbolos y elementos gráficos animados en línea de tiempo.
FlexBuilder: Dependemos de Flash para dicha tarea. Si queremos animar sin depender de Flash tendrá que ser por código.

FlashCS3: dependemos de un .fla o varios para nuestro desarrollo
FlexBuilder: no necesitamos en principio un .fla, a no ser vayamos a generar librerías de símbolos en formato swf o swc

FlashCS3: Los archivos .fla a veces se corrompen, se estropean, o dan errores sin sentido al compilar (lo he sufrido mucho en mis carnes)
FlexBuilder:No sule haber problemas al compilar.

FlashCS3: Compilamos y se genera el swf resultante o una plantilla html básica.
FlexBuilder: Además de generar un html más completo, podemos configurar el programa para que despues de compilar, abra una url en concreto, cosa muy útil cuando trabajamos con aplicaciones de datos que se comunican con un servidor o cargan archivos externos, ya que siempre estaremos viendo un “caso real” y evitando sorpresas relacionadas con el sandbox al llevar el proyecto a producción.

FlashCS3: Desde un .fla solo podemos linkar una “Document Class”
FlexBuilder:En un mismo proyecto podemos tener tanas aplicaciones como queramos. Cada una genera un swf diferente.

FlashCS3: está muy limitado si queremos extender su funcionalidad.
FlexBuilder: existen varios plugins de terceras partes como por ejemplo CVS, Subclipse (subversion), editor de snippets, etc, que nos ayudarán en la mecánica de trabajo.

FlashCS3: podemos programar en procedural sin programación orientada a objetos
FlexBuilder: debemos seguir una estructura orientada a objetos

FlashCS3: La depuración (debug) en FlashCS3 deja mucho que desear
FlexBuilder: La depuración es bastante avanzada y además tenemos “memory profiling” o gestión de memoria. Podremos saber en tiempo de ejecución, cuántas instancias de cada objeto existen, y cuál es su peso. Esto es muy útil para optimizar nuestra aplicación, y ver por dónde puede estar fallando el rendimiento.

¿Por qué utilizar FlexBuilder y no otro editor como FDT o FlashDevelop?

Pues eso ya es cuestión de cada uno. Personalmente creo que como editor de código, FlexBuilder deja mucho que desear frente a Eclipse FDT que es muchísimo más potente (solo le falta programar solo), y FlashDevelop que también lo es.
Pero FlexBuilder es más sencillo de aprender, de configurar y según instalas está listo para trabajar con AS3. En otros editores hay varios pasos previos antes de poder compilar.

FDT, aunque es mi editor favorito, y creo que la herramienta más potente que existe ahora mismo, en la versión más avanzada, es bastante más caro (712.81 € al día de hoy), contra los 207,64 € que vale FlexBuilder.
En cambio FlashDevelop es gratis, cosa muy a tener en cuenta a la hora de decidirse. (Se requiere .NET framework para poder utilizarlo)

Seguro que me he dejado mucha información importante, pero creo que la idea queda clara. Todo lo que he contado se basa en las experiencias reales que he tenido, más allá de lo que se pueda leer en las webs de sus autores.

Espero vuestros comentarios
Un saludo

Vamos cargando esas imágenes o swf´s en nuestra aplicación y todo es muy bonito y fabuloso… hasta que algo empieza a fallar, se ralentiza o simplemente deja de funcionar. !Mierda! mi pc no vale para nada! Lo tiras por la ventana y te compras uno nuevo… pero a ver, si en mi ordenador que es un pepino, no funciona, los clientes lo van a flipar más aún.

Fuera de bromas, todo esto pasa porque lo que vamos cargando se almacena en memoria, y cuando hacemos desaparecer un contenido, no lo estamos aniquilando debidamente.
Resulta que el típico MovieClip.unloadMovie() de AS2 ha desaparecido en el olvido. Ese método se cargaba cualquier cosa que hubiera cargado externamente, liberando así la memoria y haciéndonos más felices y contentos. En cambio, en AS3 la cosa se complica mucho. Según leo en el blog de gSkinner, éstos son los motivos del problema, y por los cuáles sería imposible “descargar” algo:

• Cualquier listener, timer, o variable que haga referencia al contenido cargado
• Un contenido cargado con la línea de tiempo reproduciéndose
• Un contenido cargado con algún listener que se refiera al stage, o a cualquier cosa fuera de su ámbito

Y creo que no podría explicarlo mejor que gskinner en este párrafo:

“In AS3, calling Loader.unload() simply removes the reference to the loaded movie. If any other references exist to the loaded content, it will not be unloaded. Even when all references are removed, it only frees the content for collection by the garbage collector at some indeterminate point in the future. This means that even if everything worked as expected the loaded content will continue to execute, and remain in memory for an indeterminate amount of time after you unload it. This is problematic in many ways, but it is made worse by a bug in the player.“

Parece mentira que a estas alturas con un señor Flash Player 9 y el tan supuestamente mejorado y todo poderoso ActionScript 3.0, nos encontremos con que la gestión de memoria es lo más decadente que nos podamos echar encima.

Aunque no todo es feo y negativo. Por lo visto con Flash Player 10 está medio resuelto el problema, y esperemos que este player se extienda rápido para poder producir con él.

Otro buen artículo sobre gestión de recursos, tambien de Grant Skinner.

Ala! a disfrutar con Adobe

ArgumentError: Error #2015: Objeto BitmapData no válido

Despues de mirar en la ayuda de Flash, vi que podía ser por por dos razones:

1. Estamos intentando crear un BitmapData con un ancho o alto que no es un valor numérico válido (esto suele pasar si lo creamos a partir de una imagen que hemos intentado cargar externamente pero que no se ha cargado bien)
2. Estamos intentado crear un BitmapData demasiado grande (el límite tanto para el ancho como para el alto son 2880 pixeles). Para esto podemos hacer un simple control de errores

if(loquesea.width > 2880 || loquesea.height > 2880)
{
	throw new Error("La imagen supera los 2880 pixeles permitidos para BitmapData");
	return;
}

Un saludo

Me parece idónea para movernos por la escena y explorarla desde todas las vistas posibles cuando estamos desarrollando con Papervision3D. Además podemos explorar en tiempo real, propiedades muy importantes como “fov”, “near plane” y “far plane” para el manejo del frustum culling (la explicación de todo esto vendrá en nuevo post), lo que nos evitará tener que cambiar y probar con numeritos “mágicos” tropecientas veces hasta que los objetos se vean como queremos.

La clase se encuentra en el mismo package de las cámaras (org.papervision3d.cameras).
Si no la encuentras hazle un “update” a tu repositorio, que lo más seguro es que tengas una versión desactualizada.

Aquí va una prueba sencilla de lo que estoy contando:
(en modo fullscreen no funciona el teclado, no es culpa mía, sino de Adobe)

Source

De momento usaremos solamente un material, el WireframeMaterial, ya que el uso de materiales se detallará debídamente en otro post.

Aunque no es una primitiva tambien usaremos la clase UCS (objects.special), que no es sino un eje de coordenadas 3D visibles formadas por líneas (core.geom.Lines3D), que nos pueden ser muy útiles en algunos casos.

También aprovecho para implementar un movimiento de cámara con tweenings, de una primitiva a otra, y una navegación mediante botones fuera de la escena de Papervision, que servirán para navegar. Los botones son de la clase “ItemButton”, de los cuáles podéis ver la referencia en este post, aunque lógicamente sirve cualquiera.

Los botones hacen uso de un asset que se encuentra en un swc linkado al proyecto ActionScript de FlexBuilder.

Si esto te suena a chino, puedes leer este post.

Si solo quieres echar un vistazo, aquí tienes la clase Primitives.as
Para descargar todos los archivos: SamplePrimitives.zip

En resumen: te facilita la vida para proyectos sencillos, evitando instanciar y declarar unas cuantas cosas.
La clase la podéis encontrar dentro del package “view” de Papervision3D Great White.

Veamos el mismo ejemplo del post “Papervision3D y Flex Builder: Primeros pasos“, pero ahora usando la clase “BasicView”. He quitado todos los comentarios que no vienen al caso para centrarnos en lo importante:

/**
 * Author: xleon, http://www.xinterface.net (malandro@gmail.com)
 */
package
{
	import flash.display.Sprite;
	import flash.events.Event;
 
	import org.papervision3d.cameras.Camera3D;
	import org.papervision3d.materials.WireframeMaterial;
	import org.papervision3d.objects.primitives.Plane;
	import org.papervision3d.scenes.Scene3D;
	import org.papervision3d.view.BasicView;
 
	[SWF(frameRate="31", width="500", height="350", backgroundColor="0xffffff")]
 
	public class BasicViewSample extends Sprite
	{
        private var bView:BasicView;
 
		public function BasicViewSample()
		{
			Init3D();
		}
 
		private function Init3D():void
		{
			// Creamos el BasicView que contiene viewport, camera, renderer, etc
			bView = new BasicView(500, 350, false, false);
 
			// añadimos la vista al displayList
			addChild(bView);
 
			// Configuramos la cámara:
			bView.camera.focus = 25;
            bView.camera.zoom = 10;
            bView.camera.z = -500;
            bView.camera.y = 300;
            bView.camera.x = 0;
 
			CreateObjects();
			addEventListener(Event.ENTER_FRAME, Loop3D);
		}
 
		private function CreateObjects():void
		{
			var mat:WireframeMaterial = new WireframeMaterial;
			mat.doubleSided = true;
 
			var plane:Plane = new Plane(mat, 500, 500, 8, 8);
			plane.rotationX = -90;
 
			// lo añadimos a la escena del BasicView.
			bView.scene.addChild(plane);
 
			//camera.target = plane;
		}
 
		private function Loop3D(e:Event):void
		{
			var radio:uint = 500;
			var angulo:Number = mouseX + (stage.stageWidth / 2);
 
			Camera3D(bView.camera).x = radio * Math.cos(angulo / 100);
			Camera3D(bView.camera).z = radio * Math.sin(angulo / 100);
			Camera3D(bView.camera).y = - mouseY + (stage.stageHeight / 2) + 100;
 
			// llamamos al método de renderizado del BasicView:
			bView.singleRender();
		}
	}
}

El resultado es el mismo pero con menos código =)

Descargar la clase aquí: BasicViewSample.as

Ejemplo:

Tenemos un catálogo de productos, el usuario pincha un botón del producto con “id=x”
Hacemos una consulta a la base de datos que nos devuelve todos los datos de ese producto, que parseamos creando un objeto.
El usuario continua navegando por otros contenidos. Acto seguido vuelve a reclamar el producto mostrado anteriormente. ¿Por qué volver a hacer la petición al servidor si previamente podíamos almecenar esa información?

Pues esa situación es la que resuelve esta clase.
Admite cualquier tipo de datos.

La podéis descargar aquí: CacheManager.as
Deberéis descargar también esta clase de la que depende CacheManager: ArrayUtils.as

Testeando la clase:

var cache:CacheManager = new CacheManager("Id");
trace("cache test =====================");
var obj1:Object = new Object();
obj1.Id = 24
 
var obj2:Object = new Object();
obj2.Id = 36;
 
trace(cache.Add(obj1)); // true (no existia en caché)
trace(cache.Add(obj2)); // true (no existia en caché)
trace("ejemplo de GetData:", cache.GetData(36));
trace(cache.Add(obj2)); // false (ya existia en caché)
trace(cache.Remove(obj2)); // true (existia en caché y se eliminó)
trace(cache.Remove(obj2)); // false (no existia en caché y se pudo eliminar)
cache.TraceData();
trace("cache test =====================");

Ejemplo de uso:

package
{
	import net.xinterface.managers.CacheManager;
 
	public class CacheManagerExample
	{
		private var cache:CacheManager;
 
		public function CacheManagerExample()
		{
			// "ref" es la propiedad "ref" de cada objeto almacenado en la caché.
			// es obligatoria y sirve para poder identificar los elementos almacenados
			cache = new CacheManager("ref");
		}
 
		public function SetProduct(productRef:Number):void
		{
			// antes de mostrar un producto comprobamos si ya estaba almacenado en caché
			if(cache.GetData(productRef) != null)
			{
				trace("ya estaba en cache, lo mostramos");
				ShowProduct(cache.GetData(productRef));
 
			}else
			{
				trace("no estaba en cache, consultamos la base de datos");
				DBQuery(productRef);
			}
		}
 
		private function DBQuery(productRef:Number):void
		{
			var prod:Object = new Object;
			prod.ref = productRef;
			// comunicación con el server para recuperar los datos del producto
			// prod.precio = x;
			// prod.localizacion = x;
			// prod.loquesea = x;
 
			// Añadimos el producto a la caché:
			cache.Add(prod);
			ShowProduct(prod);
		}
		public function ShowProduct(product:Object):void
		{
			// acciones para mostrar el producto...
		}
	}
}

En fin, nunca pensé en hacer piezas Flash para ser visualizadas en semejante soporte, pero quién sabe…

Características:

• Estados basados en línea de tiempo (aunque también se pueden implementar con código). Se diseña la animación en un solo sentido, que se recorre en el estado “over”. Al hacer un “out” automáticamente la animación se reproducirá hacia atrás.
• Solo hay que configurar dos estados. Estado out y over. Cuando tengo una botonera y quiero que uno se quede pulsado lo dejo en “over”. De esta manera me libro del estado “pressed” o “down”.
• Soporte para sonidos de alguna o todas las acciones de botón: click, over, out (se pasan por parámetro en el constructor)
• Se puede habilitar y deshabilitar el botón
• Complétamente integrado con la clase Menú (mi clase menú que postearé otro día)
• Aspecto gráfico y animación (asset) totalmente separado de la lógica del botón (se pasa un MovieClip por parámetro en el constructor)
• Eventos: este botón avisa de todo lo que hace mediante eventos (OVER, RELEASE, OUT, SELECTED, UNSELECTED, ENABLED, DISABLED, NOSTATE).

Ejemplo de diseño de línea de tiempo:

Solo hace falta hacer una animación en un solo sentido y con un stop() en las acciones del primer fotograma. Todo ello metido dentro de un MovieClip que tendrémos vinculado en la biblioteca o simplemente con un nombre de instancia en el escenario. En estas imágenes se ven los fotogramas clave de la animación. Solo tiene una simple animación de “tinta” de azul a verde:

Para un ejemplo simple nos sirve con esto. Simplemente un “asset” (movieClip) que utilizará nuestra clase botón. Supongamos que lo tenemos vinculado en la biblioteca:

Ahora nos podemos cargar el botón del escenario, ya que solo necesitamos usar su vinculación.

De esta forma separamos el código del gráfico o “asset” que representará nuestro botón. Creo que es una buena manera de hacerlo, y aquí va la clase botón que he llamado de forma genérica “ItemButton”, puede parecer compleja pero es muy simple, fijaros simplemente en los métodos públicos para haceros una idea, creo que hablan por sí solos:

package net.xinterface.items
{
	import flash.display.MovieClip;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
	import flash.media.Sound;
 
	public class ItemButton extends Sprite
	{
		public static const OVER:String = "over";
		public static const RELEASE:String = "release";
		public static const OUT:String = "out";
		public static const SELECTED:String = "selected";
		public static const UNSELECTED:String = "unselected";
		public static const ENABLED:String = "enabled";
		public static const DISABLED:String = "disabled";
		public static const NOSTATE:String = "nostate";
 
		private var id:String;
 
		protected var hit_mc:MovieClip;
		public var asset:MovieClip;
 
		private var volume:Number = 1;
		private var sClick:Sound;
		private var sOver:Sound;
		private var sOut:Sound;
 
		private var state:String;
 
		// constructor
		public function ItemButton(_asset:MovieClip, soundClick:Sound=null, soundOver:Sound=null, soundOut:Sound=null)
		{
			asset = _asset;
			addChild(asset);
 
			if(MovieClip(asset.hit_mc) != null)
			{
				hit_mc = MovieClip(asset.hit_mc);
 
			}else
			{
				hit_mc = new MovieClip;
				hit_mc.graphics.beginFill(0x000000,0);
				hit_mc.graphics.drawRect(0,0,asset.width, asset.height);
 
				asset.addChild(hit_mc);
			}
 
			hit_mc.buttonMode = true;
			sClick = soundClick;
			sOver = soundOver;
			sOut = soundOut;
 
			state = NOSTATE;
 
			Enable();
		}
		// Habilita el botón (se puede pulsar)
		public function Enable():void
		{
			hit_mc.enabled = true;
			hit_mc.mouseEnabled = true;
			hit_mc.addEventListener(MouseEvent.CLICK, Click);
			hit_mc.addEventListener(MouseEvent.MOUSE_OVER, Over);
			hit_mc.addEventListener(MouseEvent.MOUSE_OUT, Out);
			asset.alpha = 1;
			state = ENABLED;
		}
		// Deshabilita el botón ( no se puede pulsar )
		/** @param setAlpha true para bajar el alpha al deshabilitarlo, false para dejarlo tal cuál
		 * @param keepClick true para que el botón siga funcionando incluso al deshabilitarlo, false para un comportamiento normal (esto me ha servido el alguna ocasión
		 * */
		public function Disable(setAlpha:Boolean=true, keepClick:Boolean=false):void
		{
			hit_mc.enabled = false;
			//hit_mc.mouseChildren = false;
			hit_mc.mouseEnabled = false;
 
			if(keepClick==true) hit_mc.mouseEnabled = true;
			else hit_mc.removeEventListener(MouseEvent.CLICK, Click);
 
			hit_mc.removeEventListener(MouseEvent.MOUSE_OVER, Over);
			hit_mc.removeEventListener(MouseEvent.MOUSE_OUT, Out);
 
			if(setAlpha) SetDisableView();
			state = DISABLED;
		}
		protected function SetDisableView():void
		{
			asset.alpha = 0.3;
		}
		// Esto es público por si acaso queremos presionar un botón manualmente. "boton.Click(null);"
		public function Click(evt:MouseEvent=null):void
		{
			var event:Event = new Event(RELEASE);
			dispatchEvent(event);
			if(sClick!=null) sClick.play().soundTransform.volume = volume;
			state = RELEASE;
		}
		protected function Over(evt:MouseEvent=null):void
		{
			//trace("over");
			dispatchEvent(new Event(OVER));
			asset.removeEventListener(Event.ENTER_FRAME, TimelineBackard);
			asset.addEventListener(Event.ENTER_FRAME, TimelineFordward);
			if(sOver!=null) sOver.play().soundTransform.volume = volume;
			state = OVER;
		}
		protected function Out(evt:MouseEvent=null):void
		{
			//trace("out");
			dispatchEvent(new Event(OUT));
			asset.removeEventListener(Event.ENTER_FRAME, TimelineFordward);
			asset.addEventListener(Event.ENTER_FRAME, TimelineBackard);
			if(sOut!=null) sOut.play().soundTransform.volume = volume;
			state = OUT;
		}
		// Este método es perfecto para botoneras, al llamarlo, el botón de quedará en el estado "over",
		// y no se podrá pulsar hasta después de llamar al método "Unselect();"
		public function Select():void
		{
			if(state == SELECTED) return;
 
			Disable(false);
			dispatchEvent(new Event(SELECTED));
			Over();
			state = SELECTED;
			//trace("selected");
		}
		// vuelve a dejar el botón como estaba
		public function Unselect():void
		{
			if(state == UNSELECTED) return;
 
			Enable();
			dispatchEvent(new Event(UNSELECTED));
			Out();
			state = UNSELECTED;
			//trace("unselected");
		}
		// Timeline
		// Hace correr la línea de tiempo del "asset" hasta el último frame
		private function TimelineFordward(evt:Event):void
		{
			asset.gotoAndStop(asset.currentFrame + 1);
			if(asset.currentFrame == asset.totalFrames) asset.removeEventListener(Event.ENTER_FRAME, TimelineFordward);
		}
		// Hace correr hacia el frame 1, la línea de tiempo del "asset"
		private function TimelineBackard(evt:Event):void
		{
			asset.gotoAndStop(asset.currentFrame - 1);
			if(asset.currentFrame == 1) asset.removeEventListener(Event.ENTER_FRAME, TimelineBackard);
		}
 
		// getters y setters
		public function get State():String
		{
			return state;
		}
		public function set Volume(value:Number):void
		{
			volume = value;
		}
		public function get Volume():Number
		{
			return volume;
		}
		public function get Id():String
		{
			return id;
		}
		public function set Id(pId:String):void
		{
			id = pId;
		}
	}
}

Podéis descargar la clase ItemButton aquí

Para usar esta clase con el ejemplo de asset mostrado anteriormente:

// Pillamos el asset vinculado en la librería
var assetGrafico:MovieClip = new asset() as MovieClip;
 
// Creamos el botón y lo añadimos al displayList, fíjate que no añadimos el asset al displayList
// puesto que el botón lo hace automáticamente.
var boton:ItemButton = new ItemButton(assetGrafico);
addChild(boton);
 
// Nos subscribimos a los eventos
boton.addEventListener(ItemButton.RELEASE, HandleRelease);
boton.addEventListener(ItemButton.OVER, HandleOver);
boton.addEventListener(ItemButton.OUT, HandleOut);
 
// Administramos eventos
private function HandleRelease(e:Event):void
{
	trace("hemos hecho click en la instancia de botón", e.target);
}
 
private function HandleOver(e:Event):void
{
	trace("hemos hecho over en la instancia de botón", e.target);
}
 
private function HandleOut(e:Event):void
{
	trace("hemos hecho out en la instancia de botón", e.target);
}

Y ya solo queda probar la clase con distintos assets gráficos, que pueden ser completamente distintos al que habéis visto, siempre que mantegan su estructura. No olvidéis que también funcionan los sonidos para los estados over, out, y release.

También comentar que como instrumento fundamental y control de cualquier aplicación, necesitamos un menú, que no es más que un controlador de una lista o array de botones. En mi caso tengo una clase “Menu” que hace uso de la clase “ItemButton”, y se encarga de gestionar cuándo los botones de activan o desactivan, según en cuál de ellos pinche el usuario. Tal vez me anime y lo postee, pero eso será después de la publicidad.

Un saludo

En mi viaje he podido observar varias cosas que imaginaba. Los yankis (véase Nueva York que es lo que he podido ver) tienen un ritmo de vida y de trabajo diferente al nuestro. Hay mucha más competencia en nuestro sector (estamos hablando de nuevas tecnologías lógicamente), salarios más altos, y más nivel en general. Ahora entiendo el porqué del petardo que muchos tienen acoplados a su parte íntima y trasera, y de la rapidez abismal con la que evolucionan las cosas allí. Eso mismo se ve reflejado en muchos blogs, en los eventos y presentaciones que surgen cada vez con más frecuencia. La misma vida en la calles de Nueva York refleja esa manera de hacer las cosas. Todo va muy rápido, nadie se para para pensar. Y no creo que sea lo mejor, simplemente es una opción, pero lo que hace esta gente nos arrastra a todos de alguna manera. A todos los que al otro lado del charco queremos estar al día.

Y por eso mismo en ciertos momentos me siento frustrado. No tengo la capacidad suficiente para asimilar todo lo nuevo en un tiempo razonable. Actualmente estudio y aprendo Flex, perfecciono AS3, y estoy metido con varias librerías de terceros que últimamente son imprescindibles para hacer mi trabajo, como librerías de 3D con flash, otras que integran servicios web, físicas 2D y 3D, etc. Y todo eso solo es Flash!!!!

Antes mi trabajo como freelance y en pequeñas empresas, era multitarea. Es decir, lo mismo me encargaban diseñar una base de datos, como programar un gestor multiusuario desde cero, que diseñar y dirigir toda la gráfica de un proyecto web, pasando por maquetar con CSS-XHTML, y encima programar mis piezas con Flash.

Esos tiempos han acabado (para mí y para muchos). Esto cada vez consiste más y más en la especialización, y como siempre he dicho, el que mucho abarca poco aprieta. Si quieres hacer algo de verdad y sentirte bien con lo que haces, creo que hay que especializarse. Y eso es lo que intento ahora, que ya mi situación me lo permite: trabajo fijo y en buen lugar, haciendo justo lo que me gusta hacer. Flash.

Pero mis ansias de aprender más no me dejan tranquilo. En mis ratos intento sacar tiempo para el lado del servidor (Coldfusion que se usa en mi empresa, y C#, que me parece muy potente), ya que mi experiencia y conocimientos de ASP (el antiguo asp 3) que tanto me han servido estos años, ya no me sirven ahora para nada, excepto para entender el concepto y funcionamiento de las cosas.
Por otro lado me tocará liarme con Air tarde o temprano, cosa que hasta ahora no he podido hacer.

Además, mi paso por Pyro Studios, me llevó a interesarme mucho más por las tecnologías multiusuario, cosa que tanto abunda en los juegos que allí se desarrollan.
Las tecnologías multiusuario que se usan para aplicaciones flash me parecen muy interesantes.
Cada día se me ocurren más y más ideas para desarrollar, y de nuevo, falta de tiempo y recursos para poder hacerlo.

Supongo que todo esto tiene que ver con la ambición y las ansias de aprender de cada uno (aparte de que un día solo tiene 24 horas claro). A mí personalmente me gusta tener “controlado” todo lo que hago, si no completamente ya que es imposible, por lo menos lo suficiente para pensar que estoy dentro del “tren”.

Y eso es lo que intentaré hacer este año. Las vacaciones me han puesto las pilas, y es como si fuera año nuevo =) Todo esto que he dicho puede desanimar ciertamente, pero lo que intento es justo lo contrario. Hay que ponerse las pilas, y mucho. Concentrarse en lo que mejor se nos dé, y mejorar cada día. No me gusta ser conformista, y creo que nunca lo seré. Y aunque supuestamente hay crisis mundial, en este sector por lo menos no la veo por ninguna parte, y creo que estamos en un buen momento para evolucionar.

Este post no es propio para este tipo de blog, pero no me podía aguantar =)
Un saludo a los valientes que aguantaron hasta llegar a esta línea.

Lo cómodo de trabajar con Flash es que creamos un MovieClip en la librería, lo vinculamos con un nombre de clase, y automáticamente lo podemos instanciar mediante código con el mismo nombre que habíamos vinculado.

Y entonces para instanciar la clase “Cuadrado”, que en realidad es un MovieClip, hacemos lo siguiente:

1

 var loquesea:Cuadrado = new Cuadrado()

¿Cómo hacemos esto en Flex Builder?

Pues así, a secas, no se puede =), Flex no tiene ningún contenedor de assets donde podamos tenerlos almacenados. Pero podemos solucionarlo de dos maneras:

1. La primera y más simple es almacenar la librería de Flash en un archivo .SWC
2. La segunda, un pelín mas compleja, pero más útil, es almacenar lo mismo en un .SWF

El swc se genera igual que un swf, compilando la película de Flash, pero marcando la opción “Exportar swc” en opciones de publicación

Al publicar se obtendrá un archivo SWC en el mismo directorio de publicación que el swf.
Ahora desde nuestro proyecto Flex, linkamos dicho archivo para poder usar los MovieClips vinculados
Nota: si no sabes cómo crear un proyecto “ActionScript” en Flex, se explica en este post

Clicamos con el botón derecho sobre la carpeta de proyecto (dentro de FlexBuilder), clicamos en “Properties” y luego en “ActionScript build path”. Ahora pinchamos la pestaña “Library Path” y le damos al botón “Add swc”. Buscamos nuestro swc y le damos a ok

Ahora desde nuestro código ya podemos instanciar todos nuestros MovieClips. Además, la ayuda de código de Flex Builder reconocerá las clases vinculadas

Y listo ! Podéis compilar y veréis vuestro Cuadradito funcionand

Esto es muy útil pero tiene un inconveniente simple: el peso de nuestra película principal aumentará tanto como pese el swc, porque Flex embeberá (incorporará) en el swf generado, los símbolos o imágenes que instanciemos en nuestro código (los que no instanciemos no se incluirán).

Entonces es cuando pensamos en poner en práctica la segunda forma, se basa en lo siguiente:

1. Generamos el swf con la librería
2. Desde nuestra aplicación principal cargamos la librería en tiempo de ejecución como hacemos normalmente con cualquier otro swf
3. Accedemos (ya veremos cómo) a las clases del swf cargado (MovieClips, etc)

Continuará…

Por otro lado las comunicaciones con Flash Player 10 llevarán integradas el códec de audio de alta calidad SPEEX, con el que según se dice, se podrán realizar aplicaciones de sonido y transmisión de voz mucho más potentes.

Pero bueno, a lo que iba el post..
Parece ser que Adobe implementará en un futuro próximo una red de servidores que implementen estas conexiones y que serán accesibles desde Flash Player 10 mediante los objetos de ActionScript “NetConnection” y “NetStream”.

Digamos que el proceso sería el siguiente:

1. Un cliente swf (swf 1) establece una conexión con un server de Adobe
2. El servidor le asigna al cliente una ID única y temporal
3. Otros clientes pueden subscribirse a los eventos y streams del primero (swf 1), mediante dicha ID mientras la conexión siga abierta

Esa misma ID que se establece en la conexión servirá también como identificador para aplicaciones de chat u otras comunicaciones.

¡Gran noticia!

Ahora mismo con RTMP podemos enviar un stream de sonido o video (micrófono o webcam) a un servidor que lo propague (broadcast) a otros clientes swf. Con la nueva tecnología, se podrá enviar un stream directamente de cliente a cliente sin pasar por el servidor, lo que nos abre un mundo de posibilidades enorme.

Además, el envío de datos mediante “NetConnection.send()” no se limita a streamings, sino a cualquier tipo de datos (eso sí, con sus limitaciones de tamaño). Lo que quiere decir que ya no nos hace falta un servidor para hacer por ejemplo un chat, un juego de comunicación en tiempo real, etc.

La gran pega a todo esto es que si frente a nuestra conexión tenemos un firewall que bloquee el protocolo UDP, no funcionará.

Muchos se están preguntando si se podrá implementar una red P2P (peer to peer) con esta tecnología, pero según argumenta Justin Everett (Product Manager for Flash Player at Adobe), las redes peer to peer se basan en lectura y escritura de datos constante en disco duro, guardando en memoria las diferentes partes de los archivos cuando son necesarias. Con Flash Player 10 se puede cargar un archivo del disco duro al runtime, pero se tiene que hacer manualmente, y de uno en uno, por lo tanto el P2P queda descartado.

Y digo yo, que aunque queden descartados los intercambios masivos de datos, si que podríamos hacer un messenger con envío de archivos, un sistema de video conferencia con archivos compartidos entre los clientes, aplicaciones mejoradas de e-learning, juegos multiusuario que trabajen con imágenes y ficheros de usuarios en tiempo real, etc, etc, etc…, y todo como ya he dicho, sin programación de servidor de por medio.

Esperemos que Adobe ponga pronto a disposición los servidores de comunicaciones para que todo esto sea posible, y que se documente bien el Flash Player 10.

Ahí dejo eso, que cada uno saque sus conclusiones.

Nota: Este artículo parte de cero en cuanto a que no solo explica el comienzo de un proyecto con papervision, sino también a cómo usar un cliente de subversion para actualizar y/o descargar el uso de código de terceras partes, la configuración de un proyecto en Flex Builder y conceptos básicos con los que empezamos a lidiar cuando damos el salto desde Flash a otro modo de desarrollar ActionScript

Si nunca has desarrollado una aplicación con papervision creo que primero habría que entender cuál es su funcionamiento básico y cómo ponerlo en marcha, así como conceptos fundamentales, como qué es una escena, un viewport, renderizado, etc.

Antes de empezar: preparar nuestro entorno de desarrollo.

Papervision3D en realidad no se instala. Se trata de una librería de clases de ActionScript de la que se servirá nuestra aplicación para implementar sus funciones. En nuestro caso usaremos la herramienta Flex Builder 3 para codificar, lo que no significa que usemos el framework de Flex, ya que solo escribiremos ActionScript.

Primer paso: descargar la última versión de papervision3D

Normalmente las librerías de código se encuentran en repositorios de control de versiones como Subversion. Así funciona Google Code, que es donde se encuentra alojado el repositorio de papervision. Para poder descargar (check out) un repositorio necesitamos un cliente de subversion. Hay muchos de ellos. El más común y usado es Tortoise (no por ello el mejor), que se integra con el explorador de windows y es muy simple de usar. Si usas Mac OSX, una solución casi idéntica es SCPlugin, que podéis descargar aquí.

Descarga uno según tu sistema operativo y después de instalarlo crea una carpeta en tu disco duro que se llame por ejemplo “papervision3D”. Sobre la carpeta presiona con el botón derecho y busca el menu “SVN Checkout…” (windows) o “Más > Subversion > Checkout” (mac).

En el campo “URL” escribe la dirección del repositorio (http://papervision3d.googlecode.com/svn/trunk/), deja el resto de opciones tal cual y presiona “ok” o “checkout”.

Tendrás que esperar a que se descarguen todos los archivos. Al terminar verás que contiene 4 carpetas. La que nos interesa especialmente es lo que hay dentro de “branches/GreatWhite/src/”, ya que el resto son versiones deprecadas que ya no se actualizan. El proyecto está en constante evolución, y si lo actualizas a menudo (botón derecho sobre la carpeta > SVN update con windows o “más > svn update con mac) verás que casi siempre hay nuevas actualizaciones por parte del equipo de desarrollo.

Mi recomendación es crear una carpeta común para todas las librerías de código que utilicemos en nuestros proyectos. Yo tengo una carpeta “ActionScript” donde tengo todas las clases.
En este caso copié las contenidos de “branches/GreatWhite/src/” en mi carpeta “ActionScript”. (com, fl, org, nochump).

Segundo paso: configurar un proyecto en FlexBuilder

Abrimos Flex Builder y creamos un nuevo “ActionScript project”

Le damos un nombre al proyecto (ej: “PapervisionTest” y especificamos la carpeta donde se va a alojar, y pulsamos next:

En la pestaña “Source path” clicamos “Add folder…” y buscamos nuestra carpeta de “ActionScript” de la que os hablaba anteriormente, que es donde están alojadas nuestras clases incluidas las de papervision.
En “Main Source Folder” clicamos “Browse”, seleccionamos la carpeta de proyecto, clicamos new (automáticamente nos crea la carpeta “src”, la seleccionamos y clicamos “ok”. El resto lo dejamos tal cuál y clicamos “Finish”.

Ya tenemos todo funcionando, y ya podemos empezar a escribir código. Flex Builder crea automáticamente la clase principal de la aplicación o lo que se suele llamar “Document Class”.
Nota: esta clase debe tener un package sin nombre como en siguiente ejemplo:

Conceptos básicos

Viewport: es la parte visible de todos nuestros elementos 3D y el encargado de coordinar el tipo de renderizado, la cámara y la escena. Es lo que añadimos directamente a nuestro stage de Flash. Si definimos un viewport de 500 x 400 píxeles, todo lo que se encuentre fuera de esas dimensiones no se verá.

Escena (Scene): es el contenedor de todos los elementos visibles y formas que tendrá nuestra aplicación. Digamos que es como un “display list” interno de papervision.

Motor de renderizado (Renderer): como su nombre indica se encarga de renderizar la escena y cómo bien explica Wikipedia, en términos de visualizaciones en ordenador, más específicamente en 3D, la “renderización” es un proceso de cálculo complejo desarrollado por un ordenador destinado a generar una imagen 2D a partir de una escena 3D. En papervision, cada vez que modificamos algo en la escena 3D, debemos renderizar de nuevo. Lo que se suele hacer es un método que se encargue de ello y que se ejecuta en un intervalo fijo mediante el evento “ENTER_FRAME”.

Cámara: en papervision podemos controlar la posición, rotación y zoom de la cámara que visualiza el contenido.

Configuración típica

A continuación verás el código ActionScript con la configuración típica y básica de una aplicación papervision. En realidad no hace más que inicializar los elementos de los que hablaba en el punto anterior, y no tiene ningún efecto visual:

/**
 * Author: xleon, http://www.xinterface.net (malandro@gmail.com)
 */
 
package
{
    import flash.display.Sprite;
    import flash.events.Event;
 
    import org.papervision3d.cameras.Camera3D;
    import org.papervision3d.render.BasicRenderEngine;
    import org.papervision3d.scenes.Scene3D;
    import org.papervision3d.view.Viewport3D;
 
    // meta datos para el swf resultante:
    [SWF(frameRate="31", width="500", height="400", backgroundColor="0xffffff")]
 
    public class Sample1 extends Sprite
	{
		private var viewport:Viewport3D;
 
		// existe más de un tipo de renderizado, este es el mas comun
		private var renderer:BasicRenderEngine;
 
		private var scene:Scene3D;
 
		/*
		existe mas de un tipo de camara, con este tipo
		nos aseguramos de que siempre apunte hacia un target
		determinado, que si no se especifica, sera nuestra escena
		*/
		private var camera:Camera3D;
 
		// constructor
		public function Sample1()
		{
			// En este caso solo nos hace falta iniciar el 3D
			Init3D();
		}
		/*
		este metodo inicializa todo lo relacionado
		con nuestro entorno 3D
		*/
		private function Init3D():void
		{
			/*
			creamos el viewport y lo añadimos al displayList
			Si queremos que algun elemento de la escena sea interactivo
			o se pueda clicar en el, el parametro @interactive (el cuarto) debe ser "true"
			*/
			viewport = new Viewport3D(500, 400, false, true);
			addChild(viewport);
 
			renderer = new BasicRenderEngine;
			scene = new Scene3D;
			camera = new Camera3D;
 
			CreateObjects();
			addEventListener(Event.ENTER_FRAME, Loop3D);
		}
 
		/*
		esta función se encarga de crear y configurar los
		objetos de nuestra escena y los incluye en ella
		*/
		private function CreateObjects():void
		{
 
		}
		private function Loop3D(event:Event):void
		{
			/*
			Aquí añadimos movimientos de piezas, de camara, y toda
			la interactividad y comportamientos.
			Para que los cambios tengan efecto visualmente
			deberemos finalmente renderizar la escena
			*/
			Render();
		}
		/*
		este metodo es generico y no hará falta modificarlo
		si mantenemos la estructura
		*/
		private function Render():void
		{
			renderer.renderScene(scene, camera, viewport);
		}
	}
}

Añadiendo movimiento y un objeto simple

Ahora que ya tenemos todo en condiciones, podemos añadir un elemento a la escena, e incluir una ecuación sencilla para el movimiento de cámara, de tal forma que podremos interactuar con el movimiento del ratón.

En el método “Init3D()” añadimos este código para posicionar la cámara:

// configuracion de la camara
camera.zoom = 10;
camera.z = -1000;
camera.y = 300;
camera.x = 0;

Creamos un plano que es un elemento básico o primitiva. Para que un plano u otra primitiva sea visible deberemos asignarle un material.
Para ello creamos primero un WireframeMaterial, que no es sino un material donde solo se ven los triángulos de la maya 3D. Por último lo añadimos a la escena. Incluiremos todo esto en el método “CreateObjects()”:

private function CreateObjects():void
{
// Creamos un material con dos caras iguales:
var mat:WireframeMaterial = new WireframeMaterial;
mat.doubleSided = true;
 
// Creamos un plano con el material anterior:
var plane:Plane = new Plane(mat, 500, 500, 8, 8);
plane.rotationX = -90;
 
// lo añadimos a la escena
scene.addChild(plane);
}

Para finalizar el ejemplo añadiremos un có