Mathématiquement, faire tourner un objet géométrique n’est pas fondamentalement compliqué. Tout bachelier sait qu’avec la trigonométrie dans le plan ou le produit vectoriel dans l’espace, on peut facilement s’en sortir. Avec les techniques de traitement des matrices, un autre outil tout aussi maitrisé est spécialement conçu par les mathématiciens pour qui l’outil matriciel est d’une évidence triviale. OK, j’avoue que dans ce préambule je frime outrageusement pour vous impressionner. N’en déduisez surtout pas que j’aligne aisément les équations de l’espace, bien au contraire. Toutefois, en informatique l’approche est différente. En effet, nos données ne sont pas des points rangés dans un espace cartésien, mais des Octets qui « se suivent en ligne » dans la mémoire du microcontrôleur. Trouver des traitements les moins boulimiques en code Objet n’est pas d’une évidence biblique, tout au moins pour votre narrateur quand il a désiré faire tourner des plans frontaux de 90° dans le sens horaire ou antihoraire. Pourtant j’avais imaginé que ce serait facile ! Arriver à scribouiller un code raisonnable qui fonctionne m’a pris au final pas mal de temps.
Traitement relatif à une rotation horaire.
Détailler le processus impose de le faire sur un exemple concret. Celui utilisé dans ce chapitre n’est pas du tout un thème visuel intégré dans le programme d’exploitation. Il s’agit d’une image particulière utilisée uniquement pour valider les lignes de code. Elle est conçue pour faciliter le repérage des divers PIXELs dans la matrice et leurs « déplacements » durant le traitement. La relation entre l’image et les éléments de la « matrice numérique » est ainsi plus immédiat.
• En Fig.53 est représentée à droite l’image en bleu clair telle que nous la désirons, c’est à dire ce qu’affichera le cube sur l’un des plans frontaux accueillant ce dessin lumineux.
• En Fig.53 à gauche précise « l’étalement latéral » des divers BITs constituant les huit octets du thème.
Un « 0 » logique correspondra à un point non allumé, et un « 1 » devra illuminer la LED concernée.
• Nous savons que pour visualiser un plan vertical, il faut effectuer un balayage de multiplexage. Compte tenu de l’agencement des procédures qui effectuent ce travail, l’image doit être transportée en RAM dans le tableau Empreinte [109]. Le balayage dynamique impose de disposer les Octets en inversant Haut et Bas ainsi que Gauche et Droite. C’est ce que montre la Fig.54 avec à gauche la présentation géométrique de la MATRICE des OCTETS. Dans cette représentation sont repérés les ordres des BITs avec à gauche le poids fort dans l’Octet et à droite le poids faible.
• Sur la Fig.55 à droite le dessin bleu traduit l’image telle que nous la désirons visualisée sur le cube quand elle aura tourné de 90° dans le sens horaire. Le dessin en couleurs pour sa part présente l’inversion que doit subir latéralement et en hauteur cette image pour se voir multiplexée correctement. La grille numérique à gauche indique comment les BITs doivent « se déplacer » dans la MATRICE pour occuper la bonne position. Chaque individu des points allumé conserve la couleur qu’il avait en Fig.54 pour repérer facilement le saut virtuel qu’il doit effectuer.
Comme on désire enchaîner un nombre quelconque de rotations, l’enchevêtrement déterminé sur la Fig.55 ne se fait pas dans Empreinte [109] qui sert à afficher, mais dans le tableau Original [109] chargé de conserver une image ainsi « réutilisable ».
La procédure de rotation ne modifie que les huit premiers octets dans Empreinte [I].
NOTE : Comme c’est précisé dans le programme source, créer une procédure unique faisant tourner de 90° dans le sens Antihoraire conduit à une taille de programme bien plus grande vu le nombre de test à effectuer. Cette procédure a finalement été abandonnée. Nous arrivons au terme de notre cheminement, le précieux cube attend avec impatience l’arrivée de Noël …
La fin est ici.
