Je tate la version 2 de GD, et je tombe sur un crash assez fréquent :
J’ouvre ma scene
Je me mets en prévisu de celle-ci
Je lance la prévisu
Je veux revenir à l’édition, je clique sur le bouton Edition de scène
Crash C++
Ce problème apparait moins souvent si je clique d’abord sur les flèches de rafraichissement (afin de recharger la scene de prévisu, et donc arrêter la prévisu en cours).
Au passage, y-a-t-il une méthode pour enchainer facilement sauvegarde → prévisu de la scène → Edition de la scène ?
Ce serait plus rapide si le bouton de sauvegarde de projet était accessible à tout moment, sans avoir à repasser par le menu Projet (pour ensuite repasser par le menu Scene).
J’imagine que c’est lié à la taille des images utilisées (1024x768 en png RGBA).
A partir d’un certain poids, le moteur de compilation doit s’emmêler les pinceaux.
Testée sur une scène vide avec des astéroides en rotation (5 à 6 en même temps, image fixe, échelle de sprite modifié par les évènements).
Ca se produit de façon aléatoire, mais surtout si je ne clique pas sur “rafraichir” avant de cliquer sur “Edition”.
C’est bon à savoir.
Au passage …
C’est quoi l’équivalent du modulo sous GD2 ?
Le classique “%” n’est pas reconnu par l’éditeur d’expression. Il n’accepte que le div “/”.
Je suis pas convaincu que ça vienne de là, une fois la scène lancée la compilation n’intervient plus, et la compilation est totalement agnostique vis à vis des images utilisées.
Je viens de me rendre compte que GD2 me bouffait 1.5 Go en mémoire vive, même à partir d’une scène vierge.
Je suis en train de tester à partir d’un projet vierge, pour voir ce qui déclenche ce besoin en megaoctets.
Le souci ne vient pas du lancement de la scène, mais du retour à l’édition après celle-ci (édition → prévisu → édition [crash] ).
Au moment où GD passe du mode prévisu en fenêtre vers le plein écran de l’édition.
Le test à partie d’un projet vierge ne révèle pas d’explosion de la conso mémoire.
C’est donc propre à mon projet.
Quand j’observe mon projet, je remarque que :
lorsque je passe de Edition à prévisu, la conso mémoire augmente
lorsque je passe de prévisu à édition, la conso mémoire augmente
Or, si je compare avec ce qui se passe avec un projet vierge, une fois repassé à l’édition, la conso mémoire devrait diminuer.
Dans mon projet, elle augmente de 100 Mo mini à chaque va et vient.
On dirait que GD2 n’arrive pas à faire le ménage lors de la fin de la prévisu, et garde en mémoire les prévisu précédentes (d’où une consommation exponentielle de mémoire vive).
J’ai désactivé les extensions dont je ne me servais pas (au cas où). Mais le problème demeure …
Je précise que je teste mon projet sur une nouvelle scène vierge, avec deux évènements et deux objets (un sprite et un particule).
Aucun lien vers des évènements externes ou des objets sprite maousse.
Je suppose que lorsque GD2 ouvre une scène, il ne charge pas autre chose. Ici, ça me fait l’effet que toutes mes scènes sont ouvertes en même temps.
[spoiler]Sinon, rien sur l’operateur modulo dans l’éditeur d’expression ?
C’est mignon le div, mais le modulo aussi est bien sympa … [/spoiler]
Y a t il moyen que tu me passe le fichier de jeu ? Pour voir si j’ai aussi la fuite de mémoire.
De mon coté, j’en ai trouvé une, je ne sais pas si elle est liée, mais je vais la corriger : viewtopic.php?f=5&t=2890
Bon, je viens de tester chez moi, sur un i3 avec une nVidia 1Go derrière.
Je ne rencontre plus ce problème de fuite mémoire.
J’ai aussi vérifié que tous les objets nommés dans les évènements externes avaient bien leur équivalent dans la liste d’objets globaux.
Je réessaierai plus tard sur le i3 avec Intel HD.
C’est peut être un problème lié aux cartes graphiques bas de gamme …
En revanche, ça crashe toujours autant lorsque je passe direct de Prévisu à Edition, sans cliquer sur Rafraichir.
Ok pour la fuite de mémoire, je pense dans ce cas que c’est dû à la carte graphique Intel en question : Peut être mettre à jour les drivers corrigerait le problème ?
Ça crashe aussi avec un jeu vierge ou ça semble dû à ton projet ?
La carte graphique a déjà été mise à jour il y a un mois. Car elle ramait à mort avec Blender (notamment en Edit mode où c’était un vrai festival de lag).
Elle semble très mal gérer tout ce qui est OpenGL.
La dernière mise à jour a réglé ce souci de performance. Et je n’ai plus remarqué de problème depuis.
A noter néanmoins, Unity3D crache aussi pas mal (au bout d’une heure d’utilisation en général). Je rencontre moins ce problème avec les nVidia, même si le crash finit par survenir.
C’est vrai que la cause pourrait être commune à Unity et GD …
Non, c’est lié à mon projet. Comparé à un projet vierge, le temps de latence entre le moment où je clique sur Edition et où je repasse effectivement en mode Edition, il s’écoule 5 secondes mini.
Vu que mon projet bouffe 300Mo en mémoire vive mini, je suppose qu’il pousse GD assez loin (fichier de projet = 3 Mo). Je travaille également sur clé USB, ce qui peut impacter les temps de réponse.
Pour info, c’est une Kingston Data Traveller 410 de 32 Go (un modèle plus rapide que les clés USB classiques, et bien plus fiable ).
Toujours avec ce plantage, cette fois même quand je reste dans l’éditeur d’évènement. La conso mémoire enfle jusqu’à ce que Windows tire la gueule.
A priori résolu dans la version à venir.
Mais au cas où, voilà du neuf. Des captures d’écran d’un bug de WxWidgets.
A noter que l’image recensée ici n’est pas présente dans la scène, seulement dans les objets globaux (et encore, en tant qu’image de particules) non instantiés dans la scène.
A voir si c’est facilement corrigeable, déjà corrigé ou GCpa.
Le dernier message signale “file is corrupted or not enough memory”. Je pense pour la deuxième hypothèse vu qu’actuellement GD gobe de la mémoire à tout va, ce qui fait que ce bug n’est qu’un “dommage collatéral” du manque de mémoire.