Intentando aprender algo de romhack

Lugar donde se intentarán resolver problemas específicos
Responder
Avatar de Usuario
tchusami
Mensajes: 86
Registrado: 29 Ene 2011, 20:01
Ubicación: Librilla
Contactar:

Intentando aprender algo de romhack

Mensaje por tchusami » 15 Nov 2012, 23:07

Buenas a todos, estoy intentando aprender algo de romhacking pero estoy muy perdido, he cogido un juego de nes al azar, el juego en cuestión es Crystalis.

Como no sabia por donde empezar he empezado a buscar los textos, a primera vista los textos eran faciles de encontrar, estaban a la vista y sin necesidad de tablas, pero esos eran solo los de las animaciones (por llamarlas de algun modo). Los textos de los diálogos también se ven sin necesidad de tablas, pero el problema esta en que entre el texto de los diálogos hay bytes que direccionan palabras o partes de palabras en una tabla, asi que me he puesto a analizar esa tabla.

La parte de la tabla se compone de: una tabla de punteros de dos bytes y la tabla de palabras separadas por el byte 0x00.
La forma en la que los punteros direccionan las palabras es, invertir los bytes (pasar a little endian segun recuerdo), y añadile al principio un 0x02, entonces un puntero AB apunta a 0x02BA.

Como tengo una dudilla pongo una captura para explicarme mejor:

[img]http://s12.postimage.org/anp8jab0p/Crystalis_Nes.jpg[/img]

Aqui he marcado unos punteros (recuadro rojo arriba) que apuntan a otros punteros (recuadro rojo abajo), y un puntero (recuadro azul arriba) que apunta a un byte (0x00) abajo (también en azul). Aquí viene mi duda, ¿Por qué hay punteros que apuntan a otros punteros, y por qué ningún puntero apunta a 'as' o al byte anterior a 'as'?

Tengo algunas dudas mas pero no quiero liarme con mucha información de golpe. Espero que no sea una molestia esto, y no pongo la rom porque supongo que no se podrán postear roms en el foro.

Un saludo.

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

Mensaje por CUE » 16 Nov 2012, 09:11

Por un momento pensé que te iba a dar una alegría porque tengo alguna cosilla del Crystalis, pero es para la versión de GBC, así que nada.

Esos textos son MTE (Multi Tile Encoding), que son cadenas o partes de un texto que se repiten bastante en el script o que se usan como medio de compresión. Se suelen codificar como si fuesen caracteres, en este caso con 2 bytes, que coinciden con su posición en memoria. Aquí siempre cometéis el mismo error, que es suponer que la dirección hexadecimal que se ve en un editor es donde están los textos, pero no es así.

Una cosa a saber de las mal llamadas ROMs de NES es que los 16 primeros bytes se añaden para que puedan funcionar en los emuladores, así que si se quiere trabajar con un editor, lo mejor es hacer una copia y eliminar esos bytes, por lo que todo lo que has estado haciendo debe estar 0x10 bytes antes. En este caso, esos MTE comienzan en 0x8AF0 (sin el 0x02), curiosamente coincidiendo con los punteros que tienes en rojo en 0x00028910, que en realidad es 0x00028900, un número más "redondo". A partir de ahí, y hasta que empiezan los MTE, están todos los offsets de los mismos, en valores de 2 bytes.

Otra forma de verlo es usar un emulador. Yo uso el FCEUX (dale al enlace de Emuladores de la página principal y búscalo, que es uno de los que se actualiza a menudo). Ejecutas la ROM, no "el ROM" o "la ROOM", que ya les vale a muchos con la tontería, y cuando veas aparecer los textos le das a la pausa para fisgar. La Pausa es esa tecla que pone "Pausa/Inter" o "Pause/Break", que no sé por qué mucha gente siempre pregunta cómo hacerlo, y es de lo más obvio.

Mirando la PPU puedes ver la fuente para saber qué caracteres usa, que en este caso emplea también códigos para mostrar textos de 2 letras, como "et", " o", "f ", incluso varios caracteres se usan para poner textos, como "Sword", "Shield", etc. Muchísimas veces el código del tile corresponde con el del carácter, así que pasando el cursor por encima de cada tile puedes ver qué cáracter representa:
[img]http://imageshack.us/a/img525/7066/88523169.png[/img]

Con el editor hexadecimal del emulador puedes buscar esos MTU, que están en 0x008AF0, donde ya ves que el 0x02 del que hablas sobra.
[img]http://imageshack.us/a/img11/396/87287741.png[/img]

Hay más cosas, pero no quiero liarte con mucha información de golpe (vamos, que me tengo que ir a hacer mis cosillas, pero si lo digo así no tiene gracia).

Eso sí, busca información de la estructura de las ROMs de NES, para saber lo que son esos 0x10 bytes de la cabecera, y lo que son los CHR y PRG.

Avatar de Usuario
tchusami
Mensajes: 86
Registrado: 29 Ene 2011, 20:01
Ubicación: Librilla
Contactar:

Mensaje por tchusami » 16 Nov 2012, 15:51

Ya he mirado todo lo que me has dicho, aunque hay cosas que no termino de entender. Si yo quiero aumentar el tamaño de la rom porque al traducir una palabra esta es mas larga en español, ¿tendría que añadir bytes a cero hasta completar un bloque de 16K al final del PRG y recalcular la cabecera o es algo mas complejo aun?

La verdad es que he estado probando con la rom y si cambio el tamaño ya no se ejecuta (cosa que veo logica), pero claro no se donde completar el nuevo bloque que se añade para que el resultado de sumar el PRG y el CHR en bytes sea igual al tamaño de la rom, que hasta donde tengo entendido, la suma tiene que ser el tamaño de la rom sin la cabecera NES.

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

Mensaje por CUE » 16 Nov 2012, 17:58

Si quieres aumentar el tamaño de algo te toca meterte de lleno con el ensamblador de la NES para ver si puedes mover las cosas de sitio.

Avatar de Usuario
tchusami
Mensajes: 86
Registrado: 29 Ene 2011, 20:01
Ubicación: Librilla
Contactar:

Mensaje por tchusami » 16 Nov 2012, 18:55

Vaya jaleo entonces. Y para extraer imagenes he leido por ahi que se componen de 16 bytes, divididos en dos canales y que hay que juntar los canales operando con los bytes, pero no entiendo porque pone que si tienes en el canal A un 1 y en el B otro 1 al juntarlos sale un 3, pero un bit solo toma valores 0 y 1, así que no me aclaro. ¿Dónde se guarda el resultado y cómo se interpreta luego?

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

Mensaje por CUE » 16 Nov 2012, 19:51

Eso es lo que se llama imágenes planares. Para que lo entiendas, si en un plano hay 1 y en el otro hay 1 entonces el pixel es "11", que es 3 en binario. Si fuesen 1 y 0 sería "10", que es 2, etc. En cristiano entendible, se reparten los bits del pixel entre los planos.

► AÑADIDO

Aquí hay un documento que explica alguno de los formatos gráficos, de cuando el romhacking era en realidad romhacking, no lo que hay hoy día, que muchas veces se reduce todo a usar un editor o un programa determinado, sin que la gente se preocupe por entender lo que es cada cosa. Muchos de los formatos explicados vienen en los programas habituales que se suelen usar para editar gráficos, pero son muy pocos los que conocen su significado.

Código: Seleccionar todo

Console Graphics Document
Author:   Klarth
Contact:  stevemonaco@hotmail.com
          http://rpgd.emulationworld.com/klarth
          Started on July 18, 2000

Version 0.7 - January 2, 2000
-- Initial Release covering 11 of the most common console graphic formats

I.  Table of Contents

1.  Introduction and Terminology
2.  1BPP NES/Monochrome
3.  2BPP NES
4.  2BPP SNES/Gameboy/GBC
5.  3BPP SNES
6.  4BPP SNES/PC Engine
7.  8BPP SNES
8.  Mode 7 SNES
9.  2BPP NGPC
10. 2BPP Virtual Boy
11. 4BPP SMS/Game Gear/WSC
12. 4BPP Genesis/x68k
13. Thanks Section

_______________________________________________________________________________________________


1.   Introduction and Terminology

-----A. Introduction

     There was a period when I didn't even look at this document for probably two or three 
     months, particularly after when I forced myself to do nearly all of the SNES formats.  
     This document really isn't for somebody beginning to learn graphics but rather for 
     somebody with a fairly strong bitmap graphic knowledge and to use this as a reference.

     If you wish to put this document on your site, please contact me for authorization 
     *before* you post this file on your site.  If I seem to "magically" disappear from the 
     scene, you may post this document *only* in its original form.  If you use this doc 
     please credit me in a thanks section since I just like to see who reads and uses them.

-----B. Terminology

     BPP:  Bits per pixel.

     Xth Bitplane: Tells how many bitplanes deep the pixel or row is; the top layer 
          is the first bitplane, the one below that is the second, and so on.

     [rC: bpD]: row number C (0-7 in a 8x8 tile), bitplane number D (starting at 1).

     [pA-B rC: bpD]: pixels A-B (leftmost pixel is 0), row number C (0-7 in a 8x8 tile), 
          bitplane number D (starting at 1. bp* means it's a linear format and stores the 
          bitplanes one after another bp 1 to bp Max.)

_______________________________________________________________________________________________


2.  1BPP NES/Monochrome
  Colors Per Tile - 0-1
  Space Used - 1 bit per pixel.  8 bytes per 8x8 tile.

  Note: This is a tiled, linear bitmap format.
  Each pair represents one byte
  Format:

  [r0, bp1], [r1, bp1], [r2, bp1], [r3, bp1], [r4, bp1], [r5, bp1], [r6, bp1], [r7, bp1]

  Short Description:

  The first bitplane is stored row by row, very simple.

_______________________________________________________________________________________________


3.  2BPP NES
  Colors Per Tile - 0-3
  Space Used - 2 bits per pixel.  16 bytes per 8x8 tile.

  Note: This is a tiled, planar bitmap format.
  Each pair represents one byte
  Format:

  [r0, bp1], [r1, bp1], [r2, bp1], [r3, bp1], [r4, bp1], [r5, bp1], [r6, bp1], [r7, bp1]
  [r0, bp2], [r1, bp2], [r2, bp2], [r3, bp2], [r4, bp2], [r5, bp2], [r6, bp2], [r7, bp2]

  Short Description:

  Bitplane 1 is stored row by row and then bitplane 2 is stored row by row.

_______________________________________________________________________________________________


4. 2BPP SNES/Gameboy/GBC
  Colors Per Tile - 0-3
  Space Used - 2 bits per pixel.  16 bytes per 8x8 tile.

  Note: This is a tiled, planar bitmap format.
  Each pair represents one byte
  Format:

  [r0, bp1], [r0, bp2], [r1, bp1], [r1, bp2], [r2, bp1], [r2, bp2], [r3, bp1], [r3, bp2]
  [r4, bp1], [r4, bp2], [r5, bp1], [r5, bp2], [r6, bp1], [r6, bp2], [r7, bp1], [r7, bp2]

  Short Description:

  Bitplanes 1 and 2 are intertwined row by row.

_______________________________________________________________________________________________


5. 3BPP SNES
  Colors Per Tile - 0-7
  Space Used - 3 bits per pixel.  24 bytes for a 8x8 tile.

  Note: This is a tiled, planar bitmap format.
  Each pair represents one byte.
  Format:

  [r0, bp1], [r0, bp2], [r1, bp1], [r1, bp2], [r2, bp1], [r2, bp2], [r3, bp1], [r3, bp2]
  [r4, bp1], [r4, bp2], [r5, bp1], [r5, bp2], [r6, bp1], [r6, bp2], [r7, bp1], [r7, bp2]
  [r0, bp3], [r1, bp3], [r2, bp3], [r3, bp3], [r4, bp3], [r5, bp3], [r6, bp3], [r7, bp3]

  Short Description:

  Bitplanes 1 and 2 are stored first, intertwined row by row.  Then the third bitplane is 
  stored row by row.  This format isn't used by many games since it's actually a type of 
  compression, because the SNES doesn't natively support the 3BPP format.  There is a routine 
  that inserts the fourth bitplane before or while it's being transferred to VRAM so that it 
  can be used by the SNES.

_______________________________________________________________________________________________


6. 4BPP SNES/PC Engine
  Colors Per Tile - 0-15
  Space Used - 4 bits per pixel.  32 bytes for a 8x8 tile.

  Note: This is a tiled, planar bitmap format.
  Each pair represents one byte
  Format:

  [r0, bp1], [r0, bp2], [r1, bp1], [r1, bp2], [r2, bp1], [r2, bp2], [r3, bp1], [r3, bp2]
  [r4, bp1], [r4, bp2], [r5, bp1], [r5, bp2], [r6, bp1], [r6, bp2], [r7, bp1], [r7, bp2]
  [r0, bp3], [r0, bp4], [r1, bp3], [r1, bp4], [r2, bp3], [r2, bp4], [r3, bp3], [r3, bp4]
  [r4, bp3], [r4, bp4], [r5, bp3], [r5, bp4], [r6, bp3], [r6, bp4], [r7, bp3], [r7, bp4]

  Short Description:

  Bitplanes 1 and 2 are stored first, intertwined row by row.  Then bitplanes 3 and 4 
  are stored, intertwined row by row.

_______________________________________________________________________________________________


7. 8BPP SNES
  Colors Per Tile - 0-255
  Space Used - 8 bits per pixel.  64 bytes for a 8x8 tile.

  Note: This is a tiled, planar bitmap format.
  Each pair represents one byte.
  Format:

  [r0, bp1], [r0, bp2], [r1, bp1], [r1, bp2], [r2, bp1], [r2, bp2], [r3, bp1], [r3, bp2]
  [r4, bp1], [r4, bp2], [r5, bp1], [r5, bp2], [r6, bp1], [r6, bp2], [r7, bp1], [r7, bp2]
  [r0, bp3], [r0, bp4], [r1, bp3], [r1, bp4], [r2, bp3], [r2, bp4], [r3, bp3], [r3, bp4]
  [r4, bp3], [r4, bp4], [r5, bp3], [r5, bp4], [r6, bp3], [r6, bp4], [r7, bp3], [r7, bp4]
  [r0, bp5], [r0, bp6], [r1, bp5], [r1, bp6], [r2, bp5], [r2, bp6], [r3, bp5], [r3, bp6]
  [r4, bp5], [r4, bp6], [r5, bp5], [r5, bp6], [r6, bp5], [r6, bp6], [r7, bp5], [r7, bp6]
  [r0, bp7], [r0, bp8], [r1, bp7], [r1, bp8], [r2, bp7], [r2, bp8], [r3, bp7], [r3, bp8]
  [r4, bp7], [r4, bp8], [r5, bp7], [r5, bp8], [r6, bp7], [r6, bp8], [r7, bp7], [r7, bp8]

  Short Description:

  Bitplanes 1 and 2 are stored first, intertwined row by row.  Bitplanes 3 and 4 are stored 
  next intertwined row by row.  Then Bitplanes 5 and 6 intertwined row by row.  Finally, 
  Bitplanes 7 and 8 are stored intertwined row by row.

_______________________________________________________________________________________________


8. Mode 7 SNES
  Colors Per Tile - 0-255
  Space used - 8 bits per pixel.  64 bytes for a 8x8 tile.

  Note: This is a tiled, linear bitmap format.
  Each pair represents 1 byte.
  Format:

  [p0 r0: bp!], [p1 r0: bp!], [p2 r0: bp!], [p3 r0: bp!]
  [p4 r0: bp!], [p5 r0: bp!], [p6 r0: bp!], [p7 r0: bp!]
  [p0 r1: bp!], [p1 r1: bp!], [p2 r1: bp!], [p3 r1: bp!]
  [p4 r1: bp!], [p5 r1: bp!], [p6 r1: bp!], [p7 r1: bp!]
  ...
  [p0 r7: bp!], [p1 r7: bp!], [p2 r7: bp!], [p3 r7: bp!]
  [p4 r7: bp!], [p5 r7: bp!], [p6 r7: bp!], [p7 r7: bp!]

  Short Description:

  Each pixel has it's bitplanes stored right after another, so each byte directly references
  a palette color without needing to "combine" the bitplanes.

_______________________________________________________________________________________________


9. 2BPP Neo Geo Pocket Color
  Colors Per Tile - 0-3
  Space Used - 2 bits per pixel.  16 bytes per 8x8 tile.

  Note: This is a tiled, linear bitmap format.
  Each group represents one byte
  Format:

  [p4-7 r0: bp*], [p0-3 r0: bp*], [p4-7 r1: bp*], [p0-3 r1: bp*]
  [p4-7 r2: bp*], [p0-3 r2: bp*], [p4-7 r3: bp*], [p0-3 r3: bp*]
  [p4-7 r4: bp*], [p0-3 r4: bp*], [p4-7 r5: bp*], [p0-3 r5: bp*]
  [p4-7 r6: bp*], [p0-3 r6: bp*], [p4-7 r7: bp*], [p0-3 r7: bp*]

  Short Description:

  To simplify, this is merely a mirror image of the 2BPP Virtual Boy format.  Another 
  explanation would be to say that it's in Little Endian instead of Big Endian.  

  This is a linear format, so each pixel has it's bitplanes stored consecutively and then 
  moves to the next pixel's bitplanes, stored consecutively.  Probably the easiest example 
  possible of a linear bitplane format.  This format is the same as the Virtual Boy 2BPP 
  format, except that they are congruent mirror images of each other.

_______________________________________________________________________________________________


10. 2BPP Virtual Boy
  Colors Per Tile - 0-3
  Space Used - 2 bits per pixel.  16 bytes per 8x8 tile.

  Note: This is a tiled, bitmap format.
  Each represents one byte
  Format:

  [p0-3 r0: bp*], [p4-7 r0: bp*], [p0-3 r1: bp*], [p4-7 r1: bp*]
  [p0-3 r2: bp*], [p4-7 r2: bp*], [p0-3 r3: bp*], [p4-7 r3: bp*]
  [p0-3 r4: bp*], [p4-7 r4: bp*], [p0-3 r5: bp*], [p4-7 r5: bp*]
  [p0-3 r6: bp*], [p4-7 r6: bp*], [p0-3 r7: bp*], [p4-7 r7: bp*]

  Short Description:

  To simplify, this is merely a mirror image of the 2BPP NGPC format.  This is probably the 
  easiest example of a linear bitplane format.  It is stored pixel by pixel and row by row.  
  This format is the same as the Virtual Boy 2BPP format, except that they are congruent 
  mirror images of each other.

_______________________________________________________________________________________________


11. 4BPP Game Gear/Sega Master System/Wonderswan Color
  Colors Per Tile - 0-15
  Space Used - 4 bits per pixel.  32 bytes per 8x8 tile.

  Note: This is a tiled, linear bitmap format.
  Each pair represents one byte
  Format:

  [r0, bp1], [r0, bp2], [r0, bp3], [r0, bp4], [r1, bp1], [r1, bp2], [r1, bp3], [r1, bp4]
  [r2, bp1], [r2, bp2], [r2, bp3], [r2, bp4], [r3, bp1], [r3, bp2], [r3, bp3], [r3, bp4]
  [r4, bp1], [r4, bp2], [r4, bp3], [r4, bp4], [r5, bp1], [r5, bp2], [r5, bp3], [r5, bp4]
  [r6, bp1], [r6, bp2], [r6, bp3], [r6, bp4], [r7, bp1], [r7, bp2], [r7, bp3], [r7, bp4]

  Short Description:

  Bitplanes 1, 2, 3, and 4 are intertwined and stored row by row.

_______________________________________________________________________________________________


12. 4BPP Genesis/x68k
  Colors Per Tile - 0-15
  Space Used - 4 bits per pixel.  32 bytes per 8x8 tile.

  Note: This is a tiled, big Endian, linear format.
  Each pair represents one byte
  Format:

  [p1-2 r0: bp*], [p2-3 r0: bp*], [p4-5 r1: bp*], [p6-7 r1: bp*]
  [p1-2 r2: bp*], [p2-3 r2: bp*], [p4-5 r3: bp*], [p6-7 r3: bp*]
  [p1-2 r4: bp*], [p2-3 r4: bp*], [p4-5 r5: bp*], [p6-7 r5: bp*]
  [p1-2 r6: bp*], [p2-3 r6: bp*], [p4-5 r7: bp*], [p6-7 r7: bp*]

  Short Description:

  Bitplanes 1, 2, 3, and 4 are intertwined and stored pixel by pixel.

_______________________________________________________________________________________________


13. Thanks Section

  (wraith) - For showing me a more compact way of explaining how graphics are stored, which I 
           expanded on a bit.  As well as SNES 3BPP information and other things.
  Neil_    - His basic SNES graphics document taught me a bit more about bitmapped graphics.
  prez     - His NES graphics document taught me the basics of bitmapped graphics.

Avatar de Usuario
gadesx
Administrador
Administrador
Mensajes: 2006
Registrado: 24 Ene 2011, 16:43
Ubicación: El puche
Contactar:

Mensaje por gadesx » 17 Nov 2012, 02:13

lo de los bpp me toca usarlo en el micrografx cuando pongo texto y sale pequeño, y tengo que
poner en la imagen mas bpp xD

Avatar de Usuario
tchusami
Mensajes: 86
Registrado: 29 Ene 2011, 20:01
Ubicación: Librilla
Contactar:

Mensaje por tchusami » 17 Nov 2012, 12:33

La verdad es que no lo entiendo muy bien, los pares [rC, bpD] representan un byte, pero como paso yo cada byte a una imagen, es decir, si yo quisiese coger 16 bytes de una imagen a 2BPP de NES y poder visualizarla, ¿cómo lo tendría que hacer?

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

Mensaje por CUE » 17 Nov 2012, 12:54

Desde el principio, que es mejor, y así te cobro unas cervezas, pero si no pagas te mando a mis amijos, hoyga.

Supongamos que tenemos gráficos a 2bpp para los tiles de 8x8 pixeles. Eso significa que los 8x8=64 pixeles necesitan 64*2=128 bits, que son 128/8=16 bytes. Ahora ya sabemos por qué cada tile 8x8 a 2bpp necesita 16 bytes.

Ahora vamos cogiendo los pixeles (el valor del color, para que se entienda) hasta completar los 64 que hay en cada tile, empezando desde arriba a la izquierda, con dirección izquierda->derecha y arriba->abajo. El primer pixel, de 2 bits, se separa en sus dos bits, y cada uno va a un byte diferente, que es lo que se llama "fila" en ese documento, pero que nosotros lo llamaremos número de bit, que somos más castizos.

Más o menos haríamos lo siguiente:
- pixel 0 -> bit 0 del byte 0, bit 0 del byte 1 <--- este es el primer pixel de la primera fila
- pixel 1 -> bit 1 del byte 0, bit 1 del byte 1
- pixel 2 -> bit 2 del byte 0, bit 2 del byte 1
- pixel 3 -> bit 3 del byte 0, bit 3 del byte 1
- pixel 4 -> bit 4 del byte 0, bit 4 del byte 1
- pixel 5 -> bit 5 del byte 0, bit 5 del byte 1
- pixel 6 -> bit 6 del byte 0, bit 6 del byte 1
- pixel 7 -> bit 7 del byte 0, bit 7 del byte 1
- pixel 8 -> bit 0 del byte 2, bit 0 del byte 3 <--- este es el primer pixel de la segunda fila
- pixel 9 -> bit 1 del byte 2, bit 1 del byte 3
...

Para pasar del tile a imagen, se leen los bytes a pares y se van cogiendo los bits correspondientes para formar el color de 2 bits, que es el valor del pixel correspondiente.

Podría haber puesto cuatro líneas de código, que no son más, pero no tengo ganas, que quiero hacerte sudar un poco, que no es plan de dar todo siempre hecho.

Avatar de Usuario
tchusami
Mensajes: 86
Registrado: 29 Ene 2011, 20:01
Ubicación: Librilla
Contactar:

Mensaje por tchusami » 21 Nov 2012, 15:56

Bueno, después de algún examen y mientras me preparo el siguiente he conseguido extraer imágenes gracias a la explicación que me has dado. Adjunto parte de la extracción de un bloque CHR que contiene las letras de la A a la Z en mayúsculas.

LetrasCrystalisNes

Ahora me gustaría preguntarte sobre un juego de NDS, que como has desmantelado ya casi todos los juegos imaginables, supongo que sabrás como están empaquetados los ficheros. El juego en cuestión es el Monster Rancher DS, te adjunto de todas formas el fichero donde se supone que esta el script, además, todos los ficheros del juego van empaquetados con el mismo formato en un archivo .pac (ni pak, ni pack). El fichero parece componerse de una cabecera que indica donde empieza y termina cada fichero, pero no estoy muy seguro, además debe llevar algún tipo de compresión porque no se ve ningún texto ni nada, no se si estará comprimido fichero por fichero y luego empaquetado o empaquetado y comprimido.

Fichero Monster Rancher DS:

SCRIPT.pac

Pues eso es todo. Gracias.

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

Mensaje por CUE » 21 Nov 2012, 16:32

¿Y ya está? ¿Tanta historia con los gráficos y sólo me sacas unas letras esmirriadas? Lo que se hace con esos gráficos de NES es sacar toda la página con los tiles, que suelen ser 16x16, de 8x8 pixeles. Después es cuando la gente se tiene que molestar en modificar lo que quiera. Piensa que no existen gráficos sueltos en esas roms. Incluso, aunque pueda resultar sorprendente, tampoco existen fuentes de caracteres. Piensa por qué, que ya sabes lo mala persona que soy y no te lo voy a decir. :twisted:

Mirando lo de DS, los 4 primeros bytes indican el número de ficheros que hay en el archivo, y luego, por cada archivo, 4 bytes con el offset absoluto donde está y otros 4 bytes con el tamaño. Todo en low-endian, como es costumbre. Parece que los offsets siempre son múltiplos de 4, así que seguramente los ficheros están alineados a 4 bytes. Mirando el inicio de varios ficheros se ve que empiezan por 0x24, que suele ser el indicador de Huffman de 4 bits, así que ya sabes por dónde seguir, que justo acabo de comer y me da pereza comprobarlo a mí.

Avatar de Usuario
tchusami
Mensajes: 86
Registrado: 29 Ene 2011, 20:01
Ubicación: Librilla
Contactar:

Mensaje por tchusami » 21 Nov 2012, 16:43

Guay, miraré lo de extraer las imágenes en tiles de 16x16 y lo de sacar los archivos de los .pac y el señor Huffman, pero ahora voy a estudiar algoritmos y estructuras de datos que si apruebo el viernes ya no tengo que volver a examinarme.

EDITO

Bueno, anoche me puse a terminar de hacer la extracción de imagenes a 16x16 y ya de paso hice la reinserción. Aquí está el programa resultante (que supongo que habra tropecientos como este): NesTilesManager

Ya el viernes me pondré con desempaquetar los pac y a estudiarme el algoritmo de Huffman.

Un saludo.

Avatar de Usuario
tchusami
Mensajes: 86
Registrado: 29 Ene 2011, 20:01
Ubicación: Librilla
Contactar:

Mensaje por tchusami » 23 Nov 2012, 23:11

Ya estoy por aquí de nuevo, vengo con dos cosillas más para seguir acumulando mi deuda de cervezas.

Primero: En que lugar de la rom de nes se almacena la paleta de cada imagen. Yo he deducido que esta mezclada con el código de programa y dependiendo de si una imagen se carga en una zona de memoria u otra se aplica una paleta u otra.

Segundo: He hecho el extractor de ficheros pac, pero ahora estoy peleandome con Huffman porque hay varios tipos y no entiendo como hay que aplicarlo.

Eso es todo.

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

Mensaje por CUE » 24 Nov 2012, 11:05

La paleta está en la OAM, que está copiada en la RAM, donde se cambia para poder luego ser recopiada a la OAM. Todo eso lo encontrarás en alguna parte de la ROM, pero no me preguntes dónde.

Huffman sólo es una compresión, independientemente de que sea de 4 o de 8 bits. Busca los compresores por la web, que ahí encontrarás el que necesitas.

AÑADIDO: http://nesdev.com/NinTech.txt

Responder