C’est peut-etre un problème de réseau, vu que le jeu est mis en partage sur un serveur. Mais un test en local arrive au meme résultat (sur le meme ordi bas de gamme). Testé en local sur un PC en nVidia ne provoque pas ce probleme …
ce serait la carte graphique bas de gamme qui fait des siennes ?
En tout cas, c’est un joli bug graphique, qui pop un peu quand il veut (la scène marche, on en sort, on y revient, et ça bugge).
Des idées sur ses causes (et sur ses solutions) ?
EDIT :
Bon ben.
On va mettre résolu, vu que le problème ne se pose que sporadiquement désormais, et souvent lié à la machine (et sa config hardware).
Une carte graphique d’entrée de gamme semble résoudre le problème.
Pas beau en effet : J’ai fait quelques tests sur mon PC avec la version exécutable de ton jeu, ce genre de soucis ne semble pas se reproduire. ( La conso mémoire reste stable malgré plusieurs aller/retour entre deux scènes ).
Je pense que c’est un soucis de non libération en mémoire des textures graphiques : GD charge à chaque scène les images nécessaires et les décharge quand on quitte la scène, sauf si elles sont marquées “Toujours chargée en mémoire”.
A mon avis, le driver de la carte graphique bas de gamme ne fait pas ou mal ce déchargement… Quoi qu’il en soit, ça donne une belle fuite de mémoire et au bout d’un moment, le PC doit refuser de charger de nouvelles images.
Tu peux tenter de garder chargé en mémoire certaines images ( C’est une case à cocher dans les propriétés des images, dans l’éditeur de la banque d’images ), mais d’un autre coté ça va augmenter la consommation mémoire permanente, pas cool d’autant que tu as de nombreuses et grandes images…
J’ai refait des tests avec des allers et retours entre le premier écran (l’entrée principale) et le deuxième (l’embranchement vers les tableaux et l’accueil).
Il y a bien une fuite mémoire au niveau du premier écran, manifestement dûe au sprite Fantome (composé de plusieurs objets sprites superposés), de 300 Mo environ par chargement. Les images en question sont en 72 dpi, mais en 800x1200 (pour ne pas être trop moche en gros plan).
J’ai testé sur un PC d’entrée de gamme en Intel HD graphics 1000 (pilotes mis à jour via ma-config.com) et le problème apparait immédiatement.
J’ai testé sur un même PC d’entrée de gamme, mais avec une carte graphique nVidia bas de gamme, et la fuite mémoire ne se produit pas.
Ce serait donc lié à la CG, nommément la Intel HD, qui fait mal son boulot et boulotte sur la mémoire réservée au reste du système (c’est une CG à mémoire partagée).
Donc, à part changer de CG, je ne vois pas de solution (autre que diminuer la réso des gros sprites, mais ça va faire moche ingame). Je vais tester différents réglages au niveau de la mémoire partagée et au niveau de GD pour voir si je peux “contenir” ce souci.
Merci pour tes tests, ça confirme donc ce que je disais. Difficile dans ces conditions d’agir pour ma part, si la carte graphique ne libère pas ce que je lui dit.
Tu peux par contre essayer la solution que je mettais dans mon précédent post ( garder des images chargées en mémoire en mettant “Oui” dans les propriétés des images dans la banque d’images ) pour tenter de canaliser le problème en réduisant le nombre de chargement.
C’est ce que je suis en train de faire.
La fuite mémoire continue, mais de façon moins intense.
Je passe en gros de 300 Mo à 3 Mo. Ce qui est déjà mieux, mais ça reste “pas normal”.
Peut-être qu’en jonglant entre les grosses images chargée en mémoire, et les petites en libération auto, je vais arriver à stabiliser la conso en mémoire vive …
EDIT :
Après moultes optimisations du code, et modifs en tous genres, la version 3.6.76 semble avoir résolu le problème.
Plus de fuite mémoire = plus de problème pour le jeu à retrouver ses assets.
