Bonjour tout le monde!
 
    Alors voila : ma précédente hélice de wisp calculait les positions des wisps 50 fois par seconde en utilisant les fonctions sinus et cosinus. Mon hélice étant dotée de 16 wisps + celui du centre, et ayant deux variantes d'hélices tournant en même temps, le jeu laggait un peu. Un boss m'a proposé une variante utilisant le décalage (offset) par rapport au wisp du milieu.  Je l'ai essayé mais j'ai énormément de fuites de mémoire et mon proc est utilisé à 30 % parfois plus rien que pour ces 3 hélices (pentium 4 : 3,5 GHz). Alors voici donc cette variante :
 
helice de wisps lvl 2 init
    Evénements
        Map initialization
    Conditions
    Actions
        Unité - Move Feu follet 0138 <gen> instantly to (Point(550.00, 1650.00))
        For each (Integer B) from 0 to 3, do (Actions)
            Boucle - Actions
                For each (Integer A) from 1 to 4, do (Actions)
                    Boucle - Actions
                        Unité - Create 1 Feu follet for Joueur 12 (Marron) at ((Position of Feu follet 0138 <gen> ) offset by (75.00 x (Real((Integer A)))) towards (90.00 x (Real((Integer B)))) degrees) facing Orientation bâtiment par défaut degrees
                        Groupe unité - Add (Last created unit) to units_lvl[2] //ne prêtez pas attention à cette action
                        Groupe unité - Add (Last created unit) to helice_wisp_lvl2
                        Unité - Set mana of (Last created unit) to (75.00 x (Real((Integer A)))) //le mana est ici utilisé comme une deuxième custom value
                        Unité - Set the custom value of (Last created unit) to (90 x (Integer B))
 
 
helice et cercle lvl 2 turning
    Evénements
        Temps - Every 0.02 seconds of game time
    Conditions
    Actions
        Set angle_helice_lvl2 = (angle_helice_lvl2 + 1.50)
        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            Si - Conditions
                angle_helice_lvl2 Supérieur ou égal à 360.00
            Alors - Actions
                Set angle_helice_lvl2 = (angle_helice_lvl2 - 360.00)
            Sinon - Actions
        Groupe unité - Pick every unit in helice_wisp_lvl2 and do (Actions)
            Boucle - Actions
                Unité - Move (Picked unit) instantly to ((Position of Feu follet 0138 <gen> ) offset by (Mana of (Picked unit)) towards (angle_helice_lvl2 + (Real((Custom value of (Picked unit))))) degrees)
 
 
J'aimerais savoir pourquoi il y a autant de fuites de mémoire et pourqoi le processeur est autant utilisé.
 
Sinon je pensais à une solution : stocker les différentes positions des wisps dans des variables de type point.
Ca ferait donc 4 * 360/1.5 = 960 variables (4 tableaux de 240 variables).
Il y aurait également un compteur allant de 0 à 239 et s'incrémentant 50 fois par seconde. (à chaque mouvement de wisp)
Ca me paraît beaucoup mais le processeur n'aurait rien à faire et il ne me paraît pas y avoir de fuite de mémoire de cette manière.
De plus si je ne me trompe pas, une variable de type point, c'est deux réels, donc ça prend peut de place ?

les leak viennent des points et des groupes unités, il faut les remove/destroy aprés utilisation
Ton délencheur est utilisé 50 fois par seconde    
Essaye 0.04 ca divise par 2 et l'effet devrait rester potable
 
PS : c'est qui le nom du boss en memory leak ?
 
Passe au jass pour cette fonction, le if/then/else/multiple fonctions crée plusieurs fonctions inutilement comme son nom l'indique.
La différence de performance est peu être trés légère mais comme c'est une boucle tu peux avoir un meilleur résultat
Ou tout simplement fait un if/then else unique, étant donné que tu n'as que 2 actions ( si true ou false) il n'y a pas de problème.
Même remarque pour le pick every.
Je sais c'est plus chiant à éditer aprés, mais de toute façon tu n'aimes pas le gui ....

0.04 c moche. Quant au memory leak je ne vois pas pkoi il y en aurait vu que les variables sont constantes. Si il y en a je ne vois pas ce qu'est le memory leak en fait. Je pense qu'ici les variables prennent de la mémoire mais qu'il n'y a pas de fuite de mémoire.

je ne programme pas mais je peux te dire que c'est une sombre histoire de pointeur.
Tout ce qui n'est pas réel,entier,boléen utilise une autre "variable" (désolé pour le terme) comme pointeur.
Si tu ne le remove/destroy pas elle continue à prendre de la place

Pour faire ces quatre variables il me faudrait un tableau à deux dimensions ça serait beaucoup plus facile à utiliser, mais je ne crois pas que c'est possible, si ?

Je sais bien qu'elle prend de la place, mais ça n'est pas très important. Le fait qu'elle prenne de la place n'est pas une fuite de mémoire mais une simple utilisation normale de la mémoire. Les fuites de mémoire, c'est quand la mémoire ne cessent d'être de plus en plus utilisée.

"Tout ce qui n'est pas réel,entier,boléen utilise une autre "variable" (désolé pour le terme) comme pointeur.  
Si tu ne le remove/destroy pas elle continue à prendre de la place"
 
Ok mais un point n'est pas simplement un couple de réels ?

Huh, je comprends pas. Juste pour 1000 petits points la map met 3 heures a se charger et ça remplit la mémoire. ON dirait que ça boucle à l'infini et que ça n'arrête pas de créer des points ! Au secours ! 565 mo de mémoire utilisée par war3! AHHHHHHHHHHHH 580 !!!!!!!!
 
 
edit :  
Ah non lol. C'est des unités qu'il me créait à l'infini :

 
J'ai oublié d'incrémenter i. Il ne devait pas y avoir de protection contre les boucles infinies ?

En théorie oui mais apparament non  
 
Pour les boucles infnies j'ai déja essayé, et la fonction fait un "return" si une boucle est infinie, la valeur maxi que peut durer une fonction sans compter les wait est de 1ms (Source : Ayane)
 
Maintenant tu n'as peut être pas le dernier patch ?

J'ai fini mes triggers mais les wisp restent tous au centre.  Voici mon code :
 

 
Là je ne vois vraiment pas où je me suis gourré .

J'ai le dernier patch je joue sur bnet xD. Comprends pas non plus pourquoi il a pas quitté la boucle.
 
 

 Tout dépend : grâce au GUI tu n'as pas sans arrêt besoin de chercher des fonctions ni non plus de te rappeler le nom de tes variables etc. Donc j'utilise le GUI le plus possible. Par contre je passe au JASS dès qu'il s'agit de copier une même action 10 fois avec un chiffre qui change (ex: set slide_j[1] = trg_slide_j1) ou dès que je veux faire un truc un peu poussé, ou encore éviter les fuites de mémoires pour les déclo qui sont exécutés souvent. Bref, environ la moitié du temps.

a mon avis la boucle a du être quitté, tant que tu y es teste en faisant apparaitre un texte message ,aprés la boucle et pendant la boucle.
C'est simplement qu'un grand nombre d'unité prend beaucoup en mémoire vive, à mon avis quelques centaines la mémoire vive doit dèjà le ressentir ...

omg ta signature >.<

Non la boucle n'a pas été quittée. La preuve la map se chargeait indéfinniment (est le chargement de la map correspond en partie aux déclo dont l'évènement est map init) en créant des unités et le processeur était à fond. La mémoire vive montait à la vitesse de plusieurs mo par seconde.

Je ne crois pas que tu gagnes énormément en performance en ayant créé au préalable des variables globales et en les indexant plutôt que de calculer les points à chaque fois.
Là je n'ai plus le temps mais si tu ne trouves pas tout seul ou si personne n'a pu t'aider, je jetterait un coup d'oeil plus attentif demain

Ben si justement, le processeur n'a plus rien à faire.
 
J'ai un peu réfléchi aux fuites de mémoire et je crois que j'ai compris. Si tu crées une variable globale point, que tu l'utilises une fois seulement et que tu ne la détruis pas, elle reste en mémoire. Et donc si tu en crées souvent tu perds de plus en plus de mémoire. Quant aux variables locales, elles sont détruites dès la sortie de la fonction, c'est pourquoi elle ne provoquent pas de fuites de mémoire. Il faudrait que Ayane me confirme ça .

Bon ben j'ai trouvé mes 2 erreurs :
 
_Il ne faut pas mettre Deg2Rad(angle) mais angle tout court.  (l. 11-14 de l'initialisation)
_ pour cette ligne là :
    call SetUnitPositionLoc( wisp, udg_helice_lvl_2_position_1[custom_value] )
ds les autres fonctions j'avais oublié de changer la variable :
udg_helice_lvl_2_position_2
udg_helice_lvl_2_position_3       (c'était resté avec un 1 partout)
puis udg_helice_lvl_2_position_4  
 
Donc maintenant ça fontionne. Quant au CPU, comme prévu, il ne fait aucun calcul (war3.exe prend 2% au total). Et la mémoire elle monte pas (je me demande si Ayane saurait nous trouver un déclo plus performant que ça). Comme je le disais c'est le fait de créer souvent des points sans les enlever qui provoque des fuites de mémoire. Hors j'ai créé des points au début et c'est tout. C'est cool je vais pouvoir faire autant d'hélices que je veux maintenant .
 

Apparemment le CPU lui, il est pas d'accord avec toi . (avant avec les 3 hélices tournant en même temps, war3.exe utilisait le CPU à plus de 30%)
 
 

Elle est bien hein ?
 
 
 
PS : je ne comprends toujours pas bien ce qui provoque les fuites de mémoires exactement (mais plutôt ce qui ne les provoque pas ^^)

Les fuites de mémoire, ça peut venir de deux choses :
-Soit une variable alloquées dynamiquement n'a pas été delete. Mais en générale, ça provoque une fuite de mémoire à la fin de programme, pas pendant.
 
-Soit tu dépasses la taille maximum d'un tableau. Par exemple, tu as un tableau arf[] de taille 14 et tu fais arf[16] = 3.

 
Je crois savoir qu'il n'aime pas DotA    Moi non plus d'ailleurs    

Ce que l'on appelle une fuite de mémoire ce sont des "objets" qui ont été crées mais ne sont plus utilisées et continuent à occuper de la mémoire inutilement.
donc lorsque tu crées des points (variable locale ou non), lorsque tu fais un pick every cela créé un groupe non supprimé aprés utilisation, etc.
Pour les groupes tu peux rajouter le custom script set bj_wantDestroyGroup=true juste avant la fonction
lorqu'une fonction en gui est utilisée elle remet cette variable globale à false, et si elle était à true elle suprime le groupe ainsi créé
 
sinon intéressant à savoir pour le processeur

Non c'est faux. Un pick evey prend un groupe en paramètre mais ne crée pas de groupe. Quant à wantDestroyGroup, il sert lorsqu'il est à true, à détruire le groupe pris en paramètre de la fonction. En voici la preuve :

Tu as donc raison quant au custom script set_bj_wantDestroyGroup = true à placer avant le pick every.
Si l'on ne veut pas détruire le groupe, il vaut mieux utiliser ForGroup et non ForGroupBJ (je vais changer ça dans ma fonction), pour éviter un if false then.......endif inutile à chaque fois.
 

 
Tes deux choses sont en fait les mêmes puisque le dépassement d'un tableau provoque l'allocation d'une variable. Sinon je ne vois pas pourquoi le fait qu'une variable soit créée dynamiquement provoquerait une fuite de mémoire et n'en provequerait pas si elle était créée normalement.
Je réappuie mon avis la dessus : c'est la création régulière de variables (quelles quelles soient) utilisées juste après leur création mais non par la suite, sans être supprimées, qui provoquent des fuites de mémoire. Enfin qu'on le fasse régulièrement ou non, c'est une fuite de mémoire, mais celle que l'on sent dans le jeu, c'est la fuite régulière. Ce que j'aimerais savoir, c'est quoi d'autre provoque des fuites.
 
PS: il ne faut pas confondre fuite de mémoire (non suppression d'une variable qui ne sera plus jamais utilisée) et utilisation normale de la mémoire (création d'une variable qui sera utilisée longtemps (jusqu'à sa suppression ou la fin du jeu) : avec allocation dynamique ou non).

Une fois que je n'ai plus besoin de mon hélice, je fais ceci :

Je me demande s'il existe un moyen de supprimer chacune de ces variables directement sans avoir à le faire point par point, ce qui serait beaucoup plus rapide à l'exécution.

 
 
C'est uniquement si elle n'est pas delete apres (je parle en C++...).
 
Dans le C++, tu fais :
 

La ou ça provoque une fuite de mémoire, c'est si tu fais
 

 
La 800 creep ne sont pas supprimés, prennent de la place en mémoire et provoque un ramage si la classe prend beaucoup de place en mémoire.
 

Mais si tu les utilises tes 800 creeps, ça n'est pas une fuite de mémoire.  
Tu crées tes maps en C++ ?

 
Oui c'est vrai mais ce que je voulais dire c'est un exemple de ce type :
 

 
un groupe est créé : GetUnitsInRectAll(GetPlayableMapRect())
 
sinon pour les memory leak tu as tout à fait raison

 
 
Non, en fait mon exemple est mal placé, ce que je voulais dire c'est que si à chaque frame tu créer une nouvelle creep, mais que tu la delete jamais, ben à chaque frame ton programme prend un peu plus de place, et pour finir fait planter le jeu.
 
Les maps je les créer pas en C++, mais par contre j'ai d'autre projets annexes que je code en C++.

 
J'ai créé un trigger de test pour vérifier ceci :

En effet, cela provoque une fuite de mémoire de pratiquement 1 mo/s (il y a environ 50 unités dans 'Region 000').
 
Je rajoute la mise à true de want destroy group :

Il y a beacoup moins de fuites de mémoires, mais il y en a toujours. (env 1mo en un peu moins de dix secondes)
Cette fuite de mémoire vient bien de ce trigger puisque lorsque je le désactive, il n'y a plus aucune fuite. Mais d'où exactement ?
 

Essaie de désactiver toutes les actions/toutes les conditions dans ton pick Every Unit pour voir ?

pas con

Sinon j'aimerais savoir ce qui est le plus rapide à l'exécution, entre pause (resp. unpause) unit et hide (resp. unhide) unit.

La difference doit etre negligeable, non?  
Pourquoi as-tu besoin de savoir ca ?

J'ai besoin de savoir ça parce que je veux cacher ou mettre en pause les monstres des niveaux suivants, pour éviter qu'ils attaquent les persos. (c ds un escape) Et ça fait beaucoup d'unités à réactiver en même temps.

[éclair de génie] Ce n'est pas un leak mais juste une utilisation normale de la mémoire elle n'a tout simplement pas le temps d'être libérée, essaye avec un événement moins fréquent ou avec moins d'unité tu verras[/cerveau grillé]

 
utilise ce que j'ai dit precédement fait une boucle 0.00 et beaucoup d'unités avec pour action hide/unhide, regarde la vitesse à laquelle la mémoire se remplit, puis avec pause/reprendre et compare les résultats    
 

Je ne parle pas de la mémoire, je c kil n'y a pas de leak ici. De toute façon c'est une action qui s'effectue une fois en cours de jeu. Je parle du temps d'exécution, pour éviter les désynchronisation entre les joueurs.

et bien au plus la memoire allouée sera grande au plus la fonction est lente non ?

Même s'il n'y a aucune fuite de mémoire, toute action a forcément un temps d'exécution...

sans blague ..
Enfn ce que je voulas dire c'est que pour moi la vitesse interessante est celle à laquelle la fonction libérera la mémoire , néammoins il est vrai que celle de son éxécution est importante aussi
M'enfin je me disais peut être existe t'il un lien entre ces 2 temps, voir la même valeur
 

Sa doit être un truc du genre une droite affine : temps d'exécution de la fonction + cte * le leak ^^ xD