adnz a écrit:
Merci,
- J'ai déjà corrigé le directement à gauche du Pacman après le "Ready"
- j'ai commencé à intégrer la différence d'IA entre les "ghost", mais faut que je factorise en même temps pour libérer des octets sinon j'arrive trop près de 9FFF
- pour les fruits va falloir que je trouve de la place et essayer de coder ça avec un minimum d'instruction !
- peut être voir à déplacer du code dans les bank en fonction de l'accessibilité, bref ça cogite
et faut que je trouve un autre moyen d'afficher le score, juste l'affichage des digits ça ralenti grave en faite,
ça speed quand je commente le JSR qui display le score !!
...
Pour les scores... La technique est, ce pense, que tu aies 2 (ou 1 seul, ça dépend si tu as besoin des valeurs réelles du score pour d'autres usages, ce dont je ne vois pas trop, même en comparant avec le high score) espaces mémoires (3 octets chacun), un pour la version "numérique" (non nécessaire) et une pour la version affichage (en utilisant l'instruction assembleur DAA). Alors si l'ajout dépasse les 256 ça suppose de décomposer en 2 octets
Si, par exemple, tu ajoutes 1500 au score (situé en, disons $9100)
- tu lis l'octet $9102 (le plus à droite) dans A
- tu ajoutes le score de poids faible (de 1500) dans A
- tu fais un
DAA sur A
- si dépassement (>255, voir registre CC), drapeau "dépassement" (un registre)
- A=> $9102
- A<= $9101
- ré-appliquer le même processus que précédemment
- A=>$9101
- si dépassement, ajouter 1 à $9100
Ensuite, en supposant que tes chiffres "graphiques" sont dans un certain ordre dans la mémoire.
- tu prend chaque octet de la gauche vers la droite.
- Octet AND 15 => on a un chiffre de 0 à 9
- Avec ce chiffre, on affiche le graphe "chiffre" correspondant (indexé de 0 à 9 avec X*Chiffre octet d'offset) sur l'écran
- Décalage de 4 bits (4 fois LSR) de l'octet A. Réaffichage du chiffre graphique correspondant
- Retour de boucle
3 octets ça correspond à 6 chiffres... après, le Thomson étant limité à 1MHz, le fait que tu aie d'énorme graphismes pour le score, sachant que ça fait 6 sprites, je ne suis pas sûr que ça soit judicieux d'utiliser de si gros sprites pour le score pour la fluidité du jeu. Si le Thomson était à base de 6309 à 4 MHz, yaurait pas de soucis, mais c'est pas le cas.
Cette méthode est très rapide pour l'affichage de scores, à condition qu'il n'y ait pas énormément de gros chiffres à afficher. L'instruction
DAA est vraiment utile dans ce cas de figure. Mais elle ne peut êre utilisée que dans le cas d'addition
Pour ce qui est de la comparaison avec le high score, la technique est simple
- prendre chaque octet de la droite à la gauche du score
- si octet_score <hiscore => sortie
- si octet_score>highscore : affichage nouveau highscore : sortie
- octet suivant
L'affichage du highscore est le processus d'affichage du score mais à un autre endroit de l'écran. On peut éventuellement combiner l'affichage simultané du score et du hiscore EN MEME TEMP (si tu as un octet graphique en mémoire à un instant T, tu peux les afficher en même temps en 2 endroits différents, mais ça bouffe la généricité d'une partie du code (celle de l'affichage d'un sprite, à moins d'une astuce)
Pour les fruits. C'est pas compliqué, tu mets juste un affichage du fruit (qui a un indice dans ton "tableau" labyrinthe, juste différent d'une gomme) et pratique un test dessus. Le fruit est juste un élément de décor pendant un certain temps.