Sur Amiga, le trainer était essentiellement un menu enjolivé par un FX et une musique, qui permettait d'activer des options pour tricher dans un jeu : "Vie illimitées: On/Off", et ainsi de suite. Dans bien des cas, le trainer a pu être le seul moyen de parvenir à profiter totalement d'un jeu sans y passer trop de temps, vu la difficulté. Ne termine pas Shadow of the Beast qui veut...

Dans la continuité d'un programme d'hommages aux différentes figures de la scène, voici Scoopex "THREE", un trainer produit pour le fameux StingRay du glorieux groupe Scoopex. Après Scoopex "TWO" rendant hommage aux graphistes, un hommage aux crackers, donc.

Comme on pourra le constater, l'originalité a pris ici le pas sur la technique. Du moins en apparence, car en matière de programmation du hardware en assembleur sur Amiga, tout devient finalement assez technique rapidement !

Code, data et explications dans tout ce qui suit...

Mise à jour du 08/12/2019 : Le menu a été magnifiquement porté sur Flashtro. C'est ici !

Ce menu n'a toujours pas été utilisé par StingRay, mais comme dans le cas de Scoopex "ONE" j'ai jugé qu'après des mois d'attente, il était nécessaire... de ne plus attendre. A priori, il devrait être utilisé sous peu. On verra bien...

A écouter en lisant l'article...

Cliquez ici pour télécharger l'archive contenant le code et les données du trainer.

Précisons d'emblée deux choses pour éviter les déceptions :

• le code est celui du menu du trainer, et pas du trainer à proprement parler, au sens du code qui altère le code du jeu alors qu'il est exécuté ;
• le tileset n'est pas compris, mais je donne des instructions à la fin de cet article pour le recréer.

Depuis le jour où j'ai fait la découverte émerveillée d'Ultima III: Exodus sur l'affichage CGA d'un PC1512, je voue une admiration sans borne à Richard Garriott, dit "Lord British".

Inutile de dire que cette admiration s'est renforcée avec la découverte, cette fois sur Amiga, de Ultima IV: Quest of the Avatar puis de Ultima V: Warriors of Destiny. Je ne peux contempler les cartes en tissus de ces jeux - oui, je ne suis pas un pirate : j'ai les originaux, môssieur ! - sans écraser une larme en souvenir des heures joyeuses passées à explorer les recoins de Britannia. C'est dire.

Il m'a toujours semblé que le potentiel de ces jeux a été sous-estimé, tout particulièrement le quatrième opus. Enfin diable ! ne présentait-il pas un caractère unique du fait qu'il contraignait le joueur à se plier à une éthique pour gagner ? Par la suite, je n'ai pas rencontré de jeux conçus de la sorte, et j'ai toujours pensé qu'un jour, le jeu vidéo en général trouverait son utilisation en tant qu'outil de propagande. D'ailleurs, j'avais développé ce propos dans un papier programmatique intitulé Le jeu vidéo au service de la communication, dans lequel il faudrait que je me replonge. Ceci étant, c'était en 2001, avant que l'histoire ne montre que les réseaux sociaux constituent un vecteur bien plus facile à utiliser...

Mais revenons à nos moutons. De toute cette série, c'est Ultima V qui a toujours eu ma préférence. Cela tient non seulement à la richesse du scénario élaboré par Richard Garriott, mais aussi à la beauté des graphismes produits par Denis Loubet et de Doug Wike :

Pas la musique ? Non, car sur ce point, je dois dire que sur Amiga, nous n'avons pas été gâtés. Je me souviens qu'après avoir attendu des mois, si ce n'est des années, que le jeu sorte enfin sur ma machine préférée, pour en faire l'acquisition à la Fnac - je me vois encore prendre la boîte dans le rayon aux Halles -, j'avais constaté avec dépit que les musiques n'étaient pas celles que j'avais pu écouter sur Atari ST. Au lieu de plusieurs morceaux tous plus géniaux les uns que les autres, il n'y avait qu'un morceau, certes pas mal, mais faisant perdre au jeu une grande part de sa variété. Enfin, bref, du moins le jeu n'était-il pas bogué comme sur Atari ST, et j'avais tout de même pu me foutre de la gueule d'un bon copain possédant cette machine quand, après ce temps d'attente qu'il n'avait manqué de me faire sentir comme le signe de la prévalence de sa machine sur la mienne, j'avais pu me vanter d'avoir terminé le jeu, et pas lui. Enfants...

Tout cela pour dire qu'il fallait rendre hommage à Ultima V avant de passer outre.

Or j'échange un jour avec le fameux StingRay du glorieux groupe Scoopex, et voici qu'il me propose de réaliser un trainer. Pour ceux qui l'ignorent, StingRay est l'un de ces brillants coders qui contribuent à la préservation du patrimoine de l'Amiga en reprenant méthodiquement les jeux pour en produire des versions qui peuvent être exécutées depuis un disque dur avec WHDLoad, avec trainer quand ils en étaient jusqu'alors dépourvus. Par exemple, Ultima V, pas plus tard qu'en avril 2018. Il faut disposer de l'original.

Je cogite un instant, et il me vient l'idée d'un trainer pour le moins original, puisqu'il consisterait à doubler l'inévitable menu non pas d'un FX, mais de toute une animation à base de tiles d'Ultima V. Il s'agirait de suivre un joueur qui se baladerait gentiment, avant que des streums lui tombent dessus. Là-dessus, il se ferait défoncer grave la gueule, et implorerait pitié pour être trainé par StingRay. Bam ! Il hériterait de la totale, et vêtu des pieds à la tête d'un matos de ouf, il mettrait une rouste aux affreux. C'est le pitch.

L'idée plaît à StingRay pour son originalité, et je me lance dans la réalisation, avec d'autant plus d'intérêt que j'étais en train de développer un Ultima-like à base de JavaScript et de WebGL - que je finirai bien par terminer un jour ? Du moins ce trainer m'aura-t-il déjà donné l'occasion de coder tout un éditeur de cartes à base de tiles, comme on le verra plus loin.

Sur la base de l'expression des besoins de StingRay, le trainer peut proposer au joueur deux types de paramètres en pagaïe :

• une valeur entière, par défaut comprise dans l'intervalle [0, 255], mais qu'il est possible de borner dans un intervelle quelconque plus petit ;
• une valeur booléenne.

Par ailleurs, tout paramètre peut avoir une quelconque valeur par défaut.

La petite difficulté était de permettre à StingRay de facilement rédiger le contenu des pages du menu. Le mieux était d'être aussi WYSIWYG que possible, et donc de lui permettre d'entrelacer des lignes de texte, des lignes de paramètres, mais aussi des lignes permettant de naviguer dans le menu : aller à l'éventuelle page précédente, à l'éventuelle page suivante, quitter le trainer.

Pour cette raison, les lignes du menu sont déclarées dans les données sous la forme de structures :

<text>, 0, PARAM_NONE	Simple ligne de texte
<text>, 0, PARAM_BOOL, <value>	Ligne d'un paramètre booléen (0 : vrai, -1: faux)
<text>, 0, PARAM_INT, <value>, <min>, <max>	Ligne d'un paramètre entier borné
<text>, 0, PARAM_PREV	Ligne d'un lien vers la page précédente
<text>, 0, PARAM_NEXT	Ligne d'un lien vers la page suivante
<text>, 0, PARAM_QUIT	Ligne d'un lien pour quitter le trainer
0, PARAM_NONE	Ligne vide

Par exemple, pour la première page - chaque page se termine par un -1 et l'ensemble des pages se termine par un -1 supplémentaire :

	DC.B 0,PARAM_NONE
	DC.B "  .oO Idea & Opcodes: Yragael Oo.",0,PARAM_NONE
	DC.B "oO. Paintings: Loubet &| Wike .Oo",0,PARAM_NONE
	DC.B "  .Oo    Bells & Horns: JMD   oO.",0,PARAM_NONE
	DC.B 0,PARAM_NONE
	DC.B "The menu may contain lines of",0,PARAM_NONE
	DC.B "text (32 chars), possibly empty,",0,PARAM_NONE
	DC.B "even between params.",0,PARAM_NONE
	DC.B 0,PARAM_NONE
	DC.B "There may be up to 255 params.",0,PARAM_NONE
	DC.B "A param is either BOOL or INT:",0,PARAM_NONE
	DC.B 0,PARAM_NONE
	DC.B "BOOL parameters:",0,PARAM_BOOL,-1
	DC.B "INT parameters:",0,PARAM_INT,0,0,10
	DC.B 0,PARAM_NONE
	DC.B "The menu may run on several pages.",0,PARAM_NONE
	DC.B "Just add PREV/NEXT option as",0,PARAM_NONE
	DC.B "required:",0,PARAM_NONE
	DC.B 0,PARAM_NONE
	DC.B "Next page",0,PARAM_NEXT
	DC.B 0,PARAM_NONE
	DC.B "And don't forget a QUIT option:",0,PARAM_NONE
	DC.B 0,PARAM_NONE
	DC.B "Quit",0,PARAM_QUIT
	DC.B -1

Au démarrage du trainer, les données qui décrivent ainsi le menu se trouvent à l'adresse menuData. Elles sont interprétées par la routine _menuSetup, qui génère une représentation du menu facile à manipuler à l'adresse menuPages, sous la forme d'une suite de structures de données dans le détail de laquelle il est inutile de rentrer. En particulier, ces structures sont utilisées par la routine _menuPrintPage pour afficher le contenu d'une page.

Une page du menu mobilise les bitplanes 5 et 6. Sur Amiga, le bitplane 6 est particulier, car le bit 5 qu'il introduit dans le codage de l'indice de la couleur d'un pixel ne permet pas d'afficher ce pixel dans une couleur qui peut être contrôlée. Le hardware considère que les couleurs 32 à 63 sont nécessairement des versions half-bright - moitié moins lumineuses - des couleurs 00 à 31. Ce fonctionnement est idéal pour le menu, car cela permet de l'afficher sur un fond qui laisse entrevoir les bitplanes de la première cut scene en semi-transparence sans avoir à intervenir dessus.

S'il est donc parfait que la luminosité des couleurs des pixels de la première cut scene soit atténuée, il ne faut pas oublier que le bitplane 6 affecte la luminosité des autres pixels, c'est-à-dire ceux du texte du menu. C'est pourquoi la routine _menuPrintPage, après avoir rempli de bits 1 le fond du menu dans le bitplane 6, écrit chaque caractère du menu dans le bitplane 5, et l'inverse de ce caractère dans le bitplane 6.

De toutes les difficultés auxquelles le codeur du hardware de l'Amiga peut être confronté, la gestion de la souris est l'une des plus inattendues. C'est qu'autant il est simple de tester si le bouton gauche de la souris est pressé ou relâché - tester le bit 6 de $BFE001 -, autant il est ardu de tester la même chose pour le bouton droit.

La lecture de cette section de l'Amiga Hardware Reference Manual permet de supposer que le bouton droit ne se gère pas comme le bouton gauche, car il n'est pas relié à une circuiterie du même genre : il est connecté à une broche analogique et non numérique.

De fait, à la lecture de cette annexe, il apparaît que lire l'état du bouton droit sur cette broche ne consiste pas simplement tester un bit dans un registre. S'il est bien possible de tester le bit 10 (DATLY) de POTGOR, ce n'est qu'après avoir demandé au hardware de traiter la broche comme numérique. Pour cela, il faut écrire dans un autre registre, POTGO. D'où la séquence suivante :

	move.w #$8400,POTGO(a5)	;OUTRY=1, DATLY=1
	btst #10,POTGOR(a5)		;Bit 10 % 8 = 2 de l'octet de poids fort, donc DATLY

L'annexe semble préciser qu'il faut en théorie attendre jusqu'à 300 ms entre les deux opérations. Toutefois, il n'apparaît pas que ce soit véritablement nécessaire. En tout cas, le code du trainer s'en dispense.

Et pour suivre le mouvement de la souris ? Comme bien expliqué ici, déplacer la souris entraîne l'incrémentation d'un compteur quand elle est déplacée vers le haut, et la décrémentation du même compteur quand elle est déplacée vers le bas. Il s'agit d'un compteur 8 bits, dont la valeur peut être lue dans JOY0DAT quand la souris est branchée sur le port 1 - ce qui généralement le cas.

Les précisions apportées ici permettent de comprendre qu'arrivé à saturation, le compteur reboucle. Le trainer en tient compte pour éviter produire cet effet indésirable où le mouvement de la souris vers le bas est interprété comme un mouvement vers le haut, et inversement. Par exemple, suite à un mouvement vers le bas, le passage de -126 à -127 permettrait bien de détecter une variation de -1 du compteur, assimilée à un mouvement vers le bas en tant qu'elle est négative. Toutefois, au mouvement suivant toujours vers le bas, le passage de -127 à 0 du compteur conduirait à détecter une variation de +127, assimilée à un mouvement vers le haut, en tant que cette variation est positive.

Dans le code du trainer, sachant que le compteur est lu à chaque trame - 1/50^ème de seconde -, et qu'un mouvement ne peut raisonnablement faire reboucler le compteur s'il démarre à 0, le compteur est réinitialisé à 0 à chaque fois qu'il est lu. Par ailleurs, un mouvement n'est détecté que si le compteur dépasse le seuil MENU_MOUSESENSITIVITY - qui en pratique est fixé au minimum. La réinitialisation s'effectue en écrivant dans un autre registre, JOY0TEST :

	move.w JOY0DAT(a5),d1
	and.w #$FC00,d1		;Les deux bits de poids faibles doivent être ignorés
	beq _menuMoveSelectorExit
	bgt _menuMoveSelectorDown
	cmpi.w #-MENU_MOUSESENSITIVITY,d1
	bgt _menuMoveSelectorDone
	;Rajouter ici le code pour gérer un mouvement vers le haut
	bra _menuMoveSelectorDone
_menuMoveSelectorDown:
	cmpi.w #MENU_MOUSESENSITIVITY,d1
	blt _menuMoveSelectorDone
	;Rajouter ici le code pour gérer un mouvement vers le bas	
_menuMoveSelectorDone:
	move.w #0,JOYTEST(a5)
_menuMoveSelectorExit:

Il peut paraître curieux d'ignorer les deux bits de poids faible du compteur, car cela apparaît comme une perte de précision. C'est que comme expliqué ici, ces deux bits ont un comportement très particulier pour permettre de lire dans JOY0DAT aussi bien l'amplitude d'un mouvement de la souris, que la direction d'une poussée sur un joystick. Par conséquent, le mieux est de les ignorer.

Cliquez ici pour récupérer le code minimal permettant de prendre le contrôle du hardware pour afficher un écran sur un bitplane, et exécuter une boucle qui teste la pression des boutons de la souris, les mouvements de cette dernière, et le relâchement d'une touche (ESC) pour quitter.

Comme je l'ai mentionné, cela fait longtemps que j'essaie de produire un Ultima-like en JavaScript et WebGL - mais "Je l'aurais un jour ! Je l'aurais !", c'est sûr. Ce projet personnel m'a donné l'occasion de développer pas mal d'outils - c'est d'ailleurs bien le problème, cette perpétuelle digression... -, et d'acquérir une très bonne connaissance de JavaScript et de certaines des API du navigateur, dont WebGL et Canvas. Partant, je savais que si je me lançais dans le développement d'un éditeur de cut scenes pour le trainer, je n'aurais aucune difficulté pour le terminer rapidement.

Or composer le décor et décrire l'animation d'une cut scene à l'aide de codes dans un éditeur de texte allait assurément vite se révéler d'autant plus fastidieux, que je n'étais pas du tout certain de la cut scene à créer, si bien qu'il faudrait très probablement me livrer à de nombreuses retouches. Bref, disposer d'un éditeur m'est vite apparu essentiel pour travailler confortablement.

J'ai donc produit cela :

Ce gentil petit éditeur permet de créer facilement une cut scene. A la base, il charge un fichier JSON - oubliez XML pour toujours -, qui contient simplement un tableau repérant les tiles dans le fichier PNG qui les regroupe. Un exemple d'entrée :

{"id":0, "name":"Grass", "type":0, "u":4, "v":0, "nbFrames":1}

Ce tableau permet de mettre à disposition les tiles à déposer à la souris dans chaque frame de la cut scene.

Pour simplifier la vie, l'éditeur est notamment doté des fonctionnalités suivantes :

• trois layers (le décor, les personnages, les objets) pour permettre de travailler facilement sur des entités d'un certain type sans ruiner ce qui a déjà été produit sur les autres ;
• copier-coller, effacement et remplissage de l'intégralité d'une frame limité aux layers actifs ;
• undo infini pour toutes les opérations sur les tiles dans une frame, et aussi pour toutes celles de gestion de l'animation ;
• chargement et export de la cut scene au format JSON, et export au format DC.B utilisé par le trainer ;
• lecture de l'animation à partir d'une frame quelconque et retour à cette frame à la fin ou en cas d'interruption.

Ce n'est pas très gros : au plus 2 500 lignes, JavaScript, HTML et CSS - mais de HTML et de CSS, il n'y en a presque pas - confondus. Je mettrai à disposition le code aussitôt que j'aurais produit une première version de l'Ultima-like évoqué.

Pour l'animation, il ne fallait pas chercher midi à quatorze heures : c'est du différentiel. Autrement dit, exception faite de la frame 0, une frame se réduit à la liste des tiles qu'elle remplace dans la frame précédente. Cette technique permet de limiter la taille du fichier décrivant l'animation, mais aussi les opérations graphiques requises pour transformer une frame en la suivante.

Par exemple, dans son format d'exportation DC.B, la frame 1 de la seconde cut scene se résume aux octets suivants :

;Frame 1

DC.B 2,9,14,29,9,15,75

Ce qui se lit ainsi. Il faut modifier 2 tiles :

• le tile (9, 14) devient le tile d'indice 29 dans la palette des tiles ;
• le tile (9, 15) devient le tile d'indice 75 dans la palette des tiles.

...ce qui revient à déplacer le personnage d'une case vers le haut, révélant le sentier sur lequel il est censé marcher. Bref, pour passer de la frame 0 à la frame 1, il suffit de redessiner deux tiles, plutôt que de tous les redessiner.

La technique est économique, mais elle présente un inconvénient majeur lors de l'édition. En effet, un tile n'est qu'un tile, c'est-à-dire une instance d'un tile d'une palette de tiles, et non une instance d'une entité comme un personnage, un objet, ou un élément de décor, qui aurait une existence au-delà de la frame. Pour le dire autrement, un tile est à une frame de la cut scene ce qu'un pixel est à une frame d'une animation : il n'est rien de plus qu'une image, il ne comporte aucune information autre que celle qu'il permet de l'afficher.

Cela pose une difficulté particulière pour animer les entités que les tiles représentent, car il n'y a aucun lien entre une instance de tile dans une frame et l'entité qu'il représente - aucune information dans l'instance y renvoie. Par conséquent, il est impossible de dire automatiquement - ie : dans le code - si un tile en (x0, y0) dans la frame N représente la même entité qu'un tile en (x1, y1) dans la frame N+1, voire même en (x0, y0) dans cette frame. Quand bien même c'est un dragon qui est représenté aux deux positions dans les frames, comment affirmer que c'est le même dragon ? Partant, comment dire que l'image du dragon dans la frame N+1 doit être l'image de l'animation d'un dragon qui suit celle utilisée dans la frame N dans cette animation ?

L'animation des tiles ne pouvant être déduite de celle des entités qu'ils représentent, cela fait qu'à chaque frame, il faut modifier à la main le tile représentant l'entité pour produire l'animation de l'entité en question. C'est assez lourd. De plus, si jamais une frame est supprimée ou insérée, il faut modifier à la main les tiles représentant cette entité dans toutes les frames suivantes, à défaut de quoi la continuité de l'animation de l'entité est rompue. Et cela, pour toutes les entités. Autant dire qu'il vaut mieux n'animer les entités entre les frames qu'à la fin, une fois que la liste des frames qui composent la cut scene est définitive.

Il est clair qu'au regard de cette contrainte, créer les cut scenes par animation différentielle sans éditeur aurait été un pur cauchemar.

Sur la manière dont une cut scene est jouée en assembleur, quelques précisions.

Il n'y a pas de double-buffer, pour deux raisons. Tout d'abord, il est pénible de gérer le double-buffer quand il s'agit de jouer du différentiel : à chaque trame, il faut faire progresser la frame que contient le buffer courant de deux frames dans la cut scene et non d'une. Ensuite, ce n'est pas la modification de quelques tiles qui va conduire à ce que le raster rattrape le CPU, produisant le flicker que le double-buffer permet d'éviter, comme je l'ai expliqué ici.

La seule partie un peu délicate du code, et sans doute la plus longue, est la routine _drawText, qui affiche le texte dans une bulle positionnée par rapport à un angle d'un tile désigné dans les données de la frame, sur le modèle suivant :

DC.B 24,9,14,1,"I must find",$0A,"the princess"

Ce qui se lit ainsi : afficher une chaîne de 24 caractères - comprenant éventuellement des retours à la ligne - par rapport à un angle du tile (9, 14). L'angle, et la position de la bulle par rapport à cet angle, est 1. Il y a quatre valeurs possibles :

La routine calcule les dimensions de la bulle, et combine ces informations avec son positionnement relatif pour en déduire les cordonnées où l'afficher.

C'est ici que le code devient un peu subtil, car la bulle n'est pas dessinée dans les bitplanes. Elle est dessinée dans le bitplanes de sprites qui sont accolés pour former un super-sprite. Pourquoi ? Parce que c'est drôle, et parce que cela permet d'éviter d'avoir à gérer du recover.

Pour ne pas s'emmerder outre-mesure, la bulle est tout de même dessinée dans des mini-bitplanes off-screen, et le contenu de ces mini-bitplanes est ensuite recopié, colonne de 16 pixels par colonne de 16 pixels, dans les bitplanes des sprites utilisés. Il aurait été beaucoup trop pénible que le code traçant le cadre, remplissant le fond et écrivant les caractères, fasse de sauts des bitplanes d'un sprite à ceux d'un autre sprite tous les 16 pixels...

Comme expliqué ici, le hardware de l'Amiga 500 peut afficher 8 sprites en quatre couleurs, dont une transparente, d'une largeur de 16 pixels et sur toute la hauteur de l'écran. Ainsi, la largeur maximale d'une bulle est de 16 * 8 = 128 pixels, ce qui fait 15 caractères en police 8x8 par ligne, 4 pixels étant réservés de part et d'autre pour le bord de la bulle. Cela suffit amplement pour les besoins du trainer : les personnages ne déclament pas du Dostoïevski.

La bannière est affichée durant la seconde cut scene exclusivement. Y défilent quelques messages qui n'ont rien de subliminal - on ne me fera pas le même procès qu'au générique du journal de 20 heures sur Antenne 2 en son temps !

Toujours écrit avec la volonté farouche d'éviter tout recover dans les bitplanes où la cut scene est affichée, le code dessine la bannière dans les bitplanes 5 à 6 où la cut scene n'est pas affichée. Le démarrage de l'animation de la bannière conduit donc à réactiver l'affichage de ces bitplanes...

;Show bitplanes 5 and 6

movea.l copperList,a0
move.w #(DISPLAY_DEPTH<<12)!$0200,10(a0)

...que la fin de l'animation de la bannière conduit à désactiver :

;Hide bitplanes 5 and 6

movea.l copperList,a0
move.w #((DISPLAY_DEPTH-2)<<12)!$0200,10(a0)

Les instructions précédentes tapent dans la Copper list, où elles modifient la valeur qu'une instruction MOVE écrit dans le registre BPLCON0, lequel permet de notamment de contrôler le nombre de bitplanes affichés.

Tout le code de gestion de la bannière a été factorisé pour resservir en d'autres occasions. Ainsi, il adopte un modèle avec lequel ceux qui ont lu le code de Scoopex "TWO" sont désormais familiers, à savoir :

• une routine de configuration (_bnrSetup) s'appuyant sur une structure de données (bnrSetupData) dont les offsets des différents champs sont identifiés par des constantes (OFFSET_BANNERSETUP_*) ;
• une routine d'étape (_bnrStep) s'appuyant sur une structure de données (bnrState) dont les offsets des différents champs sont identifiés par des constantes (OFFSET_BANNER_*) ;
• une routine de réinitialisation (_bnrReset) ;
• une routine de finalisation (_bnrEnd).

Moins pas souci d'économiser de l'espace en mémoire que de ne pas compliquer le design, la bannière utilise une police de caractères 16x16 qui n'est autre que la police 8x8 du menu et du scroll HiRes dont les dimensions sont doublées. C'est une solution du même genre que celle déjà mise en oeuvre ici, pour produire une police de même taille. D'ailleurs, c'est le même bout de code qui est utilisé pour créer cette police 16x16 à l'initialisation du trainer.

L'animation cyclique de squares déphasés, c'est un peu une marque de fabrique. J'ai utilisé cet effet dans presque toutes mes cracktros à l'époque, non seulement parce que je trouvais cela élégant, mais aussi et surtout parce que je ne pouvais recourir aux services d'un graphiste. Quand on ne sait pas dessiner, mieux vaut faire simple : c'est toute ma théorie du design.

Le trainer m'a donné l'occasion de recycler cet effet, que j'avais repris en 2016 quand je m'étais remis à programmer en assembleur le hardware de l'Amiga. L'idée était alors de produire un certain nombre d'effets, que j'assemblerai un jour dans une démo. Finalement, ils me servent petit à petit pour produire des productions plus modestes, mais des productions tout de même, comme ce trainer. Les cimetières sont plein de bien meilleurs codeurs qui seront ignorés à jamais, car ils n'ont jamais sorti quelque chose. Et du moins ce code ne sera-t-il ainsi pas perdu pour tout le monde.

L'effet est trivial. L'écran est découpé en squares. Chaque square est animé : en quelques images, ses dimensions se réduisent à presque rien. A chaque trame - ou plus selon la vitesse qu'on souhaite donner à l'effet -, l'animation de chaque square progresse d'une image, rebouclant au début si besoin. L'astuce consiste à déphaser les animations des squares, c'est-à-dire à les faire démarrer toujours à partir de la frame 0 - totalement vide -, mais à des instants différents. Cela permet de produire un motif général, comme ici où l'écran semble se gonfler et se dégonfler :

Plutôt que d'attendre avant de débuter l'animation d'un square, pourquoi ne pas simplement faire démarrer cette animation avec celle des autres, mais à une frame différente ? Parce que s'il en allait ainsi, la première frame de la transition serait composée de squares contenant des carrés de différentes tailles. Ce serait trop brutal ; mieux vaut qu'au démarrage de son animation, un square soit représenté par un carré de côté minimal.

Dans le trainer, l'effet permet de ménager une transition entre la fin de la seconde cut scene et sa reprise, histoire de marquer la fin :

Les frames de l'animation du square ont été générées à l'aide d'un petit outil HTML5 développé pour l'occasion :

Plus généralement, cet outil permet de générer ce type d'animation sur un certain nombre de bitplanes, et sous la forme de données RAW - les bitplanes d'une frame les uns après les autres -, ou RAWB - les bitplanes d'une frame entrelacés à chaque ligne. Les raisons d'être de ces formats ont été déjà été expliquées ici.

Le motif produit par les animations déphasées des squares a été élaboré dans un outil Excel, ici encore développé pour l'occasion. En associant une couleur à l'indice de la frame de départ de l'animation d'un square, cet outil permet de se faire facilement une idée de ce que sera l'effet produit à l'échelle de l'écran :

Les squares de la transition font 16 x 16. Leur motif est inversé, en ce sens où dans une frame de son animation, le square est un carré de bits 0 sur un fond de bits 1. Cela permet de masquer progressivement le décor tandis que l'animation des squares s'achève, la dernière frame de cette animation étant simplement un fond de bits 1. Pour produire ce masquage, les squares sont dessinés dans le bitplane 5. Ainsi, à la fin de la transition, la palette des pixels à l'écran ne s'étend plus des couleurs 00 à 15 issues de la palette des tiles, mais des couleurs 16 à 31, toutes fixées au noir.

La condition d'arrêt de la transition est que tous les squares soient opaques. Comme l'animation de chaque square démarre avec ou sans retard sur celle de la transition, il est difficile de calculer à l'avance la durée totale de la transition, exprimée en trames. Elle dépend de nombreux paramètres. Le fichier cutter.s contient des commentaires qui donnent plus de détails sur l'algorithme et ce sujet.

Tout comme le code de la bannière, celui de la transition a été factorisé pour resservir en d'autres occasions. Il est regroupé dans le fichier cutter.s :

_cutSetup	Routine d'initialisation s'appuyant sur une structure de données (cutSetupData) dont les offsets des différents champs sont identifiés par des constantes (OFFSET_CUTTERSETUP_*).
_cutStep	Routine d'étape s'appuyant sur une structure de données (cutState) dont les offsets des différents champs sont identifiés par des constantes (OFFSET_CUTTER_*).
_cutReset	Routine de réinitialisation.
_cutEnd	Routine de finalisation.

La programmation d'un pilote du clavier sur Amiga n'est pas la chose la plus aisée. J'ai déjà exposé ici dans le détail comment s'y prendre pour simplement récupérer le code d'une touche pressée puis relâchée, non seulement par interruption, mais aussi par polling. Dans ce trainer, c'est la seconde solution qui est retenue.

Le pilote gère les pressions suivies de relâchements des touches suivantes :

• durant le menu, la touche Espace fait basculer sur la seconde cut scene ;
• durant le menu, une touche correspondant à un chiffre - la rangée de touches au-dessus des lettres, pas celles du pavé numérique - fait jouer un morceau donné du module ;
• durant la seconde cut scene, la touche Espace fait basculer sur le menu sauf durant l'affichage de la bannière et la transition.

EMPTY_KEYBOARD:	MACRO
_keyboardFlush\@:
	btst #3,$BFED01
	beq _keyboardEmpty\@
	bset #6,$BFEE01
	WAIT_RASTER 2
	bclr #6,$BFEE01
	WAIT_RASTER 16		;Time required by CIA to move 8 bits from 10 keys keyboard buffer to SDR and set the interrupt bit in ICR
	bra _keyboardFlush\@
_keyboardEmpty\@:
	ENDM	

La musique

Le scroller