Le gameplay : joystick, vaisseau, tirs & collisions

Le joystick : lecture ADC et orientation du vaisseau

La fonction lireJoystick() constitue le cœur des commandes du jeu. C'est elle qui transforme le geste de la main du joueur en une orientation du vaisseau triangulaire affiché au centre de l'écran. Dans le jeu, le vaisseau ne se déplace pas : il reste au centre (CX = 240, CY = 172) et pivote sur place pour viser. C'est donc uniquement l'angle d'orientation qui est piloté par le joystick, et toute la difficulté consiste à le calculer de façon fiable sans surcharger un microcontrôleur lent. Ce chapitre détaille la chaîne complète, de la mesure des deux tensions analogiques jusqu'à l'astuce mathématique qui évite tout appel coûteux aux fonctions trigonométriques.

Le joystick analogique et le convertisseur ADC

Un joystick analogique est constitué de deux potentiomètres montés à angle droit, l'un pour l'axe X (horizontal) et l'autre pour l'axe Y (vertical). Chaque potentiomètre se comporte comme un diviseur de tension : la position du manche fixe une tension comprise entre 0 V (butée d'un côté) et la tension d'alimentation (butée de l'autre côté). Au repos, un ressort de rappel ramène le manche au centre, ce qui correspond théoriquement à la moitié de la plage.

Ces deux tensions sont mesurées par le convertisseur analogique-numérique du PIC16F18877, le périphérique ADCC, configuré en résolution 10 bits. Une mesure produit donc un nombre entier compris entre 0 et 1023 (soit 2^10 − 1). Sur la carte, l'axe X est câblé sur la broche RC7 (patte 22) et l'axe Y sur la broche RC6 (patte 21). Dans le code, ces deux canaux sont désignés par les symboles poussoire_x (axe X) et poussoire_y (axe Y).

La lecture d'un canal suit toujours le même protocole en trois temps : lancer la conversion, attendre qu'elle se termine, puis récupérer le résultat. C'est exactement ce que font les trois appels suivants, utilisés à plusieurs reprises dans ce chapitre :

ADCC_StartConversion(poussoire_x);
while(!ADCC_IsConversionDone());
int adcX = ADCC_GetConversionResult();

La première ligne déclenche la conversion du canal X. La deuxième est une boucle d'attente active (while) qui ne fait rien tant que la conversion n'est pas terminée : le ! inverse le booléen, donc la boucle tourne « tant que la conversion n'est PAS finie ». La troisième ligne lit la valeur numérisée (0 à 1023) et la range dans adcX. Ces fonctions ADCC_* sont fournies par le code généré par MCC (MPLAB Code Configurator), qui se charge d'avoir configuré au préalable le multiplexeur d'entrée, l'horloge de conversion et le format du résultat. Cette attente est très courte (la conversion dure quelques microsecondes) et constitue l'un des rares moments où le programme se permet de bloquer, car il n'a rien d'utile à faire entre-temps : c'est une exception assumée au principe « ne jamais bloquer inutilement ».

lireJoystick() : la trigonométrie sans trigonométrie

C'est ici que se concentre l'idée la plus élégante du programme. Le PIC16 ne possède pas d'unité de calcul flottant matérielle : les fonctions cos, sin, atan2 ou sqrt y sont émulées en logiciel et sont lentes. Or, pour orienter le vaisseau, on a besoin du cosinus et du sinus de l'angle visé. L'astuce consiste à les obtenir sans jamais appeler ces fonctions trigonométriques.

bool lireJoystick(void){
    ADCC_StartConversion(poussoire_x);
    while(!ADCC_IsConversionDone());
    int adcX = ADCC_GetConversionResult();
    ADCC_StartConversion(poussoire_y);
    while(!ADCC_IsConversionDone());
    int adcY = ADCC_GetConversionResult();
    int dx = (adcX - joyCx) * JOY_X_SIGN;
    int dy = -(adcY - joyCy);
    long mag2 = (long)dx*dx + (long)dy*dy;
    if(mag2 < (long)JOY_DEADZONE*JOY_DEADZONE) return false;
    float fx=(float)dx;
    float fy=(float)dy*JOY_Y_SCALE;
    float mag=sqrtf(fx*fx+fy*fy);
    if(mag<1.0f) return false;
    float newCos=fx/mag;
    float newSin=fy/mag;
    float dot=newCos*shipCos+newSin*shipSin;
    shipCos=newCos;
    shipSin=newSin;
    return (dot < ANGLE_REDRAW_DOT);
}

(a) L'écart au centre

Après avoir lu adcX et adcY comme expliqué plus haut, on calcule la position relative du manche par rapport au centre calibré. La ligne int dx = (adcX - joyCx) * JOY_X_SIGN soustrait le centre mémorisé : si le manche est poussé d'un côté, dx est positif ; de l'autre, négatif ; au repos, proche de zéro. Le facteur JOY_X_SIGN est une constante de signe (+1 ou −1) qui permet d'inverser le sens de l'axe X selon l'orientation physique du joystick sur la carte (valeur à confirmer selon le câblage). Pour l'axe Y, int dy = -(adcY - joyCy) applique systématiquement un signe négatif. Cette inversion est nécessaire car, sur l'écran, l'axe vertical des pixels est orienté vers le bas (Y croît vers le bas), alors qu'en convention mathématique l'axe Y croît vers le haut. Le signe « − » remet l'axe Y dans le sens mathématique attendu, de sorte que pousser le manche vers le haut fasse pointer le vaisseau vers le haut de l'écran.

(b) La zone morte

Au repos, même après calibration, dx et dy oscillent légèrement à cause du bruit résiduel. Sans précaution, le vaisseau tremblerait en permanence. On calcule donc le carré de l'amplitude du déplacement : mag2 = dx*dx + dy*dy. Géométriquement, c'est le carré de la distance entre la position courante du manche et son centre. On compare ce carré au carré du seuil JOY_DEADZONE (qui vaut 32), c'est-à-dire 32 × 32 = 1024. Si mag2 < 1024, on considère que le manche est au repos et la fonction renvoie false sans rien modifier : le vaisseau ne bouge pas. Comparer les carrés (mag2 < JOY_DEADZONE²) plutôt que les distances elles-mêmes (mag < JOY_DEADZONE) évite une racine carrée coûteuse, tout en donnant exactement le même résultat puisque la fonction carré est strictement croissante sur les nombres positifs : c'est un principe directeur appliqué dans tout le code. On notera aussi les transtypages (long) qui forcent les multiplications à se faire en arithmétique large, là encore pour prévenir tout débordement entier (un dx de l'ordre de 500 donne déjà dx*dx = 250 000, bien au-delà de la capacité d'un int 16 bits).

(c) La normalisation, cœur de l'astuce

On convertit ensuite dx et dy en flottants fx et fy, en appliquant au passage le facteur JOY_Y_SCALE (1,04) sur l'axe Y pour compenser une légère asymétrie de course entre les deux axes du joystick. On calcule alors la norme du vecteur : mag = sqrtf(fx*fx + fy*fy), c'est-à-dire mag = √(fx² + fy²). Cette racine carrée, contrairement à celle que l'on a évitée à l'étape précédente, est indispensable ici, mais elle n'est exécutée que lorsque le manche est réellement poussé (le test de zone morte a déjà filtré tous les cas au repos). Le garde-fou if(mag < 1.0f) return false évite une division par zéro si la norme est négligeable.

Vient ensuite la double division newCos = fx/mag et newSin = fy/mag. Géométriquement, diviser un vecteur par sa norme le ramène à une longueur de 1 : on obtient un vecteur unitaire pointant dans la direction du joystick. Or, sur le cercle trigonométrique de rayon 1, un point situé à l'angle θ a précisément pour coordonnées (cos θ, sin θ). La définition même du cosinus est cos θ = côté adjacent / hypoténuse, et celle du sinus sin θ = côté opposé / hypoténuse ; dans notre triangle rectangle, l'hypoténuse est mag, le côté adjacent (horizontal) est fx et le côté opposé (vertical) est fy. Par conséquent :

newCos = fx / mag = cos θ et newSin = fy / mag = sin θ

Les composantes du vecteur unitaire sont donc directement le cosinus et le sinus de l'angle visé. On obtient (cos θ, sin θ) sans jamais calculer θ ni appeler atan2, cos ou sin. La direction normalisée porte à elle seule toute l'information angulaire dont le vaisseau a besoin pour être dessiné. C'est l'illustration la plus pure du fil rouge du projet : exploiter une identité géométrique pour supprimer un calcul que le PIC16, dépourvu de FPU, exécuterait lentement.

(d) Le produit scalaire et le seuil de redessin

Une fois le nouveau vecteur d'orientation obtenu, faut-il réellement effacer puis redessiner le vaisseau ? Si l'orientation n'a quasiment pas changé, le faire serait du gaspillage de temps de calcul et provoquerait un scintillement. On compare donc la nouvelle direction à l'ancienne (shipCos, shipSin) à l'aide d'un produit scalaire : dot = newCos*shipCos + newSin*shipSin. Pour deux vecteurs unitaires, le produit scalaire vaut exactement le cosinus de l'angle qui les sépare. En effet, si l'ancienne direction est l'angle α et la nouvelle l'angle β, alors :

dot = cos β · cos α + sin β · sin α = cos(β − α)

ce qui n'est autre que la formule d'addition cos(a − b) = cos a cos b + sin a sin b appliquée à l'écart angulaire (β − α). Ainsi, si la direction n'a pas bougé, dot vaut cos(0) = 1 ; plus l'écart angulaire grandit, plus dot diminue. La constante ANGLE_REDRAW_DOT vaut 0,9997, ce qui correspond à un écart d'environ 1,4 degré (puisque arccos(0,9997) ≈ 1,4°). La fonction met d'abord à jour shipCos et shipSin avec la nouvelle orientation, puis renvoie dot < ANGLE_REDRAW_DOT : le résultat vaut true (il faut redessiner) seulement si le vaisseau a tourné de plus de 1,4 degré environ, et false sinon. On évite ainsi des redessins inutiles tout en gardant une rotation parfaitement fluide à l'œil. Une nouvelle fois, c'est un produit scalaire - deux multiplications et une addition en flottant - qui remplace un calcul d'angle bien plus coûteux.

La fonction calculerSommetsVaisseau()

La géométrie du triangle est entièrement reconstruite par une seule fonction. La pointe avant est placée dans la direction de visée, à une distance SHIP_FRONT = 18 pixels du centre. Les deux coins arrière sont obtenus en faisant tourner la direction de visée de plus et moins 2,45 radians, puis en multipliant le résultat par SHIP_BACK = 11 pixels. Voici le code intégral :

void calculerSommetsVaisseau(void){
    shipX1 = CX + (int)(shipCos * SHIP_FRONT);
    shipY1 = CY + (int)(shipSin * SHIP_FRONT);
    float bx = shipCos*COS245 - shipSin*SIN245;
    float by = shipSin*COS245 + shipCos*SIN245;
    shipX2 = CX + (int)(bx * SHIP_BACK);
    shipY2 = CY + (int)(by * SHIP_BACK);
    float cx = shipCos*COS245 + shipSin*SIN245;
    float cy = shipSin*COS245 - shipCos*SIN245;
    shipX3 = CX + (int)(cx * SHIP_BACK);
    shipY3 = CY + (int)(cy * SHIP_BACK);
}

Détaillons bloc par bloc.

Les deux premières lignes calculent la pointe avant (shipX1, shipY1). Le vecteur de direction (shipCos, shipSin) étant unitaire, le multiplier par SHIP_FRONT donne un déplacement de 18 pixels exactement dans la direction de visée. On ajoute ce déplacement au centre (CX, CY). Le transtypage (int) convertit le résultat flottant en coordonnée entière de pixel, format que l'écran attend.

Le deuxième bloc calcule le premier coin arrière. Les variables intermédiaires bx et by représentent le vecteur de direction tourné d'un angle de plus 2,45 radians. On reconnaît la formule de rotation d'un vecteur (développée plus bas), où COS245 et SIN245 sont le cosinus et le sinus de cet angle, précalculés une fois pour toutes. Le vecteur tourné (bx, by) reste unitaire ; on le multiplie donc par SHIP_BACK = 11 pour placer le coin arrière à 11 pixels du centre, puis on l'ajoute au centre.

Le troisième bloc est rigoureusement symétrique : cx et cy représentent la direction tournée de moins 2,45 radians. Le signe affecté au terme en sinus s'inverse (on lit + shipSin*SIN245 au lieu de -, et - shipCos*SIN245 au lieu de +), ce qui correspond à une rotation dans l'autre sens. C'est cette symétrie autour de l'axe avant qui donne au triangle sa forme isocèle : les deux ailes arrière sont écartées du même angle de part et d'autre de l'axe de visée.

On notera qu'aucune fonction trigonométrique n'est appelée : la fonction ne contient que des multiplications, des additions et des soustractions de flottants. C'est exactement l'objectif recherché.

La fonction tracerVaisseau(c)

Une fois les six coordonnées mémorisées dans les variables globales shipX1..shipX3 et shipY1..shipY3, le dessin est trivial. La fonction tracerVaisseau se contente de relier les trois sommets par trois segments, à l'aide de la primitive display_drawLine de la bibliothèque graphique :

void tracerVaisseau(uint16_t c){
    display_drawLine(shipX1, shipY1, shipX2, shipY2, c);
    display_drawLine(shipX2, shipY2, shipX3, shipY3, c);
    display_drawLine(shipX3, shipY3, shipX1, shipY1, c);
}

Le paramètre c est la couleur du tracé. Pour afficher le vaisseau, on appelle la fonction avec la couleur orange du jeu ; pour l'effacer, on rappelle exactement la même fonction avec la couleur noire, ce qui repasse les mêmes pixels en couleur de fond. Aucun calcul flottant n'est effectué ici : la fonction ne manipule que des coordonnées entières déjà calculées. Le coût du dessin est donc réduit au tracé de trois lignes par l'algorithme de Bresenham, sans la moindre opération trigonométrique.

La séparation calcul / dessin

L'architecture du vaisseau illustre un principe récurrent du programme : séparer le calcul de la position du dessin proprement dit. La fonction calculerSommetsVaisseau() n'est appelée que lorsque l'orientation change réellement, c'est-à-dire lorsque le joueur tourne le joystick suffisamment pour franchir le seuil de redessin ANGLE_REDRAW_DOT = 0.9997. Ce seuil est un produit scalaire entre l'ancienne et la nouvelle direction : tant qu'il reste supérieur à 0,9997, la rotation est inférieure à environ 1,4 degré et l'on considère que le vaisseau pointe toujours dans la même direction. Ses sommets demeurent alors valides et il est inutile de les recalculer.

La fonction tracerVaisseau(), elle, peut être appelée plusieurs fois sans recalcul : une première fois en noir pour effacer l'ancien triangle, une seconde fois en orange pour dessiner le nouveau. Ce découpage « calculer une fois, dessiner ou effacer plusieurs fois » évite à la fois les recalculs inutiles et le scintillement, tout en ménageant le microcontrôleur.

Pour conclure, revenons sur la raison profonde pour laquelle un vecteur (cos, sin) normalisé suffit à décrire une direction. Un vecteur unitaire est, par définition, un point du cercle de rayon 1 ; or tout point de ce cercle s'écrit (cos theta, sin theta) pour un certain angle theta. Le couple (shipCos, shipSin) encode donc une direction sans qu'il soit jamais nécessaire de connaître theta lui-même. Comme le joystick fournit déjà, après normalisation, un tel vecteur unitaire pointant vers la cible (voir le chapitre sur le joystick), la direction de visée est disponible « gratuitement ». Pour les ailes, on écarte cette direction de plus ou moins 2,45 rad par rapport à l'axe de visée. Chaque aile fait ainsi un angle d'environ 140 degrés avec la pointe, ce qui revient à la placer à environ 40 degrés de l'axe arrière : les deux coins se retrouvent largement derrière le centre, de part et d'autre de l'arrière du vaisseau, et le triangle prend son allure de flèche. Un angle proche de 180 degrés ramènerait les ailes presque dans l'axe arrière et donnerait une flèche très effilée, tandis qu'un angle proche de 90 degrés produirait un triangle large et trapu. La valeur de 2,45 rad réalise un compromis visuel satisfaisant, tout en restant une constante que l'on peut précalculer, fidèle au fil rouge du projet : éviter le calcul flottant en temps réel pour ménager un processeur lent.

La fonction tirer() : création d'un projectile

Lorsque le joueur appuie sur le bouton de tir (BTN_B, sur RD6, patte 29), la fonction tirer est appelée. Son rôle est de trouver un emplacement libre dans le tableau et d'y inscrire un nouveau projectile, orienté comme le vaisseau.

void tirer(void){
    for(uint8_t i=0;i<MAX_BULLETS;i++){
        if(!bullets[i].active){
            bullets[i].x = CX + shipCos*SHIP_FRONT;
            bullets[i].y = CY + shipSin*SHIP_FRONT;
            bullets[i].vx = shipCos*BULLET_SPEED;
            bullets[i].vy = shipSin*BULLET_SPEED;
            bullets[i].life = BULLET_LIFE;
            bullets[i].active = 1;
            display_fillCircle((uint16_t)bullets[i].x,(uint16_t)bullets[i].y,BULLET_RADIUS,COL_ORANGE);
            son_tir();
            break;
        }
    }
}

La boucle for parcourt les quatre cases. Le test if(!bullets[i].active) sélectionne la première case libre rencontrée (drapeau à 0). Si les quatre tirs sont déjà actifs, la boucle se termine sans rien faire : il n'est tout simplement pas possible de tirer une cinquième fois tant qu'un projectile n'a pas disparu. C'est une limitation voulue, cohérente avec la taille fixe du tableau.

Une fois une case libre trouvée, le projectile est positionné à la pointe avant du vaisseau :

• bullets[i].x = CX + shipCos*SHIP_FRONT;
• bullets[i].y = CY + shipSin*SHIP_FRONT;

Ici CX et CY sont les coordonnées du centre de l'écran (CX = 240, CY = 172), point fixe où se trouve toujours le vaisseau. Le couple (shipCos, shipSin) est le vecteur unitaire d'orientation du vaisseau, déjà calculé à partir du joystick : shipCos est le cosinus de l'angle de visée, shipSin son sinus. Multiplier ce vecteur unitaire par la distance SHIP_FRONT = 18 (la longueur du nez du vaisseau) et l'ajouter au centre donne exactement la position de la pointe. Mathématiquement, on calcule le point situé à la distance SHIP_FRONT du centre dans la direction de visée :

pointe = (CX + cos(a) x SHIP_FRONT, CY + sin(a) x SHIP_FRONT)

Le tir part donc visuellement du canon du vaisseau, et non de son centre.

La vitesse reprend la même direction, mise à l'échelle par la cadence souhaitée :

• bullets[i].vx = shipCos*BULLET_SPEED;
• bullets[i].vy = shipSin*BULLET_SPEED;

avec BULLET_SPEED = 9.0. Comme (shipCos, shipSin) est un vecteur de norme 1 (cos(a)^2 + sin(a)^2 = 1), multiplier par 9 donne un vecteur vitesse de norme 9 pixels par tour, dirigé exactement comme le vaisseau. C'est l'avantage décisif de réutiliser l'orientation déjà connue : aucun appel à cos, sin ou atan2 n'est nécessaire au moment du tir, alors que ces fonctions flottantes seraient très coûteuses sur le PIC. On recycle un résultat déjà disponible, calculé une seule fois par tour lors de la lecture du joystick.

Le champ life est initialisé à BULLET_LIFE = 60 : le projectile vivra au plus 60 tours de boucle. Le drapeau active passe à 1 pour marquer la case occupée. La ligne display_fillCircle(...) dessine immédiatement le disque orange (COL_ORANGE = 0xFD20) de rayon BULLET_RADIUS = 2 à la position de départ. La conversion explicite (uint16_t)bullets[i].x tronque les coordonnées flottantes vers l'entier inférieur, car la primitive graphique (qui s'appuie sur display_fillCircle, lui-même bâti sur l'algorithme du point milieu de la bibliothèque GFX) attend des coordonnées de pixels entières. Enfin, son_tir() déclenche l'effet sonore via le périphérique NCO1 (Numerically Controlled Oscillator), qui génère une fréquence sur la patte RA6 sans solliciter le processeur pendant la lecture du son, et le break quitte la boucle : un seul tir est créé par appel, même si plusieurs cases étaient libres. Sans ce break, un seul appui remplirait d'un coup les quatre emplacements disponibles.

Les astéroïdes (météorites)

Les astéroïdes constituent la menace centrale du jeu : ce sont des octogones qui surgissent des bords de l'écran et foncent vers le vaisseau immobilisé au centre. Chaque astéroïde détruit rapporte 10 points au score, tandis qu'un contact avec le vaisseau provoque la fin de partie (GAME OVER). Ce chapitre détaille leur représentation en mémoire, leur apparition aléatoire, leur tracé graphique et leur mise à jour image par image. Comme partout dans le projet, l'objectif transversal est de ménager le PIC16F18877, un microcontrôleur 8 bits dépourvu d'unité de calcul flottant matérielle : on cherche donc à limiter le nombre d'opérations en virgule flottante et à ne redessiner que ce qui change.

Représentation en mémoire

Un astéroïde est décrit par une structure simple, déclarée dans main.c :

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

Les champs x et y représentent la position du centre de l'astéroïde à l'écran (en pixels, mais stockée en float car le calcul de trajectoire produit des valeurs non entières). Les champs vx et vy sont les deux composantes du vecteur vitesse : à chaque tour de boucle, on ajoute vx à x et vy à y pour déplacer l'astéroïde. Enfin, active est un drapeau (uint8_t, soit un seul octet) qui vaut 1 si l'astéroïde existe à l'écran et 0 si la case est libre. Le choix de uint8_t plutôt qu'un bool ou un int est délibérément économe : sur ce PIC, la RAM est limitée, et un octet suffit largement pour un indicateur logique. La structure comporte donc cinq champs : quatre flottants (position et vitesse) et un octet de statut.

Les astéroïdes sont rangés dans un tableau global de taille fixe :

Asteroid asteroids[MAX_ASTEROIDS];

avec MAX_ASTEROIDS=4. Ce dimensionnement fixe est un principe récurrent du système embarqué : on n'utilise pas d'allocation dynamique (malloc), coûteuse et risquée sur un petit microcontrôleur. Le tableau est réservé une fois pour toutes au démarrage, et le drapeau active sert de gestion d'occupation : une case « libre » est simplement une case dont active vaut 0. Limiter le nombre d'astéroïdes simultanés à quatre borne aussi la charge de calcul de la boucle de jeu, ce qui aide à conserver une cadence régulière. Le même procédé (tableau fixe + drapeau active) est utilisé pour les projectiles (bullets[MAX_BULLETS], avec MAX_BULLETS=4), ce qui confère au code une logique homogène et prévisible.

Visuellement, chaque astéroïde est un octogone (polygone à huit côtés), choisi comme compromis entre un rendu « rocheux » crédible et un coût de tracé faible (huit segments seulement).

Tracé de l'octogone : dessinerAsteroide()

Le dessin s'appuie sur deux tableaux de constantes précalculées représentant un octogone de rayon 10, centré sur l'origine :

astX[8] = {10, 7, 0, -7, -10, -7,  0,  7}
astY[8] = { 0, 7,10,  7,   0, -7,-10, -7}

Ces huit couples décrivent les sommets d'un octogone parcouru dans le sens trigonométrique : chaque sommet est à une distance d'environ 10 de l'origine (par exemple sqrt(7^2 + 7^2) = sqrt(98) ~ 9,9, proche de 10). Le fait que ces valeurs soient figées une fois pour toutes évite tout appel à cos ou sin au moment du dessin. La fonction de tracé transforme ces huit sommets puis les relie :

void dessinerAsteroide(Asteroid *a, uint16_t c){
    int px[8]; int py[8];
    for(uint8_t k=0;k<8;k++){
        px[k] = (int)a->x + (AST_RADIUS*astX[k])/10;
        py[k] = (int)a->y + (AST_RADIUS*astY[k])/10;
    }
    for(uint8_t k=0;k<8;k++){
        uint8_t j=(k+1)&7;
        display_drawLine(px[k],py[k],px[j],py[j],c);
    }
}

Le paramètre Asteroid *a. La fonction reçoit un pointeur sur un astéroïde, et non une copie de la structure. La notation a->x est un raccourci pour (*a).x : la flèche signifie « le champ x de la structure pointée par a ». Passer un pointeur évite de recopier les cinq champs de la structure à chaque appel ; on transmet simplement une adresse, ce qui est plus économe en pile et en temps. Le second paramètre c est la couleur du trait, codée sur 16 bits (uint16_t, format RGB565) ; le pilote bas niveau de l'écran la convertira ensuite en trois octets 18 bits avant l'envoi sur le bus SPI.

Mise à l'échelle et translation. La première boucle calcule les huit sommets à l'écran. Le facteur (AST_RADIUS*astX[k])/10 met l'octogone à l'échelle : comme les constantes ont été définies pour un rayon 10, multiplier par AST_RADIUS (12) puis diviser par 10 redimensionne la forme au rayon réel souhaité. Le calcul reste entier (les astX/astY sont des entiers et AST_RADIUS aussi), donc rapide : aucune virgule flottante n'intervient ici. On ajoute ensuite la position du centre (int)a->x et (int)a->y : la conversion (int) tronque la partie décimale de la position flottante pour obtenir des coordonnées de pixels entières.

Tracé des côtés et l'astuce & 7. La seconde boucle relie chaque sommet k au suivant j. Le calcul j = (k+1)&7 est le point clé : &7 est un ET binaire avec le masque 7 (0b111), qui équivaut à un modulo 8. Lorsque k vaut 7, k+1 vaut 8, et 8 & 7 donne 0 : le dernier sommet se relie donc automatiquement au premier, fermant l'octogone. On évite ainsi un if particulier pour le dernier segment. Sur un PIC, un ET binaire est nettement moins coûteux qu'une opération de modulo % (qui implique une division), d'où ce choix. Chaque côté est tracé par display_drawLine, qui s'appuie sur l'algorithme de Bresenham fourni par la bibliothèque graphique.

La détection des collisions

La détection des collisions constitue le cœur de l'interaction physique du jeu : c'est elle qui décide si un projectile détruit un astéroïde (et fait monter le score) et si un astéroïde percute le vaisseau (et provoque le GAME OVER). Sur un microcontrôleur PIC16F18877 cadencé à 32 MHz (FOSC = 32 MHz, soit un cycle instruction Tcy = 125 ns) et dépourvu d'unité de calcul flottant matérielle, le défi n'est pas seulement de détecter correctement les contacts, mais de le faire sans opération coûteuse. La stratégie retenue applique fidèlement le fil rouge du projet : modéliser chaque objet par un cercle et comparer des distances au carré pour éviter toute racine carrée. Ce chapitre détaille le test élémentaire collision(), la fonction d'orchestration collisions(), puis la justification mathématique du modèle en cercles.

Le test de base : la fonction collision()

Le principe géométrique est simple. Deux disques se touchent (ou se chevauchent) lorsque la distance qui sépare leurs centres est inférieure ou égale à la somme de leurs rayons. Si l'on note les deux centres (x1, y1) et (x2, y2), de rayons r1 et r2, la condition de contact s'écrit :

distance <= r1 + r2

avec distance = sqrt( (x1 - x2)^2 + (y1 - y2)^2 ).

Le calcul direct de cette condition demanderait une racine carrée (sqrtf), opération très lente sur un PIC8 bits sans FPU, et appelée potentiellement plusieurs fois par tour de boucle. Chaque appel à sqrtf se traduit en effet par une routine logicielle de la bibliothèque mathématique de XC8, soit des dizaines voire des centaines de cycles, là où une multiplication entière ou flottante simple reste bien plus économique. L'optimisation clé consiste donc à élever les deux membres de l'inégalité au carré. On compare alors des distances au carré, sans jamais extraire de racine. La condition devient :

(x1 - x2)^2 + (y1 - y2)^2 <= (r1 + r2)^2

Cette transformation est exacte : elle ne change ni le résultat logique, ni la précision, elle supprime simplement l'opération coûteuse. La fonction C s'écrit ainsi :

bool collision(float x1,float y1,float r1,float x2,float y2,float r2){
    float dx=x1-x2;
    float dy=y1-y2;
    float r=r1+r2;
    return (dx*dx+dy*dy) <= (r*r);
}

Détaillons ligne par ligne ce que fait ce bloc et pourquoi chaque choix a été fait.

• bool collision(float x1,float y1,float r1,float x2,float y2,float r2) déclare une fonction qui renvoie un booléen (le contact a lieu ou non) et reçoit les centres et rayons des deux objets à tester. Le passage par valeur convient ici : les six paramètres sont de petits scalaires, et la fonction ne modifie rien à l'extérieur.
• float dx=x1-x2; calcule l'écart horizontal entre les deux centres. On stocke ce résultat dans une variable locale plutôt que de le recalculer, ce qui évite de refaire deux soustractions identiques plus loin.
• float dy=y1-y2; calcule de même l'écart vertical. À ce stade, le vecteur (dx, dy) joint le centre 2 au centre 1.
• float r=r1+r2; précalcule la somme des rayons. C'est la distance de contact recherchée. La mettre dans une variable évite de l'additionner deux fois et rend la ligne de retour plus lisible.
• return (dx*dx+dy*dy) <= (r*r); évalue d'un côté le carré de la distance réelle (dx*dx + dy*dy) et de l'autre le carré de la distance de contact (r*r), puis renvoie le booléen true si le premier est inférieur ou égal au second. Aucune racine carrée n'apparaît : c'est tout l'intérêt de comparer les carrés.

Les coordonnées sont des float car les positions des projectiles et des astéroïdes évoluent par petits incréments de vitesse (BULLET_SPEED = 9.0, AST_SPEED = 4.0) et seraient mal représentées par des entiers. En revanche, les seules opérations effectuées ici sont trois soustractions/additions, trois multiplications et une comparaison, toutes nettement moins pénalisantes qu'une racine carrée. La fonction reste donc parfaitement utilisable à chaque itération de la boucle de jeu.

Pourquoi un modèle en cercles et la démonstration des carrés

Le vaisseau est en réalité un triangle et l'astéroïde un octogone (huit sommets précalculés dans les tableaux astX et astY, de rayon 10, mis à l'échelle x AST_RADIUS/10). On aurait pu calculer des intersections exactes entre ces polygones, mais ce serait inutilement complexe et coûteux. Le choix d'un cercle englobant (boundary circle) est ici parfaitement justifié : il est simple à coder, très rapide à évaluer, et suffisamment fidèle pour un jeu d'arcade où les objets sont petits et les contacts francs. Un cercle de rayon bien choisi (SHIP_RADIUS = 18, AST_RADIUS = 12) approxime convenablement l'encombrement réel de chaque forme, et l'imprécision résiduelle reste imperceptible en pratique. Ce compromis entre exactitude géométrique et coût de calcul est exactement ce qu'impose un microcontrôleur lent.

Reste à justifier rigoureusement que comparer les carrés équivaut à comparer les distances. Soit d la distance entre les centres et r la somme des rayons. Par construction, d est une distance donc d >= 0, et r est une somme de rayons donc r >= 0. On veut montrer que :

d <= r si et seulement si d^2 <= r^2

La fonction qui à un nombre positif associe son carré est strictement croissante sur l'ensemble des réels positifs ou nuls : si l'on augmente une grandeur positive, son carré augmente aussi. Plus formellement, on peut écrire la différence des carrés comme un produit :

r^2 - d^2 = (r - d)(r + d)

Le facteur (r + d) est positif ou nul puisque d et r le sont. Le signe de r^2 - d^2 est donc entièrement déterminé par le signe de (r - d). Si d <= r, alors (r - d) >= 0 et le produit (r - d)(r + d) >= 0, donc r^2 >= d^2, c'est-à-dire d^2 <= r^2. Réciproquement, si d^2 <= r^2, alors (r - d)(r + d) >= 0 ; comme (r + d) >= 0, le facteur (r - d) ne peut être que positif ou nul, donc d <= r. Les deux conditions sont bien équivalentes.