Tynambule
« mai 2008
lunmarmerjeuvensamdim
1234
567891011
12131415161718
19202122232425
262728293031


vendredi 23 mai 2008

Adobe a publié la semaine passée une première beta du Player Flash 10 (nom de code : Astro), implémentant une mise à jour de l'API de dessin, Hydra et quelques modifications de langages, dont le type Vector.

Je ne reviendrais pas dessus, car c'est un sujet qui a été largement couvert par de nombreux blogs, voici simplement quelques liens :


J'esperais plus des modifications de langage apportées par Astro. Si l'implémentation du proposal:Vector est une excellente chose, l'absence de nombreux éléments des drafts ECMA4 fait mal.

Et là où je déplore le manque, c'est surtout sur l'impossibilité de déclarer des classes génériques personnalisées :

Et bim: 1084: Syntax error: expecting leftbrace before dotlessthan.

En lisant la discussion sur les paramètres-types, je m'attendais à pouvoir faire ça de mon côté. Et visiblement non. Dommage... Une prochaine fois? Après tout, ce n'est qu'une première beta.

Allez, salut.

Ajouté le vendredi 23 mai 2008 à 15:55

lu 75 fois - aucun commentaire - aucun trackback
:: : : :

lundi 25 février 2008

Tout le monde aura déjà écrit un code de ce genre :

Ca marche bien. Mais il se trouve que dans mon projet, on a tendance à avoir besoin de beaucoup, beaucoup de loaders. Je me suis donc dit "Allons, Tyn, utilise donc un pool !" Ce qui marche également bien. On a un gain de plus de 1000% en utilisant un pool de Loader plutôt que d'en créer de nouveaux à chaque fois.

Mais qui dit pool dit nettoyage d'objet, et rendu dudit objet au pool après son utilisation. Hors, dans ce cas précis, j'ai un gros soucis: je ne peux pas récupérer mon objet Loader dans mon callback onIOError! C'est quand même très, très con. Ca signifie que je perds un élément de mon pool à chaque URL foireuse, ce qui est un leak inacceptable.

Voici donc un contournement foireux pour récupérer son objet Loader depuis un callback où LoaderInfo.loader n'est pas encore renseigné:

Et hop. C'est quand même bien crade. Si un gentil développeur de chez Adobe passe par ici (sait-on jamais), c'est quand même con que le Loader ne soit pas accessible depuis l'objet LoaderInfo en cas d'erreur de chargement alors qu'il est disponible avant le chargement. Allez, salut.

Ajouté le lundi 25 février 2008 à 15:38

lu 184 fois - 3 commentaires - aucun trackback
:: : :

samedi 12 janvier 2008

En AS3, on peut faire un chouette truc tel que décrit dans le billet sur les balises embed, à savoir ceci :

(Pour les détails, se référer au billet sur la métadonnée embed.)

Maintenant, imaginons que dans notre symbole "test", on aie un TextField qui se nomme "_tfFoo". Dans notre classe décrivant ce symbole, on en aura certainement besoin. Tout naturellement, je l'aurais ajouté en faisant :

Sauf qu'en fait non. Si on fait ça, le compilateur gueule :

ReferenceError: Error #1056: Impossible de créer la propriété _foo sur net.tynambule.exp.PrivateEmbed.
	at flash.display::Sprite/flash.display:Sprite::constructChildren()
	at flash.display::Sprite$iinit()
	at net.tynambule.exp::PrivateEmbed$iinit()[Y:\Code\Workspace\Exp\src\net\tynambule\exp\PrivateEmbed.as:11]
	at net.tynambule.exp::PrivateEmbedContainer$iinit()[Y:\Code\Workspace\Exp\src\net\tynambule\exp\PrivateEmbedContainer.as:12]

Pourquoi? Parce que les éléments placés sur la scène dans un symbol embed ne sont pas internal (ni private, ni protected), mais... public. Ce qui m'oblige à réécrire :

Et là, ça marche. Sauf que moi, j'aurais bien aimé que mon joli TextField ne soit pas accessible depuis n'importe où dans mon code, vu que je préfère quand l'interface est planquée dans son coin et qu'elle n'a rien à voir avec la logique.

Voili voilou, c'est pas très joli et c'est un peu prise de tête de piger pourquoi ça foire. J'me demande pourquoi Adobe a fait ça. Snif. Allez, salut.

Ajouté le samedi 12 janvier 2008 à 15:11

lu 248 fois - un commentaire - aucun trackback
:: : : : : :

jeudi 13 décembre 2007

Adobe a utilisé de joli rubans roses pour emballer les cadeaux qui nous arrivent aujourd'hui : les beta 3 de Flex 3 et de AIR !

Pas de différences majeures entre la beta 2 et la beta 3 pour Flex 3, si ce n'est l'arrivée de la compatibilité avec BlazeDS. En ce qui me concerne, j'ai décidément beaucoup de mal avec ces trucs de remoting génériques. Rien ne vaut un bon vieux serveur socket codé pour l'occasion !

Quant à AIR Beta 3, je n'ai pas réussit à mettre la main sur un changelog par rapport à la Beta 2.

Téléchargements :

Ajouté le jeudi 13 décembre 2007 à 17:20

lu 384 fois - aucun commentaire - aucun trackback
:: : : :

Parfois, avec Flash, il faut savoir réinventer la roue. Par exemple, lorsque l'on veut coder un moteur d'animation qui s'intègre au sein d'un système de rendu isométrique complexe, on aimerait à la foi pouvoir disposer d'un framerate le plus élevé possible, tout en jouant les animations au framerate dans lequel elles ont été réalisées.

Pour se faire, il faut obligatoirement passer par l'indispensable case du calcul du framerate en cours. Il existe peut-être des mondes merveilleux ou la valeur que l'on a entrée dans le champ "Nombre d'images par secondes" de l'IDE Flash est tout le temps vraie, mais il ne s'agit pas du notre.

Voyons différentes approches pour calculer un framerate.

Lire la suite

Ajouté le jeudi 13 décembre 2007 à 11:44

lu 540 fois - 3 commentaires - aucun trackback
:: : :