Hardcore Retrogaming

[upsilandre]

Plutot que de debugué le code de DQ pour voir comment etait utlisé la RAM de sauvegarde sur la cartouche je me suis dis que l'emulateur doit bien créer pour son usage un fichier emulant cette RAM et avec un editeur hexa je vais voir deja ce que je peux en decripter.
Effectivement l'emulateur crée un fichier de la sorte pour tous les jeux qui utilise ce genre de RAM de sauvegarde sur la cartouche mais surprise en l'ouvrant y a quasiment rien dedans, c'est principalement du vide. C'etait doublement intriguant car ca voulait dire a la fois que les sauvegardes du jeu sont de taille tres faibles (j'avais utilisé les 3 slots) et que cette RAM n'etait pas utilisé non plus par le jeu comme une extension de la RAM principale (sinon j'aurais trouvé des données dedans car y a pas de raison a priori que l'emulateur puisse faire la distinction entre l'espace réservé aux sauvegarde et celui réservé a l'extension de RAM)

J'etais un peu embarrassé car ca correspondait pas a mes attentes, ca n'avait pas trop de sens... Jusqu'a ce que je comprenne que c'est juste la version US qui a une RAM se sauvegarde. La version jap originale etait en fait un RPG a code bordel!!
J'aurais du y pensé puisque j'avais deja fait des recherches sur l'historique d'apparition des sauvegardes dans les jeux cartouche et ca débarque pas avant 1987, bien apres DQ. Du coup ca explique tout puisque la version US ne fait que stocker les codes dans ces 8Ko de RAM de sauvegarde (bien trop grosse pour 3 codes, d'ailleurs ils en stock 10 copies a chaque fois par sécurité) et le jeu ne peut donc pas non plus utiliser l'espace RAM disponible (et y en a beaucoup) car le jeu n'a pas ete concu pour ca.

Ca explique aussi la si faible persistance du monde du jeu qui m'a surpris, a un moment j'ai meme cru a un bug de l'emulation quand tu te rend compte que chaque porte ouverte avec une clé magique durement acquise les première fois revient a son etat initial (verrouillé) quand tu reviens et nécessite une nouvelle clé. Pareille pour les coffres qui repop a chaque fois. J'ai trouvé que c'etait peut etre ca l'aspect le plus archaique du jeu finalement, pour un rpg c'est un peu embetant.

Du coup DQ1 n'est pas seulement un RPG qui relève le défie de tourner avec seulement 64Ko de ROM mais aussi un RPG qui tourne avec seulement 2Ko de RAM et juste quelques octets de sauvegarde (les codes. 16 octets de sauvegarde + 8 octets de nom). C'est triple défie comparé aux autres RPG. Les contraintes etaient vraiment enorme ca en fait vraiment un RPG a part.

Mais du coup il me faut effectivement un autre RPG pour mieux etudier l'usage des RAM de sauvegarde.

[upsilandre]

Mother c'est vrai que on en a tellement entendu parler et puis c'est original. Ys j'ai joué juste un petit peu, je vous avait d'ailleurs fait un décorticage en regle y a quelques pages entre les versions NES et SMS.

Mais comme je suis plutot dans une démarche comparative, ce qui m'interresse c'est l'evolution technique des rpg sur NES. Donc je suis quand meme tenté soit de comparer DQ1 a DQ4, soit a FF1 soit a un FF3 (qui a le plus gros pool graphique). Je peux pas trop me permettre de faire un rpg NES juste pour le plaisir (sinon je pense que j'en ferais plutot sur SNES), faut que j'ai des raisons techniques de le choisir. Deja je vise plutot les cartouche 512Ko pour justement voir ce qu'ils arrivaient a faire avec cette quantité de donnée qui est a l'opposé de DQ1.

Une petite liste
http://www.listal.com/list/rpg-world-nes-edition

[dheen]

Mother c'est vrai que on en a tellement entendu parler et puis c'est original. Ys j'ai joué juste un petit peu, je vous avait d'ailleurs fait un décorticage en regle y a quelques pages entre les versions NES et SMS.

Mais comme je suis plutot dans une démarche comparative, ce qui m'interresse c'est l'evolution technique des rpg sur NES. Donc je suis quand meme tenté soit de comparer DQ1 a DQ4, soit a FF1 soit a un FF3 (qui a le plus gros pool graphique). Je peux pas trop me permettre de faire un rpg NES juste pour le plaisir (sinon je pense que j'en ferais plutot sur SNES), faut que j'ai des raisons techniques de le choisir. Deja je vise plutot les cartouche 512Ko pour justement voir ce qu'ils arrivaient a faire avec cette quantité de donnée qui est a l'opposé de DQ1.

Une petite liste
http://www.listal.com/list/rpg-world-nes-edition

p**** cette liste, qu'est ce que j'ai pu joué a hillsfar. Sinon le gap graphique entre FF1 et FF3 doit etre purement esthetique, je ne suis pas certain que les mécanique technique on grandement évolué... (c'est d'ailleur assez impressionnant de voir que de FF1 a FF9 le mode de jeux n'a pas beaucoup évolué)

Entre le 1 et le 3 la taille de la cartouche a doublé je soupçonne cette place d'avoir été utilisé pour plus de diversité graphique

techniquement ce qui peut être intéressant c'est de comparer un Zelda 1 et 2 meme si ce ne sont pas des RPG a proprement parlé , coté RPG DQ1 et DQ4 semble un bon choix aussi vu que tu as déjà decortiqué le 1

[upsilandre]

J'avais oublié la serie historique des Hydlides. Voila donc un RPG en 32Ko sur MSX.
Sur NES il sort un mois avant DQ sur une cartouche sans mapper donc 40ko (Ce qui est grotesque c'est qu'ils ont gardé sur la version NES les techniques d'affichage et de scrolling des machines qui n'avait pas de fonction de scrolling comme le PC-88 et le MSX, c'est ridicule).
J'ai trouvé aussi Dragon Slayer sur MSX en 32Ko un peu dans le meme genre que Hydlide. Les 2 on l'aire d'avoir des combats temps réel avec peu de critere (stats, magies) et une absence de background et de dialogue avec des pnj... On s'eloigne du RPG, j'ai pas l'impression qu'on soit dans la meme dimension qu'un DQ. C'est plutot comme DragonStomper sur VCS, deja l'absence de texte dans un rpg ca me parait eliminatoire.
Si vous connaissez qu'est ce que vous en pensez? J'ai l'impression que 64Ko c'est quand meme le minimum pour faire un vrai rpg.

[upsilandre]

Sinon le gap graphique entre FF1 et FF3 doit etre purement esthetique, je ne suis pas certain que les mécanique technique on grandement évolué...
Entre le 1 et le 3 la taille de la cartouche a doublé je soupçonne cette place d'avoir été utilisé pour plus de diversité graphique

Oui y a un peu plus du double de pattern graphique mais c'est ca aussi qui m'interresse. Quelle variété graphique ils arrivent a simuler. DQ s'en sort bien avec tres peu et beaucoup d'astuce. Meme si un FF3 a beaucoup plus de donnée graphique que DQ ca reste faible dans l'absolu. On est sur du 170-180Ko de tuiles. Ca demande toujours a etre astucieux pour donner l'illusion de la variété. Quand je parle de qualité graphique je pense a cette variété visuel, avoir l'impression de traverser plein de lieux differents, de croiser une grande variété de monstres et de pnj. (je trouve que sur le bestiaire DQ s'en sort pas mal, un renommage et color swap intelligent ca fonctionne quand meme bien sur l'effet de surprise).
C'est ca le défie technique qui m'intéresse dans les rpg, simuler un monde immense et vivant avec tres peu de donnée.

[upsilandre]

Il existe une version MSX de Dragon Quest. C'est la version Famicom (Meme ecran titre, sprites, littoral) donc sans les petites améliorations de la version US. Mais encore plus plus moche et avec un scrolling facon "MSX". Tout ca avec une ROM 2x plus grosse (128Ko), 4x plus de RAM et 8x plus de VRAM. La NES 

[upsilandre]

Apres l'avoir fait en entier je me suis attaché a ce jeu (DQ). Du coup je continu les investigations pour mieux comprendre ce qu'il y a vraiment dans ces fichus 64Ko.
Je remet quand meme en perspective ce que represente 64Ko. C'est 5 secondes d'un podcast HBGD ou un centième de seconde de bluray. On pourrait mettre 128 copies de DQ sur une vieille memory card PS2 d''il y a 15 ans. Ou le dupliquer intégralement 130 000 fois rien que dans la RAM de la PS4.

Pour moi c'est aussi un prétexte pour mieux maîtriser les outils de débogage car jusqu'a maintenant je me contentais des outils de débogage GPU qui sont simple a lire car ils t'affichent la RAM tilemap sous forme de tilemap, la mémoire CHR-ROM sous forme de Tileset, la mémoire palette sous forme de palette... Donc c'est tres visuel, tu vois tout de suite ce qu'il se passe, faut juste etre un minimum informé sur comment ca fonctionne pour comprendre.

Par contre les outils de débogage CPU qui consiste cette fois a observer l'execution du code du jeu lui meme c'est une autre paire de manche mais ca te donne acces a tout. Et puis comme j'ai toujours envie de programmer sur NES, faire du débogage CPU c'est parfait pour garder un doigt dans l'engrenage et bien se préparer. Ca t'oblige a bien connaitre la machine (notamment a bien mémoriser tout le mapping mémoire, c'est a dire a quelle adresse se trouve exactement chaque type de mémoire et chaque registre pour les identifier dans le code et savoir ce qu'il se passe).
Maitriser les outils de débogage c'est super important si tu fais du homebrew sur des vielles machines, ca me sera de toute facon tres utile si je me lance (ou relance puisque j'avais presque commencé l'année derniere avant de consacré plutot mon temps a decortiquer les autres consoles). Sur Atari 2600 l'outil de débogage intégré a l'emulateur (en général c'est comme ca, c'est l'emulateur qui integre les outils de débogage puisque pour débogué il faut deja amuler la machine) etait tres bon et m'a ete indispensable. Faut que je maitrise ceux de Fceux (l'emulateur NES).

D'ailleurs j'ai une idée de projet qui me trotte dans la tete maintenant que j'ai un peu approfondie le debugage de la NES (et apres avoir joué a DQ) c'est d'initier une traduction en francais d'un RPG NES. J'ai bien aimé jouer a DQ notamment parce que j'avais pu le patcher en francais, l'anglais et moi ca fait 2 et quand je fais l'effort c'est pour des docs techniques uniquement parce que j'ai pas le choix car ca me demande trop d'effort mais pour un jeu non merci.
Des hack de traduction de vieux jeux y en a pas tant que ca car justement c'est compliqué, c'est pas du tout comme un jeu d'aujourd'hui, faut vraiment passer par une phase hasardeuse de reverse engineering du code du jeu sans savori si ca va vraiment pouvoir aboutir et c'est un exercice qui me tenterait bien mais qui implique de trouver une seconde personne pour faire la traduction, jouer a fond au jeu pour bien le connaitre et aussi faire des beta testes.

Donc je me suis pas encore renseigné mais si vous avez une idée de RPG NES qu'il serait intéressant de traduire et qui n'aurait pas deja ete traduit en francais (je pense que c'est la grande majorité, un Ys NES en francais?). Le top ca serait de trouver un RPG NES qui n'aurait meme pas ete traduit en anglais et quelqu'un capable de traduire le japonais (pour faire les 2 versions tant qu'a faire) mais bon la c'est un autre niveau. Deja qu'une bonne traduction a partir de l'anglais ca doit pas etre facile.


Moi je retourne sur DQ.
En tout cas je trouve que le bestiaire est bien réussit vu les contraintes

De gros sprites détaillés (bon ils sont statique et a ce moment la y a que ca a afficher comme sprite mais la on parle surtout de la contrainte d'espace ROM qui est la véritable contrainte). Une bonne variété avec une belle utilisation du color swap (sachant que la NES c'est normalement 3 couleurs par sprite alors qu'ici y en a en général 6 et meme 9 pour le boss final donc y a un véritable effort de contourner les limites) agrémenté d'accessoires qu'ils ajoutent pour mieux les différencier voir du flipping (et des noms parfois tres differents d'un color swap a l'autre, ca aide aussi a les personnifier)  et hop on a un jolie bestiaire de 40 ennemis.

[upsilandre]

Je m'amuse vraiment beaucoup a mener mon enquete sur DQ et c'est bien le mot, c'est vraiment comme un jeu d'enquete mais en mieux car on te sert pas le truc sur un plateau.
Et pour mener mon enquete j'ai ca: https://lh6.googleusercontent.com/-uX8Gq2VKHn0/VcZxqQ1XkeI/AAAAAAAABrI/auvkqLYw5-Y/w1906/Debug.jpg

Avec ca tu peux analyser toute l'execution du code et donc tout découvrir si t'as du temps. Et c'est vraiment comme une enquete, faut faire des hypoteses, essayer de trouver des indices, faut judicieusement placer les "break point" qui servent a interrompre le programme au moment qui peut etre le plus intéressant (car en une seconde il se passe beaucoup de chose dans une machine, tu peux pas éplucher cycle par cycle). Moi je fais vraiment ca comme je jouerais a un puzzle game (bon faut dire que je fais des puzzle game un peu bisarre comme SpaceChem ou dernierement TIS-100, mais finalement je préfere  autant faire du debug de jeu NES)

La ce qui m'a intéressé dans mon enquete c'est le texte et les tilemaps du jeu. Savoir quelle quantité de donnée ca represente sur la cartouche, quelle format (compressé, pas compressé) et comment ils ont répartie entre les differentes ROM/Bank. J'ai a peu pret résolu ces questions, je vais commencé par le cas du texte.


_______________________________________________________________________________________



Alors au sujet du texte de Dragon Quest mon hypotese c'etait qu'il etait stocké dans la ROM graphique car le texte pendant un dialogue meme en mode "fast" s'affiche seulement a un caractère par frame donc c'est un acces aux donnée tres lent et qui colle bien avec la situation puisque effectivement le CPU ne peut pas accéder facilement a la ROM graphique. Ils ne peut meme pas y acceder du tout, il peut juste dire au GPU "tiens tu peux m'envoyer l'octet qui se trouve a tel adresse dans ta ROM merci" et seulement faire ce genre de demande quand le GPU est au repos c'est a dire pendant le retour de balayage vertical (Vblank) qui est court.

Alors effectivement en surveillant les acces CPU en lecture vers le GPU grace a des break point bien placé la confirmation est vite venu. Quand y a du texte a afficher le CPU fait effectivement des acces a la ROM graphique et en surveillant aussi le bank switching du mapper j'ai identifier ou.
Puis j'ai pensé a une astuce en utilisant un autre outil qui m'a permis de visualiser toute la ROM du jeu comme si c'etait une enorme tilemap et en mettant en entrée comme tileset la partie qui contenait la police de caractère du jeu. Je me suis dit que si le texte n'etait pas compressé je devrais directement le voir apparaître et bingo il est apparu. Il remplit une bank complete de 8Ko de la ROM graphique + d'autre morceau ailleurs.

Sur la version US (plus simple a dechiffrer quand meme) le texte prend quasiment 2x plus de place (ce qui repond d'ailleurs plus ou moins a la question de ce qui pouvait remplir l'espace supplemantaire de la cartouche US). Je saurais pas dire si c'est parce que le texte lui meme est plus riche (pour profiter de la place supplémentaire) ou parce que le japonais prend naturellement moins de place avec ses caractères plus riche.
Le fait est que y a quand meme une forme de "compression" du texte et qui semble plus poussé sur la version japonaise. Chaque caractère prend bien un octet mais certain octets "speciaux" code pour des commandes (comme en ASCII) ou des mots contextuel.

Par exemple sur la version US ce type de code de commande sont assez limités. J'ai identifié par exemple l'octet $F8 qui au milieu d'un texte sert a indiqué qu'il faut ecrire le nom du joueur a cette endroit (du coup ca fait plusieurs caractère pour un seul octet d'ou un effet de compression). $F4 pour le nom du monstre que tu combat, $F5 pour ecrire une valeur qui vient d'etre calculer (des point de HP perdu par exemple), $FC pour marquer la fin d'un texte, $FD pour un saut de ligne, $FB pour demander au joueur de valider pour passer a la suite du texte. En gros ca se limite a ca sur la version US alors que sur la version Jap il y a bien plus de codes de commande (dans un octet y a largement la place pour mettre un paquet de code de commande) qui a mon avis pointe chacun vers une bibliothèque de petit groupe de 2 ou 3 caractère qui sont récurent dans la langue mais je connais pas le japonais et donc ne peut pas aller plus loin mais c'est claire que c'est quelque chose de ce genre et donc un texte qui est en quelque sorte un peu plus compressé sur la version jap (mais sur la version US ils avaient aucunement besoin de ca avec les 13.5Ko supplémentaire qu'ils avaient).


Si on visualise les 4 bank 8Ko de la ROM graphique (qui sont donc censé contenir uniquement des tuiles graphiques) ca donne ca:



- On voit bien que la bank 0 qui est la bank par defaut (avant switching) est bien une bank graphique et c'est celle qui accompagne tout le jeu et contient tous les graphismes du jeu (avec donc aussi la police de caractère).

- La bank 1 on voit tout de suite que ce n'est plus des patterns graphiques, n'importe qui je pense le remarque juste a l'oeil. Et c'est cette bank la qui contient le texte brute de tous le corps du jeu.

- la bank 2 on voit qu'il y a une majorité de pattern. Ce sont celle de l'ecran titre et celle du sprite du boss final. En haut a gauche on pourait douter que ce soit des pattern graphique mais c'en est bien, c'est juste un peu confus a cause d'une superposition de 2 polices de caractère (celle de l'ecran titre et celle du jeu pour le boss final) dont on peut cacher l'une ou l'autre avec une astuce de palette.
Mais dans la derniere partie en bas a droite on voit bien que encore une fois ce ne sont pas des patterns graphiques. Effectivement dans ce paquet de donnée destiné au CPU on trouve encore du texte. On trouve le texte de fin du jeu suivie du texte des credits. Le reste des données j'ai pas pu déchiffrer.

- la bank 3 comme on le voit tout de suite c'est encore une fois des données destiné au CPU donc pas de pattern graphique.
J'ai identifié la dedans la table de pointeur qui sert au texte. En effet pour que les développeurs puissent modifier le texte du jeu sans devoir modifier tout le code du jeu pour indiquer ou se trouve maintenant chaque morceau de texte, ils passent par une table de pointeur intermédiaire qu'il suffit de corriger pour que les modifications de texte soit bien intégrer.
En décryptant cette table de pointeur je pourrais d'ailleurs proposer une meilleur traduction que ce qui a ete fait pour le hack VF de ce jeu car j'ai aussi analyser la VF et ils ont juste remplacé le texte de la version US dans la ROM mais avec la contrainte que chaque morceau de texte doit entrer dans les limites de la version US (et au final avec pas mal de gachi), c'etait pas un mauvais choix car c'etait effectivement le plus simple et rapide mais en décryptant la table de pointeur on aurait put faire une traduction plus riche et en adaptant la longueur de chaque texte aux besoins. Donc je pourrais peut etre finalement apporter ma pierre sur ce genre de projet de fan-trad.
Reste que l'essentiel de cette bank 3 m'échappe. Je vois bien que le jeu y accede chaque fois qu'on entre ou sort d'une ville/donjon, ou lorsqu'on entre en combat, et meme a l'allumage du jeu pour l'ecran titre. J'ai beaucoup soupçonner que c'etait les musiques (qui change effectivement chaque fois qu'il y a un acces a cette bank) mais j'arrive pas a suivre la piste. Je vois le CPU remplir 2x un buffer de 150 octets a chaque fois sauf qu'ensuite il n'utilise pas ce buffer avant de l'ecraser donc je comprend pas (en plus sur NES y a tellement peu de RAM que les buffers en RAM servent pour 36 choses differentes). Mystère.



donc en gros sur cette version jap (si j'ai rien raté) y a environ 10Ko de texte (avec ses metadatas), finalement un peu moins que les patterns graphiques (13.5Ko). Sur la version US c'est l'inverse (le texte pèse plus lourd que les patterns graphiques)
Prochaine fois j'evoque le cas des tilemaps qui est un peu plus intéressant je pense.

[CrichtonCrais]

Question : As-tu vu les vidéos de Double Fine où le créateur de Hack'N'Slash fait ça sur Legend of Zelda (NES) ?

https://www.youtube.com/watch?v=1bYrd6uDLeM&ab_channel=DoubleFineProd

[upsilandre]

Je connais pas (trop d'anglais pour moi) mais effectivement c'est intéressant.
Meme si je comprend pas bien ce qu'il dit j'ai quand meme tout compris a ce qu'il fait et ca c'est plutot rassurant pour moi, je peux le refaire. En plus il utilise exactement les memes outils que moi (Fceux qui est vraiment l'emulateur ultime de la NES, et le meme editeur hexa) du coup je suis pas dépaysé.

Le "RAM watch" de Fceux c'est un outil que je connaissais mais que j'avais pas encore utilisé donc c'est ca surtout qui m'a intéressé dans la video, ca m'a permit de voir le fonctionnement avant meme de l'essayer. C'est effectivement un outil plutot destiné au hack (si tu veux par exemple avoir des vies infinis et chercher des variables en particulier) d'ailleurs il est pas rangé dans le menu debug (meme si ca peut servir aussi de debug).

Ce genre de hack ca peut etre tres amusant a faire, c'est le genre de truc qui peut effectivement me plaire mais je me dis que tout a probablement deja ete fait surtout sur les classiques comme ca du coup je m'y suis pas trop intéressé mais peut etre que je me trompe. Si jamais y a un hack que vous voudriez sur un jeu je peux tenter, d'ailleurs avec Fceux plutot que de modifier le fichier ROM je peux aussi générer un code "gamegenie" qui permet au final de hacker les vrais jeux sur les vrais consoles sans faire du cartmodding (sans demonter les cartouches pour remplacer la ROM par une EPROM).
Le cartmodding d'ailleurs ca pose des problemes en ce moment car c'est beaucoup utilisé pour les jeux homebrew. Chaque fois qu'un gars vend un jeu homebrew a 200 examplaires sur une vieille console il a fallu dabord sacrifier 200 veritables cartouches d'epoque et qui ont la meme configuration (le meme mapper et configuration rom/ram) que les besoins de son jeu.

Et dans la video j'ai appris un truc aussi sur HexEditor, le coup des fichiers .tbl pour definir sur mesure la conversion hexa > ascii de l'editeur c'est effectivement vachement utile pour les jeux si on veut changer du texte (non compressé) dans un jeu. Pas besoin de coder un outil pour ca. Ils ont du faire comme ca pour la trad de DQ vu qu'ils ont pas modifier la taille du texte. C'est claire que ca a pas du leur prendre bien longtemps (juste le temps de la traduction mais y a pas beaucoup de texte).

[upsilandre]

Du coup tu m'as donné envie de hacker DragonQuest ce que j'aurais peut etre du faire pour simplifier mes tests et effectivement c'est assez facile 
J'ai trouvé la table des levels qui sert a determiner ton level selon tes points d'experiences, du coup j'ai mis 0 au level 30 (level max d'apres la table, c'est bon a savoir aussi) donc avec 0 point d'experience t'es levels max (donc dès le debut du jeu et toutes les magies).
Ensuite j'ai hacké le premier coffre dans la salle ou l'on debute le jeu pour qu'il te donne 64000 pieces de quoi tout acheter dans le jeu. Et voila :vice:

On peut faire ce qu'on veut. J'aimerais bien aussi hacker le jeu de facon a ce qu'on puisse se balader sur la map sans declencher de combat. C'est plus compliqué mais c'est probablement faisable.

[upsilandre]

Alors que dire des tilemaps de Dragon Quest.
Je rappel ce que c'est qu'une tilemap. C'est une sorte de tableau 2D ou chaque case contient une valeur entre 0 et 255 sur NES qui pointe vers l'une des 256 tuiles graphiques (qui font 8x8 pixels) et qui permet donc de composer une image en assemblant les tuiles.
Voila une illustration SNES



A gauche c'est l'image a l'ecran.
Au milieu (le tableau 2D) c'est la tilemap en VRAM.
Et a droite c'est le tileset (la bibliothèque de tuile) en CHR-RAM ou CHR-ROM.
C'est pas plus compliqué que ca. Et pour remplir un ecran NES faut une tilemap de 32x30 cases.
L'affichage des consoles par tilemap c'est en quelque sorte deja un mode de compression. Ca fait un peu penser au Jpeg qui essaie de crée des bloques de 8x8 pixels qui se repete. C'est ce qu'on fait avec les tilemap sauf que l'algo de compression c'est le cerveau du devellopeur, c'est a lui de choisir les bloc qui se répète et de les assembler a la main, la console ne fera que la decompression (le plus facile).


Sur Dragon Quest y a une map globale du monde + un certain nombre de map pour les villes et donjon. Les map sont dispo sur le net donc il est facile de calculer leur taille.
La map globale est simple, c'est une map qui fait 256x256 tuiles donc meme si c'est pas tres grand ca represente deja beaucoup de donnée. Une tilemap sur NES ca consome 8.5 bit par tuile (8bit pour désigner la tuile et 0.5bit pour definir la palette, en réalité 2bit pour un bloc de 2x2 tuiles) donc une tilemap de 256x256 c'est 68Ko c'est deja plus que la cartouche et reste les autres tilemap des villes et donjon (mais la map globale c'est 60% du total)
En tout (exterieur, ville, donjon) le monde est un assemblage d'un peu plus de 110 000 tuiles ce qui represente 114.4Ko de tilemap ce qui est beaucoup trop.

Y a une methode utilisé par DQ et qui est assez classique je pense a cette epoque qui consiste a utiliser des Metatiles.
Une metatile c'est une sorte de mini tilemap qui défini alors un assemblage de 4 tuiles qui forme donc un bloc de 16x16 pixels qu'on va utiliser comme une tuile (mais plus grosse) et d'ailleurs vous pouvez regarder sur les jeux de l'epoque, c'est en général la taille des elements du décors, la plupart du temps y avait pas besoin d'avoir un controle du decors avec une granularité 8x8 pixels.

Voila un exemple de quelques metatiles de Dragon Quest. On voit bien que la taille minimum des bloc du décor que j'ai entouré en rouge font 16x16 pixels c'est donc un assemblage de 4 tuiles.


Du coup une solution de compression assez simple est de crée des metatilmap qui au lieu de pointer des tiles vont pointer des metatiles (qui elle meme pointe des tiles) et ainsi on peut composer une image avec une table 4 fois plus petites (meme un peu plus car on peut zapper aussi les palettes qui seront associer directement aux metatile)
Par contre ca demande ensuite au jeu de transformer en temps réel la metatilemap en tilemap car le GPU a besoin d'une tilemap, c'est une forme de décompression donc faut des ressources CPU et RAM supplémentaire et faut aussi créer une bibliotheque de metatile (un metatileset).

Alors dans DQ c'est simple toutes les maps du jeu n'utilise que 24 metatiles differentes (et encore la derniere n'est utilisé qu'une seul fois donc c'est plutot 23). J'ai d'ailleurs réussit a trouver cette bibliotheque dans la ROM cpu.


voila elles sont toutes la (et dans l'ordre ou on les trouvent sur la ROM). Du coup la bibliotheque prend seulement 120 octets (5 octets par metatile, un pour pointer chaque tile qui la compose + un pour la palette) ce qui est insignifiant donc l'economie total est bien réel. On passe de 8.5 bit par tuile a 2bit par tuile + la bibliotheque de metatile. Donc on passe de 114.4Ko a 27Ko et du coup ca devient viable.
Mais 27Ko ca reste encore beaucoup quand on sait que la ROM cpu fait seulement 32Ko.
Qu'est ce qu'on peut encore faire? On a vu que la bibliotheque de metatile est composé de seulement 24 metatiles mais la metatilemap utilise un octet complet pour pointer une metatile et un octet complet ca permettrait de pointer jusqu'a 256 metatiles differente donc il reste encore ici pas mal de gachie. Y a moyen de compresser les metatilmaps elles memes.

Moi j'avais fait une hypothèse sur DQ en remarquant qu'il n'y a jamais plus de 16 metatiles differentes utilisé sur une meme map donc ca ouvrait la possibilité d'encoder 2 metatiles dans un seul octet et donc de diviser encore par 2 (on passerait alors a 1 bit par tuile et 13.5Ko au total, ca serait parfait) mais force etait de constater que c'etait pas la solution utiliser dans le jeu. Cette solution aurait ete facilement identifiable dans les données de la ROM car ca aurait fait apparaître plein d'octet symetrique.
En partant de l'hypotese qu'ils encodent alors sur 5bit (Ce qui est donc assez pour pointer les 24 metatiles) y avait aussi la solution d'utiliser un bloc de 5 octets pour encoder 8 metatiles mais ca collait pas non plus. Au final je me suis rendu compte qu'ils utilisaient des bloc de 2 octets pour encoder 3 metatiles donc 1 bit de perdu mais plus facile a manipuler et decoder.

Au final ca donne donc 1.33 bit par tuile soit 18Ko au total pour ce qui concerne la place occupé par les tilemaps sur la cartouche DQ (et tout ca est dans la ROM cpu). Faudrait aussi prendre en compte la place du code qui sert a faire ces transformations supplémentaire et qui prend aussi de la place donc on peut peut etre ajouter au pire 1Ko. C'est donc le plus gros pool de donnée (sur la version US c'est juste comparable aux données textuel)
Ma solution aurait permis d'economiser encore 4.5Ko et aurait en plus ete plus simple a décoder mais probablement que les devs ne pouvaient pas anticiper a l'avance le fait que aucune de leur map n'utiliserait plus de 16 metatiles differentes a la fois et si ils s'en sont rendu compte plus tard c'etait sans doute trop tard pour recoder le truc mais en tout cas y a encore de la marge, ca aurait pu permettre d'enrichir un peu plus le texte.



Ce qui est surprenant aussi c'est que tout l'environnement du jeu est donc composé de seulement 24 metatiles elles meme composés de seulement 71 tuiles differents alors que le simple ecran de combat lui utilise 73 tuiles soit plus que tout l'environnement du jeu.
Je parle de cette ecran de fond derrière les monstres



Cette simple image pourrait faire sourire d'autant que c'est la meme pour tout les combats du jeu donc on pourrait trouver ca radin alors qu'en vrai ca a demandé de vrai sacrifices l'aire de rien (pour le coup on est + sur une approche bitmap avec peu de récurrence graphique d'ou le cout) donc c'est qu'ils y attachaient de l'importance. C'est un élément immersif important du jeu.

[dheen]

C'est vraiment intéressant ce que tu dis. Donc en théorie on pourrais améliorer graphiquement le jeux assez facilement. (créé de nouveaux metatileset pour diversifié la carte par exemple.)

[CrichtonCrais]

upsilandre il te fait des articles de fond sans réclamer d'abonnement Premium.

[upsilandre]

C'est vraiment intéressant ce que tu dis. Donc en théorie on pourrais améliorer graphiquement le jeux assez facilement. (créé de nouveaux metatileset pour diversifié la carte par exemple.)

On peut en tout cas gagner encore quelque Ko sur la cartouche. Ensuite la facon d'utiliser ces Ko ca serait plutot pour du texte ou alors pour ajouter des donjons/villes. Enrichir l'aspect graphique ca pose d'autre probleme lié au type de configuration de la cartouche et du mapper.
Les metatiles sont dependantes des tiles qui elles sont pas nombreuse. C'est donc le tileset qu'il faudrait enrichir, la ou sont vraiment les pattern graphiques du jeu. Et le tileset du jeu c'est celui qu'on voit dans la bank 0 et il est deja full et on peut pas vraiment en utiliser un autre en cours de jeu.
Avec un mapper comme le MMC3 qui permet de switcher des bank graphiques par petit bout de seulement 1Ko la oui il aurait ete possible d'ajouter une ou 2 autre petite bank 1Ko de tuiles qu'on aurait pu switcher au bon moment pour créer d'autre environnement (et sans pour autant perdre les patterns des sprites ou de la police).

Mais le plus efficace quand t'es vraiment limité en ROM (car je parle toujours dans le cadre ou l'on veut faire un rpg avec 64Ko de ROM, c'est un peu le theme) c'est plutot un mapper de type UNROM et qui etait quasiment dispo au moment ou est sortie DQ (le premier jeu a utiliser ce mapper est sortie 2 semaines apres DQ et c'est Maikaimura).
Avec ce genre de mapper y a plus du tout de ROM graphique. Elle est remplacé par une seul bank 8Ko de RAM dans laquel tu construis toi meme sur mesure ton tileset tuile par tuile. Les pattern etant cette fois stocker dans la ROM cpu avec le reste du jeu. Du coup si tu veux changer juste 1 ou 2 tuile dans le tileset au moment ou tu entre dans tel donjon alors tu peux donc c'est bien plus simple de faire varier les graphismes de facon contextuel (au prix de transfere entre la ROM cpu et la RAM graphique qui sont lent) et dans ce cas la oui on aurait pu utiliser les quelques Ko gagné pour ajouter des tuiles.
Mais avec le mapper de DQ on peut pas, la bank du tileset c'est de la ROM et elle est fixe. Si tu veux changer les tuiles t'es obligé de changer les 512 tuiles du tileset en meme temps (les 256 du background et les 256 des sprites) avec un bank switching ce qui est problematique.

Et si en plus d'un mapper UNROM on avait pu aussi avoir une RAM de sauvegarde avec une pile on aurait pu ameliorer aussi la persistance du jeu qui est trop limité, et d'autre chose grace a la RAM supplementaire donc avec 64Ko de ROM y a surement moyen de faire encore mieux que DQ avec la bonne configuration de cartouche.


EDIT: a moins que tu faisais allusion au background de la zone de combat? Dans ce cas si on remplaçait ce background par un ecran noir effectivement on libere beaucoup de tile. On doublerait les tiles disponibles pour l'environnement du jeu.