Discussion :

[Invité]

Bonjour,

Je travaille en ce moment sur un petit jeux (rien de grandiose ^^) en 3D iso.

J'ai une classe Heros dans laquelle je gère mon héros notamment en chargeant une image avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

this.textureHomerF = this.content.Load<Texture2D>("Content/Sprite/homerF");

Mon problème est que je charge aussi des ennemis dans une autre classe et le héros doit parfois être devant, et d'autres fois derrière les ennemis.

Y a t'il un moyen de gérer une profondeur (depth) ?

Petite exemple: les + représente mon héros haut de 2 cases, les $ mes ennemis haut de 2 cases et large de 2 aussi et les * des cases vides.

****************
*****+**********
*****$$*********
*****$$*********
**************** Ici, mon héros doit apparaître derrière l'ennemi



****************
*****$$*********
*****+$*********
*****+**********
**************** Ici, mon héros doit apparaître devant l'ennemi

[Emmanuel Deloget]

Bonjour,

Je travaille en ce moment sur un petit jeux (rien de grandiose ^^) en 3D iso.

J'ai une classe Heros dans laquelle je gère mon héros notamment en chargeant une image avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

this.textureHomerF = this.content.Load<Texture2D>("Content/Sprite/homerF");

Mon problème est que je charge aussi des ennemis dans une autre classe et le héros doit parfois être devant, et d'autres fois derrière les ennemis.

Y a t'il un moyen de gérer une profondeur (depth) ?

SpriteBatch.Draw() (je présume que c'est ce que tu utilises) possède deux overloads (celui-ci et celui-ci) qui te permettent de spécifier un "niveau de profondeur" au moment du rendu des sprites. La valeur layerDepth a spécifier est >=0.0 (premier plan), <=1.0 (arrière plan).

L'autre solution consiste à dessiner les sprites dans l'ordre. Tu peux jouer avec les overloads de SpriteBatch.Begin pour t'aider.

[Mat.M]

A moins que XNA ne gère cela automatiquement ( je ne connais pas XNA) la technique c'est d'utiliser des layers ou couches graphiques et de les trier selon l'ordre,le sens de représentation par exemple du haut vers le bas..
donc sur une couche graphique tu dessines ton personnage sur un autre les objets d'avant plan une autre les monstres et une dernière les objets d'arrière plan.
Après il faut effectuer un tri pour déterminer quelle couche s' affiche avant les autres...

[Emmanuel Deloget]

A moins que XNA ne gère cela automatiquement ( je ne connais pas XNA) la technique c'est d'utiliser des layers ou couches graphiques et de les trier selon l'ordre,le sens de représentation par exemple du haut vers le bas..
donc sur une couche graphique tu dessines ton personnage sur un autre les objets d'avant plan une autre les monstres et une dernière les objets d'arrière plan.
Après il faut effectuer un tri pour déterminer quelle couche s' affiche avant les autres...

Étonnamment, c'est le sujet du dernier post de mon blog.

Ceci était un communiqué publicitaire gratuit et posté sans aucune honte.

A noter que SpriteBatch a la possiblité de gérer l'ordre de dessin, mais uniquement dans le cadre du même bloc Begin()/End() (End() provoquant le dessin des sprites).

Le pseudo-code ci-dessous:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SpriteBatch.Begin()
SpriteBatch.Draw(monSprite1, depthLayer = 0) // FRONT
SpriteBatch.End()
SpriteBatch.Begin()
SpriteBatch.Draw(monSprite2, depthLayer = 1) // BACK
SpriteBatch.End()

Dessine monSprite2 par dessus monSprite1, malgré la définition du depthLayer qui nous dit le contraire.

[Invité]

Merci pour les réponses, je vais tester ca et mettrais [Résolu] si j'yarrive

[Invité]

J'ai essayer en surchargeant la méthode SpriteBatch.Draw() mais ce la ne marche pas non plus.
Cela peut il venir du fait que je créer un nouveau ContentManager dans chacune de mes classes ?

[Emmanuel Deloget]

J'ai essayer en surchargeant la méthode SpriteBatch.Draw() mais ce la ne marche pas non plus.
Cela peut il venir du fait que je créer un nouveau ContentManager dans chacune de mes classes ?

2 cas:
1) ta boucle de dessin ressemble conceptuellement à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
batch.Begin();
foreach (Sprite s in sprites)
{
  batch.Draw(s);
}
batch.End()

Dans ce cas, tu peux gérer la profondeur via le paramètre depthLayer de SpriteBatch.Draw().

2) ta boucle ressemble conceptuellement à celle-ci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
foreach (Sprite s in sprites)
{
  batch.Begin();
  batch.Draw(s);
  batch.End()
}

Dans ce cas, tu ne peux pas utiilser depathLayer. Il te faux ordonner toi même les sprites dans l'ordre que tu souhaites les dessiner.

[Luffy49]

je programme aussi en XNA et j'ai rencontrer ton probleme.

Si tu code "bien" tu a du faire une classe DrawableGameComponant pour ton hero et une autre pour ton enemie.

Tu les instancie et tu doit faire un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Components.add(myhero);
Components.add(myenemi);

pour gerer l'ordre d'affiche des objets pas plus simple que celà :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
myhero.DrawOrder = 1;
myenemi.DrawOrder = 2;

ici l'enemie sera afficher après le hero donc il sera dessus voilà tous simplement

ps : l'order de l'update peut aussi être gérer par UpdateOrder

[Invité]

Merci Luffy, exactement ca ^^

[Emmanuel Deloget]

je programme aussi en XNA et j'ai rencontrer ton probleme.

Si tu code "bien" tu a du faire une classe DrawableGameComponant pour ton hero et une autre pour ton enemie.

Pour ma part, je ne dirais pas que c'est du code "bien" pensé : que se passe-t-il si tu as besoin de 75 sprites représentant des entités différentes ? Dans ce design, tu te retrouves avec 75 DrawableGameComponent, ce qui n'est pas vraiment une idée grandiose (enfin si, elle l'est. Par la taille...)

L'idée de base des GameComponent a évolué dans le temps depuis la première version du Framework XNA. En ces temps immémoriaux, les composants étaient dirigés par le designer, et la tentation de lier entités et composant était forte (et hop! un composant sprite ici!). Cette notion ayant été supprimée de XNA, les composants se retrouvent avec une nouvelle vie bien à eux. Ils ont alors pour but de représenter des fonctionnalités (d'où la présence de composants qui ne sont pas drawable), et non pas des entités. L'une de ces fonctions est la gestion du modèle du jeu. Une autre est la transformation modèle -> vue, et donc l'affichage du modèle. Dans ce cadre, point n'est besoin d'avoir un composant par sprite - on peut tout à fait gérer l'ensemble des sprites d'une catégorie dans un seul composant graphique.

Pour un jeu 2D, voici l'architecture de GameComponent que je préconise:

1) Capture des entrées utilisateur, et mapping de ces entrées vers des actions
2) Mise à jour du modèle de données
3) Affichage du background (graphique)
4) Affichage des entités dynamiques / sprites (graphique)
5) Affichage du foreground (graphique)
6) Affichage de l'interface utilisateur (graphique)

On peut rajouter (en 2.5) la gestion de la musique et des effets spéciaux sonores. D'autres composants peuvent être utilisés pour gérer des effets graphiques supplémentaires (post-process, etc).

Pour un jeu 3D, un concept similaire peut être employé.

[Invité]

J'avoue que ce n'est pas le plus "propre".
Mais par contre niveau ressource et charge mémoire/cpu, cela revient au même nan ?

[Emmanuel Deloget]

J'avoue que ce n'est pas le plus "propre".
Mais par contre niveau ressource et charge mémoire/cpu, cela revient au même nan ?

Non. Mais la différence n'est pas forcément notable au niveau de la mémoire (on est pas à 1Ko prêt, ni même ) 10Ko d'ailleurs), elle peut l'être au niveau du temps CPU utilisé - notamment parce que, comme je l'ai décrit dans mon article, le parcours des GameComponent est tout sauf trivial; si il avait été trivial, le problème CPU serait bien moindre. Ainsi, la complexité algorithmique globale du code de rendu ne change pas, mais ça ne veut pas dire que le temps d'exécution reste le même.