notas.tales-tra.com

La tipografía principal utilizada en Tales of Vesperia es Amerigo BT, diseñda por el holandés Gerard Unger en 1987 para la fundición Bitstream. Es una tipografía incisa, con un contraste bastante fuerte entre sus formas ahusadas y con unas serifas atrompetadas ”es decir, los remates de los extremos de las letras se abren mucho y desde muy adentro” que le dan un aspecto peculiar. Es una letra que no funciona mal en el juego, pero también es cierto que en ningún momento se utiliza a un tamaño demasiado reducido, y eso ayuda.

Dicho esto, voy a quejarme: no me gusta un pelo la afición que tienen en Namco de torturar las tipografías hasta el límite de lo demencial. Los textos de script que aparecen en el juego, dentro de los bocadillos amarillentos, están terriblemente deformados. Terriblemente. El kerning es mucho mayor de lo necesario, el interlineado tres cuartos de lo mismo y para mayor escarnio las letras están ¡achatadas!

Así es como está en el juego.

Así es como sería sin deformar.

Y esto definitivamente sería un espanto. En definitiva, la forma en la que se muestran los textos en el juego coge el trabajo que en su día hizo el tipógrafo y lo pisotea, escupe encima y luego lo vuelve a pisotear. ¿Y sabéis qué es lo que más me jode? Que a pesar de todo, y quizá por la costumbre, los textos del juego deformados me gustan bastante más que los mismos sin deformar. ¡Vaya tema!

P.S.: La tipografía principal del Tales of the Abyss era Baker Signet, también vendida por Bitstream y también una tipografía incisa.

Sí señor. A falta de ajustar las posiciones de los caracteres algunos píxeles, ya disponemos de “ñÑ¡¿” :D

¡Fuente modificada satisfactoriamente!

Joder. Estoy subnormal. Ya me extrañaba que se hubiesen complicado tanto la vida. (Y no veía código para tal complicación).

Los caracteres están tal cual ahí sin transformaciones raras xD. Podemos usar inclusive esos para añadir los que nos faltan (ya que no podemos tocar los anchos).

También se puede ver kanas que salen en la tabla que ahí salen huecos vacíos. Aunque es posible que los kanas tengan un ancho fijo y no nos sirva.

Por fin he conseguido decodificar la parte del alpha del DXT5 en el formato de 360. El truco está en que se obtiene en bloques de 16 bits big endian. Y de ahí se hace todo normal.

Sí que tiene pinta de que habrá caracteres disponibles y “usables” con un ancho similar a los caracteres que necesitamos.

ÃÇIJŒãçijõœ<[^@~{|}、。？々〆‖…』『♂♀￥†あほΦπωム que ver con el efecto.

[caption id="attachment_90" align="alignnone" width="690" caption="Prueba de fuente"][/caption]

BTW: Tiene guasa que esté la “ç” y la “Ç” y no esté la p*** “ñ”. Sería más fácil traducirlo al catalán que al español xD. Pero bueno.

Y también la “Ô y la “ã”. ¿Qué les costaba colocar una “n” debajo? y flippear en la X y en la Y los “!?”
Los “« »” parece que ya están, así que de esos nos olvidamos.

Caracteres supuestamente usables (y que teóricamente podré usar para el tuneo):
/img/2010/09/table.html

Tiene toda la pinta de que la estructura de los caracteres están embebidos en el exe. Creo que simplemente para ciertos caracteres solapa otro carácter (para formar las diferentes combinaciones).

Ahora lo que tengo que hacer es buscar caracteres que tengan un ancho similar a los de “¿¡ñÑ” y editar esos. Mañana probaré a ver qué caracteres se muestran y más o menos el ancho en pantalla.

Bueno, he estado jugando un poco. He visto ya un poco. Quedan muchas cosas por pulir: imágenes para traducir, textos por pulir, textos que siguen en inglés (montones y montones) y temas de hacking por mirar. Incluyendo por supuesto los caracteres “ñÑ¿¡” y los quotes “« »”.

Por ahora la “ñ” ahí no la vamos a poder usar. Ya veremos si el mapeado está en el exe, que como ya sabéis con JTAG sí que puedo tunear el exe lo que haga falta, pero para que rule en no JTAGs tocará hacerlo todo sin tocar el exe.

He estado varios días a full con Vesperia y Destiny. Han avanzado sustancialmente los dos proyectos. Sin embargo he estado desatendiendo cosas que tienen prioridad para poder darle un empujoncito a esto. Lo que tenía claro es que dedicarle dos horas sueltas de vez en cuando no puedo, tengo que meterme una sesión de varios días, y eso he hecho.

Los proyectos pueden seguir su curso mientras yo sigo con mis cosas.

Estaré varios días u otra semana con otros asuntos y luego me pondré de nuevo con esto. A pulir detalles y a ir haciendo cosas. Poco a poco, lento, pero con buena letra

Tras haber arreglado lo de los colores y demás, más capturas:

<03> es para color. Y además como guasa adicional, si para las cadenas se usa el string_dic_UK... para el script se usa el scenario_US. Menudos huevos.

He metido TODOS los textos de MISC:

El texto está en UTF-8.

“áéíóúÁÉÍÓÚäëïöüÄËÏÖÜñÑ¡¿âêîôûÂÊÎÔÛ”

He mirado a ver los caracteres que hay y únicamente faltarán “¿¡ñÑ”. Las letras “ü” y “Ü” están. Supongo que a malas podríamos usar algún carácter que está por ahí: “⍺ß”.

Estoy buscando el Vesperia americano para “comparar” y ver si me hago una idea donde está el mapeado de caracteres. Imagino que será un archivo con “shapes” que serán recortes de textura.

Las texturas que he puesto antes tienen los bloques desordenados. No le he dado mucha importancia porque lo importante (que son las letras) se veían ya bien. Pero no le busquéis mucho sentido al orden porque están mal colocados xd

Lo que estoy viendo no me mola un pelo...

Esperemos que no hayan tenido los santísimos cojones de hardcodear el encoding de los caracteres en el EXE y que esté en algún otro sitio. Si no, no podremos poner la ñ y demás sin usar JTAG.

Por lo que parece y ya que no veo caracteres con acentos es que habrán hecho de colocar el acento encima. Igual hay algún archivo con "recortes" de esas texturas. Tengo que mirarlo bien.

FONTTEXT.7z [3.93 MiB]

Ahí ya hay una cejilla, aunque es muy ancha (para la ñ). Imagino que de haber un sitio con las construcciones de los caracteres dejará escalar también así que igual la podemos usar sin tocar la fuente en sí.

La fuente que nos interesa: FONTTEX10.TXV.tga

El swizzling es el correcto y por eso se leen las letras. Lo que está mal son los subbloques de 4x4 que cuando decodifique los bloques DXT5, hará que se vea bien.

Detalles sobre el tema:
El archivo tiene 13 archivos con 13 fuentes diferentes. (Aunque es fácil que no se usen todas).
Cada fuente es una imagen de 2048x2048 comprimida en DXT5. Así que son 512x512 bloques de DXT5 con subloques de 4x4.
Cada carácter ocupa 32x32 pixeles. Con lo que hay 64 caracteres por columna y otros 64 por fila. Eso hace un total de 4096 caracteres por archivo/fuente.

Bueno, para ser un primer intento no está mal xD.

Un regalito para los que leéis esto:

http://tov.tales-tra.com/items/items.html

Todos los items extraídos con canal alpha. Hay algunos la mar de lolers xd.

Al final lo que pasaba es que vez de un sub-subbloque de 1x1 que inicialmente pensé y que luego pasé a 1x2 y luego a 2x2, resultaba ser un 3x2 xdd. Posiblemente relativo al tamaño de la textura.

Para ver lo que pasaba he hecho esto:

#include <...>

#define UINT unsigned int

void main() {
   int n;
   for (n = 0; n < 128; n++) {
      printf("%d, %d\n", XGAddress2DTiledX(n, 128, 4), XGAddress2DTiledY(n, 128, 4));
   }
}

Tralarí, tralará:

Al final resultó que únicamente podía sacar screenshots del dash. Así que no me sirvió el tema. Por otro lado estuve recordando todas las cosas que se hicieron de la compresión nueva y de la reinserción de scripts y demás.

Hoy posiblemente no pueda porque he quedado con la novia, y ya veremos el fin de semana que se presenta liadillo con familia y demás. Pero en cuanto pueda reinsertaré los textos con todo lo nuevo a ver qué tal. (Pasando por ahora de la fuente).

Ya puedo hacer screenshots:

Ahora falta arrancar el juego desde este dashboard xd. Tengo que ver cómo hacer para que salga en la lista.

Sigue fallando algo, y no tengo claro el qué xd.

Ya sé más o menos por donde cogerlo. Consistirá en hacer tiling de bloques de 32x32. Y aplicar un vector/matrix de swizzling de 32x16 que parece que es el patrón que se repite en los dos subbloques de 512 texels que saldrán por cada bloque de 32x32.

Voy a hacer prueba a ver qué tal. (Tengo que sacar primero el vector/matrix, claro).

Bueno, con las imágenes que he sacado (especialmente las 2 últimas y un poco la anterior) ya debería poder saber cómo va el tema. Tengo que pensarlo con tranquilidad.

Lo que se ve en el penúltimo screenshot es que cada 128 pixeles (1 fila) en esa imagen se agrupa en un bloque de 32x8 pixeles. Que a su vez se agrupa en bloques de 1x4 y de 4x4.

Esos bloques ya tienen su propia distribución, que se ve en la última imagen que tengo que analizar.

Si pudiese sacar un screenshot pixel perfect, podría hacer un programa que detectase el patrón automáticamente (con la imagen con degradados rojo y azul). Pero ahora mismo no sé cómo con una consola con jtag. Así que guessing con lo que se ve.

Si alguien me quiere echar una manita, bienvenida será. Si no, a ver si se me ocurre y veo el patrón. Que yo soy muy torpe para estas cosas.

El apple gel original:

Para probar que estaba modificando el archivo que tocaba y que todo era como esperaba, he creado una imagen raw de 128x128xA8R8G8B8 de color negro (255,0,0,0) y la he plantado donde iba el appl gel. Ha ido chachi wachi:

for ($n = 0; $n < 128 * 128; $n++) {
   list($a, $r, $g, $b) = array(0xFF, 0x00, 0x00, 0x00);
   fwrite($f, pack('C4', $a, $r, $g, $b));
}

Primeras pruebas de contenido 96 pixeles pintados de degradados de rojo, verde y azul:

for ($n = 0; $n < 128 * 128; $n++) {
   list($a, $r, $g, $b) = array(0xFF, 0x00, 0x00, 0x00);
   if ($n >=  0 && $n < 32) $r = ($n - 0) * 8;
   if ($n >= 32 && $n < 64) $g = ($n - 32) * 8;
   if ($n >= 64 && $n < 96) $b = ($n - 64) * 8;
   fwrite($f, pack('C4', $a, $r, $g, $b));
}

Prueba de mapeado completo (cada pixel tiene un color diferente la X hace que la intensidad del rojo aumente y la Y que la intensidad del azul aumente):

for ($y = 0; $y < 128; $y++) {
   for ($x = 0; $x < 128; $x++) {
      list($a, $r, $g, $b) = array(0xFF, 0x00, 0x00, 0x00);
      $r = $x * 2;
      $b = $y * 2;
      fwrite($f, pack('C4', $a, $r, $g, $b));
   }
}

Prueba con un degradado de arriba a abajo:

for ($n = 0, $y = 0; $y < 128; $y++) {
   for ($x = 0; $x < 128; $x++, $n++) {
      list($a, $r, $g, $b) = array(0xFF, 0x00, 0x00, 0x00);
      $b = $g = $r = ($y / 127) * 255;
      fwrite($f, pack('C4', $a, $r, $g, $b));
      imagesetpixel($i, $x, $y, imagecolorallocate($i, $r, $g, $b));
   }
}

Y luego prueba con un degradado de izquierda a derecha:

Para sacar el swizzling este con el orden de los pixeles en la textura hay varias formas posibles:

1º Guessing. Intentar deducir el swizzling. Lo he intentado sin suerte, así que esto descartado.

2º Localizar el código que se encarga de hacer el deswizzling. (Posiblemente se haga en la gráficamente directamente, aunque habrá versión de software posiblemente en el API del XDK)

3º Localizar el código o hacer un programa que llame a la API esta y lanzarlo desde la 360 o desde el ordenador para generar una imagen con el swizzling este. (Si me funcionase el XDK sería una opción, pero no he logrado compilar nada por el momento. También hay otras opciones que pueden ser mas fáciles.)

4º Ahora que tengo acceso a modificaciones, puedo coger una textura que sepa exactamente dónde se usa y modificarla a mi antojo para ver cómo la muestra el juego por pantalla y sacar un mapeado. La textura que he puesto en el post anterior usa un formato de color ARGB muy sencillo y el único problema es el orden de los píxeles, así que puede ser una imagen ideal para probar. Lo que haré es llenarla de píxeles transparentes y luego poner los primeros píxeles de la imagen haciendo un degradado o con colores diferentes y ver dónde se posicionan en la imagen final que se ve en pantalla. Luego será sacar el proceso inverso en cuanto vea el patrón que sigue.

Por ahora voy a probar con el método 4, que es el más directo y aparentemente el más sencillo, suponiendo que el patrón de swizzling sea fácil.

Edito:
Debido a que está nada más empezar el juego, voy a usar el gel de manzana:

A falta de escribir sobre los formatos de archivos de empaquetado y el script, voy a comentar lo que voy a hacer hoy:

Una de las cosas más peliagudas de la traducción va a ser la edición gráfica. Actualmente lo más importante es la edición de la fuente, y es lo que voy a intentar solucionar ASAP.

El paquete UI.svo (presumiblemente User Interface) contiene lo que son supuestamente las texturas que componen la fuente y otras imágenes como menús e imágenes de objetos.

La fuente presumiblemente está compuesta por los siguientes archivos: FONTTEX00.TX(M|V)-FONTTEX16.TX(M|V) 4MB cada uno (512x512x16). Los archivos con texturas están compuestos por dos archivos: TXM y TXV. TX posiblemente venga de TeXture. V igual de Vector o de Values. Y la M ni idea (quizá Modifiers).

En cualquier caso el TXM contiene información sobre la textura y el TXV los datos de la textura en raw.

Sobre el offset 0x60 o 0x64 (dependiendo) hay un entero de 32 bits big endian que contiene información sobre la textura almacenada. Si no me equivoco corresponde al enum D3DDECLTYPE que básicamente empaqueta información sobre el formato, el endian, si está tileado, el swizzling de colores (creo) etc.

Aquí un par de resultados que extraje con una utilidad que hice:

File: 18280186 : cook_beefbowl
Format: 6
Endian: 2
Tiled: 1
numForm: 0
signXYZW: 0, 0, 0, 0
swizzXYZW: 2, 1, 0, 3 (b, g, r, a)

File: 1A200154 : fonttex01
Format: 20
Endian: 1
Tiled: 1
numForm: 0
signXYZW: 0, 0, 0, 0
swizzXYZW: 0, 1, 2, 3

GPUTEXTUREFORMAT_8_8_8_8                        = 6,
GPUTEXTUREFORMAT_DXT4_5                         = 20,

Aquí tenemos una imagen que está guardada en BGRA y sin comprimir (cook_beefbowl). Y otra, la de la fuente, que usa DXT4_5.

Además de la compresión de la textura, los pixeles están almacenados desordenados (supuestamente), lo que se llama swizzling para maximizar la caché de la GPU de la 360 a la hora de renderizar polígonos y acceder a mipmaps. También creo que igual almacena en la misma imagen un mipmap. En principio y supuestamente el cook_beefbowl no debería tener mipmaps, pero no estoy 100% seguro.

Al extraer usando tiles de 32x32, he sacado esta imagen:

Los colores están bien, así que el formato 8_8_8_8 es correcto, pero obviamente los pixeles están desordenados.

Luego explicaré cómo voy a intentar "adivinar" el ordenado de los pixeles ahora que tengo la JTAG.

Herramientas:

• XexLoader (360) - Cargar los .xex
• XexTool 5.2/ X360GameHack (PC) - Quitar las restricciones/desfirmar
• wx360 (PC) - Extraer los archivos de una ISO de 360.

Ahora que ya tengo la 360 con JTAG y ya se ha reestablecido el rumbo destiny, el cual ya está casi terminado a falta de pequeños detallitos, voy a ponerme a hacer pruebas con el Vesperia cuando encuentre tiempo para ello.

Quería aprovechar para hacer un pequeño log con las cosas que vaya haciendo del hackeo, para que quede para la posteridad, para que me sirva a mí dentro de un tiempo o a otras personas para ver cómo se han enfocado ciertas cosas.