Breath of Fire 4 de PSX (versión USA o EUR)

Tutoriales, herramientas, aportes, etc

Moderador: skybladecloud

Cerrado
CUE

Breath of Fire 4 de PSX (versión USA o EUR)

Mensaje por CUE » Vie Jun 12, 2009 12:28 pm

Pues es hora de empezar con otro rollo más. En este caso, el BoF4 de PSX, aunque es prácticamente igual para el BoF3 de PSX y el BoF4 de PC. Normalmente haré referencia sólo al BoF4, que es de lo que se trata.


Primero, unas cosas que debo aclarar:
- Cuando ponga el programa, será una versión limitada que tan sólo permitirá extraer cosas, no insertarlas. El motivo es que no me gustaría que saliese primero una traducción basada en el programa que no sea al castellano. El día que alguien quiera comenzar esa traducción y piense que el programa pueda serle útil, pues pasaré el programa completo al grupo de traducción, y lo haré público cuando esté ya terminada o casi.
- Aceptaré comentarios, sugerencias, críticas, ... excepto de la versión PC, que ha sido eliminada del programa a propósito y sólo es una característica privada para mí. La razón es la falta de ayuda que recibí cuando lo solicité. Como por aquí se trabaja con consolas no creo que eso importe mucho. Cualquier comentario sobre la versión PC será ignorado, aunque a veces seré yo mismo quien comente algo sobre ella.
- El programa final no está terminado. Ahora mismo estoy con un proceso de reinserción de ficheros en una imagen de PSX con recolocación de sectores y ajuste de LBA's para poder meter textos de cualquier longitud (o músicas o sonidos) y olvidarme de la limitación que suele haber en estos casos (realmente hay un límite físico de 64KB para cada tabla de textos, pero ése es un valor que no se llegará a poner nunca, pues es el propio juego quien no lo admite).
- Una de las características del programa final, si consigo terminarlo, que tiene tela el asunto, es que recalculará los códigos de corrección de error de los sectores modificados de la imagen, quedando así una imagen perfecta que se podrá grabar y utilizar aunque se usen programas o grabadoras que no lo recalculen (hoy día es difícil, pero me gusta cubrir todas las posibilidades).
- La parte referida al BoF3 la tengo un poco abandonada. Tengo que mirar ciertos parámetros para poder incluirla y que sea 100% funcional.


El propósito del programa, en líneas generales, es sacar los textos y los gráficos del juego para poder modificarlos, reinsertarlos y volverlos a poner en la imagen del CD. Realmente se puede hacer mucho más, como sacar paletas, sonidos y música, pero lo considero secundario y no he perdido mucho tiempo con ello y tampoco explicaré mucho sobre el tema, tan sólo lo básico. Como es habitual en mí, el programa está hecho para poder utilizar los datos de una forma sencilla (sólo se necesitan el bloc de notas y el paint), sin necesidad de programas externos.


Otra de las características del programa es que permite trabajar con cualquier versión del juego, aunque tengo que mirar la conversión de los caracteres de la versión japonesa. Eso permite trabajar con la versión americana o europea sin ningún problema, siendo válidos los textos y gráficos modificados para ambas. En el caso del BoF3 también permite trabajar con las versiones alemana y francesa.


En el caso de que algún grupo esté interesado en la traducción, debo decir que ya tengo extraído todo lo necesario, con una lista de los gráficos y textos que hay repetidos y otra lista con los ficheros que tienen alguna diferencia entre las versiones USA y EURO (son chorraditas, mas que nada algunas correcciones en los textos), por lo que el trabajo que resta es únicamente traducir.


Para facilitar las cosas:
- los números de varios bytes siempre se almacenan con el valor menos significativo primero
- los números precedidos por '0x' indican un valor hexadecimal, siendo decimal en el resto de los casos
- al hablar de 'sector' me referiré siempre a los 2KB (0x800) de datos que tiene cada sector del archivo, no al sector físico del CD, que tiene distinto tamaño y más datos.


ARCHIVOS EMI

Todos los datos del juego se encuentran en los archivos EMI del CD (en el caso de PC son los ficheros DAT), así que el programa trabajará únicamente con ellos.

Abrimos uno con el WinHex para conocer su estructura, que es idéntica para todos ellos:
[img]http://img194.imageshack.us/img194/1294/54189385.th.png[/img]

Cada archivo se compone de una cabecera y un 'directorio', donde está la información de cada fichero incluido en el archivo. Esta parte siempre ocupa un sector (0x800 bytes) y se rellena con el valor 0x2E (un simple punto). A partir de este sector se encuentran los datos de los ficheros, cada uno de los cuales siempre comienza en el inicio de un sector (un múltiplo de 0x800). En el caso de que la parte final de un fichero no complete el tamaño de un sector se rellena el espacio sobrante con el valor 0x5F (un subrayado). Es decir, si un fichero ocupa 3000 bytes, serán necesarios dos sectores, el primero de 2048 bytes completo, y el segundo de 952 bytes, rellenando los 1090 bytes restantes del sector con 0x5F. Hay que decir que todos los archivos EMI tienen una longitud múltiplo de 2048, es decir, que ocupan por completo todos los sectores.

Los primeros 16 bytes son la cabecera del archivo, que se corresponden a:
- 4 bytes con el número de ficheros que tiene el archivo
- 4 bytes con la versión del archivo
- 8 bytes con la signatura 'MATH_TBL'

A partir de ahí se encuentra la información de los ficheros incluidos, 16 bytes por cada fichero:
- 4 bytes con la longitud del fichero
- 4 bytes de datos que llamaré B1, B2, B3 y B4, y que definen algunos parámetros del fichero
- 4 bytes que se corresponden con los cuatro primero bytes reales del fichero (desconozco su utilidad, pues no se chequean nunca)
- 2 bytes con el tipo de fichero
- 2 bytes sin usar para ajustar el tamaño a 16 bytes (cada byte se corresponde con el carácter de relleno, 0x2E)

Hay que hacer notar que en ningún momento se indica dónde está posicionado el fichero, por lo que siempre habrá que calcularlo teniendo en cuenta las longitudes de los ficheros anteriores. Por ejemplo, para calcular la posición del tercer fichero de la imagen del ejemplo habría que sumar:
- 0x800 del primer sector (cabecera y directorio)
- 0x1000 del primer fichero (0xE20 es la longitud, pero hay que ajustarla al tamaño de los sectores ocupados, que son dos en este caso)
- 0x800 del segundo fichero (0x88 bytes ocupando un sector)
Así pues, el tercer fichero se encuentra en la posición 0x2000 del archivo.

Los tipos de fichero pueden ser los siguientes:
- textos, tipo 0
- paletas, tipo 0
- gráficos (sólo PSX), tipo 3
- gráficos comprimidos (sólo PC), tipo 1
- fuentes (sólo PC), tipo 5
- sonidos (sólo PSX), tipos 6-7-8
- sonidos WAV (sólo PC), tipo 3
- músicas (sólo PSX), tipo 10
- músicas MP3 (sólo PC), tipo 4

Hay ciertos ficheros binarios que no trato (algunos de tipo 0, 1 y 2). No son necesarios para una traducción, así que no me he molestado en descifrarlos.

Hay varios tipos de fichero con el mismo valor, el 0, y para diferenciar unos de otros se usan los bytes B2 y B3 del directorio, que nos indican si se trata de textos, paletas de colores o datos binarios. No voy a explicar cómo diferenciarlos pues esos valores dependen de la versión (PC o PSX) y del idioma del juego.


Eso es todo por hoy.
CUE

CUE

Mensaje por CUE » Dom Jun 14, 2009 11:56 am

Sonidos y Músicas

Poco voy a decir de estos ficheros.

En la versión PSX se trata de los típicos ficheros SEQ/VAB/VB/VH/etc, comunes en muchos juegos de la consola, y una información detallada de los mismos se puede conseguir buscando por internet. No me ha parecido interesante el tema, así que sólo me he limitado a extraerlos, por si algún loco quiere hacer algo con ellos.

En la versión PC cada fichero contiene múltiples archivos WAV/MP3, y, al igual que en las versiones de la consola, no hago nada más con ellos.


Fuentes de caracteres

El bitmap con las fuentes del juego, en la versión PSX, se encuentra en ficheros gráficos, de los que hablaré más adelante. En la versión PC se trata de unos ficheros específicos, el tipo 5. Como lo que nos interesa es el juego de la consola, no comentaré nada más sobre ellos.


Paletas de colores

Las paletas siempre están separadas de los gráficos. No tienen una longitud fija, pero lo normal es que sean de 256 colores (512 bytes), pero hay casos en los que en un mismo fichero se encuentran varias paletas.

Se trata de la típica paleta de colores rgb555, donde cada 2 bytes (16 bits) definen un único color. Desconozco si se usa el bit superior, el que se corresponde normalmente con la transparencia o canal alfa, pero tampoco me he molestado mucho con él pues todos los gráficos los saco con una paleta monocroma. Pensé en hacer que el programa buscase automáticamente la paleta, pero en muchos casos es imposible, ya que puede haber más ficheros de paletas que de gráficos y en esos casos no se sabe a priori cual es el que corresponde.

Un ejemplo de imágenes, tal y como las saca el programa en monocromo, y después de añadir la paleta (son a tamaño real), extraídas de los ficheros ART*:

[img]http://img132.imageshack.us/img132/5158/a05.png[/img] [img]http://img189.imageshack.us/img189/8528/a05h.png[/img]

[img]http://img132.imageshack.us/img132/9459/a06.png[/img] [img]http://img189.imageshack.us/img189/9459/a06.png[/img]

[img]http://img132.imageshack.us/img132/651/a07.png[/img] [img]http://img191.imageshack.us/img191/651/a07.png[/img]

[img]http://img132.imageshack.us/img132/8950/a08.png[/img] [img]http://img191.imageshack.us/img191/8950/a08.png[/img]

Obviamente, quien hace la ley hace la trampa, así que he puesto unas imágenes que quedan bien, pues en otras ocasiones el resultado no es tan bonito ;)


En breves días pasaré a explicar el tema de los gráficos.
CUE

CUE

Mensaje por CUE » Mar Jun 16, 2009 11:42 am

Gráficos

Los gráficos del juego son realmente tilesets compuestos por tiles de 64x16 bytes, y pueden ser de 16 ó 256 colores. Para poder generar una imagen siempre se ha de tener en cuenta que los tiles pares siempre van a continuación (debajo) de los impares, formando lo que he denominado bloque, de 64x32 bytes. El motivo de hacerlo así es simplemente por comodidad, pues 64x32 = 2048, el tamaño de un sector, siendo más fácil trabajar de esta manera, pues cada sector se pone tal cual. El número de bloques horizontales que tiene cada tileset viene definido por el byte B2 indicado en la estructura del directorio. Así, si un tileset se compone de 10 tiles, a cada uno de los cuales llamaremos por una letra del abecedario, y en B2 tenemos definido el valor 3, la imagen se obtendría colocando los tiles de la siguiente manera:
ACE
BDF
GI
HJ


Como sabemos el tamaño de la imagen y el ancho en bytes, podemos hallar la altura de la imagen, y eso ya permite generar una imagen BMP con el tileset.

La imagen no queda 'cuadrada', pues resulta de 3x2 bloques sin usar el último, así que el programa rellena el espacio que falta con el color 0 para poder generar una imagen válida.

Ojo, que 64x16 se refiere al número de bytes del tile, no a los pixeles. No hay que olvidar que una imagen de 16 colores guarda en un byte la información de dos pixeles ya que bastan 4 bits para definir el color usado, frente a los 8 bits que se necesitan en las imágenes de 256 colores.

Una cosa que no he chequeado, en parte por vagancia y en parte por coñazo, es hacer que el programa diferencie por sí mismo las imágenes, sacando automáticamente las que son de 16 colores y las que son de 256 colores. Hay que indicar cómo se quieren sacar las imágenes. Tendría que mirar más a fondo los bytes B1-B2-B3-B4, pues casi seguro que ahí se define el número de colores usados.

Como tomar las paletas de cada imagen no es posible a priori, todas se sacan con una paleta monocroma. Por lo que he visto, para la imágenes de 16 colores basta una paleta monocroma general para poder ver perfectamente todas las imágenes, pero en las de 256 colores hay dos patrones distintos, motivo por el que hay que utilizar dos paletas, siendo necesario indicar al programa cual se va a usar.

Un ejemplo de una imagen de 256 colores usando ambas paletas, donde se ve claramente la necesidad de especificar la que se desee utilizar:
[img]http://img195.imageshack.us/img195/5128/01a.png[/img] [img]http://img189.imageshack.us/img189/7959/01b.png[/img]

Imagino que chequeando los bytes B1-B2-B3-B4 se podrá también averiguar qué paleta usar, pero no me he puesto con ello.

Hay unos pocos casos en los que el tileset ocupa un único byte, que me lleva a pensar que son imágenes borradas. En esos casos el programa los ignora sin más.

Los gráficos de la versión PC del juego se tratan igual, pero en esa versión vienen comprimidos, y es una de las cosas que me guardo.


Fuentes PSX

Antes de pasar al tema de los textos, hay que hablar de las fuentes usadas en las versiones PSX, pues así se sabrá cómo proceder para añadir caracteres, ya sean los 16 del idioma español, o cómo modificar los existentes en el caso de querer traducir el juego a otro lenguaje. Sólo hablaré del BoF4 en su versión inglesa (americana o europea), pero el BoF3 es muy similar, aunque permite añadir menos caracteres. La versión japonesa tiene muchos más caracteres y no he querido meterme con ella a fondo y no sé si lo haré en un futuro.

El gráfico original que contiene la fuente de caracteres es el siguiente:
[img]http://img14.imageshack.us/img14/8118/27867827.png[/img]

Se observa que hay 3 juegos distintos de caracteres. Todos ellos comienzan con el carácter 32, ya que los códigos 0-31 son especiales y definen diferentes acciones cuando se ponen en los textos. Los caracteres que están definidos son los que van del 32 al 127 (0x20-0x7F), y pueden definirse 32 más, del 0x80 al 0x9F, que irían en los espacios marcados de la siguiente imagen:
[img]http://img14.imageshack.us/img14/413/92986489.png[/img]

El primer juego de caracteres se usa en el GUI. Son esas letras pequeñas que aparecen.

El segundo juego de caracteres es el usado en los textos del GUI y los diálogos.

El tercero no he llegado a verlo todavía, y ya lo modificaré cuando tenga más tiempo libre.

Los sets no son exactamente iguales, pues hay varios caracteres diferentes entre ellos, e incluso no todos los caracteres están defeinidos. Eso no importa a la hora de extraer los textos, pues basta con tener los caracteres alfanuméricos y los signos de puntuación para poder tratar los textos de la misma forma, independientemente del set que usen. Si en algún texto aparece un carácter que parece "extraño" se deberá a esa situación.

Un ejemplo de fuentes modificadas, con los 16 caracteres especiales del castellano (áéíóúüñ¡ÁÉÍÓÚÜÑ¿) en los códigos 0x80-0x8F, es el siguiente (el tercer set no está terminado, me he limitado a copiar los caracteres originales):
[img]http://img14.imageshack.us/img14/4449/39110103.png[/img]

La disposición de los caracteres deberá indicarse en el fichero de conversión de textos, que lo explicaré en la sección de textos.

Una cosa que me gustaría averiguar es saber dónde se define el ancho de los caracteres. En la imagen se ve que todos tienen 8 pixeles de ancho, pero basta con ejecutar el juego para ver que cada carácter tiene un ancho específico. Con ver la 'i' y la 'm' de cualquier texto nos podemos dar cuenta. Los caracteres añadidos siempre serán de 8 pixeles de ancho, y, aunque no es ningún problema que aparezcan así, me gustaría saber dónde definir esa anchura, sobre todo por si se traduce el juego a otro idioma y se necesitan modificar los caracteres originales.


Nada más por hoy
CUE

CUE

Mensaje por CUE » Mar Jun 23, 2009 9:45 am

Textos

Los textos del juego son simples tablas. En un mismo archivo podemos encontrarnos con varios ficheros de textos, los cuales pueden componerse de una o de más tablas.

La siguiente imagen muestra un fichero compuesto de una tabla:
[img]http://img196.imageshack.us/img196/8107/39002295.th.png[/img]

Cada tabla se compone de dos partes: la zona de direccionamiento (la parte enmarcada de la imagen, con dos bytes por cada dirección) y la zona de textos. El direccionamiento nos indica dónde empieza cada texto, pero hay que interpretar bien los datos pues en ocasiones no apuntan a ningún texto o no está bien actualizada la dirección.

Para comprender un poco cómo se almacenan los textos imaginemos que tenemos una tabla tipo C de 6 elementos (no es exactamente así, pero sirve para ilustrar cómo se guardan los datos):

tabla[6] = { "", "", "", "", "", "" }

Supongamos que las direcciones se almacenan en la posición 0x0000 y los textos en 0x1000, para hacerlo más sencillo.

En las posiciones tenemos:
0x0000: 0x1000, 0x1000, 0x1000, 0x1000, 0x1000, 0x1000
0x1000: nada

Vemos que todas las direcciones apuntan al inicio del almacenamiento de los textos, aunque no tenemos ninguno todavía.

Ahora metemos 3 textos:

tabla[6] = { "", "hola\0", "", "", "conecta", "dos\0" }

y en las posiciones nos quedaría:
0x0000: 0x1000, 0x1000, 0x1005, 0x1005, 0x1005, 0x100C
0x1000: 'h', 'o', 'l', 'a', 0, 'c', 'o', 'n', 'e', 'c', 't', 'a', 'd', 'o', 's', 0

Si nos fijamos en las direcc¡ones, vemos que hay 6 que apuntan a 3 textos distintos (0x1000, 0x1005, 0x100C), y deben considerarse tan sólo 3 textos, no 6. En este caso es sencillo hacerlo, pero hay ocasiones en las que no se ve tan claro, pues en teoría las direcciones deben estar almacenadas de menor a mayor, y no siempre ocurre así debido a que algunos elementos de la tabla no están actualizados porque no se usan.

Si nos fijamos en los textos podemos cometer el error de pensar que el código 0 es el separador de cada uno de ellos, y sólo veríamos dos: 'hola' y 'conectados', pero ya hemos visto al crear la tabla que realmente se trata de tres textos. Éste es uno de los "problemillas" causantes de que algunos que empezaron la traducción lo dejaran, pues interpretaban mal los datos.

La forma correcta de sacar cada texto es mirar la tabla de direcciones, cogiendo una y restándosela a la siguiente, con lo cual obtenemos su longitud. Si el valor es 0 se trata de un elemento no usado. Si el valor es negativo tendremos que usar la siguiente dirección.

No todos los textos se componen de caracteres. El juego usa códigos de control, de uno o varios bytes, para realizar ciertas acciones y hay que ternelos en cuenta para interpretar bien los textos.

Básicamente eso es todo sobre los textos. Hay ciertos casos "especiales" pero no merece la pena hablar de ellos (ahora mismo recuerdo una tabla en BoF3 que la primera dirección apuntaba a una posición fuera de la tabla, pero es un glitch debido a la no actualización de los valores y no interfiere en el desarrollo del juego).

Como las direcciones son de dos bytes ya podemos saber una cosa más, y es que cada tabla de textos no puede superar los 64KB (son bastante más pequeñas, así que no hay problema).

La siguiente imagen muestra un fichero con varias tablas:
[img]http://img196.imageshack.us/img196/1603/15413965.th.png[/img]

En este caso vemos que el inicio del fichero contiene varios punteros de 4 bytes que apuntan a cada una de las tablas, que están seguidas, sin ninguna separación entre ellas.

La forma de ver si se trata de varias tablas es muy simple: los bytes 3 y 4 del primer puntero siempre son cero, y los bytes 1 y 2 nos indican donde empieza la primera tabla. Dividimos este valor entre 4 y obtenemos el número de tablas que hay. En el ejemplo, ese valor es 24 (0x18), que al dividir entre 4 nos da 6, el número de tablas presentes, que se tratan de la manera antes explicada.

No todos los textos están en estos ficheros, hay 2 excepciones:
- los nombres de los personajes
- los nombres de los enemigos

En ambos casos se encuentran en ficheros binarios. Los personajes no tienen interés, pues no creo que a nadie se le ocurra traducir los nombres, pero los enemigos sí son importantes. El programa interpreta esos ficheros como un caso especial de textos y extrae los nombres de los enemigos, aunque hay que tener en cuenta que sólo se consideran los 8 primeros caracteres, que es lo que admite el programa.


El próximo día pondré el programa
CUE

CUE

Mensaje por CUE » Jue Jun 25, 2009 10:03 am

AQUÍ está el programa.

BoFtool_test.txt es la conversión de caracteres para BoF4 de PSX (para BoF3 y BoF4 de PC hay que utilizar otros ficheros). Ya está preparado para soportar los caracteres propios del castellano.

Los códigos 0x00-0x1F son internos del juego y no deben tocarse.
Los códigos 0x20-0x7F son los caracteres definidos en la versión inglesa y americana del juego.
Los códigos 0x80-0x8F son los caracteres añadidos.
Los códigos 0x90-0x9F no se usan.

Este fichero, así como ltodos los textos que se extraen, siempre está en formato unicode. El por qué de hacerlo así es para que sirva para cualquier lenguaje, permitiendo mostrar los caracteres usados.

BoFtool_test.exe es el programa. Las opciones activas en esta versión son:

BoFtool -?
Muestra la sintaxis.

BoFtool -e ARCHIVO
Extrae todos los ficheros del archivo EMI indicado.

Cada fichero creado se llama igual que el archivo EMI, añadiendo dos dígitos con el número de fichero dentro del archivo y una letra que indica el tipo de fichero. Así, el archivo INIT.EMI, por ejemplo, generará los ficheros:
- INIT.EMI.00.b (bmp)
- INIT.EMI.01.p (paleta)
- INIT.EMI.02.b (bmp)
- INIT.EMI.03.p (paleta)
- INIT.EMI.04.p (paleta)
- INIT.EMI.05.t (texto)
- INIT.EMI.06.t (texto)

BoFtool -ebmp4 ARCHIVO
BoFtool -ebmp8a ARCHIVO
BoFtool -ebmp8b ARCHIVO
Extrae los gráficos del archivo en formaro BMP con paleta monocroma. El nombre de los ficheros generados es el mismo que con la opción '-e', pero con la extensión completa. En el caso anterior nos sacaría:
- INIT.EMI.00.bmp
- INIT.EMI.02.bmp

La diferencia entre las tres opciones es que en el primer caso se saca una imagen de 16 colores, siendo de 256 colores en los otros dos. El motivo de que haya dos opciones para las imágenes de 256 es que pueden usar una paleta genérica distinta.

BoFtool -etxt ARCHIVO
Extrae los textos del archivo EMI en ficheros TXT unicode. Cada texto va entre corchetes, y es lo único que hay que tocar. Aparecen códigos hexadecimales entre llaves que indican los códigos de control. Todo lo demás son datos que necesita el programa para poder reinsertar de nuevo los textos.

Un ejemplo:
:0100
;01
<0002>["You must be the{01}repairmen, right?{02}Hold on--I'll power{01}up the gondola."{1400}{0C92}Please{01}Never mind{00}]
<0001>[There's water flowing--do{01}you want to jump in?{1401}{0C82}Yes{01}No{00}]
<0001>["Once we get this{01}plugged up,{02}the aqueduct'll{01}finally be finished!"{00}]
<0001>[There's a rope holding the{01}drawbridge.{00}]
<0001>["All right, just a{01}second..."{00}]
<0001>["Huh? OK...{02}Well, when you want{01}to use the gondola,{01}tell me, all right?"{00}]
<0001>["This aqueduct's{01}attached to an army{01}installation--{02}that's why they're in{01}such a hurry to get{01}it repaired.{02}Make sure you do a{01}good job, OK?"{00}]
<20F8>0000

Una breve indicación de lo que es cada código de control está en el fichero de conversión. No he buscado todos, pero están los más usados.


Unas cosas más a saber:
- el programa ejecutable y la tabla de conversión deben estar en la misma carpeta
- se pueden indicar varios archivos EMI y usar comodines en el nombre
- los ficheros generados se crean en la carpeta donde está el archivo EMI

Cerrado