Hardcore Retrogaming

Démarré par upsilandre, Novembre 09, 2013, 04:00:23 PM

« précédent - suivant »

Sprite Oddity


upsilandre

C'est un émulateur en box qui prend des cartouches NES c'est ca?

Sprite Oddity


upsilandre

Intéressant (si y a pas d'entourloupe)

Bakappoi


upsilandre

Une video tres sympa sur la Saturn (activez les sous-titres). C'est le genre de video que j'aimerais faire.



upsilandre

Je continu de décortiquer plein de machines et de jeux mais hier j'ai décortiqué le tout premier Dragon Quest sur Famicom. et RPG + console Nintendo = HBGD. D'ailleurs j'ai commencé une partie (avec un patch en francais) et je pense que je vais aller jusqu'au bout, finalement j'aime le coté minimaliste.

Le jeu m'intrigue pour etre l'un des tout premier jrpg a une epoque ou les cartouches sont encore tres modeste donc y a une petite odeur de défie technique quand meme. Et effectivement y a des choses surprenantes notamment au niveau des chiffres. Essayez d'estimer la quantité de data réservé aux patterns graphiques (les fameuses tuiles).
1 - Quelle quantité de data pour la totalité des patterns des sprites du joueur + ceux des PNJ ?
2 - Quelle quantité de data pour la totalité des patterns des environnements (exterieur, interieur, ville et zone de combat)?
3 - Quelle quantité de data pour la totalité des patterns des sprites ennemis/monstres que l'on combat (excepté le boss final)?

Coca_Impact

HO ça faisait si longtemps que j'attandais le retour passionné d'Upsilandre et de ses pavey si denses et pourtant si longs  :cry2:

86, c'est pas le début des MMC ça ? Bon on va dire que la cartouche a 128ko (donc MMC1), je dirais donc :

1- 32ko
2- 64ko
3-32ko

....ouai ma répartition est facile quand même

upsilandre

Oui mais c'est dans l'idée, t'as joué le jeu, juste une vague approximation pour mettre un peu en perspective, et tes chiffres sont a priori crédible mais bien sure si j'en parle c'est que les véritables chiffres sont assez different de ce a quoi on peu s'attendre, moi meme ca m'a un peu surpris.

DQ sort juste avant l'explosion de la capacité des cartouches qui debute avec Makaimura (128Ko) un mois plus tard donc le jeu se contente d'une cartouche modeste de 64Ko qui a ce moment la est quand meme une grosse cartouche puisque c'est seulement la 4eme du genre (un mois apres Gradius qui utilise la meme configuration de carotuche) mais moins qu'un Zelda sortie 3 mois plus tot sur le Famicom Disk.
Donc 64Ko pour un RPG deja c'est chaud.

Ensuite quand on y regarde de plus pret on remarque que c'est donc une configuration classique pour l'epoque avec 2 ROMs distinctes dans al cartouche. Une ROM pour le CPU (PGR-ROM) et une ROM pour le GPU (CHR-ROM) qui est celle qui contient toutes les patterns graphiques du jeux (les tuiles ou tileset). Chacune de ces 2 ROMs faisant 32Ko.
Donc on se dit bon 32Ko de tuiles c'est pas terrible mais on doit pouvoir faire quelque chose avec ca... Mais en y regardant de plus pret on découvre qu'ils ont stocké du code CPU dans la CHR-ROM en plein milieu des patterns graphiques comme des sagouins. Alors on se dit mais pourquoi donc?

L'expliquation c'est qu'on est encore aux prémices des mappers. Le MMC1 n'existe pas encore en 1986, meme pas le UNROM plus primitif. Le seul dispo que propose Nintendo depuis l'année précédente c'est le CNROM dont la fonction est de proposer du bank switching uniquement sur la CHR-ROM donc seulement pour augmenter la capacité de la ROM graphique qui etait le gros point faible a l'epoque (car limité a 8Ko, tous les jeux en souffrait depuis plus de 2 ans) mais pas encore de possibilité a cette epoque d'augmenter la capacité de la ROM CPU limité a 32Ko mais qui etait suffisant pour les jeux en général... sauf qu'un RPG a besoin de pas mal de ROM CPU entre autre pour les nombreux textes essentiel au genre et les tilemap (comme son nom l'indique ce sont donc les map de tuiles qui servent a definir la facon d'assembler les tuiles pour construire l'environnement, donc dans un RPG faut pas mal de tilemap pour construire le jeu car les lieux sont relativement vaste. Meme si c'est toujours les meme tuiles qu'on retrouve elles sont chaque fois agencé différemment)

Du coup Enix n'a pas eu d'autre choix que de stocker du code CPU dans la CHR-ROM (la ou il n'a rien a faire) et sans doute faire des transfères ponctuel vers la SRAM 8Ko que contient aussi la cartouche pour les sauvegardes (qui doivent en utiliser qu'une partie je pense).
Donc revenons aux chiffres. Une fois enlevé le code stocker dans la CHR-ROM qu'est ce qu'il reste de ces 32Ko pour les tuiles... et bien 13.5Ko, meme pas la moitié! A cela s'ajoute le fait que se mapper primitif a une granularité grossiere, il switch par bank de 8ko ce qui complique l'optimisation de la répartition des tuiles. Au final le corps du jeu lui meme est un peu contraint de se contenter d'une seul bank de 8Ko, l'autre bank qui contient 5.5Ko de tuiles (+ 2.5Ko de code CPU) sera utilisé pour l'ecran titre (qui se paye le luxe d'etre plus beaux que la version US pourtant upgradé) et aussi pour le sprite du boss final.

Donc il nous reste 8Ko de tuiles pour le corps du jeu... Mais n'oublions pas les text-box indispensable a un rpg, il faut une police de caractère et ca c'est aussi pas mal de tuile, une centaine + quelques tuiles pour les contours de la box, ca fait presque 2Ko en moins. Et la donc on arrive aux chiffres de la questions.

Pour l'intégralité des monstres du jeu c'est 3.5Ko de tuiles qu'on trouve sur la cartouche.
Pour l'intégralité des décors exterieur, interieur, ville, zone de combat, c'est 2.26Ko de tuiles...
Et pour le sprite du joueur + l'intégralité des pnj du jeu c'est... roulement de tambours... 0.5Ko!

Le dernier chiffres merites de s'y arreter un peu. Les conséquences (au dela du fait que la variété de pnj est tres limité en plus de recycler des morceaux de l'un vers l'autre, par exemple entre le joueur et les soldats) c'est que tous les sprites des personnages joueur inclus sont composés d'une seul frame ce qui donne cette caractéristique assez incongru a DQ d'avoir des sprites qui n'ont qu'une seul orientation (toujours de face) et aussi cette bizarrerie quand tu utilises la commande "parler" qui est de te demande dans quelle direction (faut selectionner le texte gauche/droite/haut/bas) car tu peux pas orienter ton sprite vers un pnj.
Mais pourtant on peut observer que les sprites sont animés? oui mais c'est toujours avec l'unique frame qui les composent. Le jeu fait juste un "flipping" du sprite. C'est a dire qu'il affiche une version du sprite avec une symétrie d'axe vertical en alternance ce qui donne l'illusion d'animation. C'est une features du chip graphique (tel que les consoles savent le faire sur les sprites depuis l'Atari 2600 a l'exception de la Master System). Donc tous les sprites (meme ceux des monstres) sont composé d'une seul frame.

tout ca résume assez bien l'efficacité de ce type d'affichage par tuile qu'on utilisé toutes les consoles pendant pas mal de temps. Et aussi a quelle point les contraintes etaient folle a une epoque.
Je reviendrais aussi sur les differences qu'on apporté la version US. Je veux pas faire un pavé trop gros.


pippoletsu

Version us codée par un homme seul, un certain Satoru Iwata.

Coca_Impact

Wow, impressionnant (et intéressant), je me demande si il y a un seul jeu qui n'a pas buter sur les contraintes de mémoire

Akṣobhya

J'aimerais bien un numéro Castlevania 3 et Shin Megami Tensei 1 + 2 svp
Dire que SMT2 est l'un des premiers a avoir une sorte de NG+, et c'est assez surprenant l'amélioration graphique entre le premier et le second.

upsilandre

Citation de: Coca_Impact le Juillet 31, 2015, 04:03:30 PM
Wow, impressionnant
Et surtout ca donne un vrai rpg. J'ai quelques heures de jeux, level 10, et ca fonctionne bien je trouve, on y croit, on a l'impression de retrouver tous les ingredients de base d'un rpg. J'accroche bien au coté minimaliste.

Donc ma conclusion pour l'instant c'est que 64Ko ca peut suffire pour faire un rpg. Je cherchais un peu la limite.
Il existe un rpg de 24ko sur Atari 2600 qui utilise le supercharger (une cartouche custom sur laquel on peut brancher un lecteur cassete audio pour charger le jeu en cassette dans une RAM de 6Ko) qui est sortie en 1982 et qui s'appel DragonStomper



C'est une belle tentative car on retrouve les ingredients du rpg contrairement a "adventure" par exemple qui serait plutot un zelda like. avec des menus dans lesquelles on peut afficher ses status, sélectionner un item. Mais le peu que j'y ai joué je dirais qu'on est quand meme sous le seuil, le gap avec DQ est consequent, manque la couche de background, les dialogues avec des pnj. Dans DQ on essaye quand meme de te raconter une histoire et de te placer dans un contexte, il sagit pas de faire juste une sorte de donjon crawler et ca change pas mal de chose.
Je me posais la question de ce qu'on pourrait faire comme rpg sur Colecovision dont les cartouche n'ont pas dépassé les 32Ko (pas de mappers). Du coup difficile de trancher car DQ semble quand meme marquer la limite basse.


Sinon quand on jete un oeil sur FF1 on constate deja le gap graphique, on est a plus de 80Ko de pattern graphique, c'est deja une autre catégorie mais c'est aussi lié a des choix de gamedesign car ces differences on les retrouves meme avec DQ4 qui utilise une grosse cartouche 512Ko mais qui apparemment a toujours moins de pattern graphique qu'un FF1. Je pense que les DQ misent clairement plus sur le texte et/ou la taille de la map (mais j'y connais rien en rpg)

upsilandre

Citation de: Démiurge le Juillet 31, 2015, 04:48:28 PM
J'aimerais bien un numéro Castlevania 3 et Shin Megami Tensei 1 + 2 svp
Dire que SMT2 est l'un des premiers a avoir une sorte de NG+, et c'est assez surprenant l'amélioration graphique entre le premier et le second.
Les Castlevania je m'y etais deja un peu intéressé. Megami Tensei je connais juste de nom mais aucune idée de ce a quoi ca ressemble. Y a tellement de jeu a tester sur NES.

pippoletsu

Tu devrais t'intéresser aux 1er Ultima pour rire.