deeph (./12) :
C'est sympa le repository, [...]

Le repo c'est bien pour rendre public et voir les changements d'une version à l'autre mais c'est surtout une garantie de ne pas avoir à faire plein de sauvegardes dans son coin.
Et le plus important à mon avis c'est que je ne code pas en ayant peur de planter ce qu'il y avait avant, puisque je peux revenir à une version antérieure facilement.

edit : je viens de regarder rapidement, tu utilises des listes pour les coordonnées des bombes ? J'aurai plutôt fait une matrice pour la map (déjà pour la dessiner c'est plus simple je pense), à laquelle j'aurais ajouter directement les bombes et explosions. Ensuite suffit de gérer le déplacement des personnages toujours sur la matrice pour savoir s'ils sont touchés ou pas, etc...

Je n'y avais pas pensé, gh m'a parlé de double buffering mais je ne l'ai pas utilisé (dans un projet futur je pense).

A propos du source :
Je ne blit pas tout l'ecran à chaque fois (c'est un choix en partie justifié par le fait que le joueur ne peux pas chevaucher les rocher).
J'efface sous le joueur quand il se déplace puis je l'affiche (d'ou le clignotement sur le screenshot).
J'affiche les bombe à chaque déplacement (je crois).
Une liste pour les x, une liste pour les y, et une liste pour le timer, lorsque x ou y ou timer sont à 0 ça signifie qu'il ne faut pas afficher.
Le timer est décrémenté à chaque tour, si on est à 10, on affiche l'explosion, si on est à 1 la bombe disparait.
La encore si le joueur est sur la bombe il meurt donc pas de probleme de superposition.
J'ai imaginé me servir du graphbuffer pas simplement comme buffer d'affichage mais aussi pour tester des pixels éteints ou pas, mais finalement je ne l'ai pas fait.
J'utilise une grosse matrice de la taille de l'écran pour le fond (pas de tilemap). Je sais c'est mal


Comment fais-tu pour utiliser une matrice.
2 hypothèses me viennent à l'idée :
- Une case de la matrice correspond à un emplacement 8x8 donc on a du mal à gérer le déplacement s'il ne sont pas alignés sur une case non?
- Ou alors tu utilises 1 octet par pixel (ce qui permet d'attribuer une valeur différente si c'est le coin haut-gauche d'un sprite bombe, sprite bonhomme, sprite rocher etc...) mais la ça fait gros en mémoire

Tu parcours toute la matrice à chaque fois pour savoir ou il y a une bombe?
Bref c'est pas bien clair si tu as 2 min pour m'expliquer ton idée...

Autre chose ; concernant le double buffering, y a t il un emplacement pour ces buffers (je suis quasi sur que non).
Et comment gérer ça (j'imagine avec un pointeur sur l'élément courant et un decalage avec le registre ix par exemple) ?
Ca ferait donc 3 buffers avec le graphe buffer (un pour le premier plan, un pour le fond et enfin le graph buffer) ?

Je vais créer un autre topic dès que j'ai 5 min


Thibault