Les Verrous de Collision du TIA de l’Atari 2600 alimentent la Détection de Sprite de Raiders of the Lost Ark

À l’intérieur d’un classique basculé sur 8 Ko F8: des verrous par pixel, des scanlines de 76 cycles et les flux de travail de l’émulateur qui expliquent chaque coup, ramassage, et glissement sur le mur

Vous le ressentez le moment où Indy frôle un mur ou que sa “main” à l’écran s’empare d’un artefact sur un piédestal: Raiders of the Lost Ark sur l’Atari 2600 vit et meurt par les collisions au niveau du matériel. Pas de boîtes englobantes. Pas de physique complexe en mathématiques. Le jeu s’appuie sur les verrous de collision du TIA — des bascules minuscules qui se mettent en place lorsque des pixels à l’écran se rencontrent précisément au même instant pendant une scanline. Ces verrous alimentent silencieusement chaque coup, ramassage, et glissement dans un jeu de 1982 compressé en 8 Ko de ROM et 128 octets de RAM.

Ce n’est pas de la nostalgie; c’est un design dicté par le matériel. Le CPU 6507 de la 2600 a 76 cycles pour desservir chaque scanline pendant que le TIA dessine l’image du téléviseur. Toute logique de jeu qui n’est pas parfaitement chronométrée risque de déchirer l’affichage. La détection des collisions devait être “gratuite” pendant le dessin et bon marché à consommer plus tard. Raiders se conforme avec un modèle qui est définitif sur ce système: véridique au niveau pixel, par paires, verrouillé jusqu’à libération, et indépendant de la priorité de dessin. Le comprendre clarifie comment les émulateurs reproduisent le comportement, comment les hacks restent compatibles, et ce qu’un remake fidèle aurait besoin de reproduire — ou de remplacer — dans un moteur moderne.

Les contraintes qui ont dicté la stratégie de collision de Raiders

Raiders est une cartouche de 8 Ko utilisant la commutation de banque de style F8 — un schéma 2600 courant qui bascule entre deux banques de 4 Ko à l’intérieur de l’espace d’adresse visible minuscule de 4 Ko du 6507. La RAM système est juste de 128 octets. Le TIA dessine la vidéo directement; le “kernel” du jeu doit configurer les positions des sprites et les données du champ de jeu ligne par ligne, dans les 76 cycles CPU par ligne. La plupart des logiques réelles du jeu, y compris les décisions de collision, fonctionnent pendant les périodes non visibles: le blanc vertical et la surbalayage.

Ces contraintes rendent les collisions logicielles impraticables. Les bitmasks par sprite ou les vérifications de boîtes englobantes balayées coûteraient des cycles et de l’espace de code que le jeu n’a pas — et compliqueraient le kernel chronométré des scanlines. Pendant ce temps, Raiders doit également jongler avec deux joysticks: l’un déplace Indy; un second manipule la “main” à l’écran, un interacteur ressemblant à un curseur pour les objets. Cette division s’adapte parfaitement à l’ensemble limité d’objets dessinables du TIA et à son système de collision matérielle.

Comment fonctionnent les verrous de collision du TIA — et pourquoi ils sont définitifs

Le TIA offre une détection de collision en matériel. Lorsque deux pixels opaques de différentes classes d’objets TIA se chevauchent sur la même horloge colorée pendant l’affichage actif, un verrou correspondant se met en place. Le CPU lit ces verrous via des adresses dédiées et les efface explicitement via un seul registre de réinitialisation. De manière critique, les verrous reflètent le chevauchement physique, pas ce qui apparaît visuellement devant; la priorité d’affichage ne supprime pas la détection des collisions.

Les registres de collision:

• CXM0P ($30): Missile 0 avec Joueur 0/1
• CXM1P ($31): Missile 1 avec Joueur 0/1
• CXP0FB ($32): Joueur 0 avec Champ de jeu/Balle
• CXP1FB ($33): Joueur 1 avec Champ de jeu/Balle
• CXM0FB ($34): Missile 0 avec Champ de jeu/Balle
• CXM1FB ($35): Missile 1 avec Champ de jeu/Balle
• CXBLPF ($36): Balle avec Champ de jeu
• CXPPMM ($37): Joueur 0 avec Joueur 1 et missile-missile

Les verrous sont effacés en écrivant à CXCLR ($2C). Sémantiquement, chaque bit signifie “depuis le dernier effacement, au moins un chevauchement a eu lieu”. Il n’y a ni localisation, ni nombre, ni ordre temporel dans cette trame — juste oui/non pour cette paire.

Pourquoi cela est définitif sur la 2600 est simple: les vérifications des collisions se font entièrement dans le TIA pendant que le CPU “court contre le faisceau.” Après la partie visible, le CPU n’a besoin que de quelques lectures pour savoir quels types d’objets se sont touchés à un moment quelconque de cette trame.

Mapper Indy, la “main”, et le monde aux objets TIA

Un jeu 2600 a cinq types d’objets mobiles — deux joueurs (P0, P1), deux missiles (M0, M1), et une balle (BL) — plus le champ de jeu massif, en miroir (PF). Raiders les utilisent d’une manière cohérente avec à la fois son design et la pratique contemporaine 2600:

• Indy et les grands PNJ: Sprites de joueurs (P0/P1). Les collisions avec le terrain et la balle apparaissent dans CXP0FB/CXP1FB; les chevauchements joueur-joueur s’enregistrent dans CXPPMM.
• Le curseur “main”: un missile ou la balle. De nombreux titres 2600 réquisitionnent un missile ou la balle comme pointeur car le matériel peut le positionner indépendamment et ses collisions sont exposées dans les mêmes registres CX. Avec la main à second joystick de Raiders, détecter “curseur touchant un objet” ou “curseur sur une affordance environnementale” découle de CXM0P/CXM1P (missile-joueur), CXM0FB/CXM1FB (missile-champ de jeu/balle), ou, si la balle est utilisée pour le curseur, via les bits relatifs au FB dans les registres joueur/missile et CXBLPF pour balle-champ de jeu.
• Le monde: Champ de jeu pour les murs, barrières, et silhouettes de pièces. Comportement de blocage, de glissement le long des murs, et déclencheurs de portes dérivent des collisions joueur/missile/balle contre le champ de jeu — les registres CXFB et CXBLPF.

Cette correspondance permet au kernel de dessin de faire la partie coûteuse — générer des pixels; le TIA met en place les verrous passivement; et Raiders interprète quelques bits par trame pour dire ce qui s’est passé.

Filtrer, ordonner, et donner sens aux chevauchements ambigus

Le TIA vous dit seulement qu’une collision est arrivée « au moins une fois depuis le dernier effacement. » Si Indy a frôlé un mur et a simultanément chevauché un point culminant basé sur une balle, CXP0FB allumera les deux bits — mais le CPU ne peut pas dire lequel est arrivé en premier ou où. La priorité d’affichage ne compte pas non plus: une collision peut s’enregistrer même si un sprite est dessiné “derrière” un autre en raison des réglages de priorité.

Raiders gère ce minimalisme en logiciel:

• Effacer au bon moment: Écrire CXCLR juste avant le segment d’écran où les interactions comptent ou au début de la trame visible, pour que les verrous ne capturent que les contacts pertinents.
• Lire une fois par trame: Pendant le vblank/surbalayage, lire CXM0P…CXPPMM et masquer les bits non pertinents selon l’état du jeu (par exemple, ignorer missile–PF si la main est désactivée dans une pièce).
• Appliquer une priorité fixée: Décider des dangers avant les ramassages avant l’environnement, ou tout ordre déterministe qui a du sens. Puisque le matériel ne fournit aucune liste d’événements, le jeu impose une politique: les coups létaux priment sur tout; les ramassages nécessitent à la fois contact et un état “intentionnel”; les rebonds environnementaux ou fixent la position en dernier.

Cette politique est ce que les joueurs ressentent comme une interaction cohérente et prévisible même lorsque plusieurs chevauchements sont ambigus sous le capot.

Contact binaire, seuils, et cas limites de scanline

Il n’y a pas de rayon ajustable ou de “proximité” sur la 2600 — le contact est binaire et précis au pixel. Pour éviter les déclenchements scintillants, les jeux se basent souvent sur la persistance: nécessitent que le même verrou soit établi sur plusieurs trames consécutives, ou uniquement lorsque l’intention de mouvement correspond (par exemple, ne ramasser que si la main chevauche un objet et que le joueur appuie sur l’action du second joystick). La dynamique main-et-objet de Raiders demande pratiquement ce genre de filtrage additionnel.

Quelques cas limites importent:

• Les frolements à une scanline: Un chevauchement de ligne unique met le verrou en place pour cette trame. Si le jeu ne filtre pas, effleurer un danger pour une ligne ressemble à un coup. Les vérifications multi-trame aident à lisser les contacts de frôlement.
• Placement horizontal sous-pixel: Les positions fines d’HMOVE et les décalages signés de 4 bits de HMPx signifient que les verrous correspondent à de vrais décalages à l’écran, non pas à des étapes grossières de grille de byte. Cela rend la détection de collision précise sans travail CPU supplémentaire.
• Rareté verticale: Si l’art alterne les scanlines ou est dessiné particulièrement fin, il existe moins d’opportunités pour le chevauchement de pixels, ce qui peut rendre les interactions moins “collantes”. Les acteurs principaux sont généralement dessinés sur chaque scanline pertinente pour minimiser le “tunneling” interne de la trame.

En d’autres termes: les collisions sont exactes jusqu’aux pixels que vous voyez, ligne par ligne, avec toutes les forces et bizarreries que cela implique.

Résolution et chronométrage: là où Raiders gère réellement les collisions

Un kernel stable ne peut pas se permettre de surprises en milieu de trame. La 2600 vous donne 76 cycles par ligne visible pour configurer les graphismes de la ligne suivante; dépasser ce budget risque de perdre la synchronisation. Raiders reporte la résolution aux zones sûres:

• Effacer les verrous une fois par trame, souvent tôt.
• Dessiner la trame visible pendant que TIA met en place les verrous de collision automatiquement.
• Pendant le vblank/surbalayage, lire les registres CX une fois, appliquer le filtrage et l’ordre logiciel, puis résoudre.

La résolution elle-même est économe en budget: clamp-ou-glisse pour joueur-contre-mur, ne revenir que sur l’axe gênant si un mouvement pénétrerait le champ de jeu, puis traiter les objets et les déclencheurs cosmétiques. Le résultat est cette sensation familière de “glisse le long des murs”, née autant de la nécessité que du design.

Pourquoi les verrous gagnent en performance et mémoire

Dans un système avec 128 octets de RAM et 8 Ko de ROM, les verrous de collision du TIA sont un gain d’efficacité fortuit:

• Ils sont essentiellement gratuits pendant le dessin. Le TIA les met en place au fur et à mesure que les pixels sont composés.
• Le coût pour les consommer est minuscule. Le CPU lit une poignée d’adresses en vblank/surbalayage et écrit un seul effacement.
• Ils préservent la stabilité du kernel. Pas de boucles en milieu de trame ni de tests lourds en mathématiques intrusifs sur le budget de 76 cycles.

Contrastez cela avec les collisions logicielles: les tests de bitmask par scanline pour chaque paire de sprites ou une grille de tuiles approximative feraient exploser les ROM et les cycles. La détection continue des collisions pour empêcher le “tunneling” interne de la trame — courant dans les moteurs modernes — est redondante sur la 2600 parce que les chevauchements sont évalués à la granularité où l’écran est dessiné.

Bizarreries et notes régionales qui affectent la perception, pas la logique

Quelques réalités façonnent la façon dont les joueurs perçoivent les collisions sans changer la logique sous-jacente:

• NTSC vs. PAL: Les nombres de lignes, la palette et la cadence diffèrent par région, mais les sémantiques de collision du TIA sont identiques. Si le PAL semble un cheveu “plus lâche” ou “plus collant”, cela est dû au timing total du cadre et aux différences visuelles, pas un changement dans la façon dont les verrous se mettent en place.
• Coups cachés: Parce que la collision ignore la priorité de dessin, un chevauchement peut s’enregistrer même si un objet est visuellement occlus par un autre avec une priorité plus élevée. C’est un piège classique du 2600 et peut surprendre lors de modifications ou lors de la débogage de coups inattendus.
• Verrous périmés: Oublier de nettoyer via CXCLR transporte les collisions sur plusieurs trames, produisant des ramassages fantômes ou des murs qui semblent “solides” de façon permanente. C’est la première chose à vérifier lorsque le comportement devient étrange.

Ce ne sont pas des bugs dans les émulateurs ou les révisions ROM; ils sont intrinsèques à la façon dont fonctionne le TIA.

Test et débogage en 2026: Stella, Gopher2600, et Distella

La chaîne d’outils d’aujourd’hui rend la machinerie de collision de Raiders transparente — sans toucher à la ROM:

• Le débogueur de Stella expose les registres de collision en direct. Vous pouvez définir des points d’arrêt sur les lectures/écritures CX, regarder CXM0P…CXPPMM flip à mesure que la trame avance, et même “suspendre lorsque CXP0FB!= 0” pour atterrir sur le code vblank exact qui gère Indy-contre-murs. Le défilement image par image transforme ces verrous abstraits en décisions concrètes.
• Gopher2600 met l’accent sur le comportement du TIA fidèle aux cycles et le placement d’objets par scanline. C’est parfait pour valider quand un chevauchement pourrait se produire, surtout avec des kernels serrés ou des graphiques qui n’allument que certaines lignes.
• Distella désassemble la ROM de Raiders. Rechercher des lectures de $30–$37 et des écritures à $2C localise le traitement des collisions et l’ordre de résolution du jeu. Ces ancres sont là où les modifications réussissent — en respectant le timing et l’état — ou se heurtent à des contraintes invisibles.

Ensemble, ces flux de travail reflètent les meilleures pratiques des guides de programmation classiques tout en ajoutant une observabilité moderne. Ils soulignent également un point clé: exécuter la ROM originale en émulation préserve exactement le comportement des collisions parce que la logique réside dans le modèle TIA, que les émulateurs reproduisent par pixel et par scanline.

Émulation, modifications ROM, et ce qu’un remake moderne ferait réellement

Exécutez Raiders sous Stella ou Gopher2600 et vous obtenez le même système de collision par pixel, verrouillé jusqu’au nettoyage, avec le même timing. Les émulateurs reproduisent la pipeline de composition du TIA et le comportement des verrous; les lectures et nettoyages de la ROM se produisent aux mêmes endroits relatifs à la trame. L’avantage pratique en 2026 est un meilleur outillage, pas un gameplay différent.

Les hacks de ROM qui modifient l’art, les couleurs, les cartes ou petites règles mais conservent le moteur original héritent des mêmes sémantiques de collision. Ils lisent toujours CXM0P…CXPPMM et écrivent CXCLR dans les mêmes fenêtres de trame et sont liés par la même ambiguïté “depuis-le-dernier-nettoyage”. Les hacks qui réutilisent la main, qui inversent le joueur qui rend Indy, ou qui redessignent les salles doivent respecter cet appariement et ce timing ou faire face à des bogues déroutants: coups invisibles dus à l’indépendance de la priorité, ou états fantômes dus à des nettoyages manqués.

Un remake de zéro avec le label “Raiders2600” ferait face à un choix. S’il intègre la ROM originale et un noyau 2600, les collisions se résument au modèle TIA par conception. S’il ne le fait pas, il doit remplacer les verrous par un logiciel:

• AABB en phase large pour joueur-contre-monde, avec des tests de bitmap en phase étroite pour les ramassages précis.
• Vérifications continues/balayées pour empêcher le tunneling à des vitesses plus élevées — inutiles sur la 2600 parce que les chevauchements se produisent ligne par ligne.
• Filtrage couche/masque pour refléter le schéma pair-à-pair du TIA mais avec un contrôle plus riche.
• Simulation à pas de temps fixe pour stabiliser les réponses — similaire en esprit au rythme verrouillé sur la trame de l’original.

Le résultat pourrait être remarquablement similaire, surtout avec la résolution clamp-et-glisse et l’ordre d’événement déterministe, mais ce serait une réimplémentation plutôt qu’une réutilisation du mécanisme original.

Un verdict concis sur le modèle de collision de Raiders

Raiders of the Lost Ark sur l’Atari 2600 est une étude de cas sur la manière de laisser le matériel faire le gros du travail. Les verrous de collision par pixel du TIA — qui se mettent en place à l’instant où deux classes de pixels se chevauchent, indifférents à la priorité de dessin, et verrouillés jusqu’à être nettoyés explicitement — pilotent un spectre complet d’interactions: les murs qui repoussent Indy, les dangers qui priment, et une main à second joystick qui “touche” les trésors.

Trois décisions de design le font fonctionner:

• Embrasser la vérité binaire, par trame: une poignée de bits CX lus une fois en vblank/surbalayage et un ordre logiciel discipliné pour résoudre l’ambiguïté.
• Garder la logique hors du kernel: dessiner pendant le budget de 76 cycles; penser pendant le blanc.
• Dépenser les cycles là où ils comptent: pas de tests de pixel logiciel; des résolutions clamp-et-glisse qui sont stables et bon marché.

Pour les émulateurs et les hacks, le mandat est simple: préserver les sémantiques et le timing des verrous et tout se met en place. Pour un remake, l’objectif est clair: reproduire le contact par pixel et la résolution déterministe, ou envoyer la ROM originale à l’intérieur d’un noyau fidèle.

La leçon durable est que les contraintes engendrent la clarté. Le modèle de collision de Raiders n’est pas seulement correct pour son époque — c’est un cours magistral pour obtenir des interactions décisives au pixel près gratuitement, puis faire juste assez en logiciel pour les faire ressentir comme une aventure. 🎮

Annexe: Référence rapide des registres de collision

Registre	Paire(s) verrouillée(s)
CXM0P ($30)	Missile 0 avec Joueur 0/1
CXM1P ($31)	Missile 1 avec Joueur 0/1
CXP0FB ($32)	Joueur 0 avec Champ de jeu/Balle
CXP1FB ($33)	Joueur 1 avec Champ de jeu/Balle
CXM0FB ($34)	Missile 0 avec Champ de jeu/Balle
CXM1FB ($35)	Missile 1 avec Champ de jeu/Balle
CXBLPF ($36)	Balle avec Champ de jeu
CXPPMM ($37)	Joueur 0 avec Joueur 1; missile–missile

Sources & Références