Voilà j’ai un problème avec mon jeu une fois exporté.
J’ai fait quelques niveaux de tests dans ce jeu, mais une fois que j’ai joué à certains, le jeu revient au menu principal (ce qui est normal jusque là).
Sauf que parfois, le fond (qui est un objet mosaïque) ne s’affiche pas !
Voici comment cela doit s’afficher normalement (cliquez pour voir plus grand) :
Et voilà comment cela s’affiche après avoir essayé quelques niveaux sans fermer le jeu :
Je précise que mon ordinateur est équipé d’un GPU Intel HD3000 et que ce problème ne se produit pas sur NVIDIA et AMD.
Je pense que c’est dû au fait que le chipset Intel possède moins de mémoire, et j’ai entendu dire qu’il y a des fuites mémoires avec ces chipsets, ce qui explique cette erreur de chargement.
Voilà, merci d’avance si vous trouvez une solution à ce problème !
Juste pour savoir, quels sont les propriétés de l’image de l’objet mosaique (résolution, poids, format, etc. ) ?
Regarde l’évolution de la consommation de la mémoire avec le gestionnaire des taches, lorsque tu joues.
Si la mémoire vive est entièrement consommée, c’est qu’il y a bien une fuite mémoire. Et donc que ton projet peut se bloquer après un certain temps de jeu (en général 15 minutes). J’espère que tu as prévu un système de sauvegarde automatique …
L’objet Mosaïque (les étoiles) ont la même dimension que le jeu (1280x720), l’image est au format .png et elle pèse 27 ko.
La mémoire vive n’est jamais entièrement consommée, par contre elle diffère selon l’ordinateur.
Sur mon PC Windows 7 (équipé d’une carte graphique AMD HD5450), le processus du jeu ne dépasse jamais 150 000 Ko (selon le Gestionnaire des tâches), et ce même en changeant plusieurs fois de scène, et la consommation mémoire est plutôt raisonnable et ne monte jamais “à l’infini”.
En revanche, sur mon Mac Mini sous Boot Camp Windows 8.1, le GPU est un Intel HD3000, et là … bah c’est une autre histoire !
A chaque changement de scène, le jeu prend de plus en plus de mémoire … dans l’onglet “Performance”, le gestionnaire des tâches indiquait qu’il y a 4 Go de mémoire vive utilisée (pas le jeu en lui seul, mais c’en est la cause).
Et à force de changer de scène, divers éléments du jeu cessent de s’afficher. Et si j’insiste encore … le pilote d’affichage plante !
Après je sais pas ce que tu veux dire par “sauvegarde automatique”. Je sais pas si c’est possible de programmer ça sous Game Develop … en tout cas, sauvegarder sa progression me plairait bien, mais je ne sais pas si c’est pris en charge.
Ca me parait vachement léger pour un png …
Sinon, tu peux diminuer sa résolution. Comme c’est un objet Mosaique, même en 200x200 tu auras un fond uniforme sur 1280x720.
Vu que les png sont reconvertis en bmp dans la mémoire vive, moins ils sont larges, mieux c’est.
Sauf que si tu continues à jouer, au bout d’un moment certain et d’un certain moment, ton jeu va planter. Car même avec une conso fixe, la carte graphique finit par tirer la tronche et forcer l’arrêt de l’exécutable.
J’ai rencontré exactement le même problème sur le même matériel. Le jeu sature la mémoire vive, jusqu’à l’occuper entièrement. Et du coup, le jeu ne peut plus rajouter de nouvelles images (provoquant leur non-chargement).
Ca me rassure dans un sens : ça veut dire que mes algos ne sont pas cause. C’est bien un problème de hardware.
La seule solution que j’ai trouvé, c’est qu’il y aurait des mises à jour de la librairie sfml, qui corrige ce souci. Mais je ne sais pas si GD les intègre (ou si elles sont compatibles) …
Le jeu sauvegarde automatiquement la progression du joueur, et permet à celui-ci de reprendre sa partie depuis l’écran titre.
Bien sûr, tout cela doit être fait à la main :
créer un fichier xml
le remplir des valeurs des variables importantes
créer un menu supplémentaire pour gérer le chargement des sauvegardes
lire et fichier xml et charger les variables avec les bonnes valeurs
Une fonction “Dump” à la RPG Maker serait la bienvenue …
(sauvegarder l’ensemble des variables dans un fichier crypté sans poser de question, et pouvoir le recharger tout aussi facilement)
Malheureusement je ne peux pas car sa conception est faite de telle sorte que je suis obligé de mettre une grande résolution pour avoir un meilleur rendu.
Ce que je veux dire par “meilleur rendu”, c’est que l’image affiche quelques éléments que je souhaite faire apparaître par intervalles et non directement !
Voici le fond d’origine, il fait la même hauteur que le jeu mais il est par contre plus large.
Et donc y a t-il une solution pour éviter ce malheureux plantage ?
Ah cool ! Faut juste que je me mette à créer un .xml, étant donné que je n’en ai jamais fait !
Essaie avec ces versions là (le fond étoilé en mosaique, et les autres éléments en sprites que tu fais bouger avec les évènements, le tout sur un calque séparé du reste)
A ma connaissance, non.
En dehors de n’utiliser que de petites images (inférieur à 500 px ? ).
Oui, mais fais bien attention à ne pas oublier une variable (ou à charger le fichier au mauvais moment).
Tout dépend de la manière dont tes scènes foncionnent.
Ah, sinon, il y a un truc que j’ai remarqué en HTML5 : les valeurs lues depuis un fichier xml sont souvent erronées.
On dirait que le chargement du fichier se fait mal, et des valeurs bidons remplacent celles sauvegardées (un genre de stack overflow).
Si ton jeu est Windows seulement, pas de problème. Mais si tu vises le web, cette sauvegarde auto risque d’être plus retord que prévu.
Il faut donc gérer deux systèmes de sauvegarde différents ?
Et comment qu’on fait pour savoir si le jeu tourne en natif ou en web (en dehors d’une variable qu’il faut penser à mettre à la bonne valeur avant d’exporter) ?
Les fichiers “XML” sont en effet émulés sur la plateforme web (tout simplement car une page web n’a pas le droit d’accéder aux fichiers de l’ordinateur, les navigateurs ne laissent pas faire cela).
Mais à part le fait que le fichier n’existe pas réellement, tout devrait marcher pareil.
Il n’y a pas de moyen d’identifier si on est en web ou en natif ?
J’avais essayé avec “si le fichier truc existe”, mais cette condition n’est pas dispo en plateforme web (surement pour les mêmes raisons).
D’ailleurs, remplacer les actions non dispo dans une plateforme par des “???” n’est peut-être pas une bonne idée. Il vaudrait mieux leur coller une couleur différente, afin de les séparer du reste du code compatible, tout en les laissant lisibles. On peut ainsi relire ce qui a été fait natif, lorsqu’on travaille sur le web.
EDIT :
Retour au problème de départ : les fuites mémoires des objets graphiques.
Il y a un passage intéressant dans la faq de sfml :
et dans le paragraphe en dessous :
Le problème ressemble à un mélange des deux : lorsque la mémoire est réallouée, au lieu de supprimer l’anciennne, la texture est copiée à nouveau. D’où la fuite mémoire. Peut-être qu’en changeant un sf:Image par un sf:texture (ou l’inverse ? ), on forcerait GD à réallouer correctement la mémoire.
Pour la petite histoire, j’ai essayé de remplacer les dll sfml copiées avec un projet exporté par les dll de sfml 2.1 (dispo sur le site officiel). Évidemment, ça ne marche pas. Ce qui me fait dire que le sfml embarqué par GD est une vieille version …
