[PSX] Ace Combat 3 - busco ayuda

Lugar donde se intentarán resolver problemas específicos
Responder
Iroquois
Mensajes: 16
Registrado: 13 Jun 2012, 09:01

[PSX] Ace Combat 3 - busco ayuda

Mensaje por Iroquois » 19 Jun 2012, 00:20

Bueno, he descubierto este foro muy recientemente, y quería preguntarle algo a los gurúes del romhacking.

Participé y sigo el proyecto de traducción de Ace Combat 3 Electrosphere, http://projectnemo.net , y ya fue traducido totalmente. El problema es que no encontramos programador para meterlo en el juego. Hace un par de meses apareció uno, que lleva un blog con sus intentos pero ninguna noticia alentadora por el momento.

Se encontró un par de textos en TIM, que son los del cutscene ingame, pero todavía nada sobre todos los demás scripts que componene la historia (que sí, justamente la versión japonesa es la que tiene HISTORIA; en EEUU/PAL lo violaron al juego sin condón).


Alguno podría por favor darle una mirada a ver qué encuentra y si es posible insertar los textos? Si necesitan la BIN yo se las subo.
Gracias

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

Mensaje por CUE » 19 Jun 2012, 12:52

Yo no terminio de entender el asunto. ¿Significa que los textos no se han sacado del juego y se hacen como la típica acción que se hace en gamefaqs, copiando los textos según aparecen en el juego? Si es así, es perder el tiempo, pues no hay ninguna garantía de que los textos estén almacenados tal y como se copian, ni hay garantías de que puedan meterse por falta de espacio.

~~~ AÑADIDO ~~~
Más o menos he sacado un montón de cosas y he visto la compresión usada. Me temo que lo de meter los textos no es tan simple como parece. Cuando tenga un rato explico un poco lo que he visto.

Iroquois
Mensajes: 16
Registrado: 13 Jun 2012, 09:01

Mensaje por Iroquois » 19 Jun 2012, 14:15

Sí, desde un principio supusimos que los textos estaban guardados en imágenes.
En el BIN no hay ningún texto JIS para buscar, y con algunos extractores TIM se veían algunos textos de cutscenes corruptos.

La traducción sí, se hizo tal cual. Se tradujo una wiki japonesa con todo el texto transcripto a mano.
Probé dumpear la RAM en distintas partes del juego y encontré los textos del briefing/videos con el psx multi rip, sumado a un montón de TIM del menú y textos de la interface que no aparecían con el timviewer:

[img]http://img198.imageshack.us/img198/3064 ... iefing.png[/img]

Por lo que si en verdad todo el texto está en imágenes, haría falta hacer ingeniería inversa al mecanismo que carga esas imágenes para ver dónde y cómo se guardan. Pero eso me excede completamente :S

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

Mensaje por CUE » 19 Jun 2012, 19:06

Lo primero: no voy a hacer nada para este juego. Si lo que explico puede ser aprovechado por alguien, pues eso que se ahorra, además de tener una base para empezar.

ACE3.BIN es el ejecutable, que es llamado desde el SLPS.

ACE.SPH es el fichero índice de ACE.SPB, que parecen ser sólo vídeos, aunque no me he molestado mucho en comprobarlo. Con jpsxdec se pueden ver, así como los TIMs.

ACE.BPH es el fichero índice de ACE.BPB, que es donde parece estar todo el mogollón.

Los índices tienen una cabecera de 20 bytes:
- 4 bytes con la signatura "AC3E"
- 4 bytes ?
- 4 bytes ?
- 4 bytes ?
- 4 bytes con el número de entradas
Después hay 8 bytes para cada una de las entradas:
- 4 bytes ?
- 4 bytes con el LBA (multiplicar por 0x800 para obtener el offset)

Con esos datos se pueden extraer los archivos de los ficheros de datos. Esos archivos suelen estar empaquetados.

Si el archivo está empaquetado tiene una cabecera:
- 4 bytes con el número de ficheros
Después hay 4 bytes para cada uno de los ficheros:
- 4 bytes con el offset

Los ficheros que salen ahora también pueden estar empaquetados de la misma forma.

Para saber si un fichero está empaquetado se cogen los 2 primeros valores de 32 bits. Al primero le incrementamos una unidad y lo multiplicamos por 4. Si el número resultante es el segundo de los valores es que se trata de un fichero empaquetado.

Hay 2 tipos de ficheros que se reconocen a simple vista: los TIM y los ULZ. Los ULZ son ficheros comprimidos con variantes de LZR en cuya cabecera se indican el número de bits del offset del dato de la compresión (esto sólo vale para quien comprenda un poco esa compresión). La cabecera de los ULZ parece que se compone de 16 bytes en esta versión, que es la 1.04. Yo trabajé con la 1.00, que no es exactamente igual, con una cabecera de 20 bytes, para el juego "Time Crisis", donde había 4 compresiones, y sólo saqué 3. En este juego parece que hay cosas algo diferentes, pero básicamente son compresiones LZR, que son compresiones LZSS donde se separan los datos en tres partes (flags, datos sin comprimir, datos comprimidos) en vez de tener todo seguido.

He hecho una chorradita para extraer todos los ficheros de ACE.BPB, sólo hay que poner el programa en una carpeta con ACE.BPH y ACE.BPB y ejecutarlo: http://www.mediafire.com/?az3lly0ck1la3ra

Iroquois
Mensajes: 16
Registrado: 13 Jun 2012, 09:01

Mensaje por Iroquois » 20 Jun 2012, 01:40

Wow, muchísimas gracias!
Ciertamente, es un avance, muy desalentador porque extiende el panorama aún más... pero es un paso más.

Lo que me imagino es que con tanta compresión, la edición se complicaría bastante. No es como un bmp o texto que reemplazas pero siempre tienen el mismo tamaño, quizás al editarlo la compresión queda más chica o más grande, ¿y entonces..? ¿ajustar tablas y punteros por toda la iso?

Entendí que no vas a hacer nada más para este juego, pero qué posibilidades le ves de realizarse (ya que experimentaste con otros juegos con compresión)?
Y en cuanto a los ULZ, no hay ninguna utilidad o documentación para des/comprimirlos? Hay otros juegos traducidos que los usen? Intenté buscar eso de versión 1.04 y 1.00 y no encontré. Sólo vi el foro de romhacking donde también hablaban del Time Crisis en español.

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

Mensaje por CUE » 20 Jun 2012, 08:22

En teoría, parece que reemplazar ficheros de distinto tamaño no es ningún problema, pero están esos campos de las cabeceras que no se sé qué son y si pueden llegar a afectar en algo (pueden ser fechas, CRCs, ...).

Hacer algo con este juego lo veo bastante complicado. No vas a encontrar nada sobre la compresión porque nadie se ha metido con ella, exceptuando el tipejo que tengo delante del espejo, y no terminé de hacerla al 100% porque en realidad son varios tipos de compresión y sólo encontré algunos, y me da la impresión que en el AC3 hay más. Si no recuerdo mal, en el Time Crisis me faltaron 2 gráficos por comprimir, aunque, la verdad sea dicha, tampoco me esforcé demasiado, que no era plan de perder semanas en algo que después se comprobó que no debí haber empezado. En el caso de que encuentres a alguien que tenga conocimientos de compresión LZSS podrá usar lo que tengo del Time Crisis:

Código: Seleccionar todo

//
// ULZ header (20 bytes)
// ---------------------
// 0x0000 - 4 bytes: signature "ULZ" + 0x1A
// 0x0004 - 2 bytes: 0
// 0x0006 - 1 byte : mode? (2/normal LZ, 0/unkown LZ type)
// 0x0007 - 1 byte : nbits for LZ algorithm
// 0x0008 - 4 bytes: offset to decompressed data (aligned to 32 bits)
// 0x000C - 4 bytes: offset to compressed data (aligned to 32 bits)
// 0x0010 - 4 bytes: size of decompressed file
// 
// ULZ body (aligned to 32 bits)
// -----------------------------
// 0x0014 - X bytes: flags data
// ?????? - X bytes: decompressed data (pointer in 0x0008)
// ?????? - X bytes: compressed data (pointer in 0x000C)
// 

// in:
//   source - ULZ buffer (a valid ULZ file with header)
//   target - data buffer for the decompressed data
// out:
//   0 - decompression ok
//   1 - decompression failed
int UnULZ(unsigned char *source, unsigned char *target) {
  unsigned char  *ulz_f, *ulz_d, *ulz_c, *tgt, *end;
  unsigned int    len, pos, nbits, msk;
  unsigned char   flags, mask;

  if (source[0x06] != 0x02) {
    if (_DEBUG_) printf("Mode %02X not supported\n", source[0x06]);
    return (1);
  }

  nbits = source[0x07];
  msk = 0xFFFF >> (16 - nbits);

  ulz_f = source + 0x14;
  ulz_d = source + *(unsigned int *)(source + 0x08);
  ulz_c = source + *(unsigned int *)(source + 0x0C);
  tgt   = target;
  end   = target + *(unsigned int *)(source + 0x10);

  for &#40;mask = 0; tgt < end; mask <<= 1&#41; &#123;
    if &#40;!mask&#41; &#123; mask = 0x01; flags = *ulz_f++; &#125;;
    if &#40;flags & mask&#41; &#123;
      *tgt++ = *ulz_d++;
    &#125; else &#123;
      pos = *ulz_c++;
      pos |= *ulz_c++ << 8;
      len = &#40;pos >> nbits&#41; + 2;
      pos = &#40;pos & msk&#41; + 1;
      while &#40;len--&#41; *tgt++ = *&#40;tgt - pos&#41;;
    &#125;
  &#125;

  return &#40;0&#41;;
&#125;
Lo ideal sería que alguien buscase la descompresión en el ejecutable para ver cómo lo hace, pero eso ya son palabras mayores.

Responder