Keytotruth escribió:SkyBladeCloud escribió:Probablemente a que truthkey es traductor, no romhacker/programador, como él mismo decía:
the text uses a custom encoding which you can decipher using a table I created and uploaded to mediafire. Even after that you'd need to know how to edit the text files properly which requires rom-hacking and programming knowledge.
Incluso es la forma incorrecta de verlo: el programa de texto se compone de un conjunto de punteros a diversas secciones de la fuente; así, el byte 0x00 apuntará al 1º caracter de la fuente (en este caso, un espacio); el byte 0x01, apuntará al 2º caracter de la fuente, y así sucesivamente. Claro, si en lugar de mapear la fuente, creas una tabla de convierta los bytes en caracteres ASCII, el texto debería ser también visible/editable; pero esto es una chapuza que limitaría enormemente la traducción; de entrada, así no es posible ni extraer ni reinsertar los textos (tendrían que editarse con un editor hexadecimal + tabla) ni mucho menos aumentar el espacio reservado para cada intervención.
De todos modos el juego no es tan fácil como pueda parecer: los textos de los menús son de 8 bits: si se hacen los cálculos 2^8= 256 posibles caracteres en la fuente. Es decir, una fuente pequeña y "fácil" de mapear ó generar tabla. Pero en el caso de textos de 16 bits: 2^16 = 65536 -> Para mapear esto se hace necesario ver la fuente, y es prácticamente imposible generar una tabla usando búsquedas relativas de 16 bits (supongo que por eso truthkey decía que era imposible hacer la traducción completa, al menos llevaría demasiado tiempo). En mi caso, con la fuente delante y alguien que me la convertira a txt (para ésto ya necesitaría la ayuda de algún traductor), los textos de 16 bits deberían salir fácilmente, tal como los de 8 bits.
Un saludo:
~Sky
Sé que ya hace tiempo desde esta intervención de Sky, pero quería comentarla. No puedes asumir mis conocimientos por dos ratos que hemos hablado. Yo programo y romhackeo, simplemente no tengo demasiado conocimientos en ciertos aspectos. Type-0 usa una tabla UTF-16 con una pequeña ligera variación en sus carácteres según su fuente que sería muy sencilla de adaptar. Hice la tabla para poder hacer una pequeña traducción rápida. No sé quién ha dicho nada de encriptación, en Type-0 apenas hay nada encriptado ni comprimido. Solo dije que la traducción era imposible por mi parte porque los ficheros de textos tienen punteros de 24 bits, lo que limita altamente el tamaño que puede alcanzar el archivo final y en algunos casos necesitas mucho espacio para ponerlo todo en su sitio, ya sabes que para una expansión de ese tipo habría que tocar más a fondo para hacer que el juego leyese punteros de 32 bits.
O a lo mejor meto la mata y estamos hablando de Last Ranker. Ahí ya no me meto.
Pues a lo mejor estás hablando del last ranker, que si venía encriptado y comprimido en algunas partes. Más que nada porque nadie ha mencionado nada sobre encriptaciones ni compresiones sobre este juego, más que para desmentir que las tuviera unas páginas más atrás; me cito a mi mismo:
Ningún juego es imposible de traducir por muy encriptado que esté; es más, en Type-0 no hay ninguna encriptación de textos, propiamente hablando, solamente vienen con una codificación específica, optimizada para el juego. No íbamos a esperar que vinieran en txt, claro xD.
Sobre la "tabla UTF-16", si hablas de los textos de tu parche, vienen a 8 bits, de ahí lo 1º que comentaba. Los textos de la historia son los que vienen codificados a 2 bytes, también según la fuente, nunca he pensado que hiciera falta el uso de ninguna tabla, y es que implementar el encoding personalizado usado por el juego es una solución mucho más limpia, de todos modos hay que dar soporte a la extracción, reserva de memoria y reinserción de los textos...
Sobre los punteros de 24 bits, no recuerdo si last ranker los tendría o no, pero no recuerdo punteros de 24 bits en Type-0; sólamente los del paquete principal (yellow.pkg, si no me falla la memoria). Aún así, eran punteros de 32 bits con un direccionamiento lógico, según la zona de memoria de psp adónde fuera a parar el fichero, por ejemplo:
la zona de memoria para el kernel comienza en 0x
00000000
La zona de memoria de usuario comienza en 0x
08000000
Por eso, de obviar el último byte (el 1º en big endian) da la impresion de tener punteros de 24 bits. Igualmente y con todo, con 24 bits se pueden direccionar 2^24 = 16 MB de datos por fichero. No entiendo por que dices que con 24 bits no es suficiente (teniendo en cuenta que el fichero de tu parche son menos de 700 kb en total, no sólo para los textos; necesitas más de 15 megas a mayores? 0_o?) Ya un videojuego con 16 megas de texto es inconcebible, incluso estando completamente en UTF-16
...
![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")
![[snif]](/images/smilies/nuevos/triste_ani1.gif "llorando")
![[mad]](/images/smilies/nuevos/miedo.gif "loco")
DDDD
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[decaio]](/images/smilies/nuevos2/decaido.gif "decaido")
