J’ai un réel souci avec le jeu que j’ai fait pour les novendiales (je l’avait déjà sur mon début d’autre jeu mais j’ai pas fait le max d’améliorations).
Et là je coince, et ça le fait pas trop de filer un jeu dans ses travaux qui à des problèmes de perfs
Pas besoin de beaucoup de vaisseau, sur la scène de jeu, au tout début, il ne peut y avoir plus de 50 vaisseaux ennemis (3 image d’animations), il y a 38 sprites a 2 images d’animation plus le vaisseau du joueur, le curseur, la jauge d’énergie et le cadre de cette jauge, le pourcentage d’énergie affiché en texte, le score et le nombre de S.E.C récupérés /38
Au début tout va bien mais si on attend 5 minute (voir moins même) on sent déjà que il y à un problème de fps (enfin dans l’éditeur il voit pas de chute de fps mais réellement ien a ^^)
Chaque vaisseau ennemis a 2 variables, qui se renouvelle automatiquement afin d’indiquer une position aléatoire vers laquelle se diriger
Et il y a un chrono qui se lance pour faire apparaitre les vaisseau au maximum de 50 (puis il se met en pause)
Evidemment quand il y a beaucoup de vaisseaux, le problème se ressent très vite.
Faut que je trouve une solution avant ce soir sinon ça va pas le faire
Merci d’avance.
-Vérifie si tu as ce problème avec un jeu compilé.
-Peux tu voir si les performance chute si tu désactive le suivi de performances ( Utilise alors un logiciel comme Fraps ) ?
-Si tu repasse en mode édition et que tu repasse en mode aperçu, est ce que les performances redeviennent normales ?
Quelle est la taille des fichiers image des sprites ?
S’il y en a 50 à l’écran, ils ne doivent pas excéder la dizaine de Ko.
Sinon, les problèmes peuvent survenir.
Y-a-t-il une action 'Dupliquer un objet" dans la scène ?
Faut faire gaffe avec ça.
Car un objet dupliqué sera dupliqué à son tour par cette même action.
On obtient donc rapidement 2^infini dans un évènement classique.
Diminuer le nombre de sprites à l’écran
Moins de sprites, moins de calculs de collision et autres.
Qu’il y en ait 50 ou 40 ne devrait pas changer grand chose pour le joueur.
Rajoute un chrono de cadençage global
Copie/colle tous les évènements de la scène dans un évènement externe, crée un évènement dans ta scène “Si chronomètre GlobalCooldown > 0.01 : remettre GlobalCooldown à zéro”, et mets en sous-évènement le lien vers l’évènement externe où se trouve les évènements de la scène.
Comme ça, tu obliges GD à faire les vérif tous les dixièmes de seconde, ça devrait être invisible aux yeux humains, mais ça soulagera le proc sur la durée.
Y-a-t-il des émetteurs de particules dans la scène ?
Je sais que dans la mienne, un lag apparait au bout de 30 secondes, puis disparait lorsque j’arrête mon vaisseau (son réacteur n’émet plus de particules).
Je précise que je supprime les objets particule dès qu’ils sont vides. Mais ça n’empêche pas GD de ramer tant qu’il reste un émetteur actif.
Je ne me suis pas encore sérieusement penché sur le problème … mais je crois savoir d’où ça vient.
Moralité : eXtreme Programming
On ne passe pas à l’étape suivante tant que l’étape actuelle n’est pas finalisée et optimisée.
C’est toujours plus simple d’améliorer un petit code qu’un gros.
Donc, toujours optimisé un algo avant passer à la suite.
Alors les sprite, font tous moins de 100 par 100 px, à par les image qui servent à flasher l’écran (1920.1080) mais c’est juste une image blanche et le fond (4000 par 4000) que j’ai allégé au max (8 Mo au lieu de 40 )
Le truc c’est que ce fond reste fixe, aucune interaction avant pendant après, il est là il y reste.
Pas de duplication, particule, collision, automatisme ou autre, on est vraiment sur un truc basique.
Essayez le jeu non ? (partie jeu terminé mais ça a pas l’air beaucoup visité )
Tout est déjà sous chrono, chaque action (à par les affichage du texte à l’écran et la jauge d’énergie ainsi que le centrage de la caméra, bref tout ce qui touche à l’interface ne contient pas de chrono et sont des évènement sans conditions (excepté ceux qui doivent s’effectuer durant un moment à la place d’un autre mais ça comporte juste le décompte des secondes)
Je compte uploader le programme en rentrant (juste les “codes” afin de nourrir un peu l’aide à la communauté on va dire, je penses que comme ça vous serez en meilleur posture pour m’aider
Bon ben, cherche pas plus loin.
Tu demandes à GD de rafraichir 1000 fois par seconde l’interface, alors que le joueur n’en a besoin sur toutes les 0.5 secondes.
Calculs supplémentaires inutiles.
Centrage caméra aussi. Un chrono à 0.01 secondes devrait faire illusion. Et le proc te dira merci.
L’image blanche de 8 Mo, c’est pas bon.
Colle-là en JPG, on verra pas la différence, et ça tiendra sur moins de 100 ko.
Tu peux aussi coller la couleur de fond de la scène à “Blanc” (propriétés de la scène).
Ca fait pareil, et pas d’image à fournir.
Mets le lien de tes projets en signature.
Ca évite de chercher pendant des plombes.
Non, non, non, non, ne bidouillez pas vos jeux avec d’affreux chronos : La limitation d’images par seconde est déjà fait pour ça. Comment ça marche ? Ça endort le programme le temps qu’il faut pour éviter justement de faire surchauffer votre processeur si vous n’avez pas besoin de 2500 images par secondes.
Vraiment, vous avez pas besoin de vous embêter avec des chronos. La limitation d’images par secondes configurable dans les propriétés du jeu est déjà fait pour ça.
Et au pire, si vous limitez pas le nombre d’images par secondes, votre PC travaillera plus, mais c’est pas pour ça que le jeu ralentira. C’est juste que le jeu prendra tout le processeur pour soit.
J’ai essayé le jeu hier soir. J’ai du y jouer 2 minutes, je vais le relancer pour voir.
Ton problème est de savoir d’où vient la chute de performance.
Avec un chrono, tu isoles une partie de tes évènements, en les forçant à s’enclencher toutes les secondes (par exemple)au lieu de tous les millièmes de seconde, sans les désactiver pour autant.
Ca peut te permettre d’identifier quelle partie de ton code provoque les ralentissements.
C’est assez rapide à mettre en oeuvre si tu as construit ta scène avec des évènements externes.
Sinon, ça va être chiant de copier/coller tous les évènements un par un dans l’évènement Chrono.
J’ai quand même pas compris où mettre les chrono de façon à ce que je comprenne d’où vienne la chute de performance.
Et puis, lorsque on supprime otut les enemis sur la scène (car ça lag que si on garde les même ennemis longtemps) ben ça lag plus, même si il y a 200 ennemis (mais ça viens plus vite quand il y a 200 ennemis)
En gros je simplifie.
Tu prend ton personnage, tu lui met 20 autre perso “IA” autour, pendant les 5 première minute pas de souci, mais les performances chutes doucement, sans qu’aucun changement ne se produise.
Supprime les 20 IA et refais en 20, ça va plus lagger puis revenir au bout d’un certain temps.
Comme si dans le temps, une IA occupait plus d’espace mémoire.
Bah ça vient sûrement du problème de particules qu’évoquait mtarzaim, à savoir que le jeu finit par lagguer tant qu’un émetteur de particules est sur la scène (même s’il n’émet plus rien).
Sauf que ça ne marche pas … Enfin, la dernière fois où je l’ai essayé (avant la nouvelle version).
Car tant qu’une instance de l’objet émet des particules, tous les autres ne sont pas prises en compte dans la condition.
Enfin, c’est l’impression que j’avais.
Idem pour les objets classiques.
Si je mets “Opacite de machin == 0 → supprimer objet machin”, ca ne marche pas tant qu’il reste une instance d’objet dont l’opacité est > à 0.
Là encore, c’était le cas dans la version de GD précédente, je ne l’ai pas retesté avec la version actuelle.
Pas très grave pour moi, car la session de jeu est limitée.
Le temps que le lag devienne trop important, le joueur aura déjà changé de scène.
Mais c’est quand même ennuyeux s’il faut créer des objets différents avec le même sprite …
Euh, attention à ne pas voir des bugs là où il n’y en a pas.
Ça fait des lustres, depuis la première version en fait, que Game Develop va analyser les conditions pour chaque objet et choisir seulement ceux qui remplissent la condition.
Je ne dis pas que le programme est infaillible, mais enfin là c’est quand même la base du fonctionnement des évènements : Si tu n’est pas convaincu, fais un petit jeu avec un sprite, place en 4 ou 5 à différents endroits sur la scène et fait par exemple :
Condition : la position X de TonObjet est < à 250 pixels
Action : Supprimer TonObjet
Tu verra que les objets dont la position X est inférieure à 250 pixels sont bien supprimés.
Vraiment, je suis ouvert à tout rapport de bug, mais vérifiez quand même ce que vous dites avec un petit jeu avant de dire que GD ne va pas prendre en compte les objets tant que tous ne remplissent pas la condition…
J’ai testé, premièrement avec le suivi de performance activé. Il semble qu’il y ait dans le suivi de performances un petit soucis, car les performances se dégradent au fil du temps. J’ai testé, ça le fait même sur un jeu vide.
J’ai ensuite testé ton jeu normalement : Je l’ai lancé dans l’éditeur et attendu un bon moment ( sans y jouer du tout ) : Pas de perte de performances à priori…
)
)
) à un moment pour reramer par la suite ?)