Gestion de la memoire pour un petit jeu

Version imprimable

08/07/2008, 15h36
franck06

Gestion de la memoire pour un petit jeu

Salut,

j'ai un petit jeu, faconné en scenes, ou chaque scene peut lancer une autre scene comportant ses propres images, backgrounds ...

Mon probleme est que si une scene est appelée regulierement et que je la cree a chaque fois avec new, jai une erreur heap exception lorsque je depasse la taille globale allouee au heap Space (64Mo)

y a une solution qui serait de faire un singleton, mais ca voudrait dire que si 100 scenes sont appelees au cours du jeu, on a 100 singletons et la possibilite de faire peter la JVM

je souhaiterais plutot creer une scene lorsque necessaire, mais relacher toutes ses ressources lorsqu elle se termine ...
j ai essaye mettre scene = null puis dappeler le GC juste apres, mais ca donne quedale.

donc ma question cest, comment on gere cela ???? :)

Tu pourrais avoir un truc de ce genre :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class SceneFactory {
	private static HashMap<String,Scene> map = new HashMap<String,Scene>();
 
	public static Scene getScene(String nom) {
		Scene scene = map.get(nom);
		if(scene == null) {
			scene = new Scene();
			map.add(scene);
		}
		return scene;
	}
 
	public static void release(String scene) {
		map.remove(scene);
	}
}

08/07/2008, 16h42
adiGuba

Salut,

Appeler explicitement le GC est une très mauvaise idée, et ne prédit généralement rien de bon... :?

Et plutôt que de mettre à null des variables, il est préférable de limiter leurs scopes au maximum (ex: ne pas utiliser un attribut static pour une variable locale, ...)

Enfin plutôt que de tout définir en Singleton, ce dont je ne comprend pas vraiment l'intérêt, tu devrais plutôt passer par un système de cache qui ferait en sorte de ne pas charger plusieurs fois les mêmes objets, et de les partager... un peu comme indiqué par verbose.

Sinon il faudrait connaitre un peu plus ton application et son fonctionnement (que contient une scene, etc...)

a++

Citation:
Envoyé par verbose
Tu pourrais avoir un truc de ce genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public class SceneFactory { private static HashMap<String,Scene> map = new HashMap<String,Scene>(); public static Scene getScene(String nom) { Scene scene = map.get(nom); if(scene == null) { scene = new Scene(); map.add(scene); } return scene; } public static void release(String scene) { map.remove(scene); } }
j y avais pensé a ca oui

testé a linstant sans succes, jappelle ma scene avec getScene(...) puis desuite apres je fais un release

j ai límpression que la scene ne passe jamais dans le garbage collector, je comprends pas trop pourquoi

08/07/2008, 17h07
adiGuba

Citation:

Envoyé par franck06

j ai límpression que la scene ne passe jamais dans le garbage collector, je comprends pas trop pourquoi

On pourrait voir le code que tu as utilisé ??? Et comment tu fais pour affirmer que le GC ne passe pas ?

Sinon je rappelle que le GC ne s'exécute pas aussitôt mais regroupe les libérations...

Sinon verbose, une remarque que je viens de voir sur ton code : il n'est pas thread-safe et donc potentiellement dangereux dans un environnement multi-thread.

Comme on ne peut pas garantir qu'un élément static ne soit utilisable que d'un seul thread, il faudrait synchronisé tout cela, par exemple :

Code:

private static Map<String,Scene> map = Collections.synchronizedMap(new HashMap<String,Scene>());

a++
08/07/2008, 17h20
franck06

Citation:

Envoyé par adiGuba

Salut,

Appeler explicitement le GC est une très mauvaise idée, et ne prédit généralement rien de bon... :?

Et plutôt que de mettre à null des variables, il est préférable de limiter leurs scopes au maximum (ex: ne pas utiliser un attribut static pour une variable locale, ...)

Enfin plutôt que de tout définir en Singleton, ce dont je ne comprend pas vraiment l'intérêt, tu devrais plutôt passer par un système de cache qui ferait en sorte de ne pas charger plusieurs fois les mêmes objets, et de les partager... un peu comme indiqué par verbose.

Sinon il faudrait connaitre un peu plus ton application et son fonctionnement (que contient une scene, etc...)

a++

les scenes globalement contiennent une image de fond, des personnages animees (donc des images Png pour chacun), et le plus lourd, une map de Tiles qui est chargee via un tableau d'int (tableau de 5000 int) depuis un fichier txt
la map de tiles sappuie sur une image png pour etre creee, decoupee elle meme en petites images stockees

il est possible de ne charger les images des personnages qu une seule fois pour la scene, par contre, la TileMap varie en fnction du Level on va dire, donc le tableau est recharge a chaque Level chargé
08/07/2008, 17h28
franck06

Citation:

Envoyé par adiGuba

On pourrait voir le code que tu as utilisé ??? Et comment tu fais pour affirmer que le GC ne passe pas ?

Sinon je rappelle que le GC ne s'exécute pas aussitôt mais regroupe les libérations...

Sinon verbose, une remarque que je viens de voir sur ton code : il n'est pas thread-safe et donc potentiellement dangereux dans un environnement multi-thread.

Comme on ne peut pas garantir qu'un élément static ne soit utilisable que d'un seul thread, il faudrait synchronisé tout cela, par exemple :

Code:

private static Map<String,Scene> map = Collections.synchronizedMap(new HashMap<String,Scene>());

a++

effectivement mais c'est monothread donc pas de pb ...

pour le code :

grosso modo disons que j'ai une scene principale qui appelle un jeu (genre un Mario classique) comportant differents Levels

dans la scene principale, j appelle le jeu de la facon suivante :

JadeScene scene = miniGameFactory.getScene(display, "mario"); display.start(scene);
miniGameFactory.release("mario");

selon ou lon se trouve dans la scene principale, on charge un level different du Mario classique (un peu comme le vrai jeu on va dire)

ici, le Level chargé est en permanence le meme, mais bon, la taille du Heap devrait pas exploser ...
08/07/2008, 17h28
verbose

Citation:

Envoyé par adiGuba

On pourrait voir le code que tu as utilisé ??? Et comment tu fais pour affirmer que le GC ne passe pas ?

Sinon je rappelle que le GC ne s'exécute pas aussitôt mais regroupe les libérations...

Sinon verbose, une remarque que je viens de voir sur ton code : il n'est pas thread-safe et donc potentiellement dangereux dans un environnement multi-thread.

Comme on ne peut pas garantir qu'un élément static ne soit utilisable que d'un seul thread, il faudrait synchronisé tout cela, par exemple :

Code:

private static Map<String,Scene> map = Collections.synchronizedMap(new HashMap<String,Scene>());

a++

;)
08/07/2008, 17h30
adiGuba
Code:

1 2 JadeScene scene = miniGameFactory.getScene(display, "mario"); display.start(scene); miniGameFactory.release("mario");
Oui mais que devient scene ?
Si elle est toujours référencé le GC ne pourra pas la libérer...

a++
08/07/2008, 17h38
franck06
Citation:
Envoyé par adiGuba

Code:

1 2 JadeScene scene = miniGameFactory.getScene(display, "mario"); display.start(scene); miniGameFactory.release("mario");

Oui mais que devient scene ?
Si elle est toujours référencé le GC ne pourra pas la libérer...

a++
dans mon code, scene n'est referencee qu ici
cela dit, j utilise une petite librairie 2D qui se charge de stopper demarrer une scene
il est possible peut etre que les scenes soient referencees ailleurs alors
je vais regarder le code de la lib pour voir

Citation:

Envoyé par franck06

dans mon code, scene n'est referencee qu ici
cela dit, j utilise une petite librairie 2D qui se charge de stopper demarrer une scene
il est possible peut etre que les scenes soient referencees ailleurs alors
je vais regarder le code de la lib pour voir

ok, la librairie ne reference pas les scenes
on dispose d un display qui joue une scene grosso modo, le start du display ca donne en gros :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public final void start(Scene scene) { if(running) throw new Error("Engine already running !"); scene.begin(); running = true; ... while(running) { scene.mainLoop(); .... } running = false; scene.end(); }
pour arreter une scene, il suffit alors de faire display.stop() qui set running a false et permet de sortir de la boucle ...

mystere, la je sais plus que faire

08/07/2008, 18h23
dinobogan

Et l'objet display ? Tu es sûr qu'il est unique ? Son instance n'est pas conservée quelque part ?
Tu confirmes bien qu'il n'y a aucun Thread démarré dans une Scene ?
08/07/2008, 18h39
franck06

Citation:

Envoyé par dinobogan

Et l'objet display ? Tu es sûr qu'il est unique ? Son instance n'est pas conservée quelque part ?
Tu confirmes bien qu'il n'y a aucun Thread démarré dans une Scene ?

Aie

le display est cree dans la scene initial, mais ensuite, on le passe de Scene en Scene, donc on en garde une reference dans chaque scene

ca veut il dire que tant que display n'est pas null, chaque scene le reference et sera vivante en quelque sorte ??
09/07/2008, 14h59
Vivian Pennel

Tant qu'une référence au moins existe sur un objet, le GC ne fera pas le ménage.

Le GC compte le nombre de référence associé à un objet lorsque ce nombre est égal à 0 il nettoie.
09/07/2008, 17h53
dinobogan

Citation:

Envoyé par Vivian Pennel

Tant qu'une référence au moins existe sur un objet, le GC ne fera pas le ménage.

Le GC compte le nombre de référence associée à un objet lorsque ce nombre est égal à 0 il nettoie.

Exact.

De plus, le fait de conserver une instance de Display dans une Scene n'influence pas la suppression de la Scene par le GC.
Une Scene fait-elle des accès à un base de données ?
11/07/2008, 12h25
franck06

Citation:

Envoyé par dinobogan

Exact.

De plus, le fait de conserver une instance de Display dans une Scene n'influence pas la suppression de la Scene par le GC.
Une Scene fait-elle des accès à un base de données ?

non aucun acces en base

donc si je mets le Display en variable public static dans la scene principale et que jutilise cette varaible depuis les autres scenes, cest miuex ???