Salut

Je suis entrain de faire un éditeur de niveau et je bloque sur un nouveau point. J'ais une fonction map() générale qui affiche chaques sprites, gère les collision en fonction de l'emplacement de ces sprites etc...
Mais j'ais un petit soucis pour ce qui concerne les sprites pouvant bouger.

Logiquement, pour un jeu a vue de 3/4, il faut afficher les sprites ayant la valeur de y la plus grande en dernier, puisque si un sprite est près, il doit être affiché au dessus de ceux plus loin.
Avant, je me contentais de trier moi-même dans map() en faisant attention a la valeur y de l'affichage. Mais maintenant que je m'attaque aux sprites non-fixe, cette valeur va changer aléatoirement, et je ne vois pas du tout comment gérer sa.

Quelqu'un pourrait-il m'aider?

il te faut gerer deux ensembles de sprites.
les sprites fixes et les sprites mobile.
tu peux trier tes sprites fixes une fois pour toute.
a chaque rendu, tu trie tes sprites mobiles.
lorsque tu affiche les sprites, tu parcours les deux ensembles en traitant celui de y maximal.

C'est justement pour mettre ça en oeuvre que je bloque.

Ca voudrais dire qu'avant chaque affichage d'un sprite de map(), il faudrait que je parcoure une autre fonction contenant les sprites mobiles et tester chacuns pour voir s'il ont une valeure y supérieur au précédent sprite affiché, mais inférieure a celui que je suis sur le point d'afficher pour intercaler le ou les mobile(s) entre les deux?

soient deux collections de sprites triées selon leur valeur y:

liste_fixe.y_liste[0,0,0,5,5,5,10,10,10] //trié une fois pour toutes
liste_mobile.y_liste[2,3,7,11,13] //trié à chaque frame

tantque liste_fixe!=vide ET liste_mobile!=vide faire :

//on va tester quel élément des deux listes a le plus petit y, les listes
//étant triées, on teste les têtes
_ si liste_mobile.premier.y < collection_fixe.premier.y alors :
_ _liste_mobile.pop puis afficher
_ sinon
_ _ liste_fixe.pop puis afficher
// Puis après la boucle, il ne reste dans une seule liste que les éléments
//de plus grand y, triés.
afficher ce qui reste.

Si ton moteur d'affichage supporte le Zbuffer tu peux tout afficher dans un ordre quelconque.

Tu peux aussi tout mettre dans une seul liste et faire un "quicksort" dessus. (vu que t'es obligé de trier la liste des elements mobiles, autant tout trier)

J'avoue que j'ais du mal a voir comment trier les affichages de sprites.
Sachant que j'ais une fonction de ce style :

map()
{
placement(sprite1,0,0)
colision(0,0,50,50)
placement(sprite2,500,500)
colision(0,0,50,50)
}

J'ais du mal a voir comment trier des appels de fonctions...
Quelqu'un peux m'aider?

Déjà, je pense que l'organisation au complet me semble innapropriété.
Premièrement, il faut "toujours" séparer l'affichage du reste de la logique du jeu, en particulier des collisions et doit généralement suivre ce schéma:
[capture des evennements]->[annalyse des evennement et execution de la logique du jeu]->[affichage] (et bouclé sur le début)
Les -> symbolisent un format de donné efficace qui est traité par chaque partie afin de limiter au maximum les échanges entre les différentes parties. La première flèche, par exemple, donne sous la forme de booléens l'états des touches, et s'il y a un réseau, les evennements reçuts extérieurs. La seconde donne uniquement un identifiant des objets à afficher et leur position (voir un état pour savoir la frame correspondante...)
La partie du milieu, la partie de toute la logique du jeu doit s'occuper de gérer les collissions en fonction des évennements récupérés et de l'état actuel des objets de la map (note que l'affichage n'a pas accès à cet état des objets de la map, la partie affichage reçoit un format pour l'affichage et uniquement l'affichage)

2°, L'affichage 2D se fait généralement sur 3 plans. Le sol, dessiné quoiqu'il arrive (ou pas si l'affichage est bien optimisé dans des cas précis), puis est dessiné l'état dit intermédiaire. C'est la que sont affichés les éléments qui sont à la hauteur des personnages mobiles et enfin sont dessinés les élements supérieurs, comme les toits de maison, ou encore les feuillages des arbres, derrières lesquels les personanges passent.
On comprend donc que la partie la plus dure réside dans la partie intermédiaire. Dans un système de tiles(tuiles) c'es très évident.
On commence par la ligne y en haut de l'écran, s'il on ne rencontre aucun mob (mouving object) on ne dessine que les éléments normaux, puis on passe à la ligne suivante...
A chaque fois que l'on passe à la tile x suivante, il faudra donc vérifier, parmis tous les objets "inabituels" (mobs) s'il y en a un à placer. Si oui le dessiner, puis passer à la tile suivante et ainsi de suite.

Voilà en gros la base la plus simple et efficace à suivre.

Si tu veux plus de détails, monpseudo @ hotmail.fr

Mmmh pourquoi faut-il séparer l'affichage du reste?
Enfin c'est surtout qu'en procédant comme sa, j'ais juste un SDL_Rect gobal qui servira pour chaque sprite, alors qu'en séparant, il va en falloir autant que de nombre de sprite a afficher, donc je ne vois pas bien l'interet...

1°_ On sépare toujours le plus possible en modules différents les différentes parties d'un programme pour faciliter l'intégration de nouvelles.

2°_ Tu utilise tout autant de mémoire avec tam éthode actuelle voir plus. Je suppose que actuellement tu utilises une matrice contenant toutes les tiles à afficher. De cette façon tu as les X et Y en fonction de ta matrice. Pour les afficher, il suffit donc de n'utiliser qu'un seul rectangle: rect.x = X *tile_sizeX, rect.y = Y * tile_sizeY . Et tu changes les valeur de ce rectangle à chaque affichage. Jamais tu n'as besoin de beaucoup de mémoire, d'ailleurs ma méthode permet de ne pas en utiliser plus que ce dont tu en as besoin.

3°_ "placement(sprite1,0,0) ;
colision(0,0,50,50) ;"
Tu testes tes collisions en fonction de quoi là en fait? La réutilisabilité d'un même code pour les différents objets d'un programme est indispensable pour être efficace et s'en sortir.
Si tu es obligé de changer "manuellement" les tests de collission en fonction du sprite que tu viens juste d'afficher, sa taile etc... alors ton code n'est pas "bon". Pour illustrer ce problème, j'ai déjà une source d'un jeu de plateforme proche d'un mario like dont la fonction de test de collision prends 4000 lignes (oui tu as bien lu) car il a codé pour chaque état de son personnage, chaque objet en coollision etc... à force de rajouter des éléments dans son jeu, il a finit par avoir un truc énorme que si tu bouges un truc tout plante.
Bref, ce n'est pas de la programmation correcte.

Dernier point, la complexité mémoire est toujours négligeable face à la complexité d'execution. Mieux vaut un bon code avec une mémoire plus grande que ce qui est nécessaire, qu'une mémoire parfaitement optimisé avec un code inréutilisable qui te fait perdre une semaine pour rajouter un truc tout con.

Tu testes tes collisions en fonction de quoi là en fait?
En fait j'ais donc un SDL_Rect global pour la position d'un sprite et a chaque appel de placement() sa valeure change (c'est pourquoi j'enchaine sur l'affichage puis les collisions).
Donc comme la position du perso est aussi dans une variable globale, j'ais juste besoin de mettre la "bouding box" voulue en paramètre.
Donc si j'ais besoin de rajouter une fonction j'ais juste a la placer.