Tynambule

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

package net.tynambule.exp {
	import flash.display.Sprite;
	[Embed(source="assets/test.swf", symbol="test")]
	public class PrivateEmbed extends Sprite
	{
		public function PrivateEmbed()
		{
		}
	}
}

(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 :

package net.tynambule.exp {
	import flash.display.Sprite;
	import flash.text.TextField;
	[Embed(source="assets/test.swf", symbol="test")]
	public class PrivateEmbed extends Sprite
	{
		internal var _tfFoo : TextField;
		public function PrivateEmbed()
		{
		}
	}
}

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 :

public var _tfFoo : TextField;

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.

Comme vous le savez peut-être, je travaille en ce moment chez Ankama comme responsable du client de Dofus (site web), un MMORPG flash-based acceuillant plus de 80’000 joueurs en simultané en heure de pointe. Ces derniers temps, de très gros projets ont été lancés, et le manque d’effectif se fait ressentir plus que jamais.

J’ai pu constater dans les dernières semaines à quel point il est difficile de trouver des flasheurs en ce moment. À croire qu’on ne pousse pas sous les sapins (ha ha ha). De nombreuses annonces ont été publiées à de nombreux endroits (forums Flash, site d’annonces d’Ankama, etc), et pourtant, c’est la galère. Je m’imaginais que la tâche ne serait pas bien compliqué, étant donné la renommée d’Ankama et de Dofus dans le monde des flasheurs francophone, c’était une erreur.

Je m’adresse donc à vous, amis lecteurs. Si vous recherchez un boulot passionnant, à la pointe de la pointe de la technologie Flash (que je sache, aucune team ne repousse les limites de Flash aussi loin que la notre, dans le monde entier), très (parfois trop) prenant, au sein d’une équipe chaleureuse, acceuillante et pleine de gens super sympas (normal, j’y suis), n’hésitez pas : POSTULEZ !

Voici l’annonce :

Votre rôle: Développeur Flash Actionscript 3
Domaine d’activité: Jeux vidéo / MMORPG / Développement

Missions:
Dans le cadre d’un projet de MMORPG de nouvelle génération, le groupe ANKAMA recherche un développeur Flash AS3. Vous travaillez au sein d’une équipe à la pointe du développement de jeux vidéo forte de son expérience sur DOFUS, et réalisez des implémentations concrètes et des nouveaux systèmes et moteurs pour le projet.

Profil recherché:
- Rigueur, autonome, esprit d’équipe;
- Excellente connaissance de l’ActionScript 3;
- Bonne connaissance de l’ActionScript 2 exigée;
- Rapidité, efficacité et organisation;
- Expérience dans la programmation Flash/Flex (site, application, jeux);
- Expérience dans le monde du jeu vidéo souhaitée;
- Bonne connaissances de l’univers Flash;
- Des notions d’autres langages de programmation sont un plus (Java, C#, C++, SQL, PHP, etc).

Postes à pourvoir: 2

Période: Dès maintenant
Type de contrat: CDI
Lieu: Roubaix (59100)
Rémunération: entre 20k€ et 30k€ par an ( Selon profil ).
Contact: Samuel Lorétan (C’est moi, n’ayez pas peur, il n’y a pas de vilain DRH entre nous.)

Pour répondre à cette offre, veuillez envoyer un mail à jobs@ankama.com (ou directement à tyn@ankama.com si vous êtes timide !) en précisant la référence GAMES-DEVAS3-JOB. Joignez une lettre de motivation, un CV, et un moyen de consulter vos différents travaux.

Allez, n’hésitez plus. Ca pète de bosser ici. Allez, salut.

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 :

• Flex Builder 3 Beta 3
• AIR Beta 3

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…

Un petit crash du player 9 !

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package net.tynambule.exp {
	import flash.display.MovieClip;
	import flash.display.LoaderInfo;
	import flash.display.Sprite;
	import flash.net.URLRequest;
	import flash.events.Event;
	import flash.display.Loader;
	[SWF(backgroundColor="#ffffff", frameRate="250", width="100", height="100")]
	public class MovieClipSpriteTest extends Sprite
	{
		public function MovieClipSpriteTest()
		{
			var l : Loader = new Loader();
			l.contentLoaderInfo.addEventListener(Event.INIT, onLoadInit);
			// Un SWF Flash 9/AS3 avec "Document class" défini à "MobileSprite"
			l.load(new URLRequest("swfexterne.swf"));
		}
		private function onLoadInit(e : Event) : void
		{
			var MobileSprite : Class = (e.target as LoaderInfo).applicationDomain.getDefinition("MobileSprite") as Class;
			var instance : MovieClip = new MobileSprite() as MovieClip;	// KA-BOOM
			this.addChild(instance);
		}
	}
}

Ce code fonctionne très bien si l’on utilise l’option « Linkage » d’un clip dans la bibliothèque, mais crash lamentablement si on place directement nos éléments sur la scène et que l’on défini une « Document class ». À noter que c’est l’instanciation de la classe récupérée qui foire, et non pas sa récuperation. Si l’on fait un describeType sur MobileSprite dans le code ci-dessus avant de créer l’instance, le retour est normal, il s’agit bien d’une classe qui étend bien MovieClip.

C’est pô bô. Allez, salut.