LAlex devblog v6 - AS3 / Flex2

Tips: Angles et géométrie

-Alexandre LEGOUT aka LAlex- — Fri, 20 Jun 2008 13:45:00 +0200

Je suis actuellement en train de me bruler les neurones sur un éditeur, permettant entre autres de modifier un visuel à la souris. De quoi devoir replonger dans nos bonnes vieilles notions de trigo.
J'en profite donc pour donner ici 2-3 astuces

Rotation d'un point

Pour passer d'un point (x, y) à un autre (x', y') en lui appliquant une rotation d'angle a, l'équation est la suivante:

        x' = x*cos(a) - y*sin(a)
        y' = x*sin(a) + y*cos(a)

Ce qui nous donne un petite méthode AS3:

public function rotatePoint(point : Point, angle : Number, isRadian : Boolean = false) : Point {

        if (ang == 0) return point.clone();

        var radAngle : Number = isRadian ? angle : angle * Math.PI / 180;

        var angleCos : Number = Math.cos(radAngle);

        var angleSin : Number = Math.sin(radAngle);

        return new Point(point.x * angleCos - point.y * angleSin, point.x * angleSin + point.y * angleCos);

}

Notez que l'on peut passer cette méthode un angle en degré (par défaut) ou en radians.

Angle fait par un vecteur

L'AS3 nous fournit une méthode toute prête: Math.atan2. Elle prend en paramètre les coordonnées du vecteur (j'utilise un point dans l'exemple) et retourne un angle en radian (d'où le flag isRadian de la méthode précédente).
Notez bien que la coordonnée 'y' est le premier argument (chez moi, FDT m'affiche 'x' en premier, je me suis fait avoir au début)

var vector : Point = new Point(mouseX, mouseY);

var angRadian : Number = Math.atan2(vector.y, vector.x);

Normaliser un angle

Selon les besoins, il peut être nécessaire d'utiliser systématiquement un angle entre 0 et 360, ou entre -180 et 180. Avec les modulos, cela peut se faire facilement:

// Get a random number between -1500 and 1500

var angle : Number = Math.random() * 3000 - 1500;



// Normalize angle between 0 and 360

var angleIn360 : Number = ((angle % 360) + 360) % 360;

// Normalize angle between -180 and 180

var angleIn180 : Number = ((angle % 360) + 540) % 360 - 180;

---

Voilà pour les ch'tites astuces de l'oncle LAlex

JSFL mon amour...

-Alexandre LEGOUT aka LAlex- — Mon, 31 Mar 2008 17:30:00 +0200

L'équipe d'envrac avait prévenu, mais je suis en train de doucement glisser vers la dépendance au JSFL...

Un p'tit langage qui permet de scripter l'IDE et ainsi de raccourcir drastiquement les taches répétitives, c'est quand-même du pain béni pour peu qu'on prenne le temps de s'y pencher. Pas encore interessé aux panneaux "custom", j'ai pondu quelques petites déclinaisons d'un script inspiré par une ancienne collègue - si tu te reconnais, un paquet de Carambars - et qui facilite grandement l'intégration timeline/code (un petit article prévu la dessus dés que je lève un peu la tête des mes projets et que je me défénéantise en ce qui concerne ce blog).

Bref, ceci est un ensemble de 4 scripts JSFL qui font le tour des instances nommées dans un clip, et affiche dans le panneau de sortie les déclarations AS3 de celles-ci : je ne parlerais pas ici de la quasi obligation morale qui nous incombe à tous de décocher la case "Déclarer automatiquement les instances etc..." si vous êtes pas des trouillards... :p

Plusieurs déclinaisons donc:

"Lazy Timeline Variables": affiche les déclarations sour forme public var monClip:MonClip;
"Lazy Timeline GetSet": même chose, mais déclare les variables en mode private préfixées avec un underscore, ainsi que les getter/setter publics corrspondant (pratique si vous voulez détecter l'ajout d'un clip à la timeline, sans attendre un Event.ADDED puis un Event.RENDER)...
"Lazy Selected Variables"/"Lazy Selected GetSet": même chose que les deux précédents, mais uniquement pour les instances sélectionnées dans l'IDE: pratique quand on a déjà utilisés les précédents, mais qu'on a rajouté une instance entre temps...

A savoir que chacun de ces scripts:

Utilise les classes renseignées dans l'IDE: en gros, si les éléments ne sont pas exportés pour AS dans la bibliothèque, c'est MovieClip ou SimpleButton qui seront utilisés, sinon, c'est soit la BaseClass, soit la classe elle-même qui seront utilisées.
Copie ces déclarations dans le clipboard, pour qu'il n'y ai plus qu'un "coller" à faire dans le vrai environnement de développement que vous utilisez certainement!

Ces scripts se décompressent dans le répertoire ~/Library/Application Support/Adobe/Flash CS3/en/Configuration/Commands (sur Mac, vous trouverez l'équivalent sur Windows), et deviennent accessibles depuis Flash dans le menu "Commandes"...

Pour le petit exemple de "Lazy Timeline GetSet" pour 2 boutons:

/* JSFL Example*/

                // Private timeline properties



                private var _upButton:MinimalButton;

                private var _downButton:MinimalButton;



                // Public timeline getters/setters



                public function set upButton(displayObject: MinimalButton) : void {

                        _upButton = displayObject;



                        // Rajouté a posteriori

                        _upButton.addEventListener(MouseEvent.CLICK, upButtonClickHandler);

                }

                

                private function upButtonClickHandler(event : MouseEvent) : void {

                        trace("Up clicked")

                }



                public function get upButton() : MovieClip{

                        return _upButton;

                }



                public function set downButton(displayObject: MinimalButton) : void {

                        _downButton = displayObject;



                        // Rajouté a posteriori

                        _downButton.addEventListener(MouseEvent.CLICK, downButtonClickHandler);

                }

                

                private function downButtonClickHandler(event : MouseEvent) : void {

                        trace("Down clicked")

                }



                public function get downButton() : MovieClip{

                        return _downButton;

                }

Tous ces zoulis scripts sont téléchargeables: LazyScripts.zip

Les composants, c'est pour les graphistes!

-Alexandre LEGOUT aka LAlex- — Tue, 18 Mar 2008 20:09:00 +0100

... qu'y disent! Eh ben, non madame, c'est bien pour les codeurs aussi!

Prenons totalement au hasard un exemple de petite classe utilitaire de debug pour afficher le framerate et la mémoire utilisée: et bien c'est quand-même bien plus pratique de déposer un petit composant sur sa scène plutôt que de se frapper un 'new FramerateViewer()' dans une DocumentClass quand-même... Et ca se fait tout aussi vite!
Et que même si on veut mettre une icone et tout et tout, ca prend bien 2mn de plus!

Allez, l'exemple en pratique: Framerate.swc

PS: Merci famfamfam pour l'icone

Flex 3, AIR 1.0, etc...

-Alexandre LEGOUT aka LAlex- — Mon, 25 Feb 2008 12:58:00 +0100

Ca y est! Les blougs du monde entier l'ont déjà dit, le Flex 3 SDK, première release OpenSource de Flex et Adobe AIR, la saint graal gratuit des développeurs de RDA (Rich Desktop Applications, bande d'inclutes), sont sortis!

Tout ca semble extremement prometteur.
Je ne vais pas faire la liste des features, mais juste mettre le doigt sur un enorme point positif de cette release: la disponibilité des sources de la classe WebService de Flex! Le passage a l'AS3 avait tout simplement zappé cette classe dans Flash CS3.

Maintenant, reste à voir s'il est possible de se servir de celle-ci sans se trimbaler la moitié du framework Flex...
Si je trouve le temps de faire des tests, j'en donnerai le resultat ici...

Pathfinding A-star sur bitmap

-Alexandre LEGOUT aka LAlex- — Thu, 21 Feb 2008 20:02:00 +0100

L'algorithme A* (A-star) connait de nombreuses implémentations. La plupart utilisent une grille (tableau à deux dimensions) en tant que carte. Etant à la base des jeux "tile-based", celles-ci suffisent la plupart du temps à la grande majorité des jeux. Seulement cela impose un certain nombre de contraintes, notamment en terme de dimensions des "obstacles", mais aussi en terme de performances: l'algorythme se basant sur des noeux (nodes), une grille de 40/40 offre 1600 cases (maximum, l'A* n'étant pas exhaustif), ce qui est déjà bien important...

J'ai voulu essayer de me baser plutôt sur un bitmap, simple (pour l'instant), une couleur étant celle du sol, l'autre celle des obstacles :

Ma jolie video

En gros, l'appel de méthode utilisé ici est

var bmp:BitmapData = new BitmapData(400, 400);



// Génération d'un bitmap aléatoire: fillRect aléatoires, etc...



var finder:BitmapAStar = new BitmapAStar;

var path: /*Point*/ Array = finder.findPath(bmp, new Point(5, 5), new Point(395, 395));

L'A* n'a évidemment pas été le plus compliqué à mettre en oeuvre, mais c'est bien l'analyse et le découpage de ce bitmap qui ont été difficiles à mettre en place. Beaucoup de choses restent à faire malgré cette démo fonctionnelle, notamment l'optimisation du placement des "portes" (ronds blancs sur l'affichage "debug"), et des trajectoires (je pense notamment faire un lissage du chemin à parcourir). D'autres fonctionnalités peuvent être envisagées, comme la gestion des altitudes (terrain en pente, ou les falaises qui seraient des portes à sens unique - qu'on peut sauter mais pas grimper) ou des types de terrain (un malus associé à chaque couleur par exemple).

Dans le plus ardu, on peut aussi imaginer un découpage des formes non rectangulaires (polygones ou courbes).

Une fois cleanées (l'API notamment) et optimisées, je mettrai les sources à disposition sur ce blog...

Options d'une méthode "Array-like"

-Alexandre LEGOUT aka LAlex- — Wed, 20 Feb 2008 19:57:00 +0100

Un appel à une méthode paut parfois avoir besoin d'un certains nombre "d'options", comme c'est le cas pour la méthode Array.sort par exemple.

Il existe alors plusieurs possibilités, la plus simple étant de proposer un certain nombre de paramètres booléens facultatifs, avec des valeurs par défaut. Le problème est tout d'abord que cela alourdit considérablement le code, mais aussi que rajouter une option supplémentaire modifie la signature de la méthode: si on travaille avec des interfaces, bonjour la galère).

Bref, il existe aussi la possibilité de passer un seul entier, qui sera la somme de puissances de 2. En gros, cela permet d'avoir, en binaire, une suite de 0 et de 1, chacun correspondant à l'activation (ou pas) d'une option.
Voyons comment cela fonctionne concrètement avec l'exemple de Array.sort

Les différentes options de cette méthode ont toutes une valeur numérique puissance de 2:

Array.CASEINSENSITIVE: valeur 1 (2 puissance 0)
Array.DESCENDING : valeur 2 (2 puissance 1)
Array.UNIQUESORT : valeur 4 (2 puissance 2)
etc...

Pour les utiliser, on se sert de l'opérateur OU binaire | (pipe simple) de la manière suivante:

myArray.sort(Array.DESCENDING | Array.UNIQUESORT);

Pour utiliser ce système dans d'autres situations, j'ai développé une ch'tite classe toute simple qui génère des options propres à chaque classe, et permet de tester si une option donnée est donnée dont voici l'utilisation:

package com.lalex.utils {

        import flash.display.BitmapData;        

        import com.lalex.utils.Options; 

        

        /**

         * @author LAlex

         */

        public class LAlexDemo {



                // Create options on the fly

                

                public static const SHOW_DEBUG : int = Options.create(LAlexDemo);

                public static const SHOW_BORDER : int = Options.create(LAlexDemo);

                public static const HIDE_FILL : int = Options.create(LAlexDemo);

                

                public function drawShape(bdt : BitmapData, options:int = 0) : void {



                        if (Options.hasOption(options, SHOW_DEBUG)) trace("We will show debug infos");

                        if (Options.hasOption(options, SHOW_BORDER)) trace("We will show shape's border");

                        if (Options.hasOption(options, HIDE_FILL)) trace("We will hide shape's fill color");



                }

        }

}



// Utilisation



var demo:LAlexDemo = new LAlexDemo;

demo.drawShape(myBitmapData, LAlexDemo.SHOW_DEBUG | LAlexDemo.HIDE_FILL);

Voila, un p'tit clic pour télécharger com.lalex.utils.Options

TextField, htmlText et retours à la ligne

-Alexandre LEGOUT aka LAlex- — Mon, 07 Jan 2008 19:37:00 +0100

Le nouvelle gestion des TextField avec AS3 est assez géniale je dirais: plus de propriété html, et une gestion commune entre le texte "classique" associé aux TextFormat et le texte HTML. Du coup, on peut manipuler indifféremment le HTML ou les TextFormat, la modification de l'un sera reportée sur l'autre, comme on peut le voir via le code suivant:

// Crée le champ texte

var tField:TextField = new TextField;

tField.text = "LAlex";



// Crée le format (couleur rouge)

var tFormat:TextFormat = new TextFormat();

tFormat.color = 0xFF0000;



// Applique sur les deux premiers caractères

tField.setTextFormat(tFormat, 0, 2);



// Affiche le resultat HTML de tout ca

trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#FF0000" LETTERSPACING="0" KERNING="0">LA<FONT COLOR="#000000">lex</FONT></FONT></P>

Bon, aprés on va pas chipoter sur la cohérence du formatage HTML, évidemment il y a mieux, mais le tout est d'avoir notre correspondance TextFormat/HTML...

Bref, tout ceci étant fait, si on veut obtenir le copie conforme d'un texte dans un autre, il suffit alors de copier le htmlText du premier sur le second, sans se préoccuper des TextFormat? Eh bien pas forcément...

En effet, un petit bug (a mon avis, car j'ai du mal à expliquer la logique derrière ca) s'est glissé dans la gestion du HTML par les TextField. En effet, quelle que soit la valeur de la propriété condenseWhite (sensée faire le même travail qu'un navigateur HTML, à savoir ne pas afficher les espaces blancs consécutifs), un TextField va systématiquement zapper les paragraphes vides, alors que c'est ce qu'il utilise en interne pour faire des retours à la ligne! Bref, tous les retours à la ligne vont sauter quand on copie le htmlText... Par exemple, si j'ai mis trois retours à la ligne et un texte dans un TextField, les retours à la ligne seront en fait des paragraphes vides <p>:

var tField:TextField = new TextField;

tField.text = "\n\n\nLAlex";



trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0">LAlex</FONT></P>

Bon, OK. Et si maintenant on réaffecte cette valeur à htmlText et qu'on la relit? Voilà ce que ca donne:

var tField:TextField = new TextField;

tField.text = "\n\n\nLAlex";



var myHtmlText:String = tField.htmlText;

tField.text = "";

tField.htmlText = myHtmlText;



trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0">LAlex</FONT></P>

(a noter que je remet le texte à zéro avant de le réattribuer, car sinon il ne fait aucun traitement: il doit exister en interne un traitement du type if (_odlHtmlText != _newHtmlText) {...}).

Comment parer ce problème? J'ai constaté qu'un "vrai" retour à la ligne entre deux paragraphes restaure le retour à la ligne dans le champ texte. Il suffit donc de rajouter un \n entre la fin d'un paragraphe et le suivant. Du coup, une petite regexp fait l'affaire:

var tField:TextField = new TextField;

tField.text = "\n\n\nLAlex";



var myHtmlText:String = tField.htmlText;

tField.text = "";



var reg : RegExp = new RegExp("</([Pp])><", "g");

tField.htmlText = myHtmlText.replace(reg, "</$1><");



trace(tField.htmlText);

<P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0"></FONT></P><P ALIGN="LEFT"><FONT FACE="Times Roman" SIZE="12" COLOR="#000000" LETTERSPACING="0" KERNING="0">LAlex</FONT></P>

Et voilà!

Interfaces et classes internal

-Alexandre LEGOUT aka LAlex- — Mon, 17 Dec 2007 13:04:00 +0100

L'AS3 nous a amené les classes internes (mot-clé internal) qui nous permettent d'encapsuler un certain nombre de fonctionnalités dans une classe disponible uniquement à la classe publique qui l'utilise. Bien pratique, cela évite les classes trop longues, et grâce à l'héritage (une classe interne peut en étendre une autre), cela peut aussi éviter l'utilisation d'un trop grand nombre de if, et donc abaisser la complexité du code.

Cela peut aussi permettre de disposer d'une classe qui n'est pas instanciable depuis l'extérieur. Seulement, il peut parfois être utile d'accéder à une instance de ces classes, et là, la solution c'est tout simplement les interfaces...

Prenons l'exemple d'une liste de contacts (VoIP un jour, VoIP toujours!), dans laquelle on peut sélectionner un contact. Le XML sera utilisé pour remplir cette liste, et un certain nombre d'actions peuvent être effectuées sur les contacts, mais la liste reste le seul moyen d'avoir des contacts: en gros, il est impossible de créer un contact via un constructeur de type new Contact(...).

L'utilisation conjointe des classes internes et des interfaces nous donnerai ceci: Une interface contact

package {



        /**

         * Contact public interface

         * 

         * @author LAlex

         */

        public interface Contact {

                function sendMail(text:String) : void;

                function get firstName() : String;

                function get lastName() : String;

        }

}

Une classe ContactList et son implémentation de l'interface en tant que classe interne

package {



        /**

         * @author LAlex

         */

        public class ContactList {



                private var _contacts:Array = [];               

                private var _selectedContactPosition : int = -1;

                

                function ContactList(dP:XML = null) {

                        if (dP != null) {

                                setDataProvider(dP);

                        }

                }

                

                // Methods

                

                public function setDataProvider(x : XML) : void {

                        for each (var contactNode:XML in x.contacts.contact) {

                                _contacts.push(new ContactImpl(contactNode));

                        }

                }

                

                public function selectContactAt(ind : int = -1) : void {

                        if (ind < _contacts.length) {

                                _selectedContactPosition = ind;

                        }

                }

                

                public function get selectedContact() : Contact {

                        if (_selectedContactPosition != -1) {

                                return _contacts[_selectedContactPosition] as Contact;

                        }

                        return null;

                }

                

        }

}



// Contact interface implementation

internal class ContactImpl

        implements Contact {

        

        private var _firstName:String;

        private var _lastName:String;

        

        function ContactImpl(x : XML) {

                _firstName = x.@first;

                _lastName = x.@last;

                // Other initiation

        }

        

        public function sendMail(text : String) : void {

                // Mail sending implementation

        }

        

        public function get firstName() : String {

                return _firstName;

        }

        

        public function get lastName() : String {

                return _lastName;

        }

}

L'utilisation de cette classe donnerait:

var list : ContactList = new ContactList(<dataprovider><contacts><contact first="Alexandre" last="LEGOUT" /><contact first="Gérard" last="DUPONT" /></contacts></dataprovider>);

list.selectContactAt(1);



var selected : Contact = list.selectedContact;

trace(selected.firstName + " " + selected.lastName);

Et voilà, on a accès depuis l'extérieur de la classe à tous les comportements "publics" d'un contact, sans avoir accés à son implémentation!
Alors je sais que c'est justement le but des interfaces, mais j'ai trouvé cette utilisation intéressante, et assez représentative de l'utilité des interfaces, au cas où vous ne seriez pas encore convaincus...

Tweens: frame-based vs. time-based

-Alexandre LEGOUT aka LAlex- — Mon, 03 Dec 2007 15:55:00 +0100

Actuellement en train de travailler sur un séquenceur de différents types d'action, incluant notamment les interpolations, j'en viens à re-développer une classe de Tween, incluant les améliorations standards des TweenEngine en circulation sur la toile (tween de plusieurs propriétés par exemple).

Tout d'abord, il faut savoir qu'un tween a un principe tout simple: je veux qu'une propriété numérique d'un objet (le plus souvent un objet visuel, comme un Sprite par exemple) évolue entre une valeur de départ et une valeur d'arrivée sur une durée précise. Une équation est utilisée afin de déterminer l'évolution de cette valeur, la plus simple étant une équation linéaire (on partage la distance en intervalles réguliers).

Pour cela, il existe trois méthodes:

Le frame-based

Caractéristiques: La durée du tween est donnée en nombre de frames, et le calcul de chaque position se fait à chaque frame (typiquement, en écoutant l'évènement Event.ENTER_FRAME)
Concept: à chaque calcul, on regarde le nombre de frames écoulé depuis le départ par rapport à la durée en nombre de frames.
Avantages:

On travaille avec des nombres entiers et invariants concernant la position courante dans le temps (nombre de frames écoulé) et la durée. Il devient donc possible de cacher une interpolation et donc de réduire les temps de calcul pour les interpolations suivantes utilisant le même couple équation/durée. En effet, une équation donnée sur une durée donnée se comportera toujours de la même manière. En gros, elle sera toujours à x% de son trajet à la n-ième frame, et c'est donc possible de le mettre en cache.

Inconvénient:

L'intervalle de temps entre deux frames n'est pas fixe: si lors de l'exécution d'une frame un code oblige à ralentir le framerate, le player flash le fera automatiquement. Cela est probablement du à son mode d'exécution mono-threadé. Donc, sur une animation à 30fps, un tween d'une durée de 30 peut prendre plus d'une seconde... L'autre inconvénient, qui peut aussi être un comportement voulu, est que modifier le FPS global de l'animation revient à modifier la vitesse d'interpolation.

Le time-based

Caractéristiques: La durée du tween est donnée en seconde, et le calcul de chaque position est faite à un intervalle de temps donné (typiquement avec setInterval, ou plus "clean" avec la classe Timer).
Concept: un Timer lance le calcul de la nouvelle position toutes les x millisecondes. La base de calcul est le nombre de millisecondes écoulées sur la durée en nombre de millisecondes. Un TimerEvent.updateAfterEvent s'occupe de rafraichir l'affichage indépendamment du framerate.
Avantages:

L'interpolation se fait sur une notion de temps. Bien que le Timer ne soit pas forcément extrêmement précis, c'est ce qu'on peut obtenir de plus proche. Ainsi, le taux de rafraichissement du tween peut même être configurable dynamiquement. Par exemple, on pourrait avoir un tween fluide sur une animation pourtant compilée à 2FPS.

Inconvénients:

Justement, on ne contrôle pas la synchronisation anim/temps. Du coup, on surcharge beaucoup le moteur d'affichage du Flash Player, qui doit rafraichir l'affichage à chaque frame mais aussi à chaque calcul du tween. Il est également trés dur de synchroniser deux tweens: en effet, deux Timer de même durée peuvent dispatcher à plusieurs millisecondes d'intervalle, décalant d'autant les traitements.

Le "frame/time-based"

Caractéristiques: Mix entre le time-based et le frame-based: la durée du tween est donnée en secondes, et le calcul de chaque position se fait à chaque frame.
Concept: A chaque frame, on calcule le temps écoulé en millisecondes depuis le départ sur la durée totale en millisecondes
Avantage:

On obtient les avantages combinés du frame-based (économie du moteur d'affichage) et du time-based (durée constante, indépendante du framerate).

Inconvénient:

La fluidité de l'anim nécessitera un FPS élevé, comme pour le frame-based: fini les anims fluides à 2FPS!
Comme pour le time-based, il est difficile de synchroniser les tweens entre eux, ou alors ils peuvent être synchronisés alors qu'ils ne devraient pas. En effet, admettons qu'une frame s'affiche toutes les 100ms exactement (je sais, un monde parfait n'existe pas, mais faites comme si). Le framerate est volontairement bas (10FPS) pour l'exemple. Deux tweens commencant exactement au même moment, et ayant des durées respectives de 820 et 880ms finiront en même temps, sur la frame 9. En effet, sur la frame 8, 800ms se sont écoulées, et le prochain calcul, qui déterminera la fin des deux tweens, se fera à la frame suivante, soit à 900ms.

Quel mode pour quel usage?

Le mode à utiliser est extrêmement propre à l'usage auquel il est destiné. Les moteurs existants utilisent souvent par défault la troisième option (frame/time-based), et proposent assez souvent la première (frame-based). Le deuxième reste la plus marginale, mais est tout de même proposée dans quelques moteurs/classes. Globalement, je suggèrerais:

frame-based: si vous avez le contrôle de votre environnement de déploiement ou un framerate connu et fixe, ce mode ci devrait être le plus performant car travaillant sur des petits nombres et "cachables" (sauf aprés calcul dans l'équation). Egalement bien utile quand on a un besoin de synchronisation très précise (sauf avec les classes de Tween d'Adobe, voire poste précédent) entre différents tweens, ou quand on travaille avec beaucoup d'éléments issus de la timeline (trés fréquent quand on travaille avec un graphiste/animateur flash) avec lesquels vous devez vous caler.
time-based: a priori le moins utilisé (y compris par les TweenEngine). Il est le moins performant car il rajoute du travail au moteur d'affichage du Flash Player. A utiliser si vous avez besoin d'une fluidité constante quel que soit le framerate. S'il vous faut uniquement des interpolations dont la vitesse est indépendante, voir le "frame/time-based".
frame/time-based: utile pour avoir une durée a peu prés constante indépendamment du framerate. Très utilisé avec les vidéos ou les sons par exemple, il se positionne systématiquement au bon endroit selon le temps "réel" écoulé, quel que soit le nombre de calculs déjà effectués. En bref, même si l'appli "rame", votre tween sera plus ou moins synchro. Interessant aussi quand on ignore le framerate qui sera utilisé par l'application et qu'on désire conserver la vitesse des interpolations, si votre anim est chargée par un Loader par exemple (dans un site portail, un CMS, etc...).

Perso, quand je sais que mon SWF va tourner "tout seul", j'utilise beaucoup de frame-based, avec un "stabilisateur" de framerate (type celui d'André Michelle) pour être sur qu'il sera vu de la même manière par tout le monde...

Tweens Flash CS3

-Alexandre LEGOUT aka LAlex- — Tue, 30 Oct 2007 16:50:00 +0100

Je me rend compte carrément tard par rapport au temps depuis lequel j'utilise les Tweens, mais aviez-vous remarqué que la classe fournie par Adobe dans Flash CS3 (fl.transitions.Tween) émettait l'évènement de fin (TweenEvent.MOTION_FINISH) une frame trop tard? La raison est simple, le test effectué pour détecter la fin est strict:

if (t > this.duration) {

Il suffirait d'un '>=' à la place pour modifier cela, mais à ce moment là la fonctionnalité de boucle zapperais une frame avant de boucler...

Les Tweens de Flex et des "tween engines" que j'ai vu en AS3 (TweenLite et Tweener) n'ont pas ce défaut par contre...

Des coquilles dans l'AS3

-Alexandre LEGOUT aka LAlex- — Fri, 27 Jul 2007 18:44:00 +0200

Aprés maintenant quelques un grand nombre de lignes de code en AS3, j'ai noté quelques comportements bizarres...

la propriété "constructor" de la classe Object ne semble pas être déclarée comme publique. Donc, on se retrouve avec une contradiction entre la doc et la réalité... et surtout aucun moyen de connaitre la classe qui a servie à créer l'objet. Un workaround existe utilisant describeType:

public class ClassUtils

{

        public static function getConstructor(o : *) : Class {

                var clname:String = describeType(o).@name.toXMLString();

                var claz:Class = getDefinitionByName(clname) as Class;

                return claz;

        }

}

imaginons que je crée une interface vide (ainsi que son implémentation) qui me sert uniquement à indiquer l'appartenance à deux types simultanément: en gros, une interface qui hérite de deux interfaces. Si ces deux interfaces mères ont une méthode commune et que j'utilise mon interface fille pour typer une variable, le compilateur va me remonter une erreur comme quoi la référence à cette méthode est ambigue. Ceci est tout à fait inconcevable, car il est clair que l'implémentation utilisée sera évidemment unique! Bon, étant donné que ce charabia doit être super flou, voici un exemple:

// Voir plus bas pour les différentes interfaces

package {

        import flash.display.Sprite;

        

        import itf.IDataSet;

        import itf.IList;

        import cl.DataSet;

        

        public class ASPlayground extends Sprite

        {

                public function ASPlayground()

                {

                        var ids:IDataSet = new DataSet;

                        trace(ids.getLength()); // Erreur du compilateur: Référence ambiguë à getLength.

                        trace((ids as IList).getLength()); // Marche bien !

                }

                

        }

}



package itf

{

        public interface IList

        {

                function getLength() : int;

        }

}



package itf

{

        public interface ICollection

        {

                function getLength() : int;

        }

}



// Cette interface sert au typage

package itf

{

        public interface IDataSet extends IList, ICollection

        {



        }

}



// Implémentation de IDataSet

package cl

{

        import itf.IDataSet;



        public class DataSet implements IDataSet

        {

                public function getLength():int

                {

                        return -1;

                }

                

        }

}

Rien de bien gênant, mais ca peut parfois être troublant!

Le workaround du premier problême fait surtout chuter les performances
Le deuxième problême par contre ne sacrifie en rien les performances, mais peut-être gênant si on ne connait pas les interfaces mères...

AS3 - Vérifier qu'une classe hérite d'une autre...

-Alexandre LEGOUT aka LAlex- — Fri, 06 Apr 2007 16:40:00 +0200

Ayant eu besoin de m'assurer qu'une classe (instance de Class) hérite d'une autre, j'ai cherché un bon moment à reproduire mes anciennes habitudes issues de l'AS2, à savoir utiliser les bons vieux prototypes agrémentés d'une touche de "is" histoire de faire plus actuel...

Autant vous le dire tout de suite: ca ne donne rien!

Il faut donc se tourner vers les excellentes fonctions de reflexion que nous fournis l'AS3 pour arriver à son bonheur, en agrémentant ca de E4X!

import flash.utils.describeType;

import flash.utils.getQualifiedClassName;



public function inherit(childClass:Class, parentClass:Class) : Boolean {

        return describeType(childClass).factory.extendsClass.(@type==getQualifiedClassName(parentClass)).length() > 0;

}

Et wala!