[NES] Samouraï Pizza Cats

Graou · Message non lu par **Graou** » 04 août 2011, 10:16

Si les autres solutions plus simples échouent, tu peux toujours regarder du côté du mapper pour voir s'il est possible de rajouter des banks (bancs) de mémoire supplémentaires dans lesquelles tu pourrais bouger le texte excédentaire. Par contre s'il y en a déjà le nombre max supporté par le mapper, tu es cuit.

Ca implique un peu d'asm pour ajouter ton numéro de bank dans les pointeurs et switcher de bank quand il y a besoin, mais c'est peut-être la seule solution sûre si le script est vraiment trop gros.

rid · Message non lu par **rid** » 04 août 2011, 10:22

Je suis très content que cette question soit posée Graou

Figure-toi qu'à une certaine époque, j'avais lancé l'an dernier un thread montrant comment j'avais doublé la taille de la PRG-ROM pour intégrer facilement le texte (bon ça avait ému peu de personnes alors...).

Je pourrai très bien passer par là, et ne plus me poser de question mais je trouve cette méthode (augmenter de 1/3 la taille de la rom) un peu trop "America, Fuck Yeah"

kogami · Message non lu par **kogami** » 04 août 2011, 10:26

Rid a écrit : (je dois avoir une 30aine d'emplacements de disponible dans la fonte...

Avec tout ça et une bonne optimisation Hareng-Tool compression, je pense qu'il y a de grande chance pour que ton texte rentre.

Sur DBZ HD, je ne pouvais pas déplacer le texte dans une nouvel Bank et avec une DTE graphique il me resté encore 57octet de place une fois le script réinséré.

C'est juste un peu relou car il faut tous les redessiner mais après

rid · Message non lu par **rid** » 04 août 2011, 10:38

Effectivement Hareng-Tool semble proposer pas mal de fonctionnalités très intéressante (et en plus le code source est dispo et compilable sous une distrib Linux: que du bonheur).
Je ne m'étais jamais trop intéressé à cet outil par flemme, et envie de faire les choses moi-même. Mais depuis quelques temps, j'ai revu ma position sur l'intérêt de réinventer la roue à chaque fois quand des aéroglisseurs existent...

--EDIT
... pour la petite histoire, je pense que ce revirement est plus ou moins lié à mon passage de Windows vers une distribution linux open-source...

Graou · Message non lu par **Graou** » 04 août 2011, 11:04

Rid a écrit :Je pourrai très bien passer par là, et ne plus me poser de question mais je trouve cette méthode (augmenter de 1/3 la taille de la rom) un peu trop "America, Fuck Yeah"

Personnellement, je ne vois pas du tout où est le problème avec cette méthode. Elle est tout à fait compatible avec le hardware au sens où ça pourrait tout à fait fonctionner sur une cartouche (à condition de bien respecter les specs du mapper), je ne vois vraiment pas la raison de s'en priver (sauf pour le plaisir de se coder sa compression super optimisée de la mort qui tue). Autant baser un hack sur une trappe dans un émulateur ou je ne sais pas quelle autre infâme bidouille je suis contre, autant là c'est techniquement plaisant et en plus très pratique.

M'enfin bon, les goûts les couleurs, tout ça

rid · Message non lu par **rid** » 23 août 2011, 01:20

Grmph, après mûres réflexions et diverses discussions, j'ai finalement opté pour le choix d'expansion de la taille de la ROM.

Comme je l'avais dit et démontré, avec un mapper MMC3, c'est ultra-simple de doubler la taille allouer à la PRG-ROM. Samouraï Pizza Cats utilisant un tel mapper, je dispose d'une version de la ROM agrandie pleinement fonctionnelle.
Après quelques recherches et tests sur le sujet, je suis parvenu à avoir une certaine vision de l'organisation des banks intervenant dans l'affichage des différentes scènes du jeu (une scène == une animation + du texte).

Grosso modo, voici comment se présente l'espace mémoire de la CPU au moment d'afficher les textes d'une scène:

de $8000 à $9FFF : fonctions liées à l'affichage du script (lecture du texte, des MTE, ...);
de $A000 à $BFFF : les données (script, mte, ...);
de $C000 à $DFFF : je sais pas, c'est pas important;
de $E000 à $FFFF : je sais pas, c'est pas important;

Les deux dernières banks ne m'intéressent pas car elles sont fixes. C'est à dire qu'on ne peut pas les déplacer (et elles sont pleines).

Donc finalement, je ne peux travailler que sur les deux premières banks de 2ko, ce qui est bien mais pas top.
C'est pas top car en fait le script s'étale sur plus de 2ko, je suis donc obligé d'utiliser plus d'une bank pour recueillir tout le script du jeu.

A ce sujet, j'ai déjà en tête une petite fonction ASM capable de me donner l'index de la bank à charger en fonction de l'index du pointeur de la scène. De plus, j'ai repéré l'endroit dans le code ASM où positionner l'index de la bank à charger juste avant d'afficher le texte. Cet endroit est situé dans la première bank. La bank est chargée quant à elle, je le rappelle, dans l'emplacement allant de $A000 à $BFFF.

Là où ça coince dans mon raisonnement, c'est que je ne vois pas du tout comment faire pour insérer mon petit code ASM permettant de sélectionner la bank contenant le script à afficher. En effet, la première bank est pleine à craquer: il n'y a pas plus de 5 octets de libre!

Alors, je fais appel au plus malin que moi, et je sais qu'il y en a beaucoup pour m'éclairer sur comment m'y prendre pour résoudre mon problème. Peut-être que je fais fausse route dans mon raisonnement sur comment étendre et appeler le script, j'en sais rien...

-- edit --------------------------------------------------------------------------------------------------------------------------

Boarf, après une petite nuit de sommeil sans rêve, j'ai fini par trouver plus ou moins un moyen.
En effet, au début de la bank située dans l'emplacement $8000 - $9FFF, il y a un appel à une fonction qui est réalisé (un JSR). La fonction appelée est située dans la même bank et son étendu est relativement bien cloisonné (une 50aine d'octet).

Mon idée consiste simplement à déplacer l'intégralité du contenu de cette fonction dans une nouvelle bank. Le code de la fonction dans la bank d'origine est remplacé par un code ASM qui indique de changer la bank se situant à l'emplacement $A000 - $BFFF par celle dans laquelle j'ai inséré le code de la fonction. L'appel à cette fonction se fait par un JSR $A000 (l'adresse CPU du début de la fonction déplacée). Au retour de la fonction, je replace la bank qui était dans $A000 - $BFFF avant l'appel, et le déroulement du code peut continuer tranquillement.

Cette méthode me permet de libérer quelques octets afin maintenant de placer ma bidouille ASM. Celle-ci consiste une fois de plus à changer de bank, appeler ma fonction qui place dans A le numéro de la bank contenant le script à afficher, et à replacer la bank initiale au retour. De cette manière, à l'issu de la fonction A contient l'index de la bank à utiliser pour aller chercher le contenu du texte. Et là encore, je rends la main au déroulement normal du code qui chargera la bonne bank avant de dérouler la routine d'affichage du texte de la scène.

Pour ceux qui ont suivi, j'aimerai avoir votre avis. Est-ce que je loupe un truc, ou est-ce que cette petite bidouille est susceptible de marcher? Je rappelle qu'au final, j'ai besoin de 3 banks supplémentaires (que je possède) pour faire fonctionner tout ça : 1 pour placer la fonction déplacée et la fonction qui détermine le numéro de la bank en fonction de l'index de la scène à afficher, et 2 pour le script scindé en 2.

Graou · Message non lu par **Graou** » 23 août 2011, 11:05

Ca me paraît bien et fonctionnel.
En effet le plus simple pour faire de la place, c'est de déplacer une partie du code d'origine dans un autre emplacement/bank et de faire un jsr dessus (faire un hook comme disent les djeunz il me semble),avec changement et restoration de bank si besoin.
Il faut juste que tu t'assures qu'il n'y a pas d'autre jump/branch/jsr qui atterrissent dans le code que tu déplaces.

Ah, et tu peux mettre la fonction que tu déplaces et ta nouvelle fonction dans une des bank du script, non ?

rid · Message non lu par **rid** » 23 août 2011, 11:14

Graou a écrit :Ah, et tu peux mettre la fonction que tu déplaces et ta nouvelle fonction dans une des bank du script, non ?

Hypothétiquement, ça reste possible en effet.
Je n'ai pas encore réellement calculé la taille qui sera occupée par les deux parties du script. Il va falloir que je bidouille mon outil pour qu'il ne génère non plus un seul gros bloc mais deux.
Histoire de bien faire les choses et étant donné le mode de fonctionnement de la routine d'affichage des textes, il va falloir que calcule deux dictionnaires (un pour chaque bank) de MTE.

Graou · Message non lu par **Graou** » 23 août 2011, 11:18

Ou, si tu as plein de place, tu peux toujours laisser tomber la MTE et stocker le script tel quel. Ca te prendra peut-être une ou deux bank en plus, mais ce n'est pas la fin du monde.

rid · Message non lu par **rid** » 23 août 2011, 11:28

Et avoir fait tout ça pour rien (modifier le hareng pour qu'il gère l'UTF-8 dans son calcul des mte)??? C'est bien mal me connaître

Spring · Message non lu par **Spring** » 23 août 2011, 18:24

Hey Rid!

Ravi de voir de voir que tu prends notre projet a bras le corps

Graou a écrit :
Rid a écrit :Je pourrai très bien passer par là, et ne plus me poser de question mais je trouve cette méthode (augmenter de 1/3 la taille de la rom) un peu trop "America, Fuck Yeah"
Personnellement, je ne vois pas du tout où est le problème avec cette méthode. Elle est tout à fait compatible avec le hardware au sens où ça pourrait tout à fait fonctionner sur une cartouche (à condition de bien respecter les specs du mapper), je ne vois vraiment pas la raison de s'en priver (sauf pour le plaisir de se coder sa compression super optimisée de la mort qui tue). Autant baser un hack sur une trappe dans un émulateur ou je ne sais pas quelle autre infâme bidouille je suis contre, autant là c'est techniquement plaisant et en plus très pratique.

M'enfin bon, les goûts les couleurs, tout ça

Ah ben je croyais que tu ne voulais pas de cette méthode justement parce que le jeu n'aurait pas pu être lu par la console? Bonne nouvelle alors! Je n'aurais pas à décapiter mon script pour qu'il rentre!

rid · Message non lu par **rid** » 24 août 2011, 01:06

Non, je ne voulais pas utiliser la méthode de l'expansion de la taille de la rom parce que je la trouve très chère en terme d'utilisation de l'espace.

Je rappelle que pour que la rom soit transposable sur une cartouche, il ne faut pas faire n'importe quoi avec la gestion du mapper. Et dans le cas du MMC3, augmenter la taille allouée au programme (la PRG-ROM), cela signifie la doubler (même si tu n'a pas besoin de tout cet espace).

Au final, comme j'ai pu le voir en encodant le script que tu as traduit, j'ai besoin de plus de 10ko de place disponible (à l'origine le script faisait seulement un peu plus de 7ko). Une bank de mapper MMC3 faisant 8ko, tu comprends vite que tu n'as besoin que d'une bank supplémentaire! Ce qui fait que maintenant, j'ai 5 banks de 8Ko remplies de 00 et qui ne servent par conséquent à rien si ce n'est prendre de la place

Je dis 5 banks et non 7, car pour l'instant c'est encore un peu le bordel dans la répartition de tout le bazar. Car

GRANDE NOUVELLE

, j'ai réussi à modifier la routine d'affichage du texte pour qu'elle puisse piocher dans telle ou telle bank en fonction de l'index de la scène associée au texte.
Donc pour l'instant, je dispose de deux banks destinées à recevoir les deux parties du script traduit, et d'une troisième bank qui contient la fonction que j'ai dû bouger pour intégrer la gestion des deux parties de texte.
Affaire à suivre, car je vais essayer de suivre le conseil de Graou concernant le placement de la fonction bougée dans une des deux banks contenant le script... Mais pour cela, il faut maintenant que je travaille sur le partage en deux parties du script et à son encodage (avec recalcul de pointeurs).

Graou · Message non lu par **Graou** » 24 août 2011, 10:08

Félicitations! Tu tiens le bon bout

Pour ce qui est de transposer ça sur une cartouche, je pense qu'en pratique, tu n'aurais pas besoin de mettre 5 EEPROM supplémentaires juste pour stocker des 00. Il suffit j'imagine, de s'arranger (en branchant les sorties du MMC3) pour que les numéros de banks correspondants attérissent tous dans le même composant mémoire physique (et peu importe lequel).

rid · Message non lu par **rid** » 24 août 2011, 23:42

Raaah, je suis un peu blasé là tout de suite :S

Comme on peut s'en douter, j'ai essayé d'insérer le script traduit dans la rom pour voir si cela fonctionnait. J'avais pas vraiment l'espoir d'obtenir un résultat flamboyant du premier coup, et j'ai donc été fortement surpris d'avoir ,après quelques petits réglages (enlever la taille du header des pointeurs, ...), du texte en français dans les scènes!

Donc là, j'étais content. Puis j'ai laissé un peu dérouler les différentes scènes du jeu, et là bang gros bug parce que j'avais mal fait mon boulot au moment de l'export des textes jap!

Il semble en effet que le moteur du jeu peut enchaîner deux textes pointés lorsqu'ils sont côte à côte dans la rom. Imaginez qu'on lit un pointeur de texte, on affiche le texte pointé par ce pointeur. D'habitude, une fois le caractère de fin lu, hop on s'arrête et on passe à autre chose. Pas là, il se peut en effet que le moteur décide de lire le texte qui suit sans passer par la case "lecture du pointeur" (enfin je grossis un peu les traits, j'imagine que le moteur du jeu vérifie l'index de la scène affichée, et en fonction décide de continuer la lecture des octets suivants le caractère de fin jusqu'à lecture d'un autre caractère de fin...).
Du coup, comme mon algorithme de réinsertion ne tenait pas compte de la position des textes les uns par rapport aux autres (les textes sont insérés par ordre des pointeurs dans la tables des pointeurs), les textes qui s'enchaînent n'ont désormais plus aucune logique de continuité! Il va donc falloir que je modifie mon algorithme de réinsertion pour insérer les textes en fonction de leur position les uns par rapport aux autres. C'est pas très compliqué, mais j'espère vraiment que c'est la seule surprise de la sorte que je vais trouver (j'étais encore un peu faiblard question programmation lorsque j'avais extrait le texte l'an dernier, et j'ai un peu peur de me rendre compte que des pointeurs ont été oubliés...).

Mais bon quoiqu'il en soit, ça commence à prendre forme

Spring · Message non lu par **Spring** » 25 août 2011, 17:56

Rid a écrit :Comme on peut s'en douter, j'ai essayé d'insérer le script traduit dans la rom pour voir si cela fonctionnait. J'avais pas vraiment l'espoir d'obtenir un résultat flamboyant du premier coup, et j'ai donc été fortement surpris d'avoir ,après quelques petits réglages (enlever la taille du header des pointeurs, ...), du texte en français dans les scènes!

Wouaahh, j'ai hâte de voir ça ^^
Mais tu comptes faire une MTE finalement?

Lestat · Message non lu par **Lestat** » 25 août 2011, 18:37

Faut pas se "blaser" pour ça!

En tout cas, un ou deux petits screens pour montrer l'avancement ça serait sympa (si tu as le temps)

Félicitations en tout cas!

rid · Message non lu par **rid** » 26 août 2011, 09:45

Les screens viendront le moment venu

pinktagada · Message non lu par **pinktagada** » 29 août 2011, 15:51

Je t'envoie malgré tout mes plus sincères encouragements

(et tu n'auras pas droit à la tenue de cheerleader)

Je vais me remettre à Lodis du coup

, j'ai un peu de temps libre. Mais je ne crois que ce que je vois, alors des ptits screens ça ferait bien plaisir

rid · Message non lu par **rid** » 07 sept. 2011, 15:01

Un petit point rapide pour présenter mes progrès depuis la dernière fois.

Après deux nuits de travail acharné, il y a deux semaines, je suis parvenu à comprendre (plus ou moins) comment fonctionnaient les animations des scènes de dialogues. Pour faire court, une animation est une succession de scénettes qui durent un temps défini dans un mot de 2 octets précisé au début de chaque bloc de code de scénette. Changer la valeur de ce mot rallonge ou raccourcit la durée de la scénette (et par extension de l'animation totale).

Donc, j'ai compté (si si

), il y a 37 scènes dans SPC. Chacune d'entre elles comporte au minimum 2 scénettes, et ça peut aller jusqu'à une dizaine. Donc, j'ai au moins 74 valeurs à modifier, tester, ajuster, et valider. Le tout pour une traduction française donnée: changer un texte signifie changer la durée de la scénette.

Donc, vous l'aurez compris, je ne vais pas m'amuser à modifier à la main et tester à chaque fois les durées de chaque scénette (je n'ai pas la patience ni la motivation d'un NobleBahamut pour

). Donc là, je suis plus ou moins en train de travailler à un nouvel outil de statistique de script où je vais compter tout ce qui me paraît être corrélé à la durée d'une scénette.
Pour cela, je compte repartir du script original et calculer pour une scénette le nombre de caractères affichés, le nombre retours à la ligne, le nombre de cadre, le nombre d'appel au dictionnaire des MTE, le nombre d'accents affichés (car ça utilise l'affichage de deux tiles), etc...

Une fois que j'aurai relevé toutes ces valeurs, je compte établir une règle me permettant de me rapprocher de la valeur de la durée des scénettes originales. Je compte ainsi appliquer cette règle au script traduit dans l'espoir d'arriver à quelque chose de correct et qui demandera pas ou peu de modification "à la main" par la suite.

Voilà, c'est tout pour le moment.

Conradson · Message non lu par **Conradson** » 07 sept. 2011, 16:24

Merci pour ce compte rendu détaillé, c'est vraiment plaisant de suivre de super projets comme ça, on a l'impression d'être un peu plus impliqué sans pour autant avoir fait qui que ce soit

.

Spring · Message non lu par **Spring** » 09 sept. 2011, 14:35

Rid a écrit :Pour cela, je compte repartir du script original et calculer pour une scénette le nombre de caractères affichés, le nombre retours à la ligne, le nombre de cadre, le nombre d'appel au dictionnaire des MTE, le nombre d'accents affichés (car ça utilise l'affichage de deux tiles), etc...

Si ca peut t'aider dans tes comptes, c'est le lien vers la vidéo des scènes du jeu qui m'a servi à traduire: http://www.youtube.com/user/TOPHADO#g/c ... 00CFA55DD2

rid · Message non lu par **rid** » 09 sept. 2011, 15:07

T'inquiète, j'ai trouvé où modifier la rom pour afficher telle ou telle animation au début du jeu

Lestat · Message non lu par **Lestat** » 18 févr. 2012, 23:29

Petit joueur

pinktagada · Message non lu par **pinktagada** » 19 févr. 2012, 02:25

Ouais mais la trad de rid/spring elle sera mieux

(d'abord)

(et tu la finis quand cette trad ? mon anniversaire c'est dans moins d'un mois !)

rid · Message non lu par **rid** » 19 févr. 2012, 10:36

Je suis un peu dessus qu'il n'a pas intégré la modification de l'écran titre qu'il m'avait demandé...

Et puis il l'avait commencé bien avant moi cette traduction, donc au final, j'ai encore de la marge.

Traductions de jeux vidéo (ROMs/ISOs)

[NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats

Re: [NES] Samouraï Pizza Cats