Architecture logicielle & boucle de jeu

Le programme est écrit, compilé et téléversé depuis l'environnement de développement intégré MPLAB X IDE de Microchip. La compilation est assurée par le compilateur XC8, spécialisé pour les microcontrôleurs PIC 8 bits, qui traduit le code C en code machine optimisé pour l'architecture du PIC16.

Une partie de l'initialisation n'est pas écrite à la main mais générée automatiquement par le MCC (MPLAB Code Configurator). Cet outil graphique permet de configurer les périphériques (oscillateur HFINTOSC, convertisseur ADCC, bus SPI1/MSSP1, générateur de son NCO1, broches d'entrée-sortie) via une interface, puis produit un ensemble de fichiers rangés dans le répertoire mcc_generated_files. C'est ce dossier qui fournit notamment la fonction SYSTEM_Initialize, les fonctions du convertisseur ADCC_*, l'ouverture du bus SPI SPI1_Open, ainsi que les macros d'accès aux broches (par exemple BTN_B_GetValue()). L'intérêt de cette approche est double : elle réduit le risque d'erreur dans la configuration des registres (souvent fastidieuse et source de bogues) et elle permet de se concentrer sur la logique du jeu plutôt que sur les détails du matériel. Le fichier d'en-tête mcc_generated_files/mcc.h est donc inclus dans main.c pour donner accès à toutes ces fonctions et macros.

À côté de cet en-tête généré, main.c inclut plusieurs bibliothèques C standard, chacune choisie pour un rôle précis et compatible avec les contraintes de la cible : <stdint.h> pour les types entiers de taille fixe (uint8_t, uint16_t, int8_t) qui permettent de doser finement l'occupation de la RAM ; <stdbool.h> pour le type bool ; <stdlib.h> pour rand(), utilisé pour faire apparaître les astéroïdes de manière aléatoire ; <stdio.h> pour sprintf, qui fabrique les chaînes de caractères du score ; et <math.h> pour sqrtf et la constante M_PI. Ces fonctions flottantes restent volontairement cantonnées aux phases non critiques (préparation, affichage du score) et non au cœur de la boucle de jeu.

Le jeu fonctionne comme une machine à quatre états. Pour représenter proprement cet état, le programme définit un type énuméré :

typedef enum { ETAT_MENU, ETAT_REGLAGES, ETAT_JEU, ETAT_GAMEOVER } EtatJeu;

Un enum associe un nom symbolique à une valeur entière (ici 0, 1, 2, 3 dans l'ordre). Manipuler etat == ETAT_JEU est à la fois plus lisible et plus sûr qu'un test sur une valeur numérique brute, car le compilateur connaît l'ensemble des valeurs possibles.

Les objets mobiles du jeu sont décrits par deux structures qui regroupent les données liées à un même objet :

typedef struct { float x, y, vx, vy; uint8_t active, life; } Bullet;
typedef struct { float x, y, vx, vy; uint8_t active; } Asteroid;

Une structure rassemble dans une seule entité la position (x, y), le vecteur vitesse (vx, vy) et l'état de l'objet. Le projectile (Bullet) possède en plus un champ life, une durée de vie en nombre de tours de boucle (limitée à BULLET_LIFE = 60) au-delà de laquelle il disparaît. Le champ active indique si l'emplacement est occupé par un objet vivant. On remarque le choix du type uint8_t (entier non signé sur 8 bits, issu de <stdint.h>) pour active et life : un seul octet suffit à coder ces valeurs, ce qui économise la RAM par rapport à un int classique. Regrouper ainsi les données facilite la manipulation : on peut parcourir un tableau d'objets et traiter chacun comme un tout cohérent.

La fonction main() suit le squelette caractéristique des programmes pour microcontrôleur : une phase d'initialisation exécutée une seule fois, suivie d'une boucle infinie while(1) qui ne s'arrête jamais (un microcontrôleur n'a pas de système d'exploitation vers lequel rendre la main).

void main(void){
    SYSTEM_Initialize();
    ADCC_Initialize();
    SPI1_Open(SPI1_DEFAULT);
    ILI9488_Init();
    setRotation(3);
    NCO1INC = 0;
    afficherMenu();
    while(1){
        if(etat == ETAT_MENU){
            if(appuiC()){ initJeu(); etat = ETAT_JEU; }
            if(appuiD()){ afficherReglages(); etat = ETAT_REGLAGES; }
        }
        else if(etat == ETAT_REGLAGES){
            if(appuiC()){ afficherMenu(); etat = ETAT_MENU; }
        }
        else if(etat == ETAT_JEU){
            boucleJeu();
        }
        else if(etat == ETAT_GAMEOVER){
            if(appuiC()){ afficherMenu(); etat = ETAT_MENU; }
        }
    }
}

La phase d'initialisation se lit ligne par ligne. SYSTEM_Initialize() configure l'horloge et les périphériques générés par le MCC. ADCC_Initialize() prépare le convertisseur analogique-numérique 10 bits pour la lecture des deux axes du joystick. SPI1_Open(SPI1_DEFAULT) ouvre le bus SPI1 en mode maître avec la configuration par défaut (SPI Mode 0), indispensable au dialogue à sens unique PIC vers écran. ILI9488_Init() envoie à l'écran la séquence d'initialisation (gamma, contrôle d'alimentation, registre MADCTL, format de pixel 18 bits, sortie de veille, allumage). setRotation(3) place l'écran en mode paysage 480x320 en écrivant le registre d'orientation MADCTL. NCO1INC = 0 met à zéro l'incrémenteur du générateur de son (NCO1) afin de garantir le silence au démarrage : la fréquence produite valant NCO1INC x 7,6294 Hz, une valeur nulle correspond à l'absence de signal. Enfin afficherMenu() dessine l'écran d'accueil avant l'entrée dans la boucle.

La boucle while(1) implémente la machine à états sous la forme d'une cascade de tests if / else if. À chaque tour, le programme regarde la valeur de etat et n'exécute que le bloc correspondant. Les transitions sont déclenchées par les boutons : depuis ETAT_MENU, un appui sur le bouton C lance une partie (initJeu() réinitialise le jeu, puis etat passe à ETAT_JEU) et un appui sur le bouton D ouvre les réglages ; depuis ETAT_REGLAGES, l'appui sur C ramène au menu ; en ETAT_JEU, le bloc délègue tout le travail à boucleJeu() ; en ETAT_GAMEOVER, l'appui sur C renvoie au menu. On observe que chaque transition associe systématiquement un changement d'affichage et une mise à jour de la variable etat, ce qui garantit la cohérence entre ce qui est dessiné et l'état logique du jeu. Le passage en ETAT_GAMEOVER, lui, n'est pas déclenché par un bouton mais à l'intérieur de boucleJeu(), lorsqu'un astéroïde entre en collision avec le vaisseau.

Après avoir décrit séparément le joystick, le vaisseau, les projectiles, les astéroïdes et les collisions, il reste à assembler ces briques dans une expérience cohérente. Ce chapitre traite de deux aspects complémentaires : d'une part la fabrication des écrans fixes du jeu (menu, réglages, fin de partie) et de l'élément d'interface persistant qu'est le compteur de score (HUD) ; d'autre part la boucleJeu(), qui orchestre image après image l'ensemble des traitements pendant une partie. Comme dans tout le projet, le fil rouge demeure le ménagement du PIC16F18877 : un microcontrôleur 8 bits cadencé à FOSC = 32 MHz (cycle instruction Tcy = 125 ns), dépourvu d'unité de calcul flottant matérielle, qui ne peut se permettre ni des calculs lourds inutiles, ni des réaffichages complets de l'écran à chaque tour. Pour mémoire, l'écran ILI9488 affiche 480 x 320 pixels en mode paysage et chaque pixel envoyé coûte trois octets (couleur 18 bits) transmis sur le bus SPI : économiser des pixels réaffichés revient donc directement à économiser du temps machine.

La fonction afficherMenu() compose le premier écran rencontré par le joueur. Elle commence par remplir l'écran en noir, puis appelle dessinerFondEtoiles() pour poser le décor. Vient ensuite un cadre orange épais, obtenu non pas par une primitive de bordure dédiée mais par quatre rectangles imbriqués tracés successivement : en superposant quatre contours de tailles légèrement décroissantes, on obtient visuellement un trait épais et net, alors que display_drawRect ne dessine qu'un trait d'un pixel. Cette astuce évite d'avoir à remplir une zone pleine puis à la recreuser, opération qui serait plus coûteuse en pixels écrits sur le bus SPI.

À l'intérieur du cadre figurent le titre ASTEROIDS, les crédits du binôme (Emma Grosmaire Sausse Dorian) et un petit vaisseau décoratif, dessiné avec les mêmes primitives de triangle que le vaisseau de jeu. Enfin, deux lignes rappellent les commandes de navigation : la touche C lance une partie (C -> JOUER) et la touche D ouvre l'écran des réglages (D -> REGLAGES). Ces libellés correspondent au brochage réel : BTN_C est câblé sur RD5 (patte 28) et BTN_D sur RD4 (patte 27), tous deux actifs à l'état bas (résistance de tirage pull-up : relâché = 1, appuyé = 0).

Lorsqu'un astéroïde percute le vaisseau, le jeu bascule dans l'état ETAT_GAMEOVER et appelle afficherGameOver(). Cet écran affiche le message GAME OVER ainsi que le score final. Le score, qui est une valeur entière variable, ne peut pas être écrit en dur : on le met en forme dans une chaîne de caractères à l'aide de sprintf :

sprintf(buf, "SCORE : %d", score);

sprintf écrit dans le tampon buf le texte littéral SCORE : suivi de la valeur entière de score (format %d). La chaîne ainsi fabriquée est ensuite affichée par display_printText. Le format spécifié %d (entier décimal) est cohérent avec le type de score. Enfin, un rappel C -> MENU indique au joueur comment relancer le cycle. Cet usage de sprintf provient de la bibliothèque standard <stdio.h> incluse dans main.c.

Avant que l'action ne démarre, un compte à rebours affiche successivement les chiffres 4, 3, 2 puis 1, à raison d'un chiffre par seconde, pour laisser au joueur le temps de saisir le joystick. La difficulté technique vient de la macro __delay_ms du compilateur XC8 : sa durée maximale est bornée, et l'on ne peut pas lui demander directement une attente d'une seconde pleine. La solution consiste à fractionner chaque seconde en dix attentes de 100 ms (soit 10 x 100 ms = 1000 ms) : on boucle dix fois sur un __delay_ms(100) pour totaliser une seconde par chiffre. Entre deux chiffres, on efface l'ancien et on dessine le suivant, toujours selon le principe « effacer puis redessiner » appliqué à une zone restreinte de l'écran.

La fonction boucleJeu() est appelée en continu tant que l'on reste dans l'état ETAT_JEU. Elle enchaîne les traitements dans un ordre précis, chaque tour de boucle correspondant à une image du jeu.

void boucleJeu(void){
    afficherScore();
    bool angleChange = lireJoystick();
    if(angleChange){
        tracerVaisseau(ILI9488_BLACK);
        calculerSommetsVaisseau();
        tracerVaisseau(COL_ORANGE);
        shipDrawCounter=0;
    }
    if(shootCooldown>0) shootCooldown--;
    if(appuiB() && shootCooldown==0){ tirer(); shootCooldown=3; }
    spawnCounter++;
    if(spawnCounter>=SPAWN_DELAY){ spawnCounter=0; spawnAsteroide(); }
    majAsteroides();
    majTirs();
    shipDrawCounter++;
    if(shipDrawCounter>=12){ tracerVaisseau(COL_ORANGE); shipDrawCounter=0; }
    collisions();
}

L'ordre des étapes n'est pas arbitraire. On commence par afficherScore(), qui ne fait rien si le score est inchangé (cf. le compteur de score). On lit ensuite le joystick : lireJoystick() renvoie un booléen angleChange indiquant si l'orientation du vaisseau a suffisamment varié pour justifier un redessin. Le seuil est gouverné par la constante ANGLE_REDRAW_DOT=0.9997 : on compare le produit scalaire de l'ancien et du nouveau vecteur d'orientation (tous deux unitaires) à cette valeur. Comme pour deux vecteurs unitaires le produit scalaire vaut le cosinus de l'angle entre eux, redessiner uniquement quand ce produit descend sous 0,9997 revient à exiger un écart angulaire supérieur à arccos(0,9997), soit environ 1,4 degré. En deçà, le vaisseau bougerait si peu que le redessin serait imperceptible et inutilement coûteux. Si le seuil est franchi, on applique le triptyque effacer / déplacer / redessiner : tracerVaisseau(ILI9488_BLACK) efface l'ancien vaisseau en le repeignant en noir, calculerSommetsVaisseau() recalcule ses trois sommets à partir du nouveau vecteur (shipCos, shipSin), puis tracerVaisseau(COL_ORANGE) le redessine à sa nouvelle orientation. On remet aussi shipDrawCounter à zéro, car le vaisseau vient d'être repeint.

Vient la gestion du tir. La variable shootCooldown impose un délai minimal entre deux tirs : à chaque tour, si elle est positive, on la décrémente. Lorsque le bouton B est enfoncé (appuiB(), câblé sur RD6, patte 29) et que le cooldown est nul, on déclenche tirer() puis on recharge shootCooldown=3. Ce mécanisme empêche une rafale ininterrompue tant que le joueur maintient le bouton, sans avoir besoin de détecter un front montant complexe.

On gère ensuite l'apparition des astéroïdes via un compteur : spawnCounter augmente d'une unité par tour, et lorsqu'il atteint SPAWN_DELAY=19, on le remet à zéro et l'on fait surgir un astéroïde avec spawnAsteroide(). Un astéroïde naît donc tous les dix-neuf tours de boucle, ce qui régule la difficulté (jusqu'à MAX_ASTEROIDS=4 simultanément). Puis majAsteroides() et majTirs() déplacent et redessinent respectivement les astéroïdes et les projectiles encore actifs.

Le bloc suivant illustre un point subtil du rendu incrémentiel. Comme les astéroïdes et les tirs effacent au passage les pixels du vaisseau (chacun gérant sa propre zone par effacement/redessin), le vaisseau finirait par se trouver partiellement « grignoté ». Pour réparer ces dégâts sans repeindre le vaisseau à chaque image, on incrémente shipDrawCounter, et tous les douze tours seulement on force un tracerVaisseau(COL_ORANGE) puis on remet le compteur à zéro. C'est un compromis économique : redessiner le vaisseau en permanence coûterait cher, ne jamais le redessiner laisserait des trous, le faire périodiquement maintient un rendu propre à moindre frais. Enfin, collisions() clôt le tour en testant les rencontres entre tirs et astéroïdes (gain de 10 points, destruction) et entre astéroïdes et vaisseau (déclenchement du GAME OVER), en comparant des distances au carré pour éviter les racines carrées coûteuses.