Seiken Densetsu 4 de PS2

Tutoriales, herramientas, aportes, etc

Moderador: skybladecloud

Cerrado
CUE

Seiken Densetsu 4 de PS2

Mensaje por CUE » Lun May 25, 2009 8:07 pm

Voy a ver si consigo explicar, un poco por encima, cómo extraer los datos de este juego, del que me niego a usar la horrenda traducción inglesa. Una vez terminada la explicación postearé el programa que hice para que Eliseo pudiera traducirlo de una forma más cómoda, con una explicación de sus funciones. Si alguien está lo suficientemente loco y aburrido y quiere, al final de todo, ponerlo en plan "bonito", es libre de hacerlo, que yo lo hago según me viene. Y si alguien quiere mandarme unas cervezas, bien recibidas serán (esto nunca cuela, pero lo suelto por si acaso ;) ).


Esta explicación es 'tal cual', y puede ser distribuida libremente sin ningún problema, así como el programa y demás ficheros asociados. No voy a decir eso de que se cite el nombre del autor y bla-bla-bla porque realmente no me importa. Yo ya disfruto bastante haciendo estas cosas y la mejor recompensa que puedo tener es saber que alguien pueda encontrar alguna utilidad en ello.


He visto que por aquí normalmente tratáis las imágenes de la play como si fuesen cartuchos de consola, y, aunque puede hacerse así, creo que puede ser interesante ver otros métodos.


Bueno, pues lo primero que tengo que decir es que siempre quiero hacer las cosas con el mínimo de programas posible, a saber:
- el WinHex para ojear ficheros
- el programa para tratar los ficheros
- el bloc de notas para editar los textos (o cualquier editor que soporte unicode)
- el paint para modificar los gráficos si es el caso (por desgracia, no he conseguido sacarlos bien en este juego)

Viendo el bloc de notas y el paint creo que no cabe duda de que más simple no puede ser ;)


Para facilitar un poco las cosas de la explicación:
- los números suelo indicarlos en hexadecimal, con el típico 0x delante, al estilo C, si no llevan esa coletilla es que se trata de números decimales
- los valores, a no ser que indique lo contrario, siempre se almacenan con el byte menos significativo primero
- al referirme a 'sector' quiero decir los 0x800 (2KB) bytes de información de cada sector del DVD


Lo primero que hay que hacer es averiguar dónde y cómo están los datos necesarios, o sea, los textos, las fuentes y los gráficos. A simple vista puede parecer un preñazo, pero con la práctica se reduce a muy poco tiempo.
Un vistazo al DVD del juego ya nos dice mucho. Además del típico ejecutable, el fichero de configuración típico y varios ficheros que no se necesitarán, vemos que hay un fichero, el DATA.BIN, de más de dos gigas. Ahí debe estar todo.
Para trabajar más cómodamente, copiamos el 'ficherito' al disco duro.


Echamos una ojeada al fichero con el WinHex.


Nada más abrirlo vemos que aparece la cabecera "RCB", con algún que otro número después, estando el resto del sector rellenado con ceros. Eso ya nos da una pista. Hacemos una búsqueda de la palabra "RCB" y vemos que siempre sigue la misma pauta: las 3 letras al principio de un sector, un cero, un uno, tres ceros, un número que varía, y el resto son ceros.
[img]http://img10.imageshack.us/img10/8018/61486483.th.png[/img]

El DATA.BIN tiene toda la pinta de ser un fichero que contiene archivos empaquetados, así que vamos a extraer cada uno de ellos. El primer sector de cada archivo, el que comienza con las tres letras, lo ignoramos, pues no parece que tenga información relevante. En total salen 1175 archivos RCB, que numeramos desde RCB0001 hasta RCB1175, con los números en decimal.

Ahora vamos a mirar los archivos extraídos. Cojemos el primero, el RCB0001 y empezamos a fisgar: montones de números por aquí y por allá. Vaya, por ahí aparece la palabra "system", y un poco más adelante "ArrowDrawEnv.ALL, que parece un nombre de fichero. Lo normal es que en algún sitio nos indique el número de ficheros que hay y los offsets donde están, y suele ser un dato situado al inicio del archivo. Como los RCB que hemos extraído pueden ser bastante grandes es lógico suponer que el offset a cada fichero deberá ser un entero de 4 bytes, así que vamos a ver si encontramos esos offsets, sabiendo que cada uno deberá ser inferior al posterior, pues raro sería que no estuviesen ordenados.

No fue difícil, justo en el offset 0x30 del archivo aparecen varios enteros de 4 bytes, cada uno inferior al posterior, y, al final de todos ellos, 4 ceros.
Miramos también otro par de archivos, el RCB0002 y el RCB0003, para ver si también aparecen los offsets en la misma posición.
[img]http://img10.imageshack.us/img10/8088/78348112.th.png[/img]

Lo están, así que vamos a coger unos RCB pequeños para trabajar mejor, pues tendrán menos datos. Cogemos el RCB0004, RCB0007 y RCB0010.
Contamos los offsets que hay en cada uno de esos archivos, 3,1,1, y vemos como, curiosamente, esos valores están indicados en la posición 0x08 del archivo.
[img]http://img37.imageshack.us/img37/618/62687942.th.png[/img]

Algo hemos adelantado. Miramos algún fichero grande, el RCB0001, y vemos algo raro, hay 13 offsets, pero en la posición 0x08 pone 12, y después 1. En el archivo RCB0002 hay 170 offsets, y en la posición 0x08 hay 0, seguido de 170. Así que las posiciones 0x08 y 0x0C definen el número de entradas que hay. Luego miraremos a qué se debe que estén divididas en dos campos.

Pasemos a mirar el RCB0007, que es el más pequeño de todos.
El offset que hay es 0x0070. Vamos a esa dirección, y un montón de ceros seguidos de algún que otro dato, hasta que llega a lo que parece ser un nombre de fichero, y el resto del sector se rellena con ceros.
[img]http://img37.imageshack.us/img37/1091/77173510.th.png[/img]

Miramos el RCB0010, que también tiene 1 offset, y vemos que es exactamente lo mismo.
[img]http://img37.imageshack.us/img37/7852/46750585.th.png[/img] [img]http://img37.imageshack.us/img37/5702/63601764.th.png[/img]

Aquí ya nos fijamos en algo más. El nombre del fichero empieza en 0xD00, que si restamos los 0x70 iniciales se nos queda en 0xC90, que es el valor indicado en la posición 0x70 + 0x08, es decir, 8 bytes más allá del inicio de la zona que estamos mirando. Comprobamos otros archivos, con más offsets, y vemos que en todos pasa lo mismo. Así que ya sabemos que 8 bytes más allá de la dirección del offset está el tamaño del fichero, y justo después aparece lo que debe ser el nombre del fichero, en formato asciiz, terminado en cero y rellenado con ceros hasta que comienza la dirección del siguiente offset o hasta completar el sector en el caso de que sea el último fichero.

Siguiendo con el RCB0007, vamos a ver ese texto que aparece por ahí, el 'SystemWord' (cada RCB tiene un texto por ahí, un poco más arriba de los datos del primer fichero). Está en el offset 0x5C, que, curiosamente, también está definido en las direcciones 0x20 y 0x24. Miramos más archivos y en todos es lo mismo, hasta que nos fijamos en el RCB0001, donde vemos que está definido sólo en 0x24. Otro dato que ya sabemos. Mirando más archivos parece ser que no son nombre de ficheros, mas bien parecen nombres de carpetas, pues los ficheros suelen llevar extensión, aunque no siempre.

Ahora nos queda por saber por qué el número de ficheros estaba dividido entre dos campos. Mirando esos RCB vemos que sólo el primer campo define el número de ficheros, siendo el número que aparece en el segundo campo un offset que apunta a una estructura idéntica a la que hemos descrito. Eso confirma que el texto que hemos encontrado antes era una carpeta, y los ficheros que hay son los que pertenecen a esa carpeta.

Así que ya sabemos que cada RCB se compone de ficheros y carpetas. Haciendo varias pruebas, se puede comprobar que en la dirección 0x08 se define el número de ficheros de la carpeta indicada en 0x24, y en la posición 0x0C se define el número de subcarpetas que hay, todas ellas con la misma estructura que se ha explicado, por lo que extraer los ficheros finales es un simple coser y cantar.


Dentro de 2-3 días pasamos a investigar los ficheros extraídos.



* Sorry por no poner de otra forma las imágenes, pero es como me salen, y si las pongo a tamaño real no sé si a la gente se les descuadrará el foro.

* Por cierto, ¿hay algún límite en el tamaño de los posts? Es para saber si sigo con la explicación editando éste o haciendo uno nuevo.

CUE

Mensaje por CUE » Mié May 27, 2009 4:02 pm

A seguir con el tajo.

Bueno, aunque parece "relativamente" fácil lo de los ficheros y carpetas, eso trajo algún que otro quebradero de cabeza. La primera prueba que hice me extrajo más de 30.000 ficheros en el directorio en que estaba trabajando, y menos mal que lo paré a tiempo. En total, el DATA.BIN tiene más de 160.000 ficheros repartidos en mogollón de carpetas, y aquí hay algo que no he acabado de comprender. Misteriosamente, se extraen unos 5.000 ficheros menos de los que hay. La explicación es simple: hay ficheros con el mismo nombre dentro de una misma carpeta. La única explicación que me parece viable es que se trate de "restos", basura que ha quedado ahí por algún motivo. De todas formas, ninguno de esos ficheros contiene textos, como vi después, así que tampoco me preocupa mucho el asunto.

Al ver esa historia de los ficheros repetidos hice unas pruebas más, mirando lo que extraía para ver qué tamaño tenía. En 6 casos quedaban más datos en los archivos (RCB0001,RCB0006,RCB0008,RCB0054,RCB0384,RCB1175), sin nombre ni nada. Por lo que se pude ver, la mayoría son datos de sonido y creo que tal vez vídeos, incluso en un caso hay un script lua usado para el modo debug. Como esos datos no se van a necesitar ni se va a tocar nada de ellos, los dejé tal cual.

Ahora toca interpretar esos ficheros. La verdad es que no fue difícil. Basta hacer una lista con todos los nombres y echar un vistazo. Muchos se pueden eliminar directamente porque el nombre no dice nada, pero hay varios que destacan nada más verlos: unos ficheros llamados FONT* y otros que se llaman *MESSAGE*.

Lo de FONT* ya es suficiente reclamo para echar un vistazo, así que es hora de echar una ojeada. Abriendo todos con el WinHex (son 6 en la misma carpeta) se observa una primera parte idéntica en todos ellos, desde la posicón 0x00 hasta la 0x6F, así que no parece que ahí haya datos de interés. También aparece un texto en la dirección 0x70, "TMB3", seguido de números que ya cambian entre cada fichero.
[img]http://img223.imageshack.us/img223/2092/78903963.th.png[/img]

Mirando el final de cada fichero se ve lo que parece una paleta de colores, de 4 bytes por color, lo que se traduce en 16 colores (los que hayan trabajado con gráficos y paletas verán la estructura, con ese característico 0x80 cada 4 bytes).
[img]http://img38.imageshack.us/img38/7500/89864720.th.png[/img]

Aquí ya hay datos que interesan, y no sólo la paleta. En el fichero FONT0.PS2 vemos que la paleta comienza en 0x20090, así que si es una imagen normal, es lógico suponer que sea de 0x20000 bytes, que es un número que se puede obtener con unas anchuras y alturas de 1024/512/256/128. En este caso podría ser una imagen de 1024x128, 512x256, 256x512, 128x1024, que empezaría en 0x90. Mirando los otros ficheros ocurre algo parecido, saliendo dos ficheros con el valor 0x20000, otros dos 0x10000 y otros dos con 0x08000.

Ahora ya podemos suponer que cada fichero se compone de varias partes:
- bytes 0x00 a 0x6F, sin nada de interés
- bytes 0x70 a 0x8F, que es donde está el texto "TMB3" y los numeritos que cambian
- bytes 0x90 hasta llegar a la paleta (0x???90), que debe ser la imagen
- bytes 0x???90 hasta el final, con la paleta

Más cosas en las que nos podemos fijar:
- FONT0 y FONT1, del mismo tamaño, tienen los bytes 0x88 0x88 después del texto (posiciones 0x74 y 0x75), y ambas ficheros son del mismo tamaño de imagen, 0x20000.
- FONT2 y FONT3, del mismo tamaño, tienen los bytes 0x88 0x77 después del texto (posiciones 0x74 y 0x75), y ambos ficheros son del mismo tamaño de imagen, 0x10000.
- FONT4 y FONT5, del mismo tamaño, tienen los bytes 0x88 0x66 después del texto (posiciones 0x74 y 0x75), y ambos ficheros son del mismo tamaño de imagen, 0x08000.

La verdad es que aquí ya entra en juego el haber trabajado con muchos ficheros antes y saber dónde y cómo buscar. Fijándonos en el valor que cambia, el segundo byte, y sólo en el dígito final, y en que las longitudes de las imágenes van siendo cada vez la mitad, vemos que el dígito cambia en una unidad, así que bien podría ser una potencia de 2. Hacemos un cálculo rápido:
- 8: 2^8 = 256
- 7: 2^7 = 128
- 6: 2^6 = 64

Si hacemos lo mismo con el primer byte, que siempre es el mismo, obtenemos el valor 256.

Multiplicamos ambos valores:
- 256 * 256 = 65536 (0x10000)
- 256 * 128 = 32768 (0x08000)
- 256 * 64 = 16384 (0x04000)

Curioso, se obtiene justamente la mitad del tamaño de la longitud.

Ahora entra en juego la parte de la programación, y consiste en coger cada imagen y ver si la podemos pasar a un fichero BMP, pues tenemos casi todo lo necesario, y solo nos falta ajustar la altura y la anchura. Unas pruebas con los valores antes calculados, multiplicando uno de ellos por dos para así tener la imagen completa y no sólo la mitad, permiten obtener una imagen nítida del juego de caracteres. ¡¡¡BINGO!!!.
[img]http://img39.imageshack.us/img39/9042/87457538.th.png[/img]
Al final ha resultado que la anchura es la mitad del valor obtenido a partir del primer byte y la altura es el valor obtenido a partir del otro byte. También es importante ver que incluye todos los caracteres especiales del español (en realidad muchos más que esos).

Haciendo lo mismo con los otros FONT, obtenemos dos imágenes con dos sets de fuentes similares, otras dos imágenes con algún nombre y letras sin sentido y otras dos con parte del set de caracteres. Aquí he supuesto que originalmente, en el juego en japonés, se deben utilizar los 6 ficheros, y que a la hora de traducir el juego han usado solo los dos primeros, dejando restos en los demás. Si alguien tiene opción de chequear el juego en japonés cuando postee el programa que permite extraer los gráficos, sería de gran ayuda conocer si es así o no.

Ojeando más bytes, y sabiendo ya los tamaños de la imagen, se puede hallar el tamaño de la misma con los dos bytes que hay a partir de 0x7A:
- 0x2000
- 0x2000
- 0x1000
- 0x1000
- 0x0800
- 0x0800
Vemos que son los mismo que teníamos calculados, con un cero menos, así que ese valor, multiplicado por 16, es el que define el tamaño de la imagen.

Ahora toca currar más de programata, que es la parte que aburrirá a más de uno o no entenderá, así que no me extenderé mucho con ella. Modifiqué el programa para sacar sólo los ficheros que tuvieran el "TMB3" ése que aparecía en las fuentes para ver si eran similares. Salen un montón, no recuerdo ahora la cifra exacta, pero recuerdo que eran varios miles. También hice que me sacara un log con los nombres de los ficheros, su tamaño y los valores que hay a partir del texto, así como los que podía calcular (ancho, alto, etc). En principio no me cuadraban bien los datos, así que eché una ojeada a unos cuantos. Lo primero que vi es que la paleta cambiaba. En la mayoría de los ficheros era una paleta de 256 colores, ocupando 1KB. Unas modificaciones por aquí y por allá y los datos del log ya cuadraban algo más. Por los datos obtenidos se podía ver que sólo había paletas de 16 y 256 colores. En el caso de los 16 colores, como las fuentes, todo cuadraba a la perfección, pero no así cuando eran 256 colores. No funcionaba bien la forma de calcular el ancho y el alto. Más pruebas y al final resultó que en el caso de 256 colores el ancho hay que multiplicarlo por 2 y el alto dividirlo por 2. Que nadie me pregunte por qué, pero es así. Ya coinciden ahora todos los datos, el ancho, el alto, el tamaño de la imagen y la paleta de colores.

Ahora otra vez tocaba fisgar datos. Miré los ficheros de imágenes de 16 colores y los de 256 (no todos, que sólo tengo una vida) y enseguida se veía la diferencia. En el byte 0x79 aparece un valor 0x02 o 0x33. Si aparece un 0x02 siempre hay paleta de 16 colores, siendo de 256 en el otro caso. Problema resuelto.

Aquí llegó una de mis decepciones. Ningún gráfico se ve bien. Manda narices que de varios miles de ficheros con gráficos haya empezado con los únicos 6 que me salen bien, ¡¡¡menos de 1 por mil de probabilidades de que sucediera!!! Habrá que llamar a Iker Jiménez para que lo explique, porque no lo veo normal, aunque es una suerte, porque al menos sé donde están los caracteres y eso fue vital para tratar los textos.

Un ejemplo de imagen de 256 colores, donde se puede ver el título del juego:
[img]http://img43.imageshack.us/img43/5015/11785979.th.png[/img]

Se pueden ver contornos más o menos definidos y partes de la imagen encuadradas en varios rectángulos, lo que me lleva a suponer que tanto el ancho como el alto están bien hallados, pero no entiendo porqué no sale bien. Pero el caso de los 16 colores es todavía peor. Las fuentes salen perfectas, pero el resto de imágenes a saber lo que tendrán. No lo entiendo, son las mismas estructuras de datos, hago los mismos cálculos, pero no me sale nada más. He probado a cambiar los tamaños, alternar bytes, pero nada de nada, sigue sin salir bien. Me hubiese gustado haber hecho otro tipo de pruebas, como meter ciertos datos determinados (líneas, etc) para ver cómo las mostraba el juego, pero, y esto no lo he contado antes, no tengo PS2, así que es algo imposible que haga. Tampoco puedo pedir que lo hagan por mí, porque podría hacer docenas de pruebas y eso, entre mandar los programas modificados, que metan las imágenes en los ficheros, que graben un dvd, lo prueben, me saquen fotos nítidas y demás, podría llegar a ser eterno.


Bueno, pues hasta aquí el fascículo de hoy, dedicado al maravillo mundo de los gráficos. Ya sólo quedan los textos.

CUE

Mensaje por CUE » Dom May 31, 2009 12:42 pm

Llegó la hora de otro poco de rollo más, lo ideal ahora que empieza a hacer buen tiempo (si es que a 30º se le puede llamar buen tiempo) si se desea echar una buena siesta. Para eso estoy yo aquí ;)

Llegamos a los textos, el objetivo final de toda traducción. Como se indicó anteriormente, se habían visto varios ficheros "sospechosos", pues contenían la palabra "message" en su nombre, así que ya es hora de ver qué tienen por dentro. Después de ojearlos, se ve que hay dos tipos, claramente identificables por su signatura, al igual que pasaba con lo gráficos. Uno de ellos siempre lleva el texto "MESG" en la posición 0x20 y el otro tiene "SCMS" en la posición 0x24. Todos los textos siguen esa pauta, o bien pertenecen a un tipo o bien al otro, sin excepciones. Al igual que ocurrió con los gráficos, también se miraron más ficheros para ver si llevaban textos, por si algo se pasaba por alto.
[img]http://img198.imageshack.us/img198/6043/42129420.th.png[/img] [img]http://img198.imageshack.us/img198/6683/23736706.th.png[/img]

Cada uno de esos tipos de ficheros requiere un tratamiento distinto, así que veremos cada uno por separado. Sólo voy a usar las dos imágenes anteriores como referencia, pues basta con ellas para explicar todo, pero para deducir muchas cosas se han tenido que utilizar varios ficheros, y no es plan de poner imágenes de todos ellos.


Los ficheros de signatura "MESG"

Al mirar estos ficheros se ven claramente ciertas palabras. Para que no sea todo tan sencillo, también se ven entre ellas un montón de bytes que, en principio, no tienen sentido. Lo primero que se observa es que se sólo se pueden "leer" caracteres alfanuméricos (las 26 mayúsculas, las 26 minúsculas y los 10 números). También que se repite mucho el código 0xE3 0x80 0x80, y no hay que ser muy avispado para ver que siempre está entre dos palabras, de lo que se deduce que esos tres bytes son en realidad un espacio en blanco. Así que parece ser que cualquier carácter no alfanumérico está codificado como una secuencia de bytes. Poco a poco se fueron sacando más caracteres: el punto, la coma, el guión, la admiración (de algo ha servido hacer tantos pasatiempos), ..., y se vio que hay 3 tipos de código:
- los que comienzan por la barra invertida '\', que realmente son códigos de control
- los que comienzan por 0xE?, que siempre son de tres bytes
- los que comienzan por 0xC?, que siempre son de dos bytes
el resto, como se ha dicho, son los caracteres alfanuméricos.

Con las equivalencias halladas no fue difícil sacar una relación, y es que esa codificación está relacionada con los caracteres unicode. A esto ayudó muchísimo que suelo trabajar con esos caracteres, lo que me ahorró mucho tiempo.

La relación que se encontró fue la siguiente:
- caracteres de 1 byte (NN) -> código: NN (los alfanuméricos)
- caracteres de 2 bytes (CX-NN) -> código: NN + 0x40*(CX - 0xC2)
- caracteres de 3 bytes (EX-MM-NN) -> código: NN + 0x40*(MM - 0xC2) + 0x1000*(EX - E0 + 1)
Con ese simple algoritmo se puede extraer cualquier texto (los códigos unicode se pueden ver en muchas páginas webs, así que no voy a poner ejemplos de ellos).

Todos los caracteres que aparecen en la imagen de la fuente de caracteres se pueden obtener así, excepto los dos últimos, que da la impresión de que han sido modificados. Tampoco es que importe mucho, pues no se utilizan.

Los códigos de control encontrados son los siguientes:
- '\FC', seguido de 4 bytes -> Es el 'Foreground Color' e indica que lo siguiente se escribirá en el color que indican los 4 bytes
- '\FE' -> 'Foreground End', que indica fin de color
- '\PT' -> ni idea de lo que significa
- '\PE' -> ni idea de lo que significa, pero, por deducción, parece ser 'fin de PT', sea lo que sea que signifique
- '\SP', seguido de un byte, que tampoco sé lo que es, aunque sospecho que se trata de un espaciado, indicando el número de espacios que se van a poner

Además de esos códigos hay otros que se refieren a los botones del mando de la consola. No todos se usan, pero se hace referencia a ellos en el ejecutable, y su función es mostrar el gráfico de dicho botón:
- '\ST', botón START (StarT)
- '\SE', botón SELECT (SElect)
- '\UP', botón ARRIBA (UP)
- '\RT', botón DERECHA (RighT)
- '\LT', botón IZQUIERDA (LefT)
- '\DN', botón ABAJO (DowN)
- '\CC', botón CIRCULO (CirCle)
- '\SQ', botón CUADRADO (SQuare)
- '\TA', botón TRIANGULO (TriAngle)
- '\CS', botón X (CrosS)
- '\R1', botón R1 (Right 1)
- '\L1', botón L1 (Left 1)
- '\R2', botón R2 (Right 2)
- '\L2', botón L2 (Left 2)
- '\AR', mando analógico derecho (Analog Right)
- '\AL', mando analógico izquierdo (Analog Left)
- '\R3', botón analógico??? (no estoy seguro de éste)

Ya sabemos cómo interpretar todos los caracteres que vemos, así que ahora vamos a ver cómo localizar los textos.

Cualquier texto tiene un espacio fijo, y vemos que el primero comienza en la posición 0x34, el segundo en la 0x148, ... Una simple progresión que nos dice que los textos siempre están en 0x34 + n*0x114. Los 4 bytes que hay antes de cada texto parecen ser un número identificativo (0, 1, ...), pero no son necesarios para nada.

La longitud de los textos es algo que no tengo claro del todo. En principio bien podrían ser 256 caracteres, pero, como se ve en la imagen, hay por el medio algún código (ese 0x20-0x41 del ejemplo), que no sé si son restos de textos anteriores o datos que se necesitan. Como no he querido complicarme la vida, en el programa permito que ese valor se defina, poniendo por defecto 192 caracteres, y que sea el traductor quien haga pruebas para ver si se pueden meter más o menos simplemente cambiando el valor.

Ahora ya se pueden extraer todos los textos, y de ahí se sacan más cosas. Lo primero es que muchos textos están repetidos, lo cual es una ventaja a la hora de traducir, pues basta con traducir un fichero y copiarlo donde esté repetido para no tener que hacer el trabajo varias veces (con el programa incluyo una lista de todos los ficheros de texto, indicando los que son repetidos). También se observan ciertos ficheros totalmente ilegibles, lo que supuse eran restos de la versión japonesa del juego, hecho que después comprobé, pero eso lo dejo para el final, cuando comente algunas curiosidades.

Nada más hay que contar de estos ficheros, tenemos todo lo que necesitamos para poder tratarlos.


Los ficheros de signatura "SCMS"

Aquí la suerte tuvo mucho que ver. Nada más ver la ristra de bytes que hay en cada uno de ellos supe que se trataba de un fichero .lua compilado, con los que también he trabajado antes, así que eso me ahorró también mucho trabajo. No voy a explicar cómo sacar cada dato, pues depende mucho del fichero .lua y se necesitarían muchos más posts, así que indicaré dónde está cada cosa, que es lo que importa.

Los primeros 0x20 bytes son una cabecera que no vamos a utilizar, pero ese '0x20' es necesario conocerlo para actualizar los punteros.

En la posición 0x40 se indica con un valor de 4 bytes el número de líneas de texto que tiene el fichero.

A partir de ahí, y me salto la explicación de lo que son la mayoría de bytes que siguen, que no son necesarios para nuestro propósito, buscamos el valor 0x07FFFFFF (grabado como 0xFF 0xFF 0xFF 0x07). Ese valor, seguido de otros dos valores de 4 bytes, identifican cada línea de texto. Una vez encontrado el primer valor ya podemos ir sacando los textos. El primero de los números de 4 bytes que hay es el número de orden del texto, pero no lo necesitamos para nada. El siguiente valor es el offset al texto, y hay que añadirle el 0x20 del que hablamos antes para obtener la dirección real del texto. En la imagen de ejemplo, el primer offset que encontramos es 0x000000E0, que se transforma en 0x00000100 al hacer la suma, y vemos que, efectivamente, es ahí donde comienza el texto.

Ahora vamos a ver un poco más las características de los textos. Lo primero que se puede ver es que no aparecen caracteres alfanuméricos, todos están codificados con 2 ó 3 bytes, con el mismo algoritmo de los ficheros 'MESG'. Otra cosa que se observa es que aquí los textos no tienen longitud fija, todos terminan con el típico 0x00, y lo único a tener en cuenta es que habrá que actualizar sus respectivos punteros cuando modifiquemos cada línea. En realidad lo que ocurre es que los ficheros 'MESG' usan una de las fuentes que habíamos sacado, y estos utilizan la otra, pero como son tan similares he decidido usar sólo una de las fuentes, así que ahora podremos emplear los caracteres alfanuméricos tal cual, sin usar los 2-3 bytes de la codificación, y así se gana muchísimo espacio extra. Ya sé que es una libertad que me he tomado, pero lo he hecho así para no tener que controlar el tamaño total de los textos, ganando espacio más que suficiente para poder hacer una traducción sin tener que buscar palabras alternativas o recortar frases. Lo he hecho porque no creo que se pueda meter más espacio en cada fichero, como vemos que pasa en muchos más juegos.

Ahora ya podemos sacar cualquier texto del juego.


Otras cosillas de los textos

Por lo que he podido ver, los ficheros 'MESG' se refieren únicamente a los diálogos del juego, mientras los 'SCMS' hacen referencia a los textos que aparecen en el GUI (explicaciones, etc.).

El juego únicamente muestra los caracteres que hay en las fuentes, pero nosotros podemos ver muchos más. Esos textos que no se podían leer y que son restos de la versión japonesa pueden sacarse también, ya que con el algoritmo de conversión podemos sacar los caracteres unicode a los que hacen referencia originalmente:

Como ejemplo, una de las líneas de esos ficheros, separando los códigos, es:
[{E381AA}{E381AB}{E3818C}{0A}{E4B896}{E7958C}{E3818C}{E381BE}{E381A0}{E3819F}{E38184}{E38289}{E381A0}{E381A3}{E3819F}{E38193}{E3828D} {E381A0}{E38288}?]

utilizando el algoritmo de conversión para generar un fichero de texto nos queda como:
[なにが{0A}世界がまだたいらだったころ だよ?]

(el {0A} es el salto de línea, que siempre lo indico en hexadecimal)

Con cualquier traductor que hay por la red se puede ver que la frase japonesa tiene sentido (a pesar de lo malos que son los traductores).

Aunque no sirve para nada, el programa permite también sacar los textos en su formato unicode original, sin tener en cuenta si están o no definidos los caracteres. Dichos textos no sirven para la traducción, pues no creo que nadie tenga un teclado que permita emplear directamente caracteres unicode. Las dos siguientes líneas muestran cómo se ve el texto "original" en unicode y cómo se debe tener en un fichero de texto para poder traducirlo:
- [&#65332;&#65352;&#65349;&#12288;&#65357;&#65349;&#65357;&#65359;&#65362;&#65369;&#12288;&#65347;&#65345;&#65362;&#65348;&#65363;&#12288;&#65288;&#65328;&#65331;&#65298;&#65289;&#12288;&#65353;&#65358;... <--- usando UNICODE
- [The memory cards (PS2) in... <--- usando ASCII


Hay otro tipo de ficheros, con signatura "FDB" en la posición 0x20, que traen los códigos de los caracteres que hay en las fuentes. Sólo están en el RCB0001 y los he usado para crear el fichero de configuración con la conversión de caracteres, sin tener que emplear ningún algoritmo. Su única utilidad "real" en este momento es por si alguien quiere trabajar con la versión japonesa del juego.


Creo que no me quedo nada en el tintero, así que la próxima semana toca el capítulo final, con el programa creado y una explicación de cada una de sus funciones.

CUE

Mensaje por CUE » Vie Jun 05, 2009 9:07 am

AQUÍ está el programa.

El programa es de línea de comandos (no confundir con MS-DOS) porque no se necesita ninguna ventanita para mostrar nada, así que no vi la necesidad de poner cosas innecesarias.

El fichero 'textos.txt' contiene una lista de todos los ficheros de textos del juego, indicando en qué RCB están para que sea más fácil trabajar. También se indican los que están repetidos.

El fichero 'SD4tool.txt' es la conversión de caracteres y debe estar en la misma carpeta que el ejecutable. Consta de 4 partes:
- caracteres que se reemplazarán por ASCII para poder editarlos. Son los códigos 0x20-0x7E, excepto la comilla simple y la doble, que en el juego no se usan (se usan comillas de apertura y de cierre, ninguna de las cuales es ASCII).
- caracteres de la fuente. Son las 21 filas de caracteres que hay en el gráfico (sólo se usan 13).
- caracteres ASCII que se reemplazarán al insertar los textos. Sólo son la comilla simple y la doble, por si se meten en los textos.
- longitud máxima de los textos (el 192 hablado anteriormente).

El fichero 'SD4tool.exe' es el programa. Admite los siguiente comandos:
- SD4tool -? -> muestra la sintaxis, con todas las opciones disponibles.
- SD4tool -ercb ARCHIVO -> extrae todos los archivos RCB del archivo especificado (normalmente DATA.BIN). Esos archivos se crean en la carpeta SD4-RCB\.
- SD4tool -efic FICHERO_RCB -> extrae todos los ficheros del archivo RCB indicado (admite múltiples archivos y comodines). Los ficheros extraídos se crean en la carpeta SD4-FIC\.
- SD4tool -ebmp FICHERO_RCB -> extrae todos los gráficos del archivo RCB (o archivos) y los coloca en la carpeta SD4-BMP\. Sólo saldrán bien los 6 gráficos de las fuentes y no voy a perder más tiempo mirando por qué no salen los demás.
- SD4tool -etxt FICHERO_RCB -> extrae todos los textos del archivo RCB (o archivos) en la carpeta SD4-TXT\. El formato de salida es un fichero de texto con formato unicode, por lo que se deberá usar un editor que admita esos caracteres (el mismo bloc de notas de windows admite varias fuentes unicode). Cada línea de texto va entre corchetes, y los códigos de control siempre van entre llaves.
- SD4tool -euni FICHERO_RCB -> es como la opción anterior, pero no se realiza la conversión de caracteres, sacando los caracteres unicode originales. Los ficheros se crean en la carpeta SD4-UNI\ y no sirven para la traducción.
- SD4tool -efnt FICHERO_RCB -> extrae los códigos de los caracteres usados y los coloca en la carpera SD4-FNT\.
- SD4tool -rbmp FICHERO_RCB -> reemplaza todos los ficheros bmp del archivo indicado. Esta opción no hace nada debido al desconocimiento del formato exacto de los gráficos.
- SD4tool -rtxt FICHERO_RCB -> reemplaza todos los ficheros de texto del archivo indicado.
- SD4tool -rrcb ARCHIVO FICHERO_RCB -> reemplaza el archivo RCB en el archivo bin indicado.

[img]http://img198.imageshack.us/img198/8506/28683397.png[/img]
Última edición por CUE el Sab Jun 06, 2009 11:32 am, editado 1 vez en total.

CUE

Mensaje por CUE » Sab Jun 06, 2009 9:10 am

Pues creo que no me queda nada más por decir, a no ser que algo no haya quedado muy claro y alguien quiera que lo explique un poco más. Déjalo unos días abierto y, si nadie pregunta nada, puedes cerrar el tema.


Próxima entrega: Breath of Fire 4 (no digo cuándo, que ahora estoy un pelín liado).


~~~ AÑADIDO ~~~
Como era de esperar, algo se me pasaba por alto. Ya he modificado la explicación de la opción -rbmp del programa, que realmente no hace nada ahora mismo por no saber cómo sacar los gráficos correctamente, algo totamente necesario para poder meterlos de nuevo.

Cerrado