On le sait tous, un extra-terrestre c’est bête à manger du foin, donc on va lui créer une intelligence artificielle (IA) limitée…
en fait, on va faire déplacer l’ennemi de façon autonome mais simple et de plus, l’exemple du livre ne va pas plus loin, donc….on va dire que c’est moi qui suis limité ;-)
On va utiliser une des variables que l’on a déclaré précédemment et qui s’appelle inddir (comme ‘indicateur de direction’), je vous rappelle ce que l’on avait fait pour ces variables :
On les a d’abord déclaré comme associées à une adresse spécifique de la mémoire RAM dans le pied de page de notre code , pour inddir c’était une adresse très lointaine dans la mémoire qui nous permet d’espérer qu’elle ne se fera pas écraser par du code, ici l’adresse 41002.
De ce fait on pourra stocker n’importe quelle valeur dedans et la modifier au besoin.
Cet indicateur, on va le manipuler pour le faire passer d’une valeur 0 à 1 (et inversement).
Dans l’un des articles précédent on a déclaré inddir à l’adresse 41002 mais on a stocké une valeur dedans qui était 1, un petit rappel de la manière dont on a procédé dans le code :
La stratégie va être que dans la boucle principale du programme, on va appeler une fois par boucle la routine de déplacement de l’ennemi.
Avant de le déplacer, on va aller consulter la valeur de cet indicateur :
Mais ce n’est pas tout, avant d’incrémenter le déplacement dans les sous-routine on vérifiera que la valeur de la coordonnée (ici, X) n’a pas atteint une extrémité de l’écran.
Si c’est le cas, on va aller changer la valeur de l’indicateur à l’adresse 41002 pour qu’il se déplace dans l’autre sens à la prochaine boucle et ce, jusqu’à l’extrémité opposée. un petit schéma : 
Pourquoi x=240 à droite alors que la résolution va jusqu’à 256 ?
En fait les coordonnées des sprites correspondent au premier pixel en haut à gauche de chaque sprite.
Nos sprites étant agrandis à une taille x2, ils font 16 pixels sur 16 pixels, donc quand notre sprite est à la coordonnée x=240, entre 240 et 256 ce sont les 16 pixels de l’envahisseur qui s’affichent.
Si on décidait d’aller au-delà le sprite sortirait de l’écran car il a besoin de 16 pixels à droite pour apparaître.
Je vais d’abord vous décrire l’algorithme choisi pour le déplacement (qui commence par la routine DEPENV) et ensuite on rentrera dans le code :
On a donc 4 routines à écrire :
Dans la boucle principale du programme on appellera la routine DEPENV qui dispatchera le travail entre les sous-routines en fonction de l’état de l’indicateur inddir et de l’état de la valeur de la coordonnée X du sprite envahisseur.
Passons au code que l’on rajoute en dessous de la routine DELAI (mais on pourrait le mettre ailleurs vu qu’on utilise des labels pour les appeler) :
La 1ere chose que fait la routine DEPENV, c’est de vérifier la valeur de l’indicateur inddir, s’il vaut 1 c’est que l’envahisseur doit se déplacer vers la gauche (0 vers la droite), il suffit de faire un calcul sur la valeur de l’inddir.
Ici on lui soustrait 1 :
ENGAU qui gère ce type de déplacement.la TAS abrite ces informations, elle débute à 6912 et il faut 4 adresses pour chaque sprites, donc pour l’envahisseur c’est 6917 qui abrite la valeur du X….
…bon allez, je vous fais un petit rappel de ce qu’on a rentré dans la TAS pour ces SPRITES :
Donc on récupère la valeur de la coordonnée X du sprite, comme on compare avec zéro ou pas zéro, pour vérifier si X=240, il suffit de faire un calcul dessus, si tel n’est pas le cas alors la sous-routine ENDRO1 fera le boulot de déplacement vers la droite.
Si par contre on est déjà à l’extrème droite de l’écran, on ne fait que changer la valeur de inddir pour qu’à la prochaine boucle l’envahisseur se déplace vers la gauche.
Je vous donne les autres sous-routines, elles sont maintenant simples à comprendre :
Ce code est à ajouter en dessous de la routine DEPENV.
Elles sont simple à comprendre, surtout avec le schéma de l’algorithme que je vous ai fait plus haut.
La seule subtilité c’est les routines qui ont pour rôle de calculer le prochain déplacement effectif de l’envahisseur (ENGAU1 et ENDRO1) finissent par un CALL 77 qui est l’instruction qui modifie vraiment la coordonnée X du SPRITE dans la TAS, sans ce CALL 77 les autres calculs que l’on a fait étaient sans impact sur la TAS. Ils étaient un peut comme quand l’on fait des calculs sur le coin d’un cahier de brouillon.
Il ne nous reste plus qu’à rajouter une instruction dans la boucle principale qui appellera le DEPENV et c’est CALL DEPENV (c’est la ligne 8 du code ci-dessous) :
Et pour finir le code entier du programme mis à jour qu’il ne vous reste plus qu’à compiler et lancer dans l’émulateur blueMSX :