Romxhacking Romxhacking
- Nasío pa'jakear -
 
 F.A.Q.F.A.Q.   BuscarBuscar   Lista de MiembrosLista de Miembros   Grupos de UsuariosGrupos de Usuarios   RegístreseRegístrese 
 PerfilPerfil   Identifíquese para revisar sus mensajesIdentifíquese para revisar sus mensajes   ConectarseConectarse 


Menú principal
Portal
Foros
F.A.Q.
Buscar
Lista de miembros
Grupos de usuarios
Perfil

Usuario
Nombre de Usuario:

Contraseña:

 Recordarme



He olvidado mi contraseña

¿Aún no tiene su cuenta?
Puede registrarse Aquí, es GRATIS.


Anuncio del administrador
No pretendemos solucionar todos los problemas ni ser referencia de nada, simplemente nos reunimos aquí para charlar de nuestras cosas.
NO SE RESPONDERÁ A NADA POR PRIVADO, QUE EL FORO ESTÁ PARA ALGO

Intentando aprender algo de romhack

 
Publicar Nuevo Tema   Responder al Tema    Romxhacking -> Dudas y Preguntas
Ver tema anterior :: Ver siguiente tema  
Autor Mensaje
tchusami



Sexo: Sexo:Hombre
Registrado: 29 Jan 2011
Edad: 25
Mensajes: 86
Ubicación: Librilla
Estado: Offline
MensajePublicado: Thu Nov 15, 2012 11:07 pm    Título del mensaje: Intentando aprender algo de romhack Responder citando

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:



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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor
CUE
Administrador
Administrador


Sexo: Sexo:Hombre
Registrado: 24 Jan 2011
Mensajes: 5435
Estado: Offline
MensajePublicado: Fri Nov 16, 2012 9:11 am    Título del mensaje: Responder citando

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:


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.


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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
tchusami



Sexo: Sexo:Hombre
Registrado: 29 Jan 2011
Edad: 25
Mensajes: 86
Ubicación: Librilla
Estado: Offline
MensajePublicado: Fri Nov 16, 2012 3:51 pm    Título del mensaje: Responder citando

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor
CUE
Administrador
Administrador


Sexo: Sexo:Hombre
Registrado: 24 Jan 2011
Mensajes: 5435
Estado: Offline
MensajePublicado: Fri Nov 16, 2012 5:58 pm    Título del mensaje: Responder citando

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
tchusami



Sexo: Sexo:Hombre
Registrado: 29 Jan 2011
Edad: 25
Mensajes: 86
Ubicación: Librilla
Estado: Offline
MensajePublicado: Fri Nov 16, 2012 6:55 pm    Título del mensaje: Responder citando

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?
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor
CUE
Administrador
Administrador


Sexo: Sexo:Hombre
Registrado: 24 Jan 2011
Mensajes: 5435
Estado: Offline
MensajePublicado: Fri Nov 16, 2012 7:51 pm    Título del mensaje: Responder citando

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:
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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
gadesx
Administrador
Administrador


Sexo: Sexo:Hombre
Registrado: 24 Jan 2011
Edad: 28
Mensajes: 1976
Ubicación: El puche
Estado: Offline
MensajePublicado: Sat Nov 17, 2012 2:13 am    Título del mensaje: Responder citando

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
_________________
Mi blog y mi droga: http://gadesxscene.blogspot.com/
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor MSN Messenger
tchusami



Sexo: Sexo:Hombre
Registrado: 29 Jan 2011
Edad: 25
Mensajes: 86
Ubicación: Librilla
Estado: Offline
MensajePublicado: Sat Nov 17, 2012 12:33 pm    Título del mensaje: Responder citando

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?
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor
CUE
Administrador
Administrador


Sexo: Sexo:Hombre
Registrado: 24 Jan 2011
Mensajes: 5435
Estado: Offline
MensajePublicado: Sat Nov 17, 2012 12:54 pm    Título del mensaje: Responder citando

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
tchusami



Sexo: Sexo:Hombre
Registrado: 29 Jan 2011
Edad: 25
Mensajes: 86
Ubicación: Librilla
Estado: Offline
MensajePublicado: Wed Nov 21, 2012 3:56 pm    Título del mensaje: Responder citando

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor
CUE
Administrador
Administrador


Sexo: Sexo:Hombre
Registrado: 24 Jan 2011
Mensajes: 5435
Estado: Offline
MensajePublicado: Wed Nov 21, 2012 4:32 pm    Título del mensaje: Responder citando

¿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 Evil

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í.
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
tchusami



Sexo: Sexo:Hombre
Registrado: 29 Jan 2011
Edad: 25
Mensajes: 86
Ubicación: Librilla
Estado: Offline
MensajePublicado: Wed Nov 21, 2012 4:43 pm    Título del mensaje: Responder citando

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor
tchusami



Sexo: Sexo:Hombre
Registrado: 29 Jan 2011
Edad: 25
Mensajes: 86
Ubicación: Librilla
Estado: Offline
MensajePublicado: Fri Nov 23, 2012 11:11 pm    Título del mensaje: Responder citando

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.
Volver arriba
Ver perfil del usuario Enviar mensaje privado [ Oculto ] Visitar sitio web del autor
CUE
Administrador
Administrador


Sexo: Sexo:Hombre
Registrado: 24 Jan 2011
Mensajes: 5435
Estado: Offline
MensajePublicado: Sat Nov 24, 2012 11:05 am    Título del mensaje: Responder citando

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
Volver arriba
Ver perfil del usuario Enviar mensaje privado  
Mostrar mensajes anteriores:   
Publicar Nuevo Tema   Responder al Tema    Romxhacking -> Dudas y Preguntas Todas las horas están en GMT + 1 Hora
Página 1 de 1

 
Saltar a:  
No puede crear mensajes
No puede responder temas
No puede editar sus mensajes
No puede borrar sus mensajes
No puede votar en encuestas

Temas Relacionados
 Temas   Respuestas   Autor   Lecturas   Último Mensaje 
No hay mensajes nuevos Se puede editar algo del Legend of heroes trails in the sky? 1 gadesx 1629 Thu Apr 16, 2015 8:08 pm
CUE Ver último mensaje
No hay mensajes nuevos ¿Este programa puede servir para algo? 2 gadesx 2078 Sat Sep 21, 2013 8:22 am
CUE Ver último mensaje
No hay mensajes nuevos Algo para este "formato"? 3 cralso 2354 Tue Aug 20, 2013 7:53 am
CUE Ver último mensaje
No hay mensajes nuevos Light Crusader o algo 10 gadesx 4176 Sun Aug 04, 2013 1:07 pm
Auron Ver último mensaje
No hay mensajes nuevos Monolith Soft, hay que seguir a esta gente 6 gadesx 4538 Fri Oct 14, 2011 7:07 pm
Gryphus-X Ver último mensaje
 


Crear foro gratis - Powered by phpBB © 2001, 2005 phpBB Group
subRebel style by ktauber