Juste un petit mot en passant pour vous dire que ce blog n'est pas mort !

En ce moment je découvre Fast2Reply ... Une petite communauté bien sympa, centralisée sur un système de questions auquelles il faut répondre le plus vite possible ... Une nouvelle question apparaît tous les 2-3 jours, et plus on répond vite, plus on gagne de points, que la réponse soit bonne ou mauvaise. Ensuite, les bonnes réponses donnent des points supplémentaires, et les plus originales (ou "groovy") gagnent aussi des points en plus. On peut aussi créer des clans, pour se prévenir lorsque la question arrive, acheter des sorts pour brouiller les réponses des autres etc ... C'est sympa, et la communauté est trés fun ... Si vous vous inscrivez, pensez à marquer lalex en tant que parrain, ca me fait gagner quelques points ! Quelques membres de MediaBox et moi avaons monté un clan, et on ne compte pas s'en laisser raconter !

Pas grand chose en Flash actuellement à part un petit menu dynamique en XML qui utilise les équations de Penner en AS1 (avec Flash MX, marre de redémarrer MX 2004 et de perdre du code ... :?) ... Oui je sais, y en a marre de mes menus XML, mais moi j'aime toujours autant en faire !

Je fais actuellement un développement dans l'urgence, et je dois avouer que les composants fournis par Macromedia me snot d'un secours important. Il faut bien avouer que Macromedia a fait un effort sur ces composants par rapport au composants de Flash MX. Il n'en manque pas pour faire une application "a la windows", et leurs API sont plutôt bien étudiées.

Je n'ai pas encore eu l'occasion d'en utiliser beaucoup (j'en suis encore à TextInput et DataGrid), mais il faut bien avouer que je les trouve trés sympa à utiliser. En plus, ce qui ne gâche rien, leur look n'est pas mal non plus.

Le risque avec les composants, c'est de voir fleurir un peu partout sur le web des sites qui se ressemblent tous ... :? Mais pour des applications d'entreprise, on apporte peu d'importance à l'originalité du design, et si ca peut faire gagner en temps de développement, les responsables sont toujours content ! Aprés tout, on se plaint rarement que les boutons de toutes les applications Windows (ou Mac) sont partout les mêmes !

Pour ce qui est des bugs ou des limitations, je vais un peu chercher du coté de l'héritage, car il faut bien avouer que le systèmes des composants "closed source" n'arrange rien ... C'est bien de pouvoir le faire pour les développeurs qui veulent vendre leurs composants, mais Macromedia aurait pu laisser les siens en opensource ... Bref, pour l'héritage et/ou la modification, étant donné le peu d'infos que distille Macromedia et les lacunes de la doc, c'est pas gagné ! Je vais aussi jeter un coup d'oeil sur les nouveaux composants de person13 : http://www.person13.com/components/ (merci petepx pour l'info :))

Attention ! Je considère cela comme un bug, mais peut-être que j'utilise mal le composant tout simplement ... :?

Il est possible dans Flash d'utiliser des noms d'instances qui contiennent des points (par exemple "monNom.dInstance"). Il est évident que dans ce cas la, on ne peut plus accéder aux clips avec la notation _root.monNom.dInstance, car ActionScript l'interpréterait comme une propriété dInstance de l'objet monNom ... :roll: Mais il est toujours possible d'y accéder avec la notation par crochets _root["monNom.dInstance"] ...

Eh bien figurez vous qu'il est impossible d'accéder à la propriété text d'un composant TextInput de cette manière, alors qu'on peut le faire sans aucun problème avec un TextField normal ...

J'ai jeté un coup d'oeil sur la classe mx.controls.TextInput, mais elle se contente de modifier la propriété text du TextField contenu à l'interieur (la propriété label est un TextField) : function setText(t:String):Void
{
        if (initializing)
        {
                initText = t;
        }
        else
        {
            var l = label;
                if (l.html == true)
                {
                        l.htmlText = t;
                }
                else
                {
                        l.text = t;
                }
        }
        // Send a "valueChanged" event
        dispatchValueChangedEvent(t);
}

Comment se fait-il alors que je ne puisse pas changer cette p*$%£ de propriété ?!? 8O Pour compléter ca, si on donne un nom avec un point à un composant TextField, même la valeur initiale que l'on renseigne dans les propriétés du composant n'est pas prise en compte ... :? Je n'ai pas trouvé d'instructions comme eval(...) dans les classes de composants, donc je ne vois vraiment pas ...

Le composant TextArea a le même problème, et je n'en ai pas testé d'autres ... :roll:

Peut-être que je ne vais rien apprendre à personne, mais je viens de découvrir que Flash crée ses packages sur le _root des animations. J'ai par hasard fait un createEmptyMovieClip sur _root avec un nom qui était le même que le nom d'un package, et impossible d'accéder aux classes du package !!! 8O

L'explication est sans doute que AS2 n'utilise pas le _global pour que des loadMovie n'interfèrent pas entre eux au niveau des classes, mais là ça fait quand même tout drôle ... Une autre solution aurait pu être trouvée pour un peu plus de logique ... :?

Je continue donc a penser que Macromedia n'a pas forcément fait le meilleur choix en créant un simple "traducteur" AS2 > AS1, au lieu de créer un vrai langage objet. Chez Macromedia comme dans tout développement, le bricolage n'ammène rien de bon en général ... :roll:

Ca y est, j'ai rajouté le support de quelques smileys sur le blog ! Je tiens d'ailleurs à féliciter l'auteur pour se deux packs de smileys (à la base dédiés à phpBB), que je trouve super jolis : phaetorn (que je ne connais pas, je lui ai honteusement pillé ses smileys) ...

Je sais que ca n'apporte pas grand chose (on pourrait même dire que cela nuit au sérieux du blog), mais je vous rappelle que ce blog est également un terrain d'expérimentation pour moi ...

Vous pouvez utiliser :

• : ) ou : - ) =>
  
• ; ) ou ; - ) =>
  
• : D ou : - D =>
  
• 8 O => 8O
  
• 8 ) =>
  
• : ( =>
  
• 8 | ou : roll : => 8|
  
• : P =>
  
• et le plus beau : ~ ou : lalex : => :~

Et voila, un blog tout beau tout neuf !!!

Le visuel est un peu plus évolué, donc évidemment un peu plus lourd ... Mais je pense que ca vaut le coup, parce que c'est quand même plus agréable de parcourir ces pages maintenant (enfin ce n'est que mon avis ...)

Vous pouvez maintenant utiliser quelques BBCode pour vos commentaires, histoire d'y voir un peu plus clair quand vous mettez du code ...

Vous avez à votre disposition les tags [ b ], [ u ] et [ i ] pour le gras, le souligné et l'italique ... Vous pouvez utiliser aussi [ quote ] (tout seul) pour faire un joli n'encadré, et le plus important : [ as ] pour écrire du code (la colorisation AS2 ne devrait pas tarder ...). Il en existe d'autres, mais ils me sont réservés (pas dispos dans les commentaires). Je mettrais demain le source de mon parseur de BBCode ici (avec un fichier de config en exemple) comme ca vous pourrez l'utiliser, et faire vos propres BBCode ...

Au menu des fonctionnalités à venir : la syndication et les smileys parce que je les utilise et vous aussi (je fini par me demander si je devrais pas faire un forum moi ...)

Voila, j'espère que ca vous plait !

Ca manque un peu de mise à jour en ce moment. En fait, je suis en train de redévelopper le moteur du blog pour pouvoir facilement proposer une syndication RSS des mes périgrnations Flashistiques ... Je prévois aussi de faire une inscription pour se tenir au courant des nouveaux post.
J'en profite également pour faire un nouveau design une peu plus "fin" et évolué (qui sera honteusement inspiré du nouveau blog de gskinner que je trouve superbe pour un blog), mais n'étant pas graphiste, ne vous attendez pas non plus à a quelque chose de révolutionnaire ...

Donc à trés bientôt ici même !!!

Je me re-penche actuellement sur mon moteur 3D, entamé il y a maintenant 3 ans sur Flash 5. Depuis, je l'ai porté sur Flash 6, me permettant ainsi d'utiliser quelques notions de POO, et les API de dessin pour remplir les faces et gérer les lumières. Mais depuis, j'ai appris beaucoup plus sur notamment l'héritage et le programmation évenementielle dans Flash MX. Voici donc les reflexions que j'ai entammées sur l'optimisation de ce moteur.

Tout d'abord, un bref résumé de la structure générale d'un moteur 3D :

• Un point en 3D comporte 3 coordonnées : x (abscisse), y (ordonnée), et z (profondeur).
  
• Une transformation est composée de trois points 3D spécifiant :
  
  
  
  • La translation : deplacement d'un point.
    
  • La rotation : rotation d'un point par rapport au point d'origine.
    
  • L'homotétie : multiplication de la distance entre un point et le point d'origine par un ratio (pourcentage).
    

• Un environnement 3D doit inclure un "point de vue", souvent appelé "Camera". Ce point de vue est situé a des coordonnées (est donc un point 3D), et peut subir des transformations (pour la caméra, l'homotétie n'existe pas).
  
• L'environnement 3D contient aussi un point 3D "lumière", qui indique la position de la source lumineuse. On pourra aussi ajouter une propriété "instensité" de la source lumineuse.
  
• L'environnement (ou la caméra, s'il peut y en avoir plusieurs) possède aussi une distance focale.
  
• L'environnement possède aussi un point 2D indiquant le point d'origine des coordonnées à l'écran.
  
• Un Vertex est un point 3D accompagné de l'ensemble des étapes intermédiaires pour arriver à le projeter sur l'écran. Il comporte :
  
  
  
  • Le point 3D d'origine.
    
  • Le point 3D obtenu aprés applications des transformations du point.
    
  • Le point 3D situé par rapport à l'environnement (caméra).
    
  • Le point 2D projeté sur l'écran.
    
  • Les méthodes pour passer d'une étape à l'autre. Nous les appelerons : coord2env, env2align, align2screen
    

• Une face est un triangle et est donc composée de trois Vertex. On cacule également sa "normale", qui va permettre de connaitre le degré d'exposition de la face par rapport à la source lumineuse.
  
• Une arrete est une ligne que l'on peut afficher ou non. Elle est composée de deux Vertex (depart et arrivée).
  
• Une forme (ou un objet) est composée d'une liste de Vertex, d'Arretes et de Faces. Une forme possède également une transformation
  

L'optimisation va donc passer par le fait de ne pas recalculer une étape qui n'a pas changée. C'est là que la programmation évenementielle liée à l'instruction addProperty va nous servir. En effet, le addProperty permet de créer des propriétés "publiques" associées avec une méthode get et une méthode set. Il suffit donc que les méthodes set diffusent les évenements 'onChange' appropriés. Le problème délicat est aussi de placer les écouteurs aux bons endroits. Récapitulons quels sont les changements qui peuvent intervenir, et quelles sont leurs conséquences :

• Un point change de coordonnées ou de transformation : il faut donc repasser, uniquement pour ce vertex, par les étapes coord2env, env2align, align2screen.
  
• Une forme change de transformation : il faut refaire la totalité des calculs pour tous les vertex qui la composent.
  
• La caméra change de position : il faut effectuer la totalité des calculs pour toutes les formes présentes.
  

Un des points qui me pose problème, est de savoir si par exemple un Vertex doit connaitre sa transformation ou pas. Si c'est la cas, il faut faire trés attention à ce que la transformation du Vertex soit toujours la même que celle de la forme à laquelle il appartient. La modification de la transformation de la forme devra alors diffuser un évenement écouté par ses Vertex afin qu'ils se mettent à jours systématiquement. En fait, la question est de savoir si un Vertex peut avoir une existence propre, ou s'il doit obligatoirement faire partie d'un forme... Si vous avez la réponse, n'hésitez pas à me la donner (argumentée bien sur...) !!!
J'ai pensé également à augmenter le nombre d'étapes de transformation du Vertex, en mettant une étape pour chaque tranformation individuelle (translation, rotation et homotétie), qui elles aussi doivent s'effectuer dans un ordre bien précis (l'homotétie n'est pas utilisée par la caméra) : 1=homotétie, 2=rotation, 3=translation. Si seule la translation change, cela éviterais de refaire une rotation, et permettrais alors une précieuse économie de calculs trigonométrique.

Voila pour mes quelques réflexions sur l'optimisation de mon moteur, qui vont être mises en pratique prochainement. Je suis bien sûr ouvert à toute suggestion ! Dés que j'aurais fini le recodage et l'optimisation de ce moteur, je le mettrai a disposition ici-même, et je compte même créer un script PHP qui permettra de transormer un fichier ASCII .3ds en format XML, importable dans le moteur.

PS : Voici un petit exemple de moteur 3D tout simplement bluffant : http://www.mx3d.com/ ... J'arriverais à faire le même !!! ;D

Une petite astuce trouvée en créant mon composant : dans le répertoire d'installation de Flash MX (par défaut C:/Program Files/Macromedia Flash MX), dans le dossier 'Configuration', vous pouvez créer un répertoire 'Include' (certains composants le créent), et mettre dedans vos librairies de fichier '.as'. Vous pouvez maintenant faire un #include depuis n'importe quel endroit sans avoir à mettre le fichier '.as' au même endroit que le .fla !!!