Auteur: @upsilandre

Ce contenu est la reproduction de ce thread Twitter.

Je vais vous dévoiler quelques secrets sur les clignotements de sprite. De quoi devenir un vrai spécialiste ! 🙂

Vous savez probablement que nos consoles qui embarquent des fonctions hardware d'affichage de sprite ont des limites...

Il y a plusieurs contraintes sur l'affichage des sprites mais la principale qui défini la capacité de ces hardwares c'est le nombre de sprite affichable sur la même ligne (ou de pixel-sprite) qui sur une NES correspond à 8 sprites de 8 pixels (= 64 pixels-sprite).

Cette forte contrainte par ligne est liée simplement au balayage de l'image qui se fait ligne par ligne à une vitesse très élevée et ne laisse que peu de temps pour préparer la prochaine (60 microsecondes).

Sur cette scène qui semble simple on peut déjà dénombrer 12 sprites !

C'est donc 4 de trop !

Le hardware de la NES (ou de la Master System) ne pouvant en afficher que 8, il y en a donc 4 qui ne pourront pas l'être et vont disparaître. On parle alors d'overflow de sprite par scanline 🙂.

C'est le programmeur qui choisit les sprites qui vont disparaître selon l'ordre dans lequel il va construire la liste de sprite qui définit les priorités de chacun.

Et son but va être d'alterner à chaque frame pour que ce ne soit pas toujours le même sprite qui disparaît.

C'est cette alternance choisie et provoquée volontairement par le programmeur qui va produire ce fameux clignotement de sprite (flickering) et nous permettre ainsi d'entrevoir tous les sprites malgré cette limite hardware.

Le clignotement n'est donc pas une conséquence directe de cette limite hardware. C'est quelque chose de provoqué et contrôlé par le programmeur. Si on ne fait pas cela ça donne ce type de disparition prolongée et on ne veut pas qu'un sprite disparaisse totalement de l'écran.

Si j'ai pris le temps de vous expliquer tout ça c'est uniquement pour ce dont je vais parler maintenant qui est le véritable sujet du thread 🙂

En effet parfois les programmeurs provoquent volontairement un overflow de sprite pour s'en servir comme effet graphique.

En effet ce type d'effet d'occlusion de sprite par le décors est compliqué à gérer sur NES de par la façon dont celle ci traite les priorités d'affichages entre les sprites et le background (ce type d'occlusion est plus simple à gérer sur Master System).

Et l'une des solutions pour faire disparaître le sprite de façon progressive c'est de produire volontairement une saturation de sprite sur toutes ces lignes.

On peut effectivement voir ici un paquet de 8 sprites volontairement superposés dans la marge gauche de l'image.

Ces sprites vides (et donc invisibles) créent un overflow sur toutes les lignes de l'image qui se trouve au-dessus de la porte et donc force la disparition du sprite de Link (et de tous les autres) sur ces lignes de l'écran.

J'appelle ça le trick de l'overflow 🙂.

Il existe d'autres méthodes pour faire de l'occlusion de sprite sur NES. Au moins 4 autres (par zone de transition utilisé ici pour les portes Est-Ouest, par priorité complexe, par bank switching, par découpage du sprite...).

Mais ce trick de l'overflow spécifiquement on peut le retrouver quand même dans d'autres jeux NES comme Castlevania 2 pour faire disparaître le sprite de Simon quand il marche dans les marécages...

..ou dans Felix The Cat et quelques autres.

Ce trick a déjà été utilisé avant Zelda. Après beaucoup de recherches je l'ai retrouvé seulement dans 4 jeux plus anciens. 2 jeux SG-1000 (dont H.E.R.O.) et 2 jeux Coleco (dont River Raid).

Ces machines en ont encore plus besoin que la NES car elles partagent le même chip graphique de Texas Instrument (avec aussi le MSX) qui n'a vraiment aucune fonction de priorité d'affichage entre sprite et background pour aider.

Si je parle de ce trick c'est aussi pour vous avertir de faire attention avec la fonction des émulateurs qui permet de s'affranchir des limites hardwares d'affichage de sprite (et donc du clignotement).

Car comme je viens de vous l'expliquer, cette limite hardware était donc aussi détournée par les programmeurs pour faire des effets visuels.

Si jamais vous activez cette option d'émulation sur Zelda ca risque de vous donner ce résultat ⬇️.

Sauf avec Mesen par exemple qui a une option pour adapter intelligemment (autant que possible) cette fonction selon la situation.

Voici un autre exemple de jeu NES ou le programmeur n'a pas implémenté le flickering des sprites. Les Double Dragon. De ce fait, sans routine de flickering, les sprites disparaissent littéralement (les jambes de Abobo et son coup de poing, invisibles). Ce n'est pas souhaitable.

Dans un BTA ce choix peut se justifier car la routine de flickering des sprites entre en conflit avec le Z-sorting qui est la routine qui classe et affiche les sprites dans l'ordre de profondeur (afin que les sprites plus proche s'affiche par dessus ceux qui sont plus loin).

Le flickering de sprite donne aussi encore plus d'importance aux 60 FPS dans les jeux NES car ça permet d'avoir un clignotement acceptable à 30 Hz. Alors que sur un jeu 30 FPS la plupart du temps le flickering sera alors à 15 Hz (ou 12.5 Hz en PAL) ce qui est plus embêtant.

À titre indicatif la capacité d'affichage en pixel-sprite par scanline sur les consoles 8-bit se limite à pouvoir couvrir un quart de la largeur de l'écran là où sur PCE/MD/SNES ça va être plutôt la largeur complète d'un écran et en arcade on s'approche plutôt de 3 écrans.

Pour voir l'intégralité des threads d'Upsilandre archivés sur ce site, c'est par ici.