Hardcore Retrogaming

chris1515 a écrit:

https://news.ycombinator.com/item?id=9739731

Un topic d'un dev qui a travaillé  sur l'adaptation de MGS 1 sur PC

Marrant les annecdotes sur les sons/musiques et sur les textures des yeux que Kojima a refusé

chris1515 a écrit:

http://www.quora.com/How-did-game-developers-pack-entire-games-into-so-little-memory-twenty-five-years-ago

Topic intéressant sur les astuces dans les jeux pour tenir dans la mémoire très faible des consoles pu ordinateur d'un autre temps

64Ko c'est justement la taille de DragonQuest mais c'est principalement du texte et des tilemap.

Pour les pattern graphiques ca se résume a 3.5Ko pour l'intégralité des monstres du jeu (sans le boss final).
2.26Ko pour l'intégralité des décors exterieur, interieur, ville, zone de combat.
Et 0.5Ko pour le sprite du joueur + l'intégralité des pnj du jeu...

Et juste avec ca on arrive a faire un vrai RPG (j'y ai joué et ca marche vraiment bien meme si minimaliste).
La version US a ete adapté par Satoru Iwata lui meme (tout seul) et il a fait du bon boulot car la cartouche US se débarrasse du mapper archaique de la version Jap (qui stockait une partie du code dans la rom graphique a defaut d'avoir une autre solution) pour un MMC1 plus moderne avec donc une configuration mémoire differente (on passe a 80Ko). Il a donc fallu remanier la répartition des donnée totu en faisant une upgrade graphique (avec pourtant seulement 2.5Ko de pattern graphiques supplémentaire mais Iwata a judicieusement optimisé en grignotant aussi sur l'ecran titre et la police de caractère).

3.5, 2.2 et 0.5Ko !! J'imaginais bien plus pour la partie graph, c'est le text qui prend bcp de place ? il n'est pas compressé un minimum ?

C'est vraiment une époque unique ces premiers générations de consoles, les contraintes hardware divers poussait (parfois) les dev à trouver des solutions et/ou optimisations originales pour se démarquer, battre la concurrence ou simplement réussir a créer le jeu visé

Le texte prend certainement beaucoup de place mais aussi les tilemaps qui servent a définir comment vont etre assemblé les tuiles graphiques pour former tout l'environnement du jeu.
Difficile de dire si ils utilisent de la compression sur l'un ou l'autre (mais la moindre optimisation dans la facon de stocker les data est deja une forme de compression donc y en a quasiment toujours d'une certaine facon). Sur Master System c'est assez courant de compresser les tilemaps meme si c'est des algo simpe mais y a 4x plus de RAM, le probleme de la NES c'est qu'il y a que 2Ko de RAM, ca complique l'idée de compresser les données pour les décompresser dans des buffers mais ca se fait quand meme, je l'ai constaté avec le programme que j'avais fait qui identifiait les redondances de bloc de 16 octets sur toutes les cartouches NES et certain jeu n'avait quasiment aucune redondance alors qu'il y a en a forcement dans les tilemaps (par exemple Marios bros 1, y a forcement une forme ou une autre de compression des tilemaps)
Et si ils font de la compression de tilemap je pense qu'ils peuvent faire de la compression de texte surtout que les rpg embarquent une mémoire pour les sauvegardes et cette mémoire a l'epoque n'est rien d'autre que de la RAM, la meme que la console, et je suis quasi sure qu'ils utilisent une partie de la mémoire sauvegarde comme de la RAM systeme (faut que je fasse un peu de reverse engineering la dessus car c'est une question qui me taraude depuis quelque temps et je vois pas ce qui l'empecherait)



Je peux détailler en ce qui concerne le cas DragonQuest. DQ sort juste avant l'explosion de la capacité des cartouches qui debute avec Makaimura (ghosts'n goblins) 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 cartouche) mais moins qu'un Zelda sortie 3 mois plus tot et qui accompagnait le lancement du Famicom Disk System et ses disquettes de "grande" capacité.
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 la 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 jeu (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 pour avoir une zone de jeu etendu.

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 puisque le CPU ne peut pas y acceder directement) et sans doute faire des transfères ponctuel vers la SRAM 8Ko que contient la cartouche pour les sauvegardes (qui doivent en utiliser qu'une partie je pense).
Donc 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 il ne reste plus que 3.5Ko de tuiles pour les monstres 2.26Ko pour les décores et 0.5Ko pour le sprite du joueur + l'intégralité des pnj du jeu.

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.






________________________________________________________________________________________________






Et le truc intéressant c'est que la version US est un peu differente et le codeur en charge de cette adaptation c'etait... Feu Satoru Iwata! le PDG de Nintendo fraichement décédé. Et il a fait du bon boulot.

Donc cette version US de DQ c'est un peu plus que la simple localisation habituel. Deja la cartouche change de technologie, adieu le vieux mapper CNROM pas du tout adapté a DQ et place au MMC1. Du coup meme si on reste sur une configuration ROM cpu + ROM graphique, ils peuvent cette fois choisir les capacité adapté a chacune donc au lieu de 32Ko + 32Ko ca devient une configuration 64Ko + 16Ko plus adapté au besoin du jeu.
Mais du coup ca demande des modifications dans la répartition des données et dans le code qui gerait l'acces a ces données donc faut mettre la main dans le cambouis.

D'ailleurs on se retrouve avec un paradoxe ou la version US a une ROM graphique 2x plus faible que la version jap tout en etant graphiquement upgradé mais j'ai deja donner la reponse a cette enigme plus haut. Sur la version jap la ROM graphique stock du code CPU ce qui n'est evidement pas le cas de la version US ou chacun est a sa place.
Du coup la version US a bien 16Ko de tuile contre 13.5Ko pour la version jap. Cool ca fait 2.5Ko de rab mais quelle miracle Iwata va bien pouvoir faire juste avec ca?

Premiere chose il ne va pas s'en contenter. Il va aussi grignoter sur l'ecran titre en réduisant son emprunte d'un bon 1Ko par rapport a la version jap. Du coup l'ecran titre perd en complexité, il est plus basique mais pas forcement plus moche, a vous de juger.



Alors 1Ko de gagné c'est pas grand chose mais avec les 2.5Ko de rab ca lui donne alors un budget total de 3.5Ko. Mais qu'est ce qu'il a derrière la tete pour aller grignoter ces 1Ko sur l'ecran titre?
J'ai deja dit que les sprites joueur + pnj de la version jap c'etait 0.5Ko et bien combiné a ces 3.5Ko ca donne 4Ko soit exactement une bank complete de tuile. L'idée c'est d'exploiter la meilleur granularité du mapper MMC1 qui permet de switcher des bank de 4Ko (au lieu de 8Ko) et donc de pouvoir switcher pendant le jeu entre 2 pages 4Ko de sprites au lieu d'etre bridé a une seul sur la version jap.
Du coup maintenant Iwata se retrouve avec une bank 4ko de sprite juste pour le joueur et les pnj tandis que les monstres sont sur l'autre bank (qui reste la meme que sur la version jap, rien ne change pour les monstres). Comme ils ne sont jamais affiché en meme temps il suffit de switcher les 2 bank de sprite selon que le joueur est en combat ou pas.

Ainsi il fait passer le budget des sprites du joueur et des pnj de 0.5Ko a 4Ko ca fait une upgrade x8 !! ce qui change pas mal de chose. Un peu plus de variété dans les pnj mais surtout des sprites qui sont enfin capable de s'orienter dans les 4 directions (sachant que l'orientation Est ou Ouest impose d'avoir vraiment 2 frames d'animation car on ne peut plus se contenter du flipping de sprite) ce qui va meme avoir une influence sur le gameplay puisque la boite de dialogue qui te demande de choisir dans quelle direction tu veux parler disparait rendant le jeu plus agréable.



On voit que les personnages sont libres en orientation, que le joueur est mieux différencié par rapport aux soldats, que le Roi ressemble cette fois a un Roi.
Donc c'est vraiment pas mal comme gain car c'etait le defaut le plus visible du jeu mais c'est pas la seul upgrade. Alors vous allez me dire qu'il ne reste plus de budget Ko pour ameliorer quoique ce soit d'autre?
Sauf qu'il est possible de gagner un peu d'espace sur la police de caractère moins lourde pour la version US. Le gain sera seulement d'une quinzaine de tuile soit a peine 0.2Ko mais ca va suffire a améliorer un autre défaut visuel tres visible du jeu qui est son littoral taillé a la serpe. Ils vont pouvoir créer des tuiles dédié au littoral.



Un petit détail a 0.2Ko qui change pas mal de chose.
Donc oui on peut dire que Iwata a fait du bon boulot avec peu de moyen.
Reste qu'il y a aussi 13Ko de plus du coté CPU. Les upgrade graphiques se limite a ce que j'ai montré mais possible qu'ils aient aussi upgradé la bande son mais je dirais plutot peut etre enrichie le texte, je doute qu'ils aient ajouté des zones de jeu c'etait pas le boulot.



PS: Une autre Astuce que j'ai bien aimé mais qui est present aussi dans la version d'origine c'est la superposition de 2 polices de caractère. L'ecran titre a une police de caractère qui lui est propre et qui n'est pas la meme que le jeu mais la bank graphique de l'ecran titre sert aussi pour le boss final et nécessite donc aussi d'y stocker la police de caractère du jeu (ce qui fait doublon avec celle deja contenu dans l'autre bank du jeu) juste pour cette dernière phase du jeu qui a toujours besoin de text box.
Du coup ils ont fusionné les 2 polices de caractères, l'une par dessus l'autre. L'idée c'est qu'une police de caractère peut se contenter d'un format 1bpp (une seul couleur + bg) alors que les tuiles de la NES sont des tuiles 2bpp (3 couleurs + bg) du coup les 2 polices se superpose en utilisant pas le meme bit de codage et on sélectionne l'une ou l'autre (ou plutot on cache l'une ou l'autre en lui donnant la couleur du fond) en jouant avec la palette.

Merci, c'est caviar ton épluchage de DK1 Jap et US
512 octets pour tous les sprites perso et pnj jap ... record ever pour un RPG je pense !!? J'aimerai bien comparer pour le fun avec les Gig que doivent prendre les pnj et le joueur sur un TW3 ou elder scroll online...

Iwata a assuré, il a vraiment marqué de son empreinte nin depuis le début de leurs consoles

Je m'amuse pas mal a mener l'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.
Pour mener mon enquete j'ai ca:

Spoiler:

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 (C'est mieux finalement que de jouer a TIS-100)

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.

Alors que dire des tilemaps dans 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 développeur, 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.

Je me suis amusé vite fais a me faire un hack du jeu juste pour le fun car j'avais pas encore essayé.
Je me suis fait une version du jeu ou lorsqu'on débute le jeu on est level max car faut 0 point d’expérience pour etre level max (donc max HP,MP et autre caracteristique dont toutes les magies)
Puis j'ai hacké le premier coffre qui se trouve dans la piece ou l'on débute le jeu pour qu'il contienne 64000 pieces d'or de quoi tout acheté dans le jeu.
Ensuite j'ai hacké la clé qui se trouve dans le second coffre pour en faire une clé magique non consommable avec laquelle on peut ouvrir toutes les portes du jeu (car normalement il faut une clé par porte et celle ci te sert juste a sortir de la premiere piece, faut ensuite attendre la moitié du jeu pour pouvoir acheter des clés)
Un reve de gosse.

Si jamais vous voulez un hack personnalisé sur mesure d'un jeu NES (Je peux aussi changer des bouts de texte pour les personnaliser ou meme un sprite, tout depend des jeux) je peux toujours tenter.
Je peux meme généré des codes gamegenie qui permette donc d'avoir le hack sur une vrai console avec le vrai jeu et pas juste en emulation (quoique avec un peu de cartmodding on peut mettre le fichier ROM hack sur une vrai cartouche).

En tentant de hacker le systeme de sauvegarde par code j'ai trouvé plus ou moins une reponse au dernier mystere, a savoir ce qu'il y avait dans la bank 3 de la ROM graphique (autre que la table de pointeur des textes qui doit pas occuper beaucoup de place). Et en fait ca a l'aire d'etre principalement du code CPU, de vrai bout de programme chargé en RAM.
Dans la bank 1 ils ont donc mis des données destiné au CPU (le texte) et dans la bank 3 c'est a priori plutot du code pure.
Si je dis ca c'est parce que j'y ai trouvé tout l'algo de décryptage des codes de sauvegarde.


Tout le morceau encadré en rouge c'est juste le bout de programme qui sert a decrypter les codes de sauvegarde (et qui je le repete n'a donc en théorie rien a faire dans la ROM destiné aux patterns graphiques).
Ce bout de code occupe la place de 70 tuiles soit l'equivalent de toutes les tuiles qui servent pour tout l’environnement du jeu!

Donc voila en réalité le vrai coupable, celui qui occupe le plus de place sur la cartouche, c'est le programme du jeu.
C'est la grande difference avec notre epoque ou la place occupé par le code est totalement insignifiante face aux données/assets alors qu'a cette epoque y avait tellement peu de place que le code occupait une grosse partie du stockage. D'autant plus sur le 6502 qui etait un CPU rapide mais avec un jeu d'instructions basique (et peu de registre) qui necessite parfois une succession d'instructions pour faire une operation simple et donc occupe un peu plus de place que du code Z80 (Master System, Coleco, MSX...) par exemple.

J'ai pas pu m'empecher de faire un dernier hack qui me plait bien (apres faut que j'arrete)
Dans DQ tu debutes dans un chateau avec la particularité d'apercevoir dès le debut le chateau du boss final de l'autre coté de la rive mais dont tu ne pourra acceder qu'a la fin apres un long detour et quelques items speciaux pour debloquer le chemin.




Bon ba j'ai fais venir quelques pelleteuses et j'ai construit un sentier direct vers le boss et ca marche

NX Gamer MGS 3

http://www.hardcoregaming101.net/demoscene/demoscene.htm

Bel aricle sur le démo making et son origine avec aussu les studios de jeux qui ont eu pour créateur des demomakers comme DMA design devenu Rockstar North ou Remedy...

bof le demo making c'est basique.

upsilandre a écrit:

bof le demo making c'est basique.

Excellent

NX GAMER et MGS 4

Pour aider un gars qui voulait utiliser des outils de rom haking de Megaman 3 pour refaire Makaimura j'ai du me pencher un peu sur le sprite engine de Megaman. Les sprites engine c'est la partie la plus compliqué des jeux de cette epoque (et du coté hardware c'est aussi la tres grande majorité des transistors du GPU) donc ca m'a permis d'y voir un peu plus claire, c'etait intéressant.

Mais du coup j'ai aussi relancé le Makaimura de la NES qui etait un des rares portage du jeu réussit a l'epoque mais qui malgres tout est quand meme plein de defauts techniques. Pas possible de corriger les problemes de framerate, de judder, de désynchro mais j'aurais bien aimé rectifier le sprite du zombi qui a une superposition de sprite au niveau de l'abdomen (ils ont 2 abdomen superposés) qui meme si je devine pourquoi ils ont fait ca me parait un peu idiot car ca ajoute 3 tonnes de flickering pour un gain dérisoire. Mais ca serait tres difficile et long aussi a corriger.

Du coup je me suis contenté de corriger un autre truc qui m'a toujours agacé dans cette version et qui t'agresse dès les premières secondes de jeu c'est le choix de couleur des zombis par rapport a la version original qui est un peu troublante, respecter les couleurs c'est un peu la base quand tu fais un portage.

Alors sur NES c'est vrai que tu choisie pas forcement tes couleurs car chaque palette est partagé entre plein de sprite differents et dans Makaimura certain sprite comme Arthur ou les zombis justement utilise deja 2 palettes differentes donc on peut deviner que ca necessite des compromis mais finalement j'ai trifouillé un peu et y avait moyen d'eviter cette faute de gout. Du coup je me suis fait une version hacké plus conforme.



Bon je voulais faire ca vite fait mais finalement ca m'a prit plusieurs heures car evidement il suffisait pas de refaire les pattern pour utiliser la palette differement. Le zombi utilise une palette pour la tete (blanc, rouge, bleu) et une autre palette pour le corps (blanc, rouge, noir) ce qui lui permet d'avoir 4 couleur au lieu de 3. Pour reproduire la VO (et toujours les meme 4 couleurs) ce qu'il me faut ici c'est une palette blanc,rouge pour la tete et blanc,bleu,noir pour le corps .

Or la palette du corps je ne peut pas la modifier car elle est utilisé pour plein d'autre sprite notamment Arthur par contre je peux utiliser celle ci pour la tete car y a du rouge et du blanc. Restait plus qu'a trouver les data qui associe les sprites a une palette.
Pour le corps j'ai modifier la palette de la tete que j'ai alors utiliser pour le corps. En effet cette palette blanc,bleu,rouge est surtout utiliser par les autres sprites pour son bleu et son blanc et moi j'ai juste besoin de changer le rouge en noir donc ca a peu de conséquence d'autant que les quelques sprites qui utilisait aussi le rouge de cette palette le faisait mal (par exemple le corbeau est plus jolie maintenant je trouve avec le noir a la place du rouge)

Donc restait plus qu'a trouver l'emplacement de cette palette pour la modifier et ensuite trouver les differents sprites des zombis pour modifier leurs metadata ainsi que leurs patterns (tout en sachant qu'il y a des redondances sur la cartouche, plusieurs fois le meme pool de sprite agencé differement qu'il faut corriger aussi)

Mais certain autres sprites du jeu utilisaient aussi cette palette blanc,bleu,rouge que j'ai modifié mais uniquement pour utiliser le blanc et le rouge et il se trouve que du blanc et du rouge y en avait deja dans l'autre palette (celle qui etait utilisé pour le corps du zombi et dans Arthur) donc la aussi il a fallu que je rectifie tous ces sprites pour modifier leur pattern et metadata mais il a fallu dabord rejouer tout le jeu pour les identifier (trouver ceux ou sa bug). Resultat ca concernait les flammes produit par l'arme de feu qui s'affichait en noir au lieu de rouge, pareille pour les flammes du level du pont enflammé et les explosions des ennemis ainsi que les tires des gorilles. J'ai du tous les modifier.

Au final j'ai quand meme réussit a obtenir le bon résultat sur tout le jeu. Comme quoi la aussi c'etait plutot un manque d'effort de Capcom. Quand je regarde dans le detail j'ai l'impression que le jeu a ete développer un peu dans la précipitation (Rien que quand tu vois tout le gachis d'espace qu'il y a sur la cartouche, c'est la toute premiere cartouche 128ko mais finalement mal exploité, je suis convaincu que c'est une décision de fin de développement et que le jeu etait concu au depart pour du 64Ko).

Je me suis décidé a mettre les mains dans le cambouis la semaine dernière pour enfin refaire Alex Kidd sur NES.
C'est juste une sorte d'exercice de programmation pour le plaisir et avoir des bases sur NES comme pour la VCS. J'ai pas l'intention a priori de faire plus que le premier level (qui est emblématique). Et au rythme de mes envies, j'ai pas d'objectif et suis pas pressé.
Comme toujours il sagit bien sur de programmation assembleur et "from scratch" comme on dit.

J'en suis au tout debut mais au moins j'ai réussis a produire un fichier ROM correct avec les octets au bon endroit (header, bank PGR, CHR, les pointeurs IRQ...), a faire un reset correct de la machine, a afficher un background fait maison, a le faire scroller (juste une vulgaire boucle de scroll horizontal mono-screen), a coder un debut de sprite engine et a afficher des sprites et a gérer les inputs.

Apres de long ajustements je suis assez content d'avoir réussit a reproduire correctement le background malgres les spécificité de la NES (pas de palettes RGB, seulement 3 couleurs par pattern, seulement 4 palettes de 3 couleurs, seulement une palette par metatile). Visuellement au moins ca fonctionne. Ca m'a retardé dans le code mais j'avais besoin de savoir.
J'ai aussi refais et upgradé le sprite par rapport a mes premiers essais pour etre vraiment pixel perfect avec l'original (a par quelque nuances de couleurs). Pour arriver a faire un beau sprite comme sur SMS avec la NES ca demande de la bidouille et + de budget sprite. Je me suis autorisé a augmenter le budget du sprite d'alex car apres calcule et avec un peu de bidouille ca devrait passer (je parle au niveau flickering, d'autant que sur la version Master System les sacs de pognon sont des sprites ce qui est idiot et ajoute une charge inutile dont je ferais l’économie en les intégrants au background), j'avais ete un peu strict sur mon premier jet (je voulais pas surcharger car je connais les limites de la machines) mais ca vaut le coup qu'il soit réussit.

J'ai donc aussi commencé a implémenter l'animation et le controle d'Alex au pad. On peut se deplacer (j'ai laissé le scrolling horizontal mono-screen), s'accroupir, donner un coup de poing. Manque le saut et y a bien sur aucune interaction pour l'instant, on en est loin.
Mais rien que sur ces premiers elements de controle je me suis acharné a reproduire parfaitement le comportement original comme la durée des frames d'animations, les coefficients d'accélérations et de décélération (j'ai récupéré les valeurs de la version SMS), les 10 frames de freeze quand tu fais un punch, le fait de garder l'inertie de décélération en position accroupi (glissade) ou de pouvoir se retourner, le fait que la sequence d'animation de la marche se prolonge meme une fois lacher le stick tant que la décélération n'est pas terminé, le fait de pouvoir cumuler la décélération naturel + l'accélération en sens inverse quand tu fais un demi-tour, de pas pouvoir prolonger les 10 frames de punch en appuyant tres vite ect...
C'est tout les petits détails qui font qu'on a l’impression ou pas de controler l'original donc c'est important.

Le lien de la ROM (que je mettrais a jour au fur et a mesure, le lien reste le meme):
https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ

La version Master System




Le truc intéressant c'est qu'avec la NES on a + de résolution vertical et justement sur SMS avec ce démarrage en scrolling vertical descendant on etait un peu a l'etroit, ca genait un peu le gameplay, sur NES on sera plus a l'aise pour ce genre de scrolling (surtout en emulation ou l'on voit toutes les lignes).

upsilandre a écrit:

Je me suis décidé a mettre les mains dans le cambouis la semaine dernière pour enfin refaire Alex Kidd sur NES.

T'as déjà fait énormément de choses je trouve
C'est vraiment épatant

Impressionant effectivement...

J'ai meme du faire du pixel art principalement pour refaire la pattern de l'herbe car je peux pas melanger roche et herbe sur la meme bande de metatile comme sur SMS mais finalement je m'en suis bien sortie (c'etait pas gagné)

manulelutin a écrit:

T'as déjà fait énormément de choses je trouve
C'est vraiment épatant

Le plus compliqué c'est tout ce qui sera du domaine de l'interaction et des ennemis, j'en suis loin. Je ferais des petit bout quand l'envie viendra. Ce qui est drole c'est que 2Ko de RAM ca me parait enorme apres etre passé sur Atari 2600, je sais meme pas a quoi ca va me servir (la je doit utiliser peut etre 20 octets).

upsilandre a écrit:

J'ai meme du faire du pixel art principalement pour refaire la pattern de l'herbe car je peux pas melanger roche et herbe sur la meme bande de metatile comme sur SMS mais finalement je m'en suis bien sortie (c'etait pas gagné)

ouais, j'ai vu ca pour l'herbe, c'était la principale diff', et je me suis dit que ca devait etre un probleme de pattern pour les tiles. Je suis content, ca prouve que quelque chose est resté de "cours" des posts précédents.

20 octet pour faire un systeme de scroll et de deplacement de persos 2d etc... C'est dingue, juste pour faire ca de nos jours, ces des centaines de ko réparties ds des blindes de classes ds un langage haut niveau / framework

Apres le premier jet qui m'a permis d'avoir rapidement un aperçu concret j'ai finalement presque tout recodé car certain aspect me convenait pas trop (j'avais intriqué des truc qui pour la suite nécessitait d'etre mieux dissocié) et puis c'etait un moyen de continuer a m'exercer encore un peu sur le code 6502 et retrouver un bon niveau de trick avant de continuer, je me sens bien dérouillé maintenant.
J'ai aussi revu mes regles de syntaxe et de mise en page et ma methodologie pour partir vraiment sur un truc propre.
Une fois retrouvé le niveau de la demo précédente j'ai pu corriger quelques truc et en ajouter.

Deja j'ai bloqué le scrolling dans un seul sens comme c'est le cas dans Alex kidd meme si je l'ai pas fait pour ca. C'etait surtout pour dissocier le sprite d'alex du scolling. Maintenant le sprite d'alex se deplace vraiment sur l'ecran (avant il etait fixe au centre, le scrolling faisait le reste) et enclenche le scrolling seulement en mid-screen.
Ca m'a aussi obligé a borné un peu les déplacements pour pas qu'il sorte de l'ecran et a faire aussi un peu de clipping a cause du coup de poing (quand on se collait a gauche de l'ecran en frappant, le poing apparaissait a droite).

Puis je me suis attelé au plus important, le saut qui est tres particulier dans Alex kidd (surtout sa hauteur qui ne dépend pas seulement de la durée d'appuie sur le bouton mais aussi de sa velocité horizontal) et donc devoir déterminer tous ses paramètres de facon empirique. Il a fallu aussi que je borne Y pour définir un sol (a défaut d'avoir un vrai moteur de collision).

J'ai donc maintenant un controle d'alex complet et sub-pixel perfect.
Je me suis bien prit la tete a analyser la VO frame par frame, pixel par pixel, a faire des dizaines de tests en frame advance sur les 2 versions cote a cote pour bien cerner chaque parametre.
Fallait deja comprendre que la position d'alex est géré au subpixel. Un pixel = 256 subpixel. Ensuite fallait trouver les coefficients d'acceleration et de décélération qui ne sont pas les memes et qui sont encore different en l'aire et au sol et different aussi a l'horizontal et a la vertical. definir les vitesse max (ca c'est facile) et plus chiant fallait aussi déterminer quelle variable est mis a jour avant ou apres quelle autre ou quelle process car ca implique ou pas une frame de lag qui modifie légerement les resultats. Et puis l'ensemble de conditions qui doit etre réunis pour chaque mouvement.

Au final sur ce genre de phase ca prend bien plus de temps de devoir copier un jeu que de faire un truc perso (sauf si ont est pas aussi pointilleux). Mais bon j'ai une demo NES qui reproduit le comportement d'Alex kidd au pixel pret et ca fait deja plaisir, c'est a priori pas grand chose mais pour moi c'est deja un gros morceau car c'est le coeur du jeu et pas le plus simple a reproduire de facon empirique. A vrai dire je pensais pas pouvoir le faire pixel perfect.

https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ


Par contre y a une liberté que j'ai prise par rapport a la VO. Si vous avez été joueur de Alex kidd vous vous souvenez sans doute qu'on pouvait s'accroupir dans l'elan d'une course pour glisser sous un bloc et ensuite se déplacer accroupi sous le bloc sauf que sur la version SMS pour s'accroupir il faut lacher la direction et appuyer sur bas ce qui n'etait pas du tout naturel dans l'elan d'une course, si tu faisais la diagonale il ne s'accroupissait pas et s'etait super désagréable en terme d'ergonomie, je détestais ca. Donc la j'ai corrigé, il est plus facile de s'accroupir pendant une course. Je sais pas si c'est trahir le gameplay original.