EMETTEUR DE PARTICULES AS3
pegase31
Messages postés
6138
Date d'inscription
dimanche 21 décembre 2003
Statut
Modérateur
Dernière intervention
4 septembre 2013
-
19 mai 2008 à 15:57
mousman Messages postés 23 Date d'inscription jeudi 27 janvier 2005 Statut Membre Dernière intervention 10 septembre 2008 - 10 sept. 2008 à 19:14
mousman Messages postés 23 Date d'inscription jeudi 27 janvier 2005 Statut Membre Dernière intervention 10 septembre 2008 - 10 sept. 2008 à 19:14
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/46708-emetteur-de-particules-as3
https://codes-sources.commentcamarche.net/source/46708-emetteur-de-particules-as3
10 sept. 2008 à 19:14
un peu de lutte avec l'upload du zip,
mais le zip est correcte à présent ...
22 mai 2008 à 13:38
Dès que j'ai fini je posterai le code, j'espère que Top30 pourra y jeter un oeil...
22 mai 2008 à 12:37
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 ?
22 mai 2008 à 09:54
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...
22 mai 2008 à 09:43
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.
22 mai 2008 à 09:32
Top30 ? probablement la r?ponse...
22 mai 2008 à 01:53
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..."
21 mai 2008 à 22:40
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....
21 mai 2008 à 15:57
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.
20 mai 2008 à 23:21
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...
20 mai 2008 à 22:10
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 :-)
20 mai 2008 à 19:23
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');
19 mai 2008 à 15:57
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'