C'était bien ça. Mais pourquoi tu as besoin de faire un memmove sur la liste des missiles? Je n'ai peut-être pas tout compris mais bon je vais te proposer quelque chose.
Tu prends une liste de sprites.
SPRITE sprites[100];
Chaque SPRITE est une structure (contenant ce que tu veux à propos du sprite) mais au moins un composant du genre type, qui donne le type du sprite, et 0 si un sprite est inutilisé. Donc par exemple une valeur SPR_MISSILE pour indiquer que c'est un missile.
SI tu veux ajouter un sprite, tu parcours la liste des sprites jusqu'à ce que tu trouves un sprite ayant comme type 0. Ainsi le bloc sprite est "libre" et tu pourras commencer à y écrire ton nouveau sprite.
SI tu veux effacer un sprite, tu ne fais que sprites[numéro]->type=0; Au prochain ajout, ce bloc sprite sera détecté comme libre et le nouveau sprite pourra y être placé.
SI tu veux modifier un sprite, il n'y a aucun problème, tu a un accès direct à ta liste.
Par exemple, tu crées 10 sprites, tu supprimes le troisième et le septième. Maintenant tu veux ajouter un sprite -> le premier bloc libre sera le troisième et tu pourras y placer le sprite nouveau venu. Compris?
Cet algo n'est pas super si les sprites doivent se trouver dans un ordre particulier mais là c'est pas grave, le but est de les afficher, et on s'en fiche complètement dans quel ordre...
Cet algo n'est pas bon si la taille des sprites (en octets) est variable. En gros le seul endroit où cet algo n'est pas valide a été mon agenda (version 2, le premier utilisait ce que je viens de te décrire
) car:
-Les messages ont une taille variable et font partie de la structure
-L'ordre est très important
En plus tu n'auras peut-être même pas besoin de stocker le nombre de sprites; tu sais que si tu es arrivé au centième sprite dans ta recherche de bloc libre c'est que le tableau est plein.
) car:
