top30
Messages postés1158Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention 6 août 2010
-
19 avril 2010 à 12:44
stefbuet
Messages postés576Date d'inscriptionmercredi 5 janvier 2005StatutMembreDernière intervention12 mai 2009
-
26 avril 2010 à 00:31
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
stefbuet
Messages postés576Date d'inscriptionmercredi 5 janvier 2005StatutMembreDernière intervention12 mai 2009 26 avril 2010 à 00:31
Tu parles peut être de :
addEventListener(Event.ENTER_FRAME, mbEffect.update);
Je ne vois pas le problème. Un bitmapData est créé à chaque rendu tandis que le précèdent est déchargé de la mémoire. Il n'y a pas de fuite de mémoire.
Orange73
Messages postés1375Date d'inscriptiondimanche 28 novembre 2004StatutMembreDernière intervention 2 août 2011 26 avril 2010 à 00:02
addEventListener(Event.ENTER_FRAME, mbEffect);
stefbuet
Messages postés576Date d'inscriptionmercredi 5 janvier 2005StatutMembreDernière intervention12 mai 2009 25 avril 2010 à 23:34
Salut,
Je vois pas. Fichier & Ligne stp.
Orange73
Messages postés1375Date d'inscriptiondimanche 28 novembre 2004StatutMembreDernière intervention 2 août 2011 25 avril 2010 à 22:51
Hello,
Source sympa.
J'ai pas pris le temps de regarder le code mais une chose m'a tappé a l'oeil dans ton code sample :
Tu crées un new object tout le temps via l'event ENTER_FRAME !!! c'est pas très bon cela pour les ressources CPU.
A+
stefbuet
Messages postés576Date d'inscriptionmercredi 5 janvier 2005StatutMembreDernière intervention12 mai 2009 19 avril 2010 à 23:01
En fait cela dépend du PC cible sous lequel tourne l'animation. Plus il est rapide, moins le flou sera visible. C'est le problème de cette technique. Après il faut essayer de jouer en temps réel sur le nombre d'images du buffer (dans le cas de la 1er méthode) ou le coefficient de persistance du buffer (dans le ème cas) pour avoir à peu près la même chose partout.
top30
Messages postés1158Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention 6 août 2010 19 avril 2010 à 21:08
J'ai vu que dans tes exemples tu avais changer selon mes conseils...
je dois reconnaitre que l'effet est moins "percutant", masi alors qu'est-ce que ca rame moins !!! Pour être plus proche de l'effet "original", tu devrais faire en sorte que la première copie soit déjà estompée. Sur ton exemple "physique", on dirait que les cercles les plus récents ne soient pas estompés (ou alors c'est pas assez!).
Dans tous les cas, sur le rendu des persos animés c'est pas mal !
7/10
top30
Messages postés1158Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention 6 août 2010 19 avril 2010 à 21:00
Une autre solution qui économiserait des ressources, car ca rame !
Ca serait de dessiner la cible (et non le parent) puis mémoriser la position.
Tu pourais faire en sorte que ton effet soit un "calque" contenant la cible et le flou.
stefbuet
Messages postés576Date d'inscriptionmercredi 5 janvier 2005StatutMembreDernière intervention12 mai 2009 19 avril 2010 à 14:42
J'hésitais entre les deux méthodes. Le rendu n'est pas exactement le même car avec la technique des 3 bmpData la trainé va disparaitre progressivement contrairement au gros buffer. Mais l'utiliser permet de beaucoup réduire le cout de calcul.
J'ai donc implémenté cette méthode dans la classe, et elle est utilisable en spécifiant les deux derniers paramètres du constructeur. La méthode originelle est donc toujours dispo, à l'user de choisir ce qui lui convient le mieux.
Stef.
top30
Messages postés1158Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention 6 août 2010 19 avril 2010 à 12:44
Le concept est bon...
Pour consommer moins de ressource n'utilise que 3 BitmapData !
1/ Une copie de l'image courante.
2/ Une copie de la copie précédente mais estompée.
3/ Une copie des des copies, estompée, que tu mélanges avec l'avant dernière.
Ainsi tu pourras avoir un "gros" buffer de 10 ou 100, mais toujours 3 BitmapData !
26 avril 2010 à 00:31
addEventListener(Event.ENTER_FRAME, mbEffect.update);
Je ne vois pas le problème. Un bitmapData est créé à chaque rendu tandis que le précèdent est déchargé de la mémoire. Il n'y a pas de fuite de mémoire.
26 avril 2010 à 00:02
25 avril 2010 à 23:34
Je vois pas. Fichier & Ligne stp.
25 avril 2010 à 22:51
Source sympa.
J'ai pas pris le temps de regarder le code mais une chose m'a tappé a l'oeil dans ton code sample :
Tu crées un new object tout le temps via l'event ENTER_FRAME !!! c'est pas très bon cela pour les ressources CPU.
A+
19 avril 2010 à 23:01
19 avril 2010 à 21:08
je dois reconnaitre que l'effet est moins "percutant", masi alors qu'est-ce que ca rame moins !!! Pour être plus proche de l'effet "original", tu devrais faire en sorte que la première copie soit déjà estompée. Sur ton exemple "physique", on dirait que les cercles les plus récents ne soient pas estompés (ou alors c'est pas assez!).
Dans tous les cas, sur le rendu des persos animés c'est pas mal !
7/10
19 avril 2010 à 21:00
Ca serait de dessiner la cible (et non le parent) puis mémoriser la position.
Tu pourais faire en sorte que ton effet soit un "calque" contenant la cible et le flou.
19 avril 2010 à 14:42
J'ai donc implémenté cette méthode dans la classe, et elle est utilisable en spécifiant les deux derniers paramètres du constructeur. La méthode originelle est donc toujours dispo, à l'user de choisir ce qui lui convient le mieux.
Stef.
19 avril 2010 à 12:44
Pour consommer moins de ressource n'utilise que 3 BitmapData !
1/ Une copie de l'image courante.
2/ Une copie de la copie précédente mais estompée.
3/ Une copie des des copies, estompée, que tu mélanges avec l'avant dernière.
Ainsi tu pourras avoir un "gros" buffer de 10 ou 100, mais toujours 3 BitmapData !
Clair ???