Dans ce cas, pas d’hésitation : Envoie moi le jeu (compilé et/ou les sources) et je vais voir en même temps que le jeu de mtarzaim 
Je transfère ça par FTP, ça va prendre un peu de temps, vu que je n’ai plus de connexion internet (je partage ma connexion avec mon téléphone, je suis donc en 3G, et c’est dur 
).
Après 34245 transferts, voici enfin le lien des sources ! (ouf ! 
) : blady.fr/am/AstralMasane-Sources.zip
mtarzaim j’ai en effet la fuite de mémoire lors de la compilation (sur Windows et Linux), je cherche d’où ça vient.
Blady merci je vais regarder. Que faut il faire pour reproduire le bug ?
Bah en fait il y a plusieurs scènes dont l’aperçu ne fonctionne pas (et ces scènes là plantent une fois le jeu compilé).
Les “Stage” sont incriminés ainsi que la scène “Menu”.
La scène “Tutorial” et “Intro”, eux fonctionnent sans soucis. Les autres, je n’ai pas testé.
Tant mieux, je commençais à me demander si je ne devenais pas fou …
De mon coté, je n’arrive à rien. Au bout de deux modifs dans une page d’évènement (par exemple, la scène Titre), GD grimpe à 1,2 Go et crashe.
Pas classe du tout.
Pour moi, c’est lié à la compil en arrière plan : lorsque GD détecte une modif, il lance une précompil, qui déclenche la fuite mémoire avec une (ou plusieurs) instruction(s) fautive(s).
Je continue de penser que la condition “Si en collision avec” est la source du problème. Il ne faut peut-être pas l’utiliser avec des groupes d’objets, ou alors, avec un nombre limité d’objets à l’intérieur.
Personnellement aucun problème avec cette nouvelle version, pas de fuite mémoire enfin je pense pas : 64mo constant…
J’utilise abusivement cette condition sur dexu ou trois groupe d’objet globaux et je n’est actuellement aucun problème
Je pense pas que ça soit lié une condition ou action spécifique, ça n’a pas de sens, toutes sont traitées pareils. Pareil, utiliser ou non des groupes d’objets ne doit rien changer.
Non je pense que c’est plutôt l’inclusion des évènements graĉe aux liens qui entraine une copie en mémoire des évènements qui ne sont par la suite jamais libérés.
En fait mon projet comporte 9 liens et une seul scène et pourtant je n’est pas de fuite de mémoire…
J’ai placé une condition “Ou” est patatra :
Je clic ok et :
Cette fenêtre avait le titre : Microsoft Visual C++ Runtime Library
Argh 
C’est systématique ? Si oui, envoie moi vite le projet et explique où rajouter l’instruction Ou.
Non ce n’est pas systématique, j’ai relancer GD et le bug ne se produit plus…
Mtarzaim j’ai enfin résolu le bug de fuite mémoire, un truc vraiment idiot qui faisait dupliquait en mémoire les évènements lors de leur copie.
Bon cette galère a eu le mérite de me donner le temps de mettre en place quelques tests automatisés qui vérifient à chaque modification de la base de code des fonctionnalités du coeur de Game Develop (notamment si la consommation mémoire reste stable quand on copie quelques évènements ). Pour les ceux que ça intéresse, rendez vous par ici : travis-ci.org/4ian/GD/
Maintenant que ce gros problème est corrigé et testé pour éviter tout soucis de ce genre à l’avenir, je corrige des petites choses et je met une version stable en ligne !
Les choses sérieuses vont pouvoir commencer … Incoming projets de 50 Go en html5.
Merci encore pour ton temps (et acharnement). 
C’est impressionnant, ton jeu compile et GD ne dépasse pas 124 Mo de RAM sur mon PC.
EDIT : @4ian, pour Travis CI, tu peux intégrer une petite image dans le Readme.md de Github pour voir directement le statut du logiciel :
http://docs.travis-ci.com/user/status-images/
J’ai mis en ligne (voir mon premier message) la version 3.4.72.2 qui contient pas mal de corrections. Redites moi si vous avez encore des soucis.
Il y a aussi la version Ubuntu
Blady: le crash me semble dû à une musique, dans la scène menu du moins donc surement dans les autres aussi. Avec quoi as tu encodé ton .ogg ? Es tu sur que ça marchais avant ?
Les jeux sont compatible iOS et Android ? Cool ! Mais comment savoir quand l’utilisateur appuie sur une image par exemple ? Ça ne serait pas plus clair de créer une nouvelle plate-forme “mobile” ou tu reprend le code HTML5 et tu ajoute des actions conditions spécifique à cette plate-forme ? C’est juste une idée comme ça
Non pas besoin, les conditions relative à la souris détectent aussi le toucher.
Ha ben ça c’est une bonne nouvelle
Le logiciel est nettement plus stable qu’avant. Il ne dépasse pas les 800 Mo en RAM (surement parce qu’il manque de momo vidéo, il vient la prendre en ram système).
La compil web fonctionne sans souci.
Mes problèmes de lenteur de réaction et de chargement erroné de valeur via fichier xml ne se posent plus.
En revanche, les problèmes de son sont toujours là. A savoir :
- le volume global n’affecte que le volume des effets sonores. Le volume des musiques n’est pas changé.
- les musiques ne s’enchainent pas comme elles le devraient.
Je suppose que le souci vient des canaux multiples, que les navigateurs ne sont pas capable de gérer. D’où les problèmes avec les musiques.
La compil windows a lieu, mais le jeu crashe à l’ouverture. Il charge la première scène (changement de titre de la fenêtre) mais crashe sans rien afficher dans la fenêtre de jeu.
J’ai tenté une compil en mode optimisation (1h30 de moulinage), mais il a échoué à l’édition des liens.
Voici le fichier de log :
[code]C:\Users\ADMINI~1\AppData\Local\Temp/GDTemporaries/GD0x14464400RuntimeObjectFile.o:GD0x14464400RuntimeEventsSource.cpp:(.text+0x68): multiple definition of `GDSceneEventsS89_45PatrimonialeJournaux_45MiniJeu’
C:\Users\ADMINI~1\AppData\Local\Temp/GDTemporaries/GD0x14463908RuntimeObjectFile.o:GD0x14463908RuntimeEventsSource.cpp:(.text+0x0): first defined here
C:\Users\ADMINI~1\AppData\Local\Temp/GDTemporaries/GD0x144644d8RuntimeObjectFile.o:GD0x144644d8RuntimeEventsSource.cpp:(.text+0x68): multiple definition of `GDSceneEventsS00_45Titre’
C:\Users\ADMINI~1\AppData\Local\Temp/GDTemporaries/GD0x14463830RuntimeObjectFile.o:GD0x14463830RuntimeEventsSource.cpp:(.text+0x0): first defined here
collect2: ld returned 1 exit status
[/code]