Oh ? Beaucoup moins alors parce que ca ne m'a jamais marque. Alors que la NES... Megaman ca y allait par exemple. C'est d'ailleurs un gros avantage pour moi de la Master System sur la NES.

Le clignotement, en tous cas sur NES, était dû à une limitation du hardware: la console ne peut dessiner que 8 sprites sur une même ligne, mais elle gère un système de priorités qui permet au programmeur de choisir quels sprites seront droppés à quelle image. Autrement dit, quand on dépasse les 8 sprites sur une même ligne, soit ils clignotent, soit 8 sont affichés normalement et les autres pas du tout.

Le chip vidéo de la console gère 64 sprites de 8x8 ou 8x16, sachant que la taille des sprites est un flag global -- autrement dit, soit tous les sprites font 8x8, soit tous les sprites font 8x16. Pas de super-moit-moit'. Chaque sprite peut avoir sa propre palette, mais là encore, la NES ne permet d'avoir que 4 palettes pour les sprites (et 4 pour les tiles du background) en même temps sur l'écran.


FF_Clad et les autres geeks du hard vont sans doute autant adorer que moi: Kain Xiorcal, sur le forum TheShizz, a il y a quelques temps posté une excellente analyse de l'"astuce Mega Man" dont je parlais dans mon post précédent. Et après, il a regardé jusqu'où on pouvait pousser le truc en sacrifiant des sprites hard pour améliorer la qualité graphique d'un seul objet: c'est là que ça se passe. Avec des hacks de ROM, des screenshots animés et tout, la classe!





Sérieusement, jetez-y un oeil (en Anglais, oeuf corse), c'est probablement le topic le plus intéressant que j'aie jamais lu sur les capacités techniques de la NES.
_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Ah, et j'oubliais: un sprite n'est qu'un cas particulier (bidimensionnel) de polygone. Donc oui, nos cartes graphiques state of the art gèrent une généralisation des sprites hardware (avec scaling et rotation, et à peu près tout arbitraires), en une quantité tellement importante que ça n'a plus la moindre importance pour un jeu 2D.
_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Ben, pour etre honnete je comprend pas trop pourquoi il y a un nombre limite de tiles pour commencer. C'est une restriction de la memoire video ?

Sur Amiga, ce genre de probleme n'existe pas: il n'y a pas comme sur un PC de differentiation entre la memoire centrale et la memoire de la carte graphique. Sauf a acheter de la memoire en plus, la fameuse "fast ram"qui fait planter certains vieux jeux.

Du coup je suppose, mais je me trompe peut etre, que pour etre affiche a l'ecran les ressources doivent faire tout le chemin cartouche -> memoire centrale accessible uniquement par le CPU -> memoire video (ce qui est affiche sur la fenetre de droite) -> framebuffer ? Ca expliquerait la gymnastique a laquelle il se livre, en voulant aller chercher a chaque nouvelle etape d'animation l'integralite de la texture dans la memoire centrale. Ce qui accessoirement doit bouffer des cycles CPU et faire louper la synchro avec l'ecran sinon tous les developpeurs NES auraient fait pareil.

En fait je suis completement largue sur comment fonctionne une console/un micro. Je sais comment fonctionne un Amiga, c'est tout. Et du coup j'ai un peu tendance a generaliser.

Pour en revenir à des considérations moins techniques, je dois dire qu'il y a une chose qui me dépasse complètement avec la Master System : c'est le bouton Start (Pause) sur la console-même.

J'ai acheté quelques jeux Master System au début de ma carrière de joueur console (auxquels je jouais sur Game Gear via le Master Gear Converter) mais c'est en envisageant récemment l'achat de la console pour profiter pleinement du magnifique Wonder Boy in Monster Land que j'ai réalisé à quel point la 8 bits de Sega était handicapée par rapport à la NES et ses 4 boutons sur chaque manette.
C'est d'ailleurs l'une des raisons qui font que j'hésite finalement à investir dans la Master System (outre sa lenteur en PAL pour faire tourner Monster Land).

Des joueurs Master System pourraient-ils donner leurs retours d'expérience sur ce sujet ?
Lorsque le bouton Start ne sert qu'à mettre en pause, c'est un moindre mal, mais pour les jeux dans lesquels le bouton Start a une vraie fonction comme afficher un inventaire, ça me semble vraiment très contraignant... pour ne pas dire autre chose.

Quand j'etais gamin, je jouais sur un moniteur Amiga, avec la console posee a la place du clavier. Aujourd'hui j'y joue en tirant la console de dessous la television pour la placer sur la table basse.

Dans tous les cas, il faut considerer que la console fait parti de la manette, un peu comme les micros ou l'unite centrale est egalement le clavier. Et ce n'est pas plus contreignant.

En termes de mémoire (ne parlons même pas de puissance), l'Amiga est un road train australien et la NES un Chappy . Les specs de la console sont les suivantes:

- 2 KiB de RAM "de travail" (pour stocker les données de l'état du jeu)
- 2 KiB de RAM vidéo
- 2 tilesets de 4 KiB
- 256 octets de liste d'affichage (les infos des sprites à l'écran)
- 32 octets de palettes (les 8 palettes dont je parlais dans mon dernier post)

Note tout d'abord que 2 KiB de RAM vidéo, c'est très nettement insuffisant pour stocker un framebuffer (256*224 en 64 couleurs, c'est 43 KiB): la console n'en a pas. A chaque image, elle reconstruit son affichage à partir de deux types de tiles: celles de background, et les sprites. C'est ce que tu vois sur la partie de droite des images que j'ai posté: la moitié gauche, ce sont les tiles de background, et la moitié droite, les tiles de sprites. 4 KiB par tileset. Rien n'oblige à utiliser un tileset pour les backgrounds et un pour les sprites (tu peux même piocher dans les deux sans distinction), maisdans un même tileset, toutes les tiles font obligatoirement 8x8 ou (exclusif) 8x16 pixels. Donc très souvent, le programmeur utilise un tileset en 8x16 pour le background, et un tileset en 8x8 pour les sprites -- c'est le cas pour Mega Man 5, dont sont tirés les captures de mon post précédent. Il est possible de recharger au moins une partie d'un tileset entre deux frames (je ne sais pas combien, je ne sais pas non plus combien de temps CPU ça prend, et je parie 10 balles que ça nécessite soit une astuce de programmation moisie soit un chip supplémentaire sur la cartouche).

Ces tiles sont la seule primitive gérée par la console -- tu ne peux pas manipuler les pixels directement, même pas pour faire une image statique. Chaque tile a 4 couleurs (dont généralement une de transparence), et une palette qui lui est associée (on peut faire du color cycling en changeant la palette), mais on ne peut pas avoir plus de 4 palettes "background" et 4 palettes "sprite" sur une même image.

Les tiles de background n'ont rien d'extraordinaire: il y a un tableau 2D quelque part dans la mémoire vidéo qui dit quelle tile coller où sur l'écran (un peu comme un PC en mode texte). Et je suppose qu'il y a une astuce pour faire du scrolling horizontal fluide de l'intégralité du background (pour du scrolling vertical ou diagonal fluide, ou de seulement une partie du BG, par contre, il faut un chip supplémentaire dans la cartouche).

Pour les sprites, c'est un poil plus tricky: il y a une mémoire de 256 octets, la "sprite RAM", qui contient pour chaque sprite:

- sa position
- la palette à utiliser
- la tile à utiliser

Ca prend 4 octets par sprite, ce qui donne donc une limite dure de 64 sprites (mais ça clignote s'il y en a plus de 8 sur une même ligne). Mais comme la console interroge la sprite list en temps réel pendant qu'elle trace les lignes et pas en plusieurs passes (dessiner le fond, dessiner les sprites, envoyer au framebuffer), je suis à peu près sûr qu'on peut virer un sprite de la sprite list une fois que la console a fini de le dessiner et le remplacer par un autre qu'on veut plus bas sur l'écran. Reste à savoir si des programmeurs l'ont déjà fait et si oui dans quel jeu, parce que ça doit être bien lourdingue à gérer.



_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

C'est passionant a lire Wild_Cat, merci !

Du coup, ca signifie que dans ton article, le gars parle de recharger tout un tileset entre chaque etape d'animation depuis... la cartouche ?!

J'imaginais pas que c'etait si rapide. Si tu essayais de faire ca depuis une disquette tu n'aurais meme pas une image par seconde.

Du coup, comment fonctionnait le Famicom Disk System ? Il y a une couche de memoire en plus ?

L'absence de Framebuffer devait aussi etre un enfer, a generer comme ca en temps reel ce qu'on envoi directement vers la television si on loupe une synchro on fait pas juste ramer le jeu, on affiche n'importe quoi !

edit: d'ailleurs vu la connaissance que tu sembles avoir sur ces sujets, tu pourrais peut etre creer un topic du genre "vos question sur le hardware", a l'image de celui de LVD sur le japon ? Ce serait un topic que je lirais avec attention ! (et puis j'ai peur qu'on use un peu la patience de la moitie du forum avec un aussi long hors sujet)

De rien, mais ce que je raconte, c'est juste des bouts du topic de Kain mixés avec des morceaux de Wikipedia, traduits en Français.



Non, seulement une partie. Megaman le fait déjà, si tu compares les screenshots où il marche, où il tire et où il saute.

Le vrai plan diabolique de Kain, c'est une extension de ce qui est fait pour afficher Megaman en 7 sprites et 2 palettes: en gros, tu superposes des tiles qui utilisent des palettes différentes, en jouant sur les transparences, pour obtenir un personnage en jusqu'à 12 couleurs (ce qui implique d'utiliser tes 4 palettes juste pour le perso, et une grosse partie de tes 64 sprites). Regarde ses shots de Soma Cruz (Castlevania Aria of Sorrow) plus bas dans le thread, tu vas comprendre.



Oh, non, c'est beaucoup plus simple que ça: les jeux FDS ne changent pas de tileset à la volée.

En cherchant sur Wikipedia, j'ai fini par trouver: normalement, sur un jeu NES, les tilesets sont en ROM, sur la cartouche à une adresse hardcodée dans le PPU. Je suppose que le FDS devait avoir une RAM à cet emplacement (les tilesets des jeux étant sur disquettes), ce qui doit permettre de changer de tileset, mais seulement pendant un loading.

Pour les cartouches de base, par contre, tu dois te démerder avec tes deux tilesets pour tout le jeu (et uniquement du scroll horizontal). Ca donne des jeux du niveau technique du premier Super Mario Bros, de Clu Clu Land, de Duck Hunt... Autant dire qu'on est assez loin du priapisme, et c'est pourtant le mieux qu'une NES puisse faire sans assistance extérieure.

Mais! Et c'est là que démarre ce que j'aime appeler l'escroquerie de la NES, à partir de 1986 environ, commencent à arriver des cartouches dotées d'un MMC (Multi-Memory Controller). Ce sont des puces (fabriquées par Nintendo, Konami, Rare et quelques autres) qui permettent tout d'abord de faire du bank switching (les tilesets sont stockés dans une RAM et donc switchables à la volée), puis dans les générations suivantes, de faire du scrolling vertical. Puis diagonal, puis splitté, ah, et on a mis une pile de sauvegarde, aussi, et puis la mémoire du programme est bank switchable, et on vous a dit qu'on avait rajouté 1 KiB de RAM? Partez pas, y'a aussi des canaux sonores supplémentaires et de la synthèse FM si vous avez une console japonaise!


Voilà, maintenant tu sais la vérité: à partir de 1986 (Zelda, Castlevania, Megaman 1), il y a des morceaux de console plus puissante dans pratiquement toutes les cartouches NES.

Les derniers modèles de MMC rendent possibles des jeux comme Super Mario Bros 3, Captain Skyhawk ou Castlevania 3 (dont la musique, en version japonaise, ressemble à ça: http://www.youtube.com/watch?v=vC4fYdrfS64 -- c'est l'originale, pas un remix). Le hardware de base de la NES arriverait à peine à en afficher des images fixes.



Non, ça justement c'est le PPU qui s'en charge. Toi, tu te contentes d'indiquer ce que tu veux comme fond et où tu veux tes sprites, et la console se charge du reste.

Sur Atari 2600, par contre, il fallait se taper la génération de l'image à la main, et ça pompait à peu près tout le temps CPU (faut dire qu'elle était pas bien véloce, la bête). Il fallait faire tourner toute la logique du jeu dans les HBI et VBI (les intervalles de resynchronisation, quand le canon à électrons à fini de balayer une ligne (ou une image complète) et revient en arrière pour la suivante).
_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Merci pour ce retour d'expérience, FF_Clad.
Maintenant, j'espère que le cordon d'alimentation et surtout le câble péritel sont assez longs pour se prêter facilement à ce genre de choses. Car alors qu'on jouait relativement près de l'écran sur micro, il faut tout de même compter plus de recul sur console.

Je peux commencer

La Master system n'était pas une concurrente de la NES, c'était une GameGear qui se branchait sur la télé
_________________

Le plus gros sprite de la NES, c'était dans Black Manta


_________________

Non, la dernière machine qui avait des sprites Hardware était la saturn
_________________

Perdu, ça c'est un boss réalisé en background

(note que le reste de l'écran est tout noir: c'est pour permettre au boss de bouger en faisant un scrolling)
_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Damned

Par contre quand j'avais 8-9 ans j'avais été super impressionné par ce boss
_________________

Je considère que -- en tous cas en ce qui concerne la NES -- ça peut rentrer dans le débat actuel. Le top, ce serait que quelqu'un fasse le même genre d'explication en ce qui concerne la Master System (à laquelle je ne connais strictement rien). Ca nous donnerait un point de comparaison assez sympa entre les capacités relatives des deux machines.
_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Pourtant, je ne sais pas si tu as remarque mais sous linux (et je suppose sous Windows et MacOS aussi) le curseur est toujours impeccablement fluide, meme quand le jeu rame a mort. Et quand un jeu (voir toute la machine) freeze, il est souvent possible de continuer a bouger le curseur sans meme qu'il ne laisse de "trace" derriere lui. Et pourtant quand ca plante, la machine ne peut pas "repeindre" derriere le curseur.

J'ai donc toujours suppose que le curseur d'un ordinateur moderne fonctionnait de la meme facon qu'un bete sprite hardware de NES ou Master System.

Non je pense simplement que le curseur, en tant que périphérique de contrôle, à une priorité haute dans la gestion des process de n'importe quel OS.

Sur le principe, la master system fonctionne sur le même principe que la NES avec un tile engine : une banque graphique pour les sprites, une autre pour le fond et la puce graphique s'occupe de calculer l'image.

edit : j'ai retrouvé quelques chiffres :

la SMS gère deux palettes de 16 couleurs : une première utilisable uniquement pour le fond d'écran et une seconde utilisable pour le fond d'écran et pour les sprites.

Côté objet graphique, la SMS peut gérer
-un fond d'écran de 32x28 bloc graphique de 8x8 pixels (avec gestion de l'inversion horizontale ou verticale du bloc + gestion de priorité sur les sprites)
- 64 sprites en 8x8 ou 16x8 en 16 couleurs (il faut que je recreuse ce dernier point car je ne vois pas comment programmer le sprite pour que la puce sache qu'on est fasse à un sprite de 16x8 et non deux sprites de 8x8).

La Master System, je l'aime d'amour .... parce que je ne l'ai jamais eu : mes parents m'ont offert un NES (il y a pire comme cadeau). A l'époque, Shinobi, R-type, Space Harrier me faisait plus réver que Mario et Link.

Pourtant du jeu exceptionnel c'est pas ça qui manque !

Phantasy Star, le tout premier, c'est pas fabuleux ?
Sonic dans son excellente version 8 bits, c'est pas formidable ?
Shinobi, un portage d'arcade qui fait oublier qu'il est techniquement inférieur, c'est pas merveilleux ?
Bubble Bobble, même si ce n'est pas une exclu, dans sa meilleure version 8 bits, c'est pas délicieux ?
Ghostbusters... euh, non.
Wonderboy III, c'est pas démesurément mythique ?
Power Strike, un shoot qui pourrait venir de la NEC tellement c'est bien, c'est pas enthousiasmant ?
R-Type, dans une conversion qui fait cracher ses tripes à la machine, c'est pas une claque ?
Mickey Castle of Illusion, encore une conversion de la MD qui n'a pas à rougir devant sa grande soeur; c'est pas jouissif ?
California Games, qui enfonce allégrement la version NES en quadriichromie, c'est pas radically awesome ?
Wonderboy in Monster World, le jeu qui ressemble à un jeu 16 bits, c'est pas un orgasme vidéo-ludique ?
Golvellius, qui fait peut-être du Zelda mais pas que, c'est pas une légende vivante ?
Ys, c'est pas un monument ?
Ghouls'n Ghosts, c'est pas effroyablement bon ?
Batman Returns, c'est pas gouleyant comme une bonne truite pour le pingouin ?

Et j'en passe...