Devil Survivor: problema con los perfiles de los personajes

Lugar donde se intentarán resolver problemas específicos
Responder
Avatar de Usuario
Leeg
Mensajes: 379
Registrado: 20 Mar 2014, 00:25

Devil Survivor: problema con los perfiles de los personajes

Mensaje por Leeg » 22 Mar 2015, 20:26

¡Hola!

Después de habernos matado a traducir todos las biografías de los personajes, a la hora de implementarlas me he encontrado con un problema gordo.

El archivo a editar está en data/event/ds_profile.cmp. En principio este archivo sigue la misma estructura que los textos normales así que he usado el script que hice en PHP para implementarlo con punteros modificados y tal... El problema es que en el juego me lo muestra raro, como desordenado, texto solapándose y cosas más raras:

[img][/img]

Mi teoría es la siguiente: estos textos se van desbloqueando en función del camino que sigas en el juego y demás. ¿Es posible que el juego los desbloquee en función de su offset? Eso justificaría que salgan cortados y raros... pero aun así siguen haciendo un efecto raro, como comerse la segunda línea de todo o repetir texto porque sí. Si este es el problema sería una putada en mayúsculas, porque haría muy difícil, si no imposible, la traducción de ese archivo... habría que tratarlo como fixed length.

¿Alguna teoría adicional?

Gracias mil.

PD: En este personaje hace un efecto más raro si cabe:
[img][/img]

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 22 Mar 2015, 20:40

Yo lo que vi de raro en ese fichero es que tiene un espacio en blanco al inicio de los textos, con su salto de línea. Puede que eso tenga algo que ver, o puede que no, pero no tiene nada raro.

Código: Seleccionar todo

; @ds1\Data\Event\ds_profile.cmp

[00000000]
✓

[00000001]
Atsuro Kihara✓

[00000002]
17✓

[00000003]
AT-LOW✓

[00000004]
Atsuro Kihara✓

[00000005]
 
High school classmate
and best friend of
<cn=0000>.✓

[00000006]
 
Acquainted with Naoya
through programming
forums online before
meeting <cn=0000>.✓

[00000007]
 
Striving to become a
programmer. Calls
himself "Naoya's No. 1
apprentice."✓
...

Avatar de Usuario
Leeg
Mensajes: 379
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 22 Mar 2015, 20:43

El salto de línea es simplemente para dividir los segmentos en párrafos, pero todo eso lo he respetado, claro. :/

PD: Vale, me acabo de dar cuenta de que no sé por qué el salto de línea sí lo he respetado pero el espacio en blanco no tengo ni idea de por qué no, voy a revisarlo.


PD2:¡Solucionado! Efectivamente, la falta de ese espacio antes de cada línea era lo que lo ha roto todo. Uff... menudo mini infarto casi me da, menos mal que se ha arreglado con eso. Muchas gracias, Cue ;)

Avatar de Usuario
Leeg
Mensajes: 379
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 22 Mar 2015, 22:03

Por cierto, y perdón por el doble post, para los gráficos en esta ventana voy a tratar de encontrar dónde se determina el espacio asignado a cada trocito de la imagen con los textos, porque está hecho de tal forma que no te deja poner ni una letra más y queda cutrísimo... ¿Conseguiré hacerlo o es mejor que lo dé por imposible? Nunca he editado nada parecido.

(Me refiero a lo de NOMB y EDA)

[img]http://i.imgur.com/ZrcaTzM.png[/img]

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 23 Mar 2015, 01:51

Eso se parece a los gráficos con los que tuve que lidiar en el Radiant, hay que ver estos de Atlus.
De hecho lo acabo de mirar y es la misma situación: archivos de tiles sin más (parece que los NCGR son demasiado mainstream), mostrados usando el motor 3D de la consola, y con el tamaño definido en el código ejecutable. Por ejemplo, la etiqueta "Name" original tiene un tamaño predefinido de 5x18 píxeles.

Después de buscar un rato con el No$gba, he encontrado las dimensiones de "Name" y "Age" en el arm9.bin, y la que corresponde a la longitud del gráfico está en 0x141518 y 0x141528 respectivamente. Cambia los números que hay ahí por la longitud que necesites, y debería salir el gráfico completo.

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 23 Mar 2015, 09:26

Leeg escribió:PD2:¡Solucionado! Efectivamente, la falta de ese espacio antes de cada línea era lo que lo ha roto todo. Uff... menudo mini infarto casi me da, menos mal que se ha arreglado con eso. Muchas gracias, Cue ;)
Otra cosa que aprendes y que no encontrarás en ningún manual. Siempre digo que hay que respetar el máximo posible los datos originales, que nunca se sabe lo que te puede pasar si no lo haces :D

Avatar de Usuario
Leeg
Mensajes: 379
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 23 Mar 2015, 10:09

Skye escribió:Eso se parece a los gráficos con los que tuve que lidiar en el Radiant, hay que ver estos de Atlus.
De hecho lo acabo de mirar y es la misma situación: archivos de tiles sin más (parece que los NCGR son demasiado mainstream), mostrados usando el motor 3D de la consola, y con el tamaño definido en el código ejecutable. Por ejemplo, la etiqueta "Name" original tiene un tamaño predefinido de 5x18 píxeles.

Después de buscar un rato con el No$gba, he encontrado las dimensiones de "Name" y "Age" en el arm9.bin, y la que corresponde a la longitud del gráfico está en 0x141518 y 0x141528 respectivamente. Cambia los números que hay ahí por la longitud que necesites, y debería salir el gráfico completo.
¡Hala! ¡Muchísimas gracias! ¿Podría preguntar cómo los has encontrado? Con No$GBA lo único que he encontrado yo son los offset en pantalla de los cuatro vértices que forman cada imagen, pero a partir de ahí ya no sé proceder.

Queda perfecto :')
[img]http://i.imgur.com/lx3QanA.png[/img]

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 23 Mar 2015, 11:07

Pues lo que pasa es que el juego quiere mostrar una imagen 2D con el motor 3D, y eso lo hace creando un rectángulo y poniéndole el gráfico como textura. Si seleccionas el cuadrado que quieres en el menú del 3D viewer del No$gba y lo expandes, verás que se hace con varios comandos: creación de vértices, selección de textura, multiplicación por matrices de traslación, y multiplicación por matrices de escala. A nosotros nos interesa cómo decide qué trozo de la imagen usar como textura, y eso lo hace con los comandos texcoord.

Hace 4 comandos texcoord, uno por cada vértice, y definen las cuatro esquinas del gráfico que van a usar. En el caso de "Name", los parámetros que se dan al texcoord son 0x00500000, 0x00A00000, 0x00A00120, 0x00500120. El primer número es la coordenada Y, el número de píxeles desde el borde superior de la imagen que hay que bajar. El segundo es la coordenada X, el número de píxeles desde el borde izquierdo que hay que moverse hacia la derecha. Si abrimos el gráfico y vamos a los cuatro puntos formados por esos números, vemos que forman un rectángulo alrededor de la palabra "Name".

Lo que hay que hacer es cambiar estos parámetros que se pasan al texcoord, en este caso el 0x12 ese. Para eso primero hay que ver cómo se envían los comandos. En GBATEK vemos que la dirección de memoria a la que se escriben los parámetros es 0x04000488. Ponemos un break on write en esa dirección, y tras hacerlo saltar unas cuantas veces vemos que el r4 es el que se usa para guardar los parámetros. Ahora ponemos un break cuando r4=00A00120, y cuando salta hay que ver cómo llegó el 0x12 ahí. En este caso venía de un OR con otro registro, así que ponemos un break a ese registro, y luego vemos que ese lo obtuvo de otro registro distinto, y ponemos otro break, y luego vemos que ese lo obtuvo cargándolo de la memoria, y ponemos un break on write... y así, poniendo breakpoints a registros y zonas de memoria, hasta que al final vemos que carga el 0x12 de una zona de memoria que corresponde al archivo arm9.bin y que podemos editar sin más. Otras veces puede ser una instrucción del tipo mov r0, 0x12, en ese caso hay que modificar la instrucción.

Vamos, el proceso es un peñazo pero al final consigues que todos los gráficos queden bien sin que haya que andar apretujando letras y creando una masa ilegible de píxeles.
A veces cambiar el texcoord solo no funciona, hay que cambiar la matriz de escala (mtx_scale) también, lo que implica buscar numeritos otra vez.
Y también es posible cambiar la posición del gráfico, cambiando la matriz de traslación (mtx_trans).

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 23 Mar 2015, 13:57

Bien, hay más gente que se anima a dar explicaciones que luego casi nadie leerá ni entenderá :)

No es que se quiera mostrar un tile por medio del motor 3D, es que es más simple así a la hora de hacer el juego, que el tratamiento 2D es obsoleto y se usan mejor las librerías de desarrollo. Es una evolución lógica de las consolas, que van dejando atrás los sistemas antiguos para emplear los modernos, que son los que caracterizan a dichas consolas.

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 23 Mar 2015, 16:36

Ah, pues tiene sentido. Recuerdo tener problemas al intentar cambiar el tamaño de un gráfico que se mostraba con el motor 2D, fue imposible porque solo hay 12 tamaños posibles para un objeto en pantalla. Ahí el 3D es mucho mejor, se puede poner el tamaño que sea.

Y qué lógica puede haber detrás de la decisión de guardar los tiles sin más, con el tamaño definido en el ejecutable, en vez de usar el formato NCGR que tiene las dimensiones en la cabecera?

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 23 Mar 2015, 18:21

Lógica ninguna. Si algo he aprendido todos estos años es que los desarrolladores se divierten cuando hacen las cosas, y si pueden complicarse la vida, mejor que mejor :twisted:

Yo creo que todo lo queda de 2D es por hacerlo compatible con GBA, cuando la NDS admitía los cartuchos, y, sabiendo que iban a quitar la retrocompatibilidad, yo hubiese preferido que mejorasen todas las rutinas gráficas para no andar con esas historias. Pero muchos de los formatos gráficos se siguen rigiendo por los métodos de antes, con tilesets, así que usan las rutinas de toda la vida cuando quieren.

Avatar de Usuario
Leeg
Mensajes: 379
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 23 Mar 2015, 22:46

Muchísimas gracias a los dos por las explicaciones. No me veo capaz todavía de usar el debugger de No$GBA para poner breakpoints y demás porque estoy muy verde en el tema, pero algo he aprendido.

Mil gracias ;)

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 24 Mar 2015, 10:39

Es que estas cosas necesitan que se conozca un poco la consola para saber qué son. Tú ves que se escribe un valor en una dirección de memoria y no sabes si es memoria normal para usar o memoria específica que usa la consola. Y, aún así, siempre tienes que estar echando mano de información como la de gbatek para saber qué es.

Avatar de Usuario
Leeg
Mensajes: 379
Registrado: 20 Mar 2014, 00:25

Mensaje por Leeg » 24 Mar 2015, 12:54

Algún tutorial para tontos del debugger de No$GBA no habrá por ahí, ¿no? XD

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 24 Mar 2015, 14:02

¡Ni para listos! :twisted:
Eso es a base de dale que te pego, lo que a veces es un preñazo, como dice Skye.

Responder