petites questions d'optimisation

[Sylnade]

Il arrive que certains test soient appelés un certain nombre de fois, par exemple lorsque l'on veut tirer parti du masque de collision il se peut qu'au cours de la boucle principale un pixel (disons celui de la position du joueur) soit testé plusieurs fois.
à ce moment là est-ce que ça vaut la peine de faire une seule fois le test, de "stocker" la réponse dans un drapeau et d'utiliser ce drapeau par la suite?
par exemple:

toujours
-> désactiver drapeau 0

CollisionMask( X("personnage") ; Y("personnage") )est un décor
-> activer drapeau 0

// par la suite lorsque l'on veut tester si le perso touche le sol on teste uniquement le drapeau 0

un autre exemple serait avec les calculs de trigonométrie (dans les jeux de tir particulièrement)
toujours
-> fixer var_cos à cos(angle_joueur)
-> fixer var_sin à sin(angle_joueur)

// ne plus recalculer le cosinus ou le sinus de l'angle en faisant appel aux variables var_cos et var_sin

il y a surement de nombreux exemples mais est ce que c'est utile?

si oui, quelles sont les conditions et expressions les plus lourdes que l'on pourrait moins utiliser par ce genre de procédés?

merci d'avance

[Francois]

Le plus simple est de faire une application dans laquelle tu fixe la vitesse (FPS) à beaucoup, genre 1000. Tu mets un compteur qui affiche le nombre de frame par seconde (une expression dans l'objet Storyboard). Tu fais l'essai avec et l'essai sans et tu compares. Je ne pense pas qu'il y ait une grosse difference.

[Sylnade]

oui en effet (désolé)
je viens de faire un test avec le collision mask,le gain de temps est négligeable
avec les calculs trigonométriques le clalcul est lui même négligeable (exécuté 1000 fois par boucle j'ai le même framerate que s'il n'est pas exécuté dutout...)

dans ce cas quelles sont les opérations gourmandes en temps ? (j'ai commencé une série de tests, céer puis détruire un objet est nettement plus long que faire un test du type collision mask (pas étonnant d'ailleurs) 200 opérations de ce genre par boucles commencent à faire baisser le frame rate d'une appli initialement en 60fps ne faisant que ça)

mes questions paraissent surement inutiles mais je pense qu'on gagnerait à faire attention à ce genre de détails dans certains cas (par exemple j'ai l'habitude de créer à chaque frame des objets actifs que j'utilise comme détecteurs et je les détruis tout de suite après, c'est peut être pas une bonne methode...)

[Gawen]

En fait, c'est quelque chose d'assez général en programmation (et même si on la voit pas, elle existe aussi dans MMF en arrière-tâche) : les opérations élémentaires vraiment lourdes sont celles qui allouent ou désallouent de la mémoire. Créer ou supprimer un objet entre exactement dans ce cas.

[Sphax]

Oui mais il pourrait être intéressant de faire ressortir les actions/conditions/expressions consommant plus ou moins de calcul CPU. Ca aiderait pour les optimisations et les choix de développement.

[Francois]

Les collisions sont les conditions qui consomment le plus, surtout si tu as plein de sprites à l'ecran.
Creer / detruire un objet prend du temps.
Sinon, le reste va plutot rapidement.

[Sphax]

Tu parles de la condition "object overlapping ..." ou de l'événement "object collides with ..." ?
L'événement de test de collision est toujours fait non ? Donc logiquement ça ne consomme rien ?
Est-ce que le test sur le masque de collision consomme aussi beaucoup ?

[Yves]

Le test sur le masque de collision ne consomme pas beaucoup sauf s'il y a plusieurs layers.