... dommage qu'il soit nul en maths !

trace (0.01 * 1624);

Résultat : 16.240000000000002

Wééééé...

Voici un FLA contenant 2 clips. Le premier est un rectangle blanc de 100x20 avec un 9-slices scaling, le second est un carré blanc de 100x100. Les 2 clips sont posés sur la scène et le clip 1 est déformé pour faire 100x100.

Normallement un fois compilé on devrait obtenir ca aussi. Voici ce que j'obtiens en réalité :

Tout se passe comme si Flash confondait les 2 clips. Il suffit de changer la couleur de l'un ou l'autre pour que le bug disparaisse...

Le fla est ici.

En Flash on peut être amené à manipuler des BitmapData, par exemple si on code les vignettes d'une galerie photo (c'est un exemple qui revient souvent ;-)... Voilà une première méthode "brute" qui prend un BitmapData et en retourne un autre au ratio voulu :

public static function reduceBitmapData (bmp:BitmapData, ratio:Number):BitmapData {
	var bmpData:BitmapData = new BitmapData(Math.round(bmp.width * ratio), Math.round(bmp.height * ratio));
	var scaleMatrix:Matrix = new Matrix(bmpData.width / bmp.width, 0, 0, bmpData.height / bmp.height, 0, 0);
	bmpData.draw(bmp, scaleMatrix);
		
	return (bmpData);
}

Et là forcement, on se rend vite compte que le résultat est pas génial. Donc on se dit que le paramètre smoothing de la méthode draw est LA solution, et on utilise un truc du genre :

public static function resizeBitmapData (bmp:BitmapData, ratio:Number):BitmapData {
	var bmpData:BitmapData = new BitmapData(Math.round(bmp.width * ratio), Math.round(bmp.height * ratio));
	var scaleMatrix:Matrix = new Matrix(bmpData.width / bmp.width, 0, 0, bmpData.height / bmp.height, 0, 0);
	var colorTransform:ColorTransform = new ColorTransform();
	bmpData.draw(bmp, scaleMatrix, colorTransform, null, null, true);
			
	return (bmpData);
}

Cruelle déception... autant ça donne des résultats corrects quand le ratio est proche de 1, autant les différences avec la méthode précédente sont quasi nulles quand on demande une grosse réduction... Pourquoi ?

Eh bin tout simplement parce que le filtre utilisé par Flash est un filtre bilinéaire, et qu'il est bien connu (c'est marqué dans Wikipedia) que ce filtre, rapide, trouve rapidement ses limites dans les ratio < 50% ou > 200%

Y'a rien à faire alors ?

Bah non...

Nan attendez, revenez, j'aurais pas fait un billet juste pour un pauv' paramètre smoothing. Si le filtre bilineaire est efficace pour des ratio de 50%, on va simplement procéder récursivement de 50% en 50% jusqu'au ratio voulu :

public static function resampleBitmapData (bmp:BitmapData, ratio:Number):BitmapData {
	if (ratio >= 1) {
		return (BitmapManager.resizeBitmapData(bmp, ratio));
	}
	else {
		var bmpData:BitmapData = bmp.clone();
		var appliedRatio:Number = 1;
		
		do {
			if (ratio < 0.5 * appliedRatio) {
				bmpData = BitmapManager.resizeBitmapData(bmpData, 0.5);
				appliedRatio = 0.5 * appliedRatio;
			}
			else {
				bmpData = BitmapManager.resizeBitmapData(bmpData, ratio / appliedRatio);
				appliedRatio = ratio;
			}
		} while (appliedRatio != ratio);
		
		return (bmpData);
	}
}

Les calculs sont un peu plus longs (on a rien sans rien), mais les résultats sont maintenant dignes d'un PhotoShop !

Pour les flemmards, le fichier regroupant les 3 méthodes est ici

Allez cette fois-ci c'est pas un poisson d'avril, la beta du nouveau Flash Player 10 "Astro" est disponible sur le lab Adobe

Et moi qui compile encore en 8 dans 95% des cas... -__-'

que la crise des subprimes ne toucherait pas la France ? Christine Lagarde je crois. Ils sont sacrément visionnaires dans ce gouvernement

Appliqué à notre métier ca donne ca: Oreilly France c'est terminé et 30€ de dons en paypal pour le book de Tibo, la classe...

C'est nouveau et ça cloue enfin le bec à tous ceux qui reprochaient à Flash d'utiliser un format "fermé" (ce qui était déjà pas totalement juste) : Le format SWF 9 est maintenant clairement ouvert, documenté (ça c'est pas nouveau), et désormais sans aucune restrictions sur son utilisation (ça c'est nouveau) !

Une bonne nouvelle dans le cadre du Open Screen Project

[Source : Open at Adobe via FCNG]

Comme toujours, si vous êtes un vrai killer de Flash et de Windows, vous allez doucement rigoler en lisant ce post mais pour les goonies comme moi, voila une petite astuce qui m'est venu aujourd'hui. La connexion neuronale s'est faite au moment ou je dessinais un cercle parfait depuis le centre !

Il vous est peut-être déjà arrivé de voir Flash passer subitement en anglais. Tout cela s'explique par une combinaison de touche fréquemment utilisée dans l'environnement auteur: SHIFT+ALT. Cette combinaison est également utilisée par Windows comme raccourci pour basculer le clavier dans la langue suivante dans la liste des langues installées pour le clavier, généralement l'anglais.

Pour éviter ca, il vous suffit de virer l'anglais de la liste des claviers supportés, trop fort...

PS: Une petite astuce ca fait toujours du bien en attendant "Pratique de la planche à voile avec Thibault Imbert et Mabrouk" bientot en Open source sur ByteArray.org !

Le nouveau flash player 9.0.122 est disponible en beta sur labs.adobe.com.

Parmi les nouveautés :

• Tous les bugs sur les TextFields ont été corrigés !
• Support d'une nouvelle coordonnées z pour les clips, comme présenté lors du MAX
• Possibilité de proposer en téléchargement le contenu d'un bytesArray
• Support complet du XHTML 1.1 dans les TextFields
• Gestion du deuxième bouton de la souris
• Compatibilité Silverlight 1.1

Les performances ont été grandement améliorées, approchant maintenant quasiment celles d'un PC d'il y a 15 ans !
Disponible sur Windows, Linux et machine Nespresso. On comprend mieux le nom de code de ce player, "RamboSix", parce qu'il tue tout !

... et voilà la seconde, profil de développeur Flash Senior recherché :

Lire la suite

On cherche des gens ! Voilà la première annonce, pour un dév PHP Senior :

Lire la suite

Un titre bien barbare pour rapporter un bug qui m'a causé quelques suées...

Je charge un flv dans un player Flash en progressive download avec NetConnection etc...; ça marche en local, ça marche sur mon serveur de développement, mais une fois en ligne l'estimation du chargement et le buffer sont complètement dans les choux...

La cause ce bug : le mod_deflate (ex mod_gzip) sur le serveur Apache qui gzippe à la volée les données pour les navigateurs compatibles HTTP 1.1 (tous les navigateurs modernes). Il faut absolument l'empêcher de gzipper les flv, ce qui ce fait dans le httpd.conf (pour ceux qui on un serveur dédié). Classiquement les fichiers jpeg, png et gif sont déjà dans ce cas; il suffit de rajouter swf et flv à liste liste :

# Don't compress images
    SetEnvIfNoCase Request_URI \
      \.(?:gif|jpe?g|png|swf|flv)$ no-gzip dont-vary

Qui n'a pas galéré en glissant desesperemment un .flv sur un player flash autonome ou tout autre player qui ne comprenait rien. Depuis sa dernière version (ou l'avant dernière, enfin bref depuis que je l'ai mis a jour) Winamp lit les fichiers .flv et ca c'est tout con mais c'est la classe, voila

PS: merci à Jol pour l'info

Je commence ici une nouvelle catégorie d'articles dont le sujet est la mobilité au sens large, c'est à dire comment faire quand on utilise plusieurs machines (PC, téléphone mobile...), éventuellement plusieurs OS sur une même machine, pour lire ses mails, naviguer sur le web, ou développer, sans que ça soit trop pénible à synchroniser ou passer de l'un à l'autre.

Lire la suite

1978	1979
1981	1982

chez envrac pendant la pause on bat quelques oeufs

ça envoie de l'oeuf

Sinatra, j'attends ta vidéo