Est-ce que la condition : “objet” est invisible, permet de sélectionner les objets hors du champ de la caméra ?
Sinon est-il possible de suprimer les objets qui sortent du champs de la caméra sans mettre un test de collision hors-champ ?
Je cherche à réduire les collisions, et ainsi le lag aprés un certain niveau de jeu où les tests de collisions sont déja nombreux.
Ou encore, est-il nécessaire, pour améliorer les performances de mon jeu (type arcade) de supprimer les nombreux objets qui passent hors champ (si les tests de collision se font aussi hors champs, alors la réponse est évidente; oui…)?
Rendre un objet invisible ne permet pas de le supprimer, ni de libérer de la mémoire, ça le rends juste invisible.
Collision du champ de la caméra: Mauvaise idée.
Met plutôt un petit objet caméra (ou la caméra sera centrée dessus…)
Tu fait:
Si la distance entre “objet” et “camera” est supérieure a “Taille de ton écran en X *1.5 (Résolution du jeu)”, supprimer “objet”
Dans le même genre:
Crée un groupe “objet” dans lequel tu met tous les objets qui sont susceptibles d’êtres supprimés si ils sortent…, tu n’auras qu’un seul test de distance a faire.
Voila
Merci pour ta réponse, mais elle répond pas à ma question principale (dsl) :
l’idée du test de distance est pas mal mais consommera autant qu’un test de collision avec un objet hors-champ…
J’ai du mal m’exprimer, donc j’essaye d’etre plus clair
J’ai des objets qui sortent du champs de la caméra (que j’ai pris soin de mettre dans un groupe “projectiles”).
J’ai des évènements qui testent les collisions entre différents objet du groupe “projectiles”.
problèmes :
J’ai une perte de performance au bout d’un certain temps.
solutions :
1- Je teste les collisions du groupe “projectile” avec un objet “test” placé hors-champ.
→ Mais ça réduit aussi les performances.
2- Je teste la distance entre “caméra” et “projectile”.
→ Mais ca revient à faire autant de calculs que ma solution 1, et donc réduit aussi les performances.
3- Je suprime les objets du groupe “projectile” qui sont invisible.
→ Mais là je sais pas si ça supprime effectivement les “projectiles” hors-champs.
D’où ma question !
J’espère avoir était assez explicite et merci quand même Crone pour ta réponse.
EDIT : J’ai ma solution !
Je fais simplement un test de position sur l’axe Y; si positionY() de “projectile” >600 ou <0, suprimer “projectile”.
Les performances sont ainsi amélioré !
Merci Crone tu m’as mis sur la bonne voie !
Au contraire, c’est probablement une des meilleurs solutions.
La meilleure est de tester la position comme tu l’a fait si le test est assez trivial, genre justement tester la position Y.
Si les projectiles peuvent partir n’importe comment, alors un test de distance, même si ça donne un cercle, est sans doute une des meilleurs option, et est beaucoup plus efficaces qu’un test de collision qui fait intervenir plus de calculs.
La méthode du cercle de distance est aussi celle que j’emploie pour faire le ménage dans mes projectiles, et ça marche très bien.
Je m’en sers aussi pour repositionner les ennemis quand ils sont trop loin.
Ca évite d’en recréer une palanquée parce qu’ils ne sont pas à proximité du joueur.
Tes problèmes de perf peuvent venir d’ailleurs :
Des objets Particules qui n’ont plus de particules mais qui ne sont pas supprimés.
Des tests effectués tous les 100eme de secondes alors qu’une fois par seconde suffirait
Des objets ennemis qui sont consommés, mais pas supprimés (et qui du coup s’accumulent)
Des effets visuels lourds (pleins de trucs en rotation+zoom)
Une mauvaise utilisation de l’opération “Duplication d’objets”
Des ressources graphiques et sonores trop lourdes (ça bouffe, ces machins là)
Ca fait deux tests au lieu d’un dans la méthode du cercle.
4 avec le test sur l’axe X.
Et ça ne marchera que si le joueur est dans un écran fixe.
Dans un jeu à scrolling, il faudra prendre en compte la position du joueur dans l’aire du jeu, et sa vitesse de déplacement.
Je pense que non; car dans la méthode du cercle il faut tester la valeur de X et de Y pour connaitre la position du projectile…
Donc je pense que faire deux tests sur Y ou faire un test sur X et Y, ça revient au même !
Mes projectiles ne sortent que par le haut ou le bas de l’écran (qui est fixe) avec un angle max de 10°… Dans mon cas les deux méthodes sont équivalentes en performance: J’ai sortit le jeu avec les deux méthodes et mon compteur fps varie dans les deux cas entre 52 et 54 fps…
Donc dans mon cas je vais préféré la méthode du test de Y (Ca m’évite de créer un objet pour tester la distance autour de ce dernier)…
Mais en général je suis d’accord pour dire que la méthode du cercle est la meilleure…
Bref, vous arrivez à la conclusion bien connue des programmeurs :
L’optimisation prématurée est la source de tous les maux.
C’est à dire que se casser la tête sur utiliser un test de distance ou un test X/Y est :
-Une perte de temps, car les différences entre les deux sont ridicules par rapport à un test de collision.
-Même pas à faire car suivant l’implémentation, et les optimisations effectuées par le compilateur, optimisations dont je suis moi même pas forcément au courant, on peut alors avoir une version plus rapide alors que “Pourtant je pensais que non”. Inversement, vice versa, le contraire, ou l’opposé, bref, de “si petites” optimisations peuvent varier très rapidement et devenir des contres optimisations.
Une seconde règle bien connue est alors de n’optimiser que quand on rencontre des problèmes de performances, ( Dans ton cas par exemple ). Dans ce cas, il ne faut pas forcément se focaliser sur des petites optimisations insignifiantes et mêmes pas forcément sures d’être des optimisations, mais sur la façon globale dont les choses sont gérés, par exemple passer d’un test de collision précis à un simple test de distance, ou supprimer plus rapidement certains choses, ou ce genre de trucs.
Dernier conseil connu en programmation, adopter certaines bonnes techniques si l’on sait qu’elle sont plus efficaces, par exemple ajouter directement un évènement pour supprimer les projectiles trop éloignés plutot que de le rajouter après, car on sait très bien que ça va coincer au bout d’un moment.
Mais encore une fois, l’optimisation ici n’est pas de se battre entre choisir un test de distance ou un/deux tests de position.
