begin process at 2012 05 26 05:45:44
  Trouver un code source :
 
dans
 
[ Dernières recherches ]
Accueil > 

Code

 > 

ActionScripts

 > EMETTEUR DE PARTICULES AS3

EMETTEUR DE PARTICULES AS3


 Information sur la source

Note :
9,5 / 10 - par 2 personnes
9,50 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :ActionScripts Classé sous :as3, particules, particule Niveau :Initié Date de création :19/05/2008 Date de mise à jour :10/09/2008 19:11:25 Vu / téléchargé :9 645 / 1 148
Auteur : mousman

Ecrire un message privé
Commentaire sur cette source (13)
Ajouter un commentaire et/ou une note

 Description

Deuxième version,
en prenant en compte les commentaires laissés.
en gros , ajout d'une classe particuleMatrix (routines de transformation),
d'une classe ParticuleFactory (gestion du clonage des particules), rennomage des methodes du DTO et utilisation d'interaces.
------
Je suis parti d'une source de Chamyky,
que j'ai mise à la sauce POO et AS3.
C'est un émetteur de particules qui est très paramétrable.
Il s'articule autour de 4 classes principales :
- ParticulesEmetteur qui est le générateur de particules
- ParticuleDTO qui contient les paramètres
- Particule qui est liée a un Clip de la bibliothèque du fla
et représente une particule
- ParticulesMatrix qui gère les transformations des particules

L'utilisation est simple,
particulesDTO défini des valeurs par défaut que l'on peut ensuite modifier via des setter.
Il vaut mieux cependant étendre cette classe pour se constituer une bibliothèque de particules.

Voila.

Source

  • - part.fla
  • - ParticulesEmetteur.as
  • - Particule.as
  • - ParticuleDTO.as
  • - ParticuleFactory.as
  • - ParticulesMatrix.as
  • - IMatrix.as
  • - IParticule.as
  • - IParticulesEmetteur.as
  • - BouleDeFeu.as un exemple
  • - FeuDArtifice.as un autre exemple
 - part.fla
 - ParticulesEmetteur.as
 - Particule.as 
 - ParticuleDTO.as
 - ParticuleFactory.as
 - ParticulesMatrix.as
 - IMatrix.as
 - IParticule.as
 - IParticulesEmetteur.as
 - BouleDeFeu.as   un exemple
 - FeuDArtifice.as   un autre exemple

 Conclusion

A vous pour les remarques maintenant !

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Historique

07 septembre 2008 22:11:38 :
Deuxième version
07 septembre 2008 22:32:55 :
pb avec le zip..;
10 septembre 2008 19:11:25 :
pb de zip

 Sources du même auteur

Source avec Zip EFFET PAGE
Source avec Zip EFFETDECOLLEMENT
Toutes les sources de mousman

 Sources de la même categorie

Source avec Zip Source avec une capture OUVRIR UNE ANIMATION EXTERNE DANS UN CLIP VIDE. par KcHeY
Source avec Zip ZOOM SUR UNE IMAGE par yasdar
Source avec Zip Source avec une capture UN PEU DE MATH par yasdar
Source avec Zip Source avec une capture PARTICULE SYSTEM par yasdar
Source avec Zip Source avec une capture GALLERIE PHOTO AVEC XML par yasdar
Toutes les sources de la catégorie ActionScripts

 Sources en rapport avec celle ci

TRANSFERT DE DONNÉES FLASH <-> PHP - PETITE SUBTILITÉ AVEC J... par Loubiou
Source avec Zip Source avec une capture AS3 - PRINCIPE ET APPLICATION DE FONCTION RÉCURSIVE par pegase31
Source avec Zip Source avec une capture UN PEU DE MATH par yasdar
Source avec Zip Source avec une capture AS3 - JEU DU TAQUIN par pegase31
Source avec Zip Source avec une capture PARTICULE SYSTEM par yasdar

Commentaires et avis

Commentaire de pegase31 le 19/05/2008 15:57:16 administrateur CS

Ces Classes échappent à ma logique personnelle ... je ne comprend pas pourquoi tu crées 2 classes qui ne produisent rien (BouleDeFeu.as et FeuDArtifice.as) et qui ne contiennent que des variables ... sans parler de la classe ParticuleDTO.as qui ne fait , pour la pluârt des fonctions) que renvoyer des valeurs par des foncitons, alors qu'il serait plus simple de rendre les variables Publiques pour y accéder.

La seule chose que je pourrais te dire c'est que l'utilisation de l'évènement ENTER_FRAME n'est plus trop de mise et il serait plus judicieux d'utiliser un objet TIMER pour éviter les lags, car plus l'animation va ramer plus elle va ramer. On en avait déjà parlé dans l'animation de fumée de volcan.

Mais peut-être que TOP30 ou d'autres personnes plus calées que moi en matière de class pourraient nous expliquer la raison d'une telle structure.

Peg'

Commentaire de gremlins7 le 20/05/2008 19:23:50

Bonjour,
Je suis d'accord avec Pegase31, les classes BouleDeFeu.as et FeuDArtifice.as n'ont pas de raison d'exister...tu utilises ces classes pour configurer l'objet ParticulesDTO. C'est a dire que tu construit l'objet ParticulesDTO autrement qu'avec son constructeur propre que tu as d'ailleurs laissé vide !!!
Je te propose de le remplir de la manière suivante :

public function ParticuleDTO(Feu_Ou_Boule:String)
{
     if(Feu_Ou_Boule=='Feu')
     {
          copier coller de FeuDArtifice.as //la tu construit les params pour FeuDArtifice
     }
     else
     {    
         copier coller de BouleDeFeu.as //la tu construit les params pour BouleDeFeu
     }
}

du coup tu efface ces classes qui ne servent plus a rien et tu construit avec :

var particules:ParticuleDTO=new ParticuleDTO('Feu'); par exemple ou
var particules:ParticuleDTO=new ParticuleDTO('Autre_Construction_Possible');

Commentaire de mousman le 20/05/2008 22:10:03

ok, une explication alors sur la raison d'être de bouledefeu et feudartifice et particuleDTO:

dans cet exemple leur sens n'est pas forcément évident c'est vrai  , c'est aussi  à but didacticiel.
Ils sont pour là rendre plus facile l'évolution d'une application.

- gremlins
ta solution est très bien si tu n'as que ces 2 jeux de paramètres que j'ai mis en exemple,
mais si il y en a 10 ou 20 ou plus (les possibilités avec le générateur sont nombreuses) tu te retrouves avec une classe énorme remplie de if,
ce qui n'est pas vraiment dans la philosophie objet.
Dans ce cas l'héritage et le polymorphisme sont plus recommandés , même si pour être encore plus propre dans les classes qui étendent ParticuleDTO j'aurai dut utiliser les setter (les méthodes)  plutôt que redéfinir les variables
ou pour aller plus loin utiliser un design pattern de type factory ou builder....

En ce qui concerne ParticuleDTO :
un DTO (Data Transfert Object) est une sorte de conteneur qui sert (qui ne sert qu') à passer un ensemble de paramètres entre deux objets. (je résume un peu)
Il ne contient que des variables définies en private et des méthodes pour les définir  (c'est un bean en java), méthodes définies en public, le constructeur est toujours vide.
pourquoi :
pour réduire la dépendance entre les objets :
si je décide demain qu'un des paramètres du DTO n'est plus une variable mais le résultat d'un calcul entre deux autres paramètres du DTO,
je n'ai qu'a changer la méthode set et get de cette ancienne variable du DTO,
sans avoir à modifier tous les fla ou autres qui utilisent le générateur,
c'est un gain de temps important
le DTO permet aussi de mettre des valeurs par défaut aux paramètres et de les rendre ainsi facultatifs ce qui évite d'avoir à tout définir au niveau des variables à chaque utilisation du générateur dans un fla

Voila....
j'ai un peu survolé le sujet mais j'espère avoir été clair et avoir apporté qqchose.
le débat reste ouvert :-)

Commentaire de gremlins7 le 20/05/2008 23:21:52

Merci Mousman, je savais bien qu'il y a avait aiguille sous roche...

Ce qui je pense à susciter l'attention, c'est que tes setters soit vides. On se demandait donc pourquoi. un simple commentaire du style : //Rajouter vos routines ici, aurait donné la réponse...
C'est une méthode originale très peu rencontrée avec flash car il me semble que la plupart des projets en flash, ne nécessite pas autant d'optimisation. C'est pas demain que l'on va utiliser 50 classes de particules différentes !!!

Ton code m'as mis la puce à l'oreille car je suis en train de réécrire un vieux code de moteur 3d en AS3. Et, j'ai utilisé (sans le savoir) une méthode similaire (DTO+setters) pour la création des objets 3d (cube,sphère,...), ce qui m'amène à la question suivante :
Si il est indéniable que cela réduit le dépendances entre les objets, peut on savoir le coup de la méthode sur la taille du fichier final et le temps d'exécution de l'anim final lorsque le nombre d'objet à créer et à détruire devient important ?



Si tout le monde pouvait apporter aussi clairement quelquechose...

Commentaire de top30 le 21/05/2008 15:57:43 9/10

Le concept est fort interessant.
J'apprécie l'effort et applaudi l'argumentation des tes commentaires. Même si je ne suis pas d'accord avec, au moins ils ont le méritent d'être "soutenables".

Ta structure devrait suivre certain concept utilisé par Flash. Et te libérer des dépendances de la blibliothèque. Tu n'est pas loin d'arriver. Je vais essayer de t'aider et de rester clair:

1/ ParticuleEmetteur.as
Se devrait appeler "ParticuleManager" (comme tu l'as fait dans le Fla). C'est elle qui devrait déterminer certain paramétres  que l'objet ParticuleDTO n'a pas besoin de connaitre, comme par exemple le nombre de particule par seconde, ou le comptage de création d'instance (compteur), etc...

var partManager :ParticuleManager= new ParticuleManager( AbstractParticule );
// De plus ce n'est pas nécessaire qu'il soit un élément visuel...

La transformation des particules se devrait faire à travers un object "ParticuleMatrix", simple à faire : retirer une partie de ton code de "ParticuleManager" pour un faire un "ParticuleMatrix", qui pourrait modifier à souhait toute particlue passer en paramètre.

partManager.matrix= new ParticuleMatrix() ;
partManager.matrix.transform(particule) ;


2/ ParticuleDTO.as
Se devrait réellement s'appeler "ParticuleData" car elle ne transfert pas de données, mais simplement les stock. De plus un des gros inconvénient de l'utilisation tes classes est ICI dans la classe ParticuleDTO, LE NOM DES VARIABLES:
- Si la propriété "g" est la gravité, pourquoi ne pas la nommer "gravity" ???
- Si "ss" est suivreSouris pourquoi ne pas la nommer "followMouse" ???
- Si "dx1" et "dx2" ont des décalages pour ne pas en faire une array "offsetX" ????


3/ BouleDeFeu.as
Ne devraitpas faire partie de ton package "com.mousman.flash9.fx.particules.BouleDeFeu", mais d'un sous package "com.mousman.flash9.PRESETS.particules.BouleDeFeu". Il ne dépend pas de ton package car c'est en fait un presetting "ParticuleData".


Dans l'absolu une particule ne devrait pas être non plus une classe "visuelle" type Sprite ou MovieClip. Mais une classe belle et bien indépendante capable de transformer tout object "DisplayObject" : tes modifications étant enièrement supportées par la classe "DisplayObject" ( x, y, scaleX, scaleY, alpha, rotation, colorTransform, etc...).
Ces transformations se faisant à travers une classe "ParticuleView".

var view :ParticuleView= ne ParticuleView(myDisplayObject) ;
view.transform(TransformMatrix);
// Te liberant ainsi de toute obligation avec la bibliotheque...

Donc pour résumer:

ParticuleManager
// Créer et gére les particules

ParticuleData
// Contient les données initiales des particule

ParticuleMatrix
// Contients les routines de transformation

ParticuleView
// Transformant tout object visuel.


Je n'ai mis que 9 car je trouves cela un peu "compliqué" pour ce que c'est rèllement dans l'etat actuel das choses. Si tu étais ammener à changer tes classes, je suis interessé par en suivre le cours...
Espérant t'avoir aider un peu.

Commentaire de mousman le 21/05/2008 22:40:27

merci top30.
par rapport aux points que tu as mentionnés :

1/
- pour le nom de l'émetteur je suis d'accord avec toi.
- pour certains paramètres qui n'ont pas leur place dans le DTO, tu as tout à fait raison, leur vrai place est dans le manager.
- pour la création d'un objet ParticuleMatrix c'est une excellente suggestion, en terme de capacité d'évolution ça permettra de pouvoir utiliser différents transformateurs avec le même gestionnaire de particules

2/
- pour l'appellation du DTO , je le laisserai comme ça, il ne transfert pas de données c'est vrai,mais il s'appelle comme ça parcequ'il est utilisé pour transférer des données d'un objet à un autre, même si ça reste discutable par rapport au but précis d'un DTO pour des puristes : transfert entre 2 couches applicatives,
bien que en même temps on peut considérer que dans un modèle MVC, les particules appartiendraient à la couche model,
et le ParticuleManager à la couche contrôleur (d'où son nom à l'origine),
avec comme erreur de ma part (volontaire pour ne pas complexifier encore plus) que les DTO soient instanciés dans un objet appartenant à la couche model et non dans le FLA directement. je pourrai le faire dans une deuxième version,
kestenpense ?

- pour le nom des méthodes tu as raison aussi, ça serait plus parlant (j'ai eut un peu la flemme , j'ai gardé le nom des variables du code d'origine et utilisé la génération des accesseurs avec sepy... :-)  je plaide coupable )

3/
- pour le package effectivement on peut les mettre dans un autre mais ce serait plutôt un sous package dans ce cas :
com.mousman.flash9.fx.particules.preset.BouleDeFeu

- pour ParticuleView et DisplayObject je vais regarder ça


Merci pour tes remarques et tes suggestions !
je vais me mettre au boulot pour prendre tout ça en compte,
en ajoutant aussi la gestion de l'objet Timer dont parlait pegase.
Je mettrai la nouvelle version sur le site quand ça sera fait.(pas tout de suite lol)

Voila....





Commentaire de top30 le 22/05/2008 01:53:50

Si tu veux mais ne perds pas ce que tu as conquis.
L'utilisation d'UN SEUL LISTENER "time" (L'enterFrame usant d'un Timer" en AS3) via l'enterframe de ta cible de l'objet ParticuleManager.
Me fais pas l'erreur d'intéger une "timer" au particule. Reste bien sur le concept d'un seul sur le manager.

Le sous package est effectivement le "terme et la structure théorique".
Mais dans mon cas, j'aime que le package du dépendant soit plus court que celui du contribuant.

Dans l'attente de tes modifs.
Pour une fois je vais cocher la case "être averti..."

Commentaire de gremlins7 le 22/05/2008 09:32:00

Et sinon, quelqu'un a une id?e de l'impact de la methode sur le temps d'execution final ? Je suppose que de construire les objets via des DTO est plus couteux ? la fois en memoire et en temps d'execution, puisque l'on construit plus objets qu'avec une methode classique ! Ou est-ce que c'est completement transparent ? la compilation ???

Top30 ? probablement la r?ponse...

Commentaire de mousman le 22/05/2008 09:43:22

top30 : ok
gremlins : en terme de mémoire et de temps d'exécution - à moins que tu pousses déja à leurs limites les ressources machines avec ton appli et que tu soies à la recherche du moindre octets et millisecondes -  sont négligeables.

Commentaire de gremlins7 le 22/05/2008 09:54:50

Ben justement, j'en suis la !!!
Comme je te le disais j'ai utilisé cette methode sans le savoir et lorsque je place enormement d'objets dans la scene pour eprouver mon code j'ai des super ralentissement par rapport à avant, je veux juste savoir si ca peut en être la cause avant de continuer...

Commentaire de top30 le 22/05/2008 12:37:04

Pour trancher sur "ENTERFRAME" ou "TIMER" simple:
Selon "ActionScript 3 : La référence", l'ENTERFRAME utiliserais moins de ressource que le "TIMER".
Mais la grande différence vient surtout que avec le "Timer" tu ne seras pas dépendant du frameRate du stage si ton animation est chargé dans un un parent dont tu ignores le FPS.
Donc si tu es sur de ton frameRate, utilises un EnterFrame, sinon un Timer.

Et Gremlins7, si ton animation rame, ce n'est que parceque le sprite que tu utilises pour tes effets doit posséder un dégradé alpha... non ?

Commentaire de gremlins7 le 22/05/2008 13:38:55 10/10

Non pas de degradé alpha, mais je suis en train de traquer les fonctions gourmandes en placant des compteurs partout...j'ai quand même le sentiment qu'a un moment donné cette methode bouffe de la ressource...
Dès que j'ai fini je posterai le code, j'espère que Top30 pourra y jeter un oeil...

Commentaire de mousman le 10/09/2008 19:14:53

Ca y'est !!
un peu de lutte avec l'upload du zip,
mais le zip est correcte à présent ...

 Ajouter un commentaire


Discussions en rapport avec ce code source dans le forum

masques dynamiques sur particules as3 [ par totoindia ] salut à tous, je suis nouveau sous as3 (depuis avant hier soir ...) et j'ai un petit soucis avec mon projet flash: à partir de tutoriels et de ma volo commander unloader un swf en as3 [ par trek9505 ] Bonjour J'ai un problème pour unloader un swf en as3, voici le code que j'ai utilisé pour loader mon swf dans un clip : function loadmontext (event: lecture inversée d'une interpolation AS3 [ par Loeki ] Bonjour Après maintes recherches sur le web, je ne parviens pas à trouver une façon de lire une interpolation à l'envers. Je m'explique : J'ai un text AS3 - FileReference - download() - FlashTmp0.tmp [ par deydeydesign ] Comment changer le nom du fichier temporaire (FlashTmp0.tmp) créé lors le téléchargement ? Merci. en AS3 comment vider la un tableau (Array) [ par yasdar ] en AS3 comment vider la un tableau (Array) après remplissage du tableau j'arrive pas à le vider pour le remplir par d'autres données. AS3 : comment transformer un texte dynamique en bitmap [ par yasdar ] apparament si le text dynamique commence à tourner en peut pas voir son contenu alors j'ai pensé à le convertir en bitmap.alors comment faire. et merc pourquoi un swf AS2 importer dans un swf AS3 ne marche pas normalement [ par yasdar ] pourquoi un swf AS2(mail form) importer dans un swf AS3 ne fonctionne pas utilisation de this[] en AS3 [ par solage ] Bonjour, Je voudrais pouvroi modifier dynamiquement un "sous objet". Quand je modifie ces propriétés directement cela fonctionne. Par exemple: objetA Aide jeu plateforme (AS3) [ par guibiz ] Bonjour tout le monde, Pour un projet demandé en cours [sur flash CS4, AS3], j'essaie de faire une jeu 2D avec le personnage Samus du jeu Metroid. Apr


Nos sponsors


Sondage...

CalendriCode

Mai 2012
LMMJVSD
 123456
78910111213
14151617181920
21222324252627
28293031   

Consulter la suite du CalendriCode

A découvrir
 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 1,092 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales
Outils Convertisseur VB/C# Snippets et scripts Outils en ligne La ToolBox
Communauté Programmation Photographie Technologie Newsgroups Emploi Forum Blogs
Guide d'achat Téléphonie mobile Image et son Informatique Bureautique Jeux vidéo
Logiciels Internet & Réseau Développement Market Android Jeux & Loisirs Graphisme Multimédia Sécurité Pilotes
Loisirs Cartes virtuelles Vidéos droles Jeux en ligne Géoguide AndroLib (Android Market)