Les sprites sur NES

[upsilandre]

Une petite video pour tout savoir sur les sprites NES. Qu'est ce que c'est, comment ca marche, quelle sont les limites et les tricks. Je fais un tour exhaustif mais ca reste relativement tout publique, pas besoin d'etre programmeur pour comprendre l'essentiel, c'est pour ca que je le met ici.

https://youtu.be/mbjwVQJX-NI

[Tryphon]

Je savais même pas que tu avais une chaîne Youtube.

Merci, je suis en train de télécharger les 8 épisodes (+ le reste) !

[upsilandre]

ouai je m'amuse un peu.
En plus maintenant avec le 1080p et 60fps de youtube on est bien servie pour montrer les choses avec précision (rien que parler du flickering, sur une video 30fps c'est compliqué)

[Invité]

bien tes video upsilandre (j'apprends plein de choses).   c'est super instructif... 

c'est marrant a beaucoup de tes interventions ici ou avec tes video, a chaque fois je me dis "mais comment il fait pour capter tous ces trucs ?"

good job en tout cas, pour les vid YT et tout ce que tu décortiques sur gamopat 

[upsilandre]

merci

[TotOOntHeMooN]

Un peut trop "répété", mais peut-être nécessaire pour expliquer l'envers du décors aux joueurs intéressés. 
Mais au final une belle initiative !  (ha oui, les sprites Coleco et MSX sont toujours en 16x16 / 32 octets)

[upsilandre]

oui exact, hier j'avais deja ajouté des corrections en annotation. Chaque fois que je visionne une video que je viens d'upload je vois plein truc a corriger donc je fou des annotations.
C'est pas fautes d'avoir deja ecrit des pavés sur le TMS9918 mais faut croire que c'etait y a trop longtemps deja. D'ailleurs ca m'avait surpris a l'epoque ce format 16x16, j'avais eu du mal a savoir ou etait loverflow par scanline sur le TMS9918 et il est sur le nombre de sprite et pas sur le nombre de pixel-sprite. Que tu sois en mode 8x8 ou 16x16 pour les sprites t'es toujours limité a 4 sprites du coup pour exploiter les capacités d'affichage par scanline (le plus important) y a que le mode 16x16 de valable. C'est un peu domage (le mode 8x8 aurait pu permetre l'affichage de 8 sprites et la ca aurait ete intéressant, apres avec 32 sprite ca peut faire juste d'ou probablement ce focus sur le format 16x16)
En plus y a le support du zoom x2 sur les sprites, fonction classique des consoles de l'epoque ( Atari2600, Odyssey2, Intellivision) pour compenser les faibles capacités en sprites et du coup ca créait encore plus de confusion sur ce format 16x16.
Au final pour tranché (c'est a dire savoir si la limite par scanline etait de 32 pixel-sprite ou 64 comme sur les autres consoles 8bit) j'avais ete obligé de scruter quelques jeux car dans les docs c'etait pas claire du tout de savoir si le TMS9918 pouvait afficher 4 veritable sprite 16x16 (et pas du 8x8 zoomé) sur la meme ligne et sans pouvoir en afficher plus en 8x8. Au final on a la meme capacité de pixel-sprite que pour les autres console 8bit (mais en 1bpp contre 2bpp sur NES et 4bpp sur SMS, si tu fais de la superposition de sprite pour augmenter un peu les couleurs ca se complique c'est certain)

Ce qu'on retrouve du TMS9918 dans les autres machines c'est surtout cette facon de multiplexer les sprites en hardware et donc de pouvoir gérer une liste de sprites a l'ecran qui est bien superieur a la capacité réel du pipeline du GPU contrairement a des GPU comme celui du C64 ou de l'intellivision (y en a pas beaucoup d'autre qui gére des sprites a l'epoque mais on peut ajouter les systeme Atari meme si c'est un peu different) et qui eux necessitent un multiplexage software si tu veux afficher plus de sprite a l'ecran que ne peut en supporter nativement le GPU.

Le plus intriguant c'est le Dot Clock a 5.37Mhz du TMS9918 qu'on retrouve ensuite sur toutes les consoles. C'est un bon choix de Dotclock qui permet de faire du 256 pixels (bien commode pour son format 8bit) tout en optimisant la visibilité (en evitant de gaché des pixels dans l'overscan ou presque) et puis il est x1.5 le color clock du NTSC.
Je me suis toujours demandé si ce dot clock etait né avec le TMS9918 ou si il a deja existé en arcade. Y a pas mal de resolution 256 pixels en arcade pour des raisons evidentes mais ceux que j'avais trouvé avaient des dot clock different. J'ai pas suffisement creusé mais ca serait intéressant de savoir (vu le nombre de hardware d'arcade ca serait étonnant que ca n'existe pas deja en arcade)

[upsilandre]

Tiens d'ailleurs comme je t'ai sous la main, est ce que tu connais un jeu sur Coleco ou MSX qui exploite le trick de l'overflow pour faire disparaitre partiellement un sprite et faire un effet?
Je me suis mis en tete de chercher le premier jeu qui a exploité cela a son avantage (un trick qui est donc propre a cette grande famille TMS9918 et ce multiplexage hardware)
Pour l'instant j'en suis a Zelda (donc Fevrier 1986) faudrait remonté plus haut.

[TotOOntHeMooN]

Je n'ai pas d'exemple en tête... Dans les shoots, il est courant d'afficher certains sprites une frame sur deux et/ou de les faire boucler (tirs, shield, ...), mais c'est toujours dans le but de maitriser les disparitions en augmentant virtuellementla quantité à l'écran.

[upsilandre]

Je parle vraiment de l'overflow par scanline, de ce trick la:
https://www.youtube.com/watch?v=mbjwVQJX-NI&feature=youtu.be&t=58m04s

J'aimerais bien savoir si c'est une invention de Nakago dans Zelda ou si ca existait avant.
Aller creuse toi la tete, je compte sur toi (ou n'importe qui qui connait bien le catalogue Coleco/MSX)
Ou meme juste me citer de jeux qui meriteraient que je jete un oeil au cas ou.

[upsilandre]

Petit illustration en gif du trick de l'overflow





Premier jeu a l'utiliser ou pas?

[Stef]

Je ne connais pas assez la ludothèque NES et systèmes antérieurs pour me prononcer... Sur MD un bon nombre de jeux utilisent cette astuce. En fait tu as même une "feature" (difficile de savoir si c'est une vraie feature ou un bug du VDP) sur les sprites pour activer le masking sur certains sprites (en gros on les fait précéder par un sprite qui a une position X bien particulière et le masking ne fonctionne que sur les sprites qui suivent et qui sont sur les mêmes scanlines).

[Tryphon]

Sans mauvais jeu de mot, ça sent la feature

C'est trop gros et utile pour être un bug non ?

[TotOOntHeMooN]

Si je m'abuse, le VDP de la Coleco a une autre feature de la sorte. Tout ce qui passe derrière le sprite 0 est automatiquement effacé. De ce fait, un "Zelda" sur Coleco pourrait faire de même aussi bien verticalement qu'horizontalement. (comment procède Zelda lorsqu'il sort à gauche/droite ? Ils effacent ? recouvrent ?)

[upsilandre]

Je ne connais pas assez la ludothèque NES et systèmes antérieurs pour me prononcer... Sur MD un bon nombre de jeux utilisent cette astuce. En fait tu as même une "feature" (difficile de savoir si c'est une vraie feature ou un bug du VDP) sur les sprites pour activer le masking sur certains sprites (en gros on les fait précéder par un sprite qui a une position X bien particulière et le masking ne fonctionne que sur les sprites qui suivent et qui sont sur les mêmes scanlines).

C'est marrant je viens de me rappeler que mon tout premier message sur le forum c'etait justement pour signaler un bug de sprite dans la premiere demo de Papi Commando MD lié justement a cela. C'est pas si vieux mais depuis il a fait du chemin le Vetea .

Sur Master System ou Megadrive et SNES c'est deja moins intéressant ce genre de trick comparé a la NES ou la PC-Engine car sur ces 2 dernieres t'as meme pas de gestion de priorité a la tuile. Typiquement pour Zelda y aurait pas besoin de ce genre d'astuce sur Master System, suffit de mettre la bonne priorité de tuile sur le background.
Donc pour que ce soit utile sur Megadrive faut d'autre contexte encore plus specifique ou la ligne de mask est dynamique et pas forcement a la jonction entre tuiles. T'as des exemples en tete sur Megadrive?

[upsilandre]

Si je m'abuse, le VDP de la Coleco a une autre feature de la sorte. Tout ce qui passe derrière le sprite 0 est automatiquement effacé. De ce fait, un "Zelda" sur Coleco pourrait faire de même aussi bien verticalement qu'horizontalement.

C'est un peu curieux ce que tu dis (et j'ai du mal a imaginer comment ca pourrait servir sur la verticale?)
D'ailleurs ca se gere comment les priorité sprite/background sur le TMS9918? Je trouve rien, ni au niveau des sprites, ni au niveau des tuiles, ni meme au niveau des layers entier. tous semble fixe, c'est chaud (moi qui trouvais la gestion des priorités NES galère), j'avais jamais fait attention.
Du coup ca pourait etre encore plus utile ce trick de l'overflow et donc on devrait bien finir par trouver un jeu Coleco/SG1000/MSX qui l'a utilisé avant Zelda?

(comment procède Zelda lorsqu'il sort à gauche/droite ? Ils effacent ? recouvrent ?)

Je l'ai montré vite fais sur la video Zelda. Ils switchent simplement la priorité des sprites de link (pour que le background soit prioritaire) juste au moment de la transition dans la zone buffer sans background (la petite zone noir). Faut switcher la priorité des sprites juste a la bonne frame.
Ils auraient pu faire la meme chose en haut et en bas si le format des sprites avait ete 8x8.

Sinon l'autre solution qui marche dans tout les cas (a la vertical ou l'horizontal) c'est de cacher des sprites derriere le decors qui servent alors de mask en aillant une priorité superieurs aux autres sprite tout en etant une priorité inferieur au background (l'exemple de prince of persia), ca marche bien.
Ils auraient pu utiliser ca dans Zelda, d'ailleurs ca me donne envie maintenant de trouver le premier jeu qui a penser a cette autre trick (pour le coup ca sera sur NES forcement). Je sais que The goonies de Konami sortie le meme jour que Zelda utilise ce trick. Ca serait drole que ces 2 trick soit apparu pour la premiere fois le meme jour.

[Stef]

C'est marrant je viens de me rappeler que mon tout premier message sur le forum c'etait justement pour signaler un bug de sprite dans la premiere demo de Papi Commando MD lié justement a cela. C'est pas si vieux mais depuis il a fait du chemin le Vetea   .

Sur Master System ou Megadrive et SNES c'est deja moins intéressant ce genre de trick comparé a la NES ou la PC-Engine car sur ces 2 dernieres t'as meme pas de gestion de priorité a la tuile. Typiquement pour Zelda y aurait pas besoin de ce genre d'astuce sur Master System, suffit de mettre la bonne priorité de tuile sur le background.
Donc pour que ce soit utile sur Megadrive faut d'autre contexte encore plus specifique ou la ligne de mask est dynamique et pas forcement a la jonction entre tuiles. T'as des exemples en tete sur Megadrive?

C'est vrai que l'utilité est moindre mais ça peut avoir un intérêt dans des cas spécifiques.
Mickey mania utilise le sprite overflow pour masquer les sprites qui redescendent légèrement derrière lors de cette phase :
https://youtu.be/lLx_voBwoDk?t=102

Aussi Galaxy Force 2 l'utilise (la "feature" avec le sprite positionné à -128 en X) pour faire les effets de transition sur la selection du level :
https://youtu.be/qCt05DZRoqM?t=30

Plus classiquement sur l'écran d'intro de Sonic 1 (sprite overflow), pour faire apparaitre le sprite de Sonic derrière la banderole mais devant l'anneau :
https://youtu.be/jQ3r2nAHUA0?t=13

Dans Sonic 2 même chose sur l'écran d'intro (même raison) sauf que ce coup ci ils utilisent ce que j'appelle le "complexe priority" (un sprite en priorité low qui est positionné devant un sprite en priorité high) probablement pour régler plus finement le masque sur la banderole (2 sprites à masquer ce coup ci) :
https://youtu.be/QD7lkzIEULo?t=16

Pour ce dernier trick, ça revient à ce que tu décrivais ici :

Sinon l'autre solution qui marche dans tout les cas (a la vertical ou l'horizontal) c'est de cacher des sprites derriere le decors qui servent alors de mask en aillant une priorité superieurs aux autres sprite tout en etant une priorité inferieur au background (l'exemple de prince of persia), ca marche bien.

[upsilandre]

Merci.
La je tente de remonter toutes la liste de jeux Famicom. 83 et 84 c'est vite bouclé y a quasiment rien. Faut surtout que je fasse 85, y a deja plus de choses.

[upsilandre]

Bon j'ai fini d'ecumer tous les jeux Famicom.
J'ai trouver aucun jeu qui utilisent le trick de l'overflow avant Zelda, pour la NES c'est reglé je pense.

Par contre j'ai quand meme réussit a trouver un jeu qui avait deja utilisé le trick des priorités complexes 2 mois avant The goonies:




Et c'est l'adaptation de Karateka sur Famicom en decembre 1985:



Donc celui la c'est vraiment le premier puisque ce trick on peut pas le retrouver sur MSX, Coleco ou SG-1000 (par contre peut etre sur C64, a voir).


Et bien plus tard la version Prince of Persia qui l'utilise de facon plus poussé:




Sinon comme d'hab ca m'a permis de trouver d'autre perle comme ce jeu qui a le culot d'utiliser ni scrolling hardware ni aucun sprites hardware (pas un seul), best utilisation de la Famicom ever!

https://youtu.be/ELACz9Pg90U


J'ai trouvé aussi un jeu japonais qui 3 mois apres a repiqué l'aspect graphique des buissons/nuages de Super Mario, rigolo.

[Flo4428]

Merci pour toutes ces info !

aouch il est tard j'ai du mal a gardé les yeux ouvert   mais c'est très intéressant :)

[Stef]

Bon j'ai fini d'ecumer tous les jeux Famicom.
J'ai trouver aucun jeu qui utilisent le trick de l'overflow avant Zelda, pour la NES c'est reglé je pense.

Par contre j'ai quand meme réussit a trouver un jeu qui avait deja utilisé le trick des priorités complexes 2 mois avant The goonies:

Bien joué Ca devait être la première fois que cette astuce était utilisée sur console. Par contre en arcade, possible que ça soit arrivé un peu plus tot.

Sinon incroyable ce jeu Bokosuka Wars sur NES ! Ils ont juste utilisé le tilemap, comme si on était sur un vulgaire micro avec des characteres qu'on peut redéfinir Bon en même temps il figure parmi les premiers jeux NES si je ne me plante pas (1983)

[TotOOntHeMooN]

Clair, ça pourrait-être un jeu ZX Spectrum!

[Tryphon]

C'est peut-être un portage fait vite fait d'un jeu micro où il était codé comme ça ?

[Stef]

Peut être mais dans tout les cas c'est extrêmement paresseux..

[upsilandre]

Sinon incroyable ce jeu Bokosuka Wars sur NES ! Ils ont juste utilisé le tilemap, comme si on était sur un vulgaire micro avec des characteres qu'on peut redéfinir Bon en même temps il figure parmi les premiers jeux NES si je ne me plante pas (1983)

Decembre 85, 2 ans et demi apres la sortie de la Famicom et 2 mois avant Zelda
J'en ai vu des jeux NES pourri mais celui la est pas mal.

[Invité]

je serai bien curieux de savoir ce qu'il y a derriere les stages de battletoads (le stage des serpents entre autres), et l'effet de zoom dans 3d worldrunner..un jour peut-être

[lincruste]

Putain c'est génial, merci.

[upsilandre]

J'ai pas pu resister a jouer a Bokosuka, j'ai fais une partie complete. C'est du génie.
La NES apporte enfin le scrolling hardware dans le salon >> faisont un jeu qui scroll en software!
La NES pousse le support des sprites hardware plus loin que jamais >> faisons un jeu animé en software sans sprite!
La NES offres un sound chip de qualité >> faisont une unique boucle de son de 5 secondes pour tout le jeu et qui n'exploite aucune des caracteristiques de la NES!
La NES propose un pad avec 4 boutons >> faisont un jeu de stratégie qui se joue avec un seul bouton!
Du génie. Tout ca avec un framerate a 3 fps (Sprite et scrolling sont synchro a 20 vbl, rien ne bouge pendant 20 frames) et du coup un input lag jusqu'a 40 frames!! (666 ms de lag, l'input lag du diable)
Et y a qu'un seul champ de bataille qu'on rejoue en boucle. Je parle pas du HUD qui est a la hauteur du reste

Cela dit le jeu n'est pas inintéressant, on peut se prendre au jeu (contrairement a d'autre). L'objectif est simple, parcourir tout le champ de bataille qui s'etend vers la gauche (600 metres a franchir pour trouver le boss) sans mourir, en esquivant au maximum les combats dont l'issue est majoritairement random (au total 180 ennemis sur le champ de bataille) et on est game over dès la premiere defaite.
On recrute divers allié sur le terrain et ont finis par diriger un petit bataillon (composé de 2 classes, soldat et chevalier). C'est un jeu de gestion de deplacement (la difficulté etant qu'on deplace tous les personnages d'une meme classe en meme temps) mais le gamedesign n'etant lui meme pas vraiment terminé ca devient vite penible a l'usage. Rien que l'input lag c'est insupportable pour du jeu temps réel (c'est pas du tour par tour meme si les ennemis n'attaque pas, c'est toi qui engage les combats).

[upsilandre]

je serai bien curieux de savoir ce qu'il y a derriere les stages de battletoads (le stage des serpents entre autres), et l'effet de zoom dans 3d worldrunner..un jour peut-être

C'est pas faute d'avoir deja un paquet de gif de ces jeux.

[upsilandre]

Mais du coup comment ca se passe la gestion des priorités dans Risky Rick?
https://youtu.be/AWZ_quaEWgM

On a l'impression que le layer de sprite est en priorité basse par rapport au background mais je trouve pas d'information. Dans les attributs de sprite je trouve rien, y a pas d'attribut pour les tuiles et dans le setting du GPU je trouva pas non plus de flag qui permettrait de changer la priorité du layer sprite. Tout semble figé au niveau des priorités. Ca m'intrigue les priorités sur le TMS9918, je me rend compte que je m'y suis jamais intéressé.