Je suis de retour (une nouvelle fois) pour vous signaler la présence d’un bug très énervant, ce bug je l’ai appelé le bug noir.
Ca s’est produit pour la première fois le 18 Octobre 2013. Mon système d’exploitation est Windows 7, 32 bits si ça peut aider.
J’étais sur mon projet en train de faire des modifications importantes, quand tout à coup, Game Develop a cessé de
fonctionner. (c’est mon Windows 7 qui m’en a informé)
Ce n’est pas la première fois que ça m’arrive. Ca m’est arrivé plein d’autres fois, même avec mon ancien Windows XP.
J’ai appelé ce bug “le bug noir” parce qu’il intervient n’importe quand, en bref il est PRESQUE imprévisible. Heureusement, je connais les recoins du logiciel où ce “bug noir” apparaît.
Il intervient généralement dans la fenêtre d’édition des sprites, lorsqu’on met une image un peu grande (la taille d’un logo au moins, ou d’un arrière plan) ou alors d’un format bien précis (généralement le .gif non animé et parfois même le .png). Il apparaît aussi lorsqu’on teste une scène, si il y a un évènement qui va mal, tout bugue et Game Develop plante.
Pour pouvoir mieux utiliser la fenêtre d’éditions des sprites, j’ai utilisé une technique ancestrale, utilisée depuis des millénaires, la plus efficace et la plus puissante de toutes quand il s’agit de programmes… Elle s’appele : 'Copie toutes les données que tu peux, fais un autre fichier et colle-les dedans".
Il s’avère que ça a marché, mais hélas la faille de l’éditeur de sprites est revenue, cependant bien que moins efficace que dans l’ancien projet.
Je vous prie d’essayer de remédier au plus vite avec ce “bug noir”, car comme je l’ai dit plus haut,
ce bug pourrait rendre Game Develop moins fiable qu’avant, or pourtant je sais que ce logiciel est très prometteur, donc il
serait dommager de le gâcher en ne corrigeant pas ses défauts.
“Bug noir” ou pas, la technique pour que je corrige un bug est toujours la même :
Quand tu a un jeu pour lequel faire une manipulation plante le programme, envoie moi le fichier du jeu ( avec quelques images si nécessaire ) par mail et décrit moi comment reproduire le bug ( la suite des manipulations précises à faire ).
Normalement, je peux corriger tous les bugs de façon assez rapide comme ça, plutôt que de chercher pendant des heures un bug où je ne sais même pas par où commencer
Je préfère recourir à une compétence encore plus ancienne, héritée de nos lointains ancêtres à OS monotâche : je fais un “enregistrer le projet” avant chaque aperçu, et à chaque grosse modif des évènements (toutes les 2 minutes quoi).
Il m’arrive que GD plante, en général parce que le cc1plus s’emmele les pinceaux et crashe.
Dans ton cas, vérifies son comportement dans le gestionnaire des taches. S’il bouffe tes ressources système, c’est qu’il y a un souci.
Ca peut être une image foireuse (png ou jpg uniquement, faible dpi, faible résolution) ou une instruction mal écrite (“00” au lieu de “0”, une valeur manquante, un objet mal écrit, une boucle infinie, etc. ).
Dernier coupable, ton disque dur ou ta mémoire vive qui commencent à lacher.
Merci de m’avoir répondu. Par contre je ne pense pas avoir besoin de t’envoyer le fichier de mon jeu, car en fait je ne pense pas que ça ait un rapport avec lui ; ce bug intervient avec à peu près tous mes projets ! Si tu as vraiment besoin d’un de de mes jeux je t’en passerais la copie, mais je pense que ça a surtout un rapport avec Game Develop.
Oui, moi aussi j’utilise cette technique. Cependant, nous ne sommes pas sur la même longueur d’onde, car cette technique, je l’utilise pour éviter le simple crash.
La technique que j’ai utilisé (celle que j’ai baptisé “CTLDQTPFUAFECLD”) était en quelque sorte pour calmer ce ‘bug noir’ car l’ancien projet que j’utilisais était en quelque sorte “contaminé” par ce bug noir. Il a fallu que j’utilise la technique dont vous connaissez le nom pour calmer ce bug et le rendre moins fréquent. Cependant, ça ne l’a pas éliminé.
Je n’utilise pas vraiment le C++ dans Game Develop bien que je sois en train de l’apprendre, je n’y vois pas d’utilité pour mes projets pour le moment.
Son repère est bien “gd.exe” dans le Gestionnaire des Tâches, je me trompe ?
Par “bouffer mes ressources systèmes”, que veux-tu dire ? Game Develop n’est pas censé utiliser mes ressources système ?
Oui, ça peut être aussi le disque dur/la mémoire vive qui commencent à lâcher car mon ordinateur est tout sauf une bête de course technologique quelque soit la matière.
Personne n’utilise le C++. En réalité, c’est une légende urbaine, pour faire peur aux non-programmeurs et pour pécho en soirée ultra-select sous l’appellation “soirée compil”.
Plus sérieusement, de ce j’en ai compris, GD utilise deux processus : gdide.exe, qui est l’éditeur, et cc1plus.exe, qui sert à compiler les scènes en arrière plan. Son rôle est de faire gagner du temps lors des aperçus, en préparant à l’avance les scènes. Quand il y a peu de scènes, peu de ressources visuelles, et que les évènements ne sont pas foireux, ça améliore les perfs du logiciel. Mais si on cumule les opposés (plein de scènes + grosses ressources + algo pourri), on se retrouve avec un cc1plus qui mouline, plante, et repop à nouveau. Tout cela en boucle, jusqu’à ce que gdide plante à son tour.
Si ton projet est dans ce cas (regarde les tâches pour voir comment se comporte gdide.exe et cc1plus.exe), tu dois diminuer ton nombre de scènes, diminuer la taille de tes ressources et/ou retourner à l’école des programmeurs.
Reste le 4 : fermer et ouvrir GD à chaque modif pour espérer travailler sans plantage.