La course contre le faisceau : l'Atari qui ne pouvait pas retenir une image

Imaginez écrire un programme qui doit rester parfaitement synchronisé avec un faisceau d'électrons fonçant à travers un tube de verre à plusieurs milliers de kilomètres par seconde. Prenez quelques millionièmes de seconde de retard et votre vaisseau se transforme en bouillie. Prenez de l'avance et il disparaît. Ce n'était pas une prouesse de démonstration : c'était simplement la façon de fabriquer un jeu vidéo sur l'Atari 2600, le boîtier façon bois qui a débarqué dans les salons en 1977 et appris à toute une génération ce que « Pong, mais à la maison » pouvait devenir. Le détail que la jaquette de la cartouche oublie de mentionner : la console n'avait absolument aucune mémoire pour stocker une image.

Une console sans nulle part où mettre l'image

La plupart des machines qui affichent quelque chose gardent un framebuffer : un bloc de mémoire contenant chaque pixel, que le circuit vidéo lit et peint en boucle, pendant que le programme le modifie tranquillement en arrière-plan. C'est la façon évidente de procéder. C'est aussi coûteux. En 1977, la mémoire valait une fortune, et les ingénieurs d'Atari étaient impitoyables sur les prix. Alors ils ont tout bonnement supprimé le framebuffer.

Le résultat frôle l'absurde. L'Atari 2600 dispose de 128 octets de RAM. Pas des kilo-octets — des octets. À peine de quoi retenir un meilleur score et la position de la balle. Il n'y a nulle part où ranger une image, parce qu'il n'y a pas d'image. Ce que vous voyez sur la télé n'existe nulle part à l'intérieur de la machine. Cela n'existe que pendant les quelque 63 microsecondes où le faisceau d'électrons balaie une seule ligne de l'écran — puis tout s'efface, et le programme doit inventer la ligne suivante à partir de rien.

La course contre le faisceau

Voici comment dessine une télévision des années 1970 : un canon à électrons tire à l'arrière du verre, balayant de gauche à droite pour éclairer une ligne horizontale, puis revient d'un coup pour attaquer la ligne du dessous. De haut en bas, soixante fois par seconde. Sur l'Atari, la puce qui dialogue avec la télé — le TIA, le Television Interface Adaptor — n'a ni patience ni mémoire. Elle peint ce que ses registres disent à l'instant présent, au pixel exact que le faisceau effleure.

Le travail du programmeur, donc : alimenter ces registres au pas cadencé du faisceau. Vous voulez que le milieu du vaisseau soit plus large que sa pointe ? Vous changez le registre de forme entre deux lignes, dans le mince intervalle où le faisceau est éteint et file vers le bord gauche. Les passionnés d'Atari appellent ça le balayage horizontal (horizontal blank), et il est d'une brièveté brutale. Chaque ligne offre au processeur environ 76 cycles machine au total ; seuls 22 environ tombent dans cet intervalle, et 160 pixels visibles sont déjà en train d'être tracés pendant que vous vous démenez pour préparer la ligne suivante. Les programmeurs comptaient littéralement les cycles à la main, comme un batteur compte la mesure, parce qu'un seul battement de retard mettait la mauvaise couleur au mauvais endroit. Ils ont baptisé ce numéro de funambule la course contre le faisceau (racing the beam), et c'est là que s'est forgée la réputation de virtuosité impossible de toute la console.

Pourquoi tout arrivait en bandes

Deux vérités ont façonné l'allure de presque chaque jeu Atari. D'abord, puisque le TIA ne retient qu'une ligne de graphismes à la fois, l'unité naturelle de conception était la bande horizontale. Changez les couleurs ligne après ligne et vous obteniez ces superbes ciels en dégradé ; laissez-les telles quelles et vous aviez des blocs plats. La console voulait presque vous faire penser en bandes.

Ensuite — et c'est le détail qui fait encore grincer des dents les ingénieurs — vous ne pouviez pas simplement indiquer à un sprite où aller. Pour déplacer un personnage horizontalement, vous déclenchiez un registre, et le moment du déclenchement, par rapport à la position du faisceau, décidait de la colonne. Mais le faisceau avance par sauts grossiers, si bien que le positionnement se calait sur l'une des quinze zones massives réparties sur l'écran. Pour glisser un sprite jusqu'à un pixel intermédiaire, il fallait lui fournir une valeur d'ajustement fin séparée. Oubliez cette étape et votre héros se téléporte à l'écran par bonds maladroits de quinze pixels. Ces mouvements saccadés et gauches des premiers jeux n'étaient pas du code bâclé : c'était le matériel qui transparaissait.

L'art de n'avoir rien

Ce qui est merveilleux, c'est ce que les programmeurs ont accompli malgré tout. Avec 128 octets, aucun framebuffer et une puce qui oubliait tout à chaque ligne, ils ont livré Pitfall!, Space Invaders et des jeux de course qui donnaient vraiment la sensation de courir. Le créateur de Pitfall! a fait tenir une jungle de 255 salles défilantes dans une cartouche de quatre kilo-octets en générant le monde à partir d'un seul nombre passé dans une astuce mathématique, faute de place pour le stocker. La contrainte n'a pas écrasé la créativité ; elle est devenue le médium, comme les quatorze vers d'un sonnet poussent les poètes à être plus tranchants, et non plus discrets.

Et voici la chute. Des décennies plus tard, le matériel est devenu généreux : des giga-octets de mémoire, des framebuffers partout, des GPU qui haussent les épaules devant des milliards de pixels. Puis une chose curieuse est arrivée — les développeurs indépendants modernes se sont mis à réintroduire les bandes, les sprites trapus, le scintillement des lignes de balayage, payant le prix fort pour des shaders qui imitent la lueur d'un tube cathodique. Les contraintes qui obligeaient jadis les programmeurs à disputer chaque point au faisceau sont aujourd'hui une esthétique que l'on poursuit volontairement. La machine incapable de retenir une image a fini par retenir quelque chose de plus durable : un look qu'on n'a jamais vraiment cessé d'aimer.