Annonce

Réduire
Aucune annonce.

traduction rex nebular

Réduire
X
  • Filtre
  • Heure
  • Afficher
Tout nettoyer
nouveaux messages

  • traduction rex nebular

    bonjour
    est-ce que rex nebular existe en VF ?

  • #2
    Non. Je l'avais acheté, à la FNAC, quelques mois après sa sortie, et il était en anglais bien que tous les textes sur la boîte du jeu , ainsi que le manuel sont en français.
    J'ignore s'il existe un patch... mais je n'ai jamais cherché.

    Commentaire


    • #3
      Ok ça serais bien que quelqu'un le traduise

      Commentaire


      • #4
        j'y avais pensé, mais les fichiers sont cryptés.
        Ils faudrait qu'un de nos programmeurs d'élite y jette un coup d'oeil.
        @+
        RyF
        Vieux de la Vieille de Lost Treasures Fr =^__^=

        Game Designer dans la Real Life ®©

        Commentaire


        • #5
          Je suis en train de le downloader, mais je le regarderai plutôt le weekend prochain. J'ai pas le temps et je connais pas ce jeu.

          Edit: le download s'arrête avant la fin, ça fait 2 fois déjà. Il a pas un problème, Lost Treasures? Je suis certain que c'est pas dû à ma connexion.
          Dernière modification par Hibernatus, 12-01-2004, 18h38.

          Commentaire


          • #6
            J'ai un peu regardé aujourd'hui. Voilà un début d'analyse.
            Dans le fichier GLOBAL.HAG:

            Le fichier commence par une simple table d'offsets pour les fichiers qui y sont rassemblés.
            A l'offset 0x10 un word donne le nombre de fichiers.
            La table commence à 0x12.
            Chaque entrée fait 22 bytes et contient:
            - L'offset (dword)
            - La taille (dword)
            - Le nom (byte[14], ou peut-être byte[13] suivi de B8, mais on s'en fiche)

            Dans certains fichiers le texte est en clair, avec seulement une table d'offsets à mettre à jour.

            Dans le fichier MESSAGES.DAT (offset 0x5430, mais allez voir à 0x90FA pour sauter la table d'offsets) le texte est compressé.
            Voici ce que j'ai compris de cette compression:
            Chaque texte commence par FAB. Il est segmenté en morceaux qui démarrent par un nombre (word la plupart du temps). Ce nombre indique à quels offsets du morceau on va procéder à une copie du texte précédent ("Coucou" s'écrit "Couc<copie de 'ou'>"), et la taille de chaque copie. Il indique aussi la longueur du morceau.

            Un exemple:
            "[title32][sentence] You can't take the [noun1], and even if you could, you would have no way of carrying [noun1:it:them] around with you."

            (Biensûr, ça s'affiche pas comme ça dans le jeu, mais ne vous inquiétez pas, je suis sûr de mon décodage)

            Ce texte est compressé comme suit:
            [title32][sent(FC FF)(-3)ce] You can't(0F 61) take(-5)h(-4)[n(F8 F0)(-20)n1], (-23)d e(F0 61)v(-40) if y(-20) c(18 70)(-4)ld(-23)(-11) w(3A 04) ...

            (FC FF) dit: à l'offset 0 je copie 2 chars, prochain morceau dans 15 chars.
            Donc (-3) qui est à l'offset 0 dit: copie les 2 chars qui sont 3 bytes avant moi ("en").

            (0F 61) dit: à l'offset 5 copie 2 chars, à l'offset 8 copie 2 chars, prochain morceau dans 12 chars.
            (-5) copie " t"
            (-4) copie "e "

            (F8 F0) dit: 2 char en 0, 2 chars en 7, fin à 12.
            (-20) copie "ou"
            (-23) copie "an"

            (F0 61) dit: 2 chars en 1, 8 chars en 2, fin à 12.
            (-40) copie "en"
            (-20) copie "ou"

            (18 70) dit: 2 chars en 0, 2 chars en 4, 3 chars en 6, fin à 11.
            (-4) copie "ou" (lui-même copié juste avant avec (-20))
            (-23) copie ", "
            (-11) copie "you" (pourquoi pas "you " directement, je sais pas)

            etc.

            Malheureusement je ne sais pas encore comment interpréter ce nombre au début de chaque morceau. Ca a pas l'air facile.
            En tout cas l'encodage serait possible même sans le connaître, il suffirait d'utiliser des morceaux sans copie, par exemple (FF FF), (FF 3F), etc. Et la taille on la modifie aisément avec la table. Mais bon, traduire un texte presque illisible ça serait dur...

            A part pour ce nombre ça semble être du gateau maintenant que j'ai compris l'algo. Mais ne me demandez pas d'écrire un prog J'ai vraiment pas envie de me fatiguer pour un jeu dont j'ignorais l'existence. Quelqu'un d'autre pourra le faire, c'est très simple, comme toujours quand la data est bien séparée du code (méchant lucasarts!).

            Commentaire


            • #7
              Ce nombre au début de chaque séquence ressemble à quelque chose comme ça;
              Chaque bit de ce nombre représente un des caractères suivants.
              Le bit le plus à droite représentant le premier caractère.
              S'il est à 1 le caractère est directement à prendre.
              S'il est à 0 ça indique un offset pour prendre un caractère précedent.
              d'où FC FF qui se lit FFFC donnerait 2 caractères à récupérer d'avant et 14 en clair.

              Il faut affiner car ce n'est pas exactement ça.
              [URL=http://perso.wanadoo.fr/fingus-winkle/OldWareTools.html][IMG]http://perso.wanadoo.fr/fingus-winkle/OldWareTools_Name.gif[/IMG][/URL]

              Commentaire


              • #8
                Il est strictement impossible d'avoir 1 bit par char vu qu'il faut indiquer la taille de la copie.
                Dans cette ligne que je donne en exemple il y a plus loin un 0xF4 qui veut dire copie 2 chars à l'offset 1 et termine au bout de 4 chars. J'ai eu beau verifier 15 fois c'est bien 1 seul byte et ça concerne bien 4 chars (ou bien j'ai mal vérifié et il faut concaténer avec le morceau suivant, je doute encore...). Je trouve ça assez troublant.
                Ceci dit je n'y ai pas passé beaucoup de temps, la solution est peut-être sous notre nez et on ne la voit pas Sinon un petit coup de désassembleur peut aider si on trouve un point de repère rapide.

                EDIT: Pour Dorian Gray et les autres qui veulent chercher, voici quelques infos que j'avais extraites, histoire de faire un recoupement:

                Format:
                nombre à comprendre: nombre de chars total | position1:taille1 position2:taille2 ...

                J'ai laissé le nombre comme si c'était du big endian, car j'ai un doute à cause de ce 0xF4 (qui me sidère encore

                Code:
                FF CF: 13 |
                FF 1F: 14 |
                FF 3F: 15 |
                FF 7F: 16 |
                FF FF: 16 |
                0F 61: 12 | 5:2 8:2
                F8 F0: 12 | 0:2 7:2
                F0 61: 12 | 1:2 8:2
                18 70: 11 | 0:2 4:2 6:3
                3A 04: 12 | 0:4 7:2 A:2
                78 80: 10 | 0:2 6:2 8:2
                BF 21: 13 | 7:6
                F4:     4 | 1:2
                0E 11: 11 | 0:3 5:2 8:3
                42 5A: ?? | 0:2 3:2 6:4
                43 FC: 13 | 3:2 6:3
                FF F0: 14 | 9:2
                FE FF: 16 | 0:2
                FF C3: 14 | B:2
                FF 31: 14 | A:3
                FC 3F: 14 | 0:2
                FC FF: 15 | 0:2
                10 E6: 15 | 0:2 4:2 6:4 B:4
                0F E1: 14 | 5:2 8:2
                10 FE: 12 | 1:2 4:2
                87 05: ?? | 4:2
                Dernière modification par Hibernatus, 17-01-2004, 01h31.

                Commentaire


                • #9
                  Mais si, le nombre de bits à 0 indiquant le nombre de caractères à prendre d'avant.
                  [URL=http://perso.wanadoo.fr/fingus-winkle/OldWareTools.html][IMG]http://perso.wanadoo.fr/fingus-winkle/OldWareTools_Name.gif[/IMG][/URL]

                  Commentaire


                  • #10
                    Ah ok, et tu fais comment pour différencier (0:2, 2:3) de (0:3, 3:2)? Je pensais aux chars de source au lieu des chars de destination (c'était bête de ma part d'ailleurs).
                    Dernière modification par Hibernatus, 17-01-2004, 08h39.

                    Commentaire


                    • #11
                      C'est un point de départ que je proposais.

                      exemple:
                      (0F 61) take(-5)h(-4)[n
                      (0F 61) dit: à l'offset 5 copie 2 chars, à l'offset 8 copie 2 chars, prochain morceau dans 12 chars.
                      (-5) copie " t"
                      (-4) copie "e "


                      donc 610F décomposé en binaire donne
                      0110 0001 0000 1111
                      une fois retourné
                      1111 0000 1000 0110
                      ce qui donnerait.
                      4 cars directs
                      4 cars d'avant
                      1 car direct
                      4 cars d'avant
                      2 cars directs
                      1 car d'avant

                      Le découpage a l'air correct entre parties d'avant et nouveaux caractères, sauf pour le dernier.
                      Le nombre de nouveaux caractères est correct sauf dans le premier cas; 4 au lieu de 5.
                      Et par contre le nombre d'anciens cars est à affiner comme je disais; 4 au lieu de 2
                      [URL=http://perso.wanadoo.fr/fingus-winkle/OldWareTools.html][IMG]http://perso.wanadoo.fr/fingus-winkle/OldWareTools_Name.gif[/IMG][/URL]

                      Commentaire


                      • #12
                        Vous etre tres intelligent!! (non, ça n'est pas ironique)

                        Euh.... moi je suis completement largué. Je comprends rien
                        Enfin je laisse les pros parler ensemble.

                        Commentaire


                        • #13
                          Provient du message de Dorian Gray
                          [B]C'est un point de départ que je proposais.

                          exemple:
                          (0F 61) take(-5)h(-4)[n
                          (0F 61) dit: à l'offset 5 copie 2 chars, à l'offset 8 copie 2 chars, prochain morceau dans 12 chars.
                          (-5) copie " t"
                          (-4) copie "e "


                          donc 610F décomposé en binaire donne
                          0110 0001 0000 1111
                          une fois retourné
                          1111 0000 1000 0110
                          Je trouve très bien que tu proposes des idées, surtout que moi j'en ai pas, cependant celle-ci ne correspond simplement pas à l'algo, à cause de ce (0:2 2:3) que j'ai cité. Dans les exemples que j'ai donnés il y a des cas à peu près semblables (10 E6: 15 | 0:2 4:2 6:4 B:4, 78 80: 10 | 0:2 6:2 8:2). Le problème c'est qu'on a pas "copie/pas copie", on a "copie1/copie2/copie3/pas copie". A la limite il pourrait y avoir un 1 terminateur à la fin de chaque série de zero (pourquoi pas), mais il y a des exemples avec des copies et quand même 16 chars... Bref on peut toujours essayer de bidouiller, mais j'ai pas l'impression que ça soit la bonne piste.
                          Et puis regardons tout simplement FF FF, FF 3F, FF 1F. Aucun d'eux ne fait de copie et on a déjà 3 bits de grillés.
                          Dernière modification par Hibernatus, 17-01-2004, 19h12.

                          Commentaire


                          • #14
                            Oui, j'avais noté le cas particulier des FF FF, FF 3F, FF 1F
                            Et si ils étaient gérés particulièrement pour copier moins de 16 caractères pour finir un bloc compressé ?
                            Sinon pour les autres cas que tu indiques, je n'ai pas d'idée.

                            Quant à aller voir dans l'exe

                            Au fait, il n'existe pas d'émulateur qui supporte cette bestiole ?
                            S'il existe faudrait regarder son source s'il est dispo.
                            [URL=http://perso.wanadoo.fr/fingus-winkle/OldWareTools.html][IMG]http://perso.wanadoo.fr/fingus-winkle/OldWareTools_Name.gif[/IMG][/URL]

                            Commentaire


                            • #15
                              Juste une précision, si quelqu'un veut faire des tests, ne pas oublier de changer la taille du buffer.
                              Dans la table d'offsets:
                              word nombre de textes
                              puis pour chacun:
                              int numero
                              int offset
                              word taille du buffer de décompression (comptez le terminateur NULL)

                              EDIT: pour aller voir dans l'exe ça serait peut être facile si IDA le lisait correctement. Malheureusement on dirait qu'il y a un truc inhabituel qui fout tout en en l'air Du coup il me donne pas les références à "MESSAGES" qui auraient pourtant été un bon point de départ vu que le jeu réouvre ce fichier à chaque apparition d'un nouveau message.
                              Dernière modification par Hibernatus, 17-01-2004, 20h36.

                              Commentaire

                              Chargement...
                              X