CelticFrostie
Sexador de pollos
Visto que han habido varias gentes que me ha pedido esta tutoguía pesar de haber una maravillosa de mi querido @Cheve_X, procederé a explicaros TODO lo relativo al sistema hexadecimal, (ya que pocos lo explican y nunca se le da la importancia necesaria o se le tiene miedo) y a sus aplicaciones en el ROM hacking, tanto en la plataforma GBA, como en GBC y en NDS (por extensión).
El sistema hexadecimal, que a veces abreviamos como HEX, según la wikipedia [no sabría daros una definición técnica mejor] es el sistema de numeración posicional que tiene como base el 16.
Bien, entonces supongo que todos habréis deducido a partir de la definición anterior que el sistema decimal es el sistema de numeración posicional que tiene como base el 10.
¿Para qué fue inventado? Pues para simplificar las cosas en la informática, abarcar más datos con menos cifras, por así decirlo.
Pero por mucho que conozcáis la definición técnica, seguro que no os ha quedado demasiado claro qué es exactamente ni cómo utilizarlo.
Como dice la definición, "sistema que tiene como base el 16" en este sistema de numeración, por cada 10 números decimales, tendremos 16.
Pero, para representarlos hay que usar una especie de truquillo. ¿Por qué? Por que si para los números del 10 al 16 (o mejor dicho, del 10 al 15, porque en informática, [que es para lo que se inventó éste sistema], el 0 siempre es el primer número) usamos 2 carácteres, no simplificaríamos nada.
Quiero decir que el uso de 2 carácteres, complicaría todo y convertiría al sistema hexadecimal en algo aún menos práctico que el sistema decimal.
¿Y qué narices de caracteres utilizamos para esos números del 10 al 15? Pues tendremos que usar algo sencillo (que no ocupe más de 1 carácter) y fácil de recordar.
¡Exacto! Usaremos letras.
Pues bien, ahora que ya está todo claro, dejaré de liarla y pasaré a poner las correspondencias de cada número en decimal con cada número carácter en hexadecimal.
Iremos de 0 a 15, ya que como dije y repetí, esos son realmente los 16 primeros números. Recordad, SIEMPRE empezamos por el 0, y, si os fijáis, del 0 al 15 son 16 números, como del 0 al 9 son 10.
Y tú dirás...
- Pero espera, espera... ¿Y después de F cómo seguimos?
- Tranquilo, es muchísimo más sencillo de lo que seguramente estés pensando. De F pasamos a 10, 11, 12, [...], 19, 1A, 1B, 1C, 1D, 1E, 1F, 20... ¿Tiene sentido, no?
Y así sucesivamente, haya el número de cifras a la izquierda que haya. De FF pasamos a 100, de FFF a 1000, etcétera.
Un dato muy importante que debéis saber es que cada vez que un número lleva un 0x delante, significa que está en HEX. No tiene por qué llevarlo (por ejemplo en Advance Map no aparece, y así ocurren problemas de confusiones con los minis, pero bueno, eso ya es cosa de los desarrolladores), pero otras herramientas, como el XSE trabajan con ello constantemente.
Por ejemplo, scripteando, setflag 0xFF será completamente equivalente a setflag 255.
Las conversiones. Esto es algo que, como ROM hackers, tendréis que hacer infinidad de veces: al scriptear, trabajar con herramientas como FSF y UNLZ... Y que podéis hacer con la calculadora de Windows, del XSE, del NSE o incluso online. Pero si le queréis ver el sentido, aquí tenéis unas imágenes que os explican un poco por encima cómo hacerlo:
- Paso de decimal a hexadecimal. Es muy simple:
- Paso de hexadecimal a decimal. Más simple aún:
Bueno, pues todos esos numeritos y letras preciosas de los que os he hablado funcionarán de alguna manera en la informática, ¿no?
Para explicar esto, debemos de irnos a un sistema mucho más simple que el hexadecimal, el decimal y la madre que los hizo a todos: el binario.
Como indica el nombre (o eso parece), el binario es un sistema numérico que tiene como base el 2, es decir, sólo muestra 2 cifras/estados diferentes y a partir de ahí va formando combinaciones de éstas para expresar distintos estados.
Y, como dije al principio, en informática los números siempre comienzan en el 0. Entonces, ¿cuáles serán 2 las cifras que usa el sistema binario y combina para formar lo que le de la gana? Exacto, el 0 y el 1.
Sólamente el 0 y el 1, sí. Son dos.
¿Pero por qué os hablo del sistema binario sabiendo que para el ROM hacking (o por lo menos lo que hacemos aquí) no nos hará falta? Pues porque es el sistema base, el que contiene a las unidades mínimas de la informática, el que usa la máquina para distinguir 2 únicos estados: 0 = apagado, 1 = encendido. (metáfora)
Y bit es como se llama la dichosa unidad mínima de éste sistema. Sí, la unidad mínima, la base de toda la informática.
Un ejemplo de bit:
0
Podía haber puesto 1 también, y no tendríamos más ejemplos diferentes. ¿Fácil, no? Una cifra con un valor o otro. Pero para representar un rango más amplio de valores, y que no indiquen solo que algo está x/y (como en la simplificación de la realidad que puse antes: encendido/apagado) estos bits se arrejuntan en grupos de 8, formando bytes.
Si elevamos 16 al número de cifras de un número hexadecimal nos daba el número de valores diferentes (en decimal) que toma ese número, ¿no?
Pues en el sistema binario ocurre exactamente lo mismo, y como hemos dicho que los bytes son grupos de 8 bits, y el binario es un sistema en base de 2 valores, ¿qué debemos hacer para conocer el número de valores de un byte?
Exacto; 2 elevado a 8, y eso hacen... ¡256 valores! (recordad, de 0 a 255).
Ejemplos de bytes en binario:
11111111 (255)
00000000 (0)
01011001 (89) (en homenaje a ayreon *-*)
Pero, como ya comenté, el sistema binario sólo le es útil a la máquina (procesador), en nuestra ROM no trabajaremos con los bytes en este sistema, si no en hexadecimal.
¿Y en 16 elevado a 2 no es 256 también? Entonces, ¿cuántas cifras tendrá un byte en hexadecimal? Sí, ¡2! Mirad qué simple... Y los valores de 0 a 255, ¿en hexadecimal de dónde a dónde irán?
¡Pues claro! De 00 a FF.
Y bien, como creo que ya he dicho, un byte encierra una serie de valores que indican una propiedad, las características de algo determinado o constituyen un sistema...
Ejemplos: Puede ser desde una imagen comprimida como el valor de algo concreto (por ejemplo; la amistad de un Pokémon [amistad FF=máxima=255]).
Cierto es que, estos bytes también podemos agruparlos en halfwords, words y dwords. (No confundir con las unidades de tamaño que explicaré después) Es bastante simple:
- Las halfwords son grupos de 2 bytes (16 bits). En el ROM Hacking, cada variable está asignada a una halfword, al igual que las flags y los valores que puede tomar una variable. De 0 (0000) a FFFF.
Esto quiere decir que hay 65536 variables diferentes (en decimal, de la 0 a la 65535), que hay las mismas flags y que las variables pueden tomar ese número de valores diferentes.
Fijaos en la cantidad de valores que puede adquirir una variable, eh?
- Las words son grupos de 4 bytes (32 bits). En el ROM Hacking, cada offset (si no lo sabéis, ya os explicaré con detenimiento qué es un offset, pero básicamente es un dirección en la que se almacena algo en el cartucho/.gba) tiene asignada una word. Y diréis... Que yo sepa la ROM va de 000000 a FFFFFF, (a no ser que la expandas), que son grupos de 3 bytes...
Pues no. ¿Nunca os habéis fijado en que muchos romhackers, para hablar de una dirección en la ROM (por ejemplo, 37D255) le ponen un 08 delante, quedando 0837D255?
- ¡¡¡ES VERDAD!!! ¿Por qué 08? ¿¿Por qué 08?? ¿¿¿POR QUÉ EL MALDITO 08???
- Tranquilo, no te sulfures. Ahora le daré sentido a tu vida... Llamémosle prefijos a ese numerito de delante a partir de ahora, ¿vale?
En el prefijo 08 (y en el 09 al exceder los 16 MB/al expandir ROMs en GBA, esto quiere decir si queremos buscar/llamar/lo que sea a una dirección más adelante de FFFFFF, pasaremos a poner un 09 delante en vez de un 08) es donde se encuentra la ROM. La read only memory.
Sí, lo que irónicamente (para nosotros), a pesar de llamarse "memoria de sólo lectura" aparece al abrir tu juego con cualquier editor hexadecimal (HxD por ejemplo) y puedes editar con él.
- ¿Pero entonces habrá algo detrás, no? ¿07, 06, 05, 04, 03, 02, 01 y 00 a qué corresponden?
- Buena pregunta. El "cartucho", el .gba, obviamente, tiene más cosas aparte de lo que viene siendo el juego en sí, la maldita ROM. Cosas que permiten que se pueda guardar la partida, que la pantalla se vea de cierta manera, que se puedan crear cheat codes y gamesharks...
En fin, metafóricamente hablando, la ROM sería el corazón del juego y el resto, (prefijos de 00 a 07) el cerebro.
Entonces, haré un esquema para marcar qué hay en cada lugar (recordad que es una word, 3 bytes mas los dichosos prefijos):
También repetir, por si no ha quedado claro, que el prefijo 08 sólo incluye 16 MB, es decir, bytes de 000000 a FFFFFF. A partir de 1000000 y hasta FFFFFFF (nótense los 7 carácteres), estaremos hablando de ROMs expandidas (GBA).
En la GBA, se dice que es imposible utilizar el espacio más allá de 1FFFFFF (32 MB) así que realmente, el FFFFFFF sobrepasa el límite útil del ROM.
Curiosidad: Y si sabéis de scripting avanzado, aparte del tema que comenté sobre la I/O os habréis fijado que todas las direcciones a las que se hace WBTO para editar los atributos de algunas cosas, tienen la siguiente estructura: 02xxxxxx/03xxxxxx
Esto es debido a que mediante el WBTO estamos jugando con datos de la RAM, así que ya sabéis, nunca, NUNCA pretendáis editar algo de la ROM mediante WBTO porque vais listos.
Eh... Bueno... Volvamos al tema que me he ido por las ramas... A pesar de ello habréis aprendido algo, ¿no?
- Las DWords (double-words) no os harán falta en el ROM Hacking (orientado a las plataformas con las que trabajamos aquí), pero por cultura general os puedo decir que son grupos de 8 bytes (64 bits).
Nota: Como estas unidades no están especificadas ni marcadas en ningún lado, hay gente que considera la Word a partir de 2 bytes, la DWord 4 y llama QWord al conjunto de 8 bytes. Pero el sistema que os he puesto yo es el más utilizado.
(Gracias a @BLAx301!-HSG- por comentármelo)
Supongo que esto lo sabréis todos, pero nunca está de más explicarlo.
En fin, dijimos que los bits eran las unidades mínimas, y que 8 de ellos formaban un Byte. Pues bien, los bytes también pueden formar unidades más grandes, enormes, colosales... Que todos conocéis de sobra:
1024 bytes = 1 KB (Kilobyte)
1024576 bytes = 1024 KB = 1 MB (Megabyte)
1049165824 bytes = 1024576 KB = 1024 MB = 1 GB (Gigabyte)
Como podéis ver, para pasar de una a otra multiplicamos de 1024 en 1024. Y así, después del Gigabyte tenemos el Terabyte (TB), el Petabyte (PB), el Exabyte (EB)...
Eh! Olvidaba que estábamos trabajando con pequeños juegos... Tranquilos, con lo que trabajaremos no llegará ni al Gigabyte. Eso es todo. ¿Más que simple, verdad?
Pero... Cada uno de los datos del cartucho/.gba, (pueda editarse, leerse o no, eso no nos importa ahora), se encontrará en algún lugar, ¿no? En efecto, aunque algunos datos se mueven de lugar (por ejemplo, ciertas cosas en la RAM son dinámicas), todo con lo que vamos a trabajar tiene una dirección asignada. Y esa dirección tiene un nombre: un offset.
Por ejemplo, la data de las teclas que pulsas de las que os hablé antes (en los registros de entrada y salida) están situadas en el offset 04000130.
Esa "data interna" de cada offset nosotros no la podremos manejar, es manejada por el procesador de la GBA/Emulador.
Si abrimos con el HxD nuestra ROM (virgen) Pokémon Ruby, Zafiro, Fire Red, Leaf Green o Emerald, podremos ver que hay unas columnas a la izquierda, horizontales, que empiezan en 000000 y terminan en FFFFFF. Combinándolas con las columnas verticales, tendremos una tabla preciosa con todos los offsets a los que podemos acceder en nuestra ROM.
Pero algunos de estos offsets no señalan la información directamente, también pueden apuntar a otros offsets, es decir, "contienen" otro offset para utilizar su información de alguna manera. Estos son los punteros de un offset, y siempre se encuentran de forma permutada.
Por ejemplo, necesitamos el puntero a una paleta que se encuentra en 3450BB en la ROM. Para hallarlo, debemos dividir el offset de la paleta de byte en byte (grupos de 2 cifras), añadir el 08 que nos indica que se encuentra en la ROM, y cambiamos la posición de estos bytes de izquierda a derecha, nos quedaría:
BB 50 34 08
Es importante que sepáis esto por que es terminología básica y lo podréis necesitar en cualquier momento, no os voy a poner un ejemplo de dónde se utiliza exactamente porque os liaría mucho más. Recordad que se permutan (se leen de derecha a izquierda) bytes, no dígitos.
Seguramente muchos habréis oído hablar de repuntear en este foro. Repuntear un sprite, cualquier gráfico, por ejemplo. Sí, muy bonito, ¿y qué narices es eso?
Es simple. Repuntear consiste en cambiar un puntero de lugar. Necesitaremos repuntear datos cuando éstos que insertamos son de mayor tamaño (más bytes) que la data original. Por ejemplo, si el sprite del prota ocupa un lugar de 300 bytes y queremos insertar uno que comprimido ocuparía 400 bytes, tendríamos que buscar un puntero nuevo para el sprite nuevo, ya que si no sobrescribiríamos 100 bytes extra que no tienen nada que ver con el sprite, con lo que nos arriesgaríamos a corromper nuestra ROM.
Ahora ya sabéis que cuando la herramienta UNLZ.GBA os avisa al intentar insertar algo de que "Compressed size is too long, aborting", significa que tenéis que buscar una dirección vacía lo suficientemente "extensa" donde quepa el gráfico que queremos insertar.
Probablemente muchas veces habréis oído decir cosas como: "he expandido la tabla de nosequé", "para repuntear esto otro tienes que buscar su tabla..." Sí, sí, pero ¿qué es exactamente una tabla?
Una tabla es una especie de lista en la ROM donde se encuentran todos los punteros a una lista real de algo determinado, por ejemplo, los Background de Batalla.
Como he dicho, las tablas son listas de punteros a ciertas direcciones (en la ROM obviamente, por tanto, 08 al final),, por lo que suelen tener la siguiente forma:
Más adelante os hablaré más a fondo de esto y explicaré cómo buscar tablas.
Un header (cabecera en español) es un grupo de bytes que forma una estructura determinada que controla cualquier cosa de nuestra ROM. Un ejemplo es el header de los tilesets:
[Gráficos, 3 bytes][Data del bloque, 3 bytes][Collision/effect data, 3 bytes][Animaciones, 2 bytes][00 00 (inutilizados), 2 bytes][Data de las paletas, 2 bytes]
Esto no tenéis por qué entenderlo, pero es útil que por lo menos sepáis qué es por si alguna vez os hablan/leéis sobre ello.
Nota: En esta sección hablaremos de direcciones en la ROM, es decir, con un 08 ó 09 delante, así que me ahorraré especificarlo.
Y todo este rollo del que os he hablado... ROMs, bytes, offsets, punteros, tablas... Tendremos que tocarlo físicamente, aunque sea para ver cómo es, ¿no? ¿Si no de qué os sirve (la mayoría) de lo que os he enseñado?
Bien, vale. Y... ¿con qué herramienta(s} lo hacemos?
Pues a mí, personalmente, HxD me parece la mejor herramienta para toquetear vuestra ROM hexadecimalmente hablando. Los hackers GBC suelen usar más Gold Finger, aunque yo no sé por qué así que si queréis saberlo preguntadle a @Chamber o a @Gallego13 xD
Vamos a comenzar descargando la herramienta, lo primero de todo. Podéis hacerlo aquí
Una vez descargada, OBVIAMENTE, la abrimos (sabéis cómo abrir archivos, ¿no?):
Bien, una vez abierta, seleccionáis abrir o pulsáis Ctrl+O y seleccionáis una PokéROM de GBA, GBC o NDS cualquiera (aunque con esta herramienta podéis editar la estructura de cualquier archivo existente, pero eso ahora no nos interesa).
Yo he elegido Pokémon Emerald (U). Veréis esto (o algo similar si no elegís la misma ROM que yo (?)):
Como veis, los bytes no van de uno en uno, (una sola columna) si no sería un auténtico coñazo moverse por este programa. Las filas contienen los bytes en las columnas, de 0 a F (en HEX), por tanto, van de 16 en 16 bytes (DEC y si contamos el 0). Las columnas, obviamente, si las filas van de 16 en 16, son 16, de 0 a F.
Veamos un ejemplo para que entendáis mi complicada manera de explicarme: ¿Cuál será el byte 2A?
Exactamente, es el que está en la fila 00000020 + en la columna A. Recordad, 0A es simplemente A, no os liéis.
Otra cosa: Si no os gusta esta disposición, podéis cambiarla con ésto:
Una vez entramos ahí, ponéis en DECIMAL el número de columnas que queráis ver. Obviamente, si ponemos 32, a partir de ahora las columnas irán de 32 en 32 bytes (DEC), osea, de 0 a 1F, y la siguiente columna comenzará en 20.
Lo que sí, mejor que no os compliquéis, el mejor sistema para trabajar con la ROM es el de 16 columnas de bytes. Y, haciendo clic en Offset (h), podéis ver la posición de cada byte en decimal o en octal, pero bueno, tampoco os lo recomiendo. Mejor dejarlo todo como está, sí, pero lo digo por curiosidad y por si hay algún experto rarito que no sabía esto.
En decimal, las filas y columnas se verían como en la siguiente imagen:
Vale, basta de chorradas estéticas, ahora vamos a ver lo que podemos hacer (de utilidad en el ROM Hacking, claro) con este programa, opción a opción.
Eh! espera, ¿qué son esos carácteres colocados sin ningún sentido aparente, a la derecha?
Realmente no es importante. Simplemente, es el carácter que corresponde a cada byte en el código ANSI (por default, aunque podéis cambiarlo a ASCII, etc.) que le corresponde a cada carácter, no nos sirve para el RH. Por ello, no lo toquéis.
(A no ser que os sepáis las correspondencias y lo que estáis haciendo, claro)
Bien, como dije, vamos a ver lo que podemos hacer con esta poderosísima herramienta.
Para empezar, en el menú Archivo creo que no hay nada que explicar, sólo especificar que la opción que tengo seleccionada (Exportar) no nos sirve para nada de lo que vamos a hacer romhackeando, así que pasad de ella.
Vale, ahora pasemos a la pestaña de Edición (aparece también al hacer click derecho sobre cualquier byte). Se nos desplegarán varias opciones, la mayoría de ellas sólo estarán disponibles cuando seleccionemos uno o varios bytes (clic izquierdo y cursor adelante):
Deshacer: Sólo funciona cuando hacemos algún cambio en el archivo (esc. Para cambiar uno o varios bytes por otro, escribís encima de él. Importante, si es sólo un dígito, poned un byte delante. Por ejemplo: para cambiar 00 por C deberemos escribir 0C, de lo contrario habremos puesto C0 que no tiene nada que ver. Esto parece obvio pero conozco a quien ha cometido fails graves por no fijarse en ésto (;
Por cierto, cualquier cambio que hagáis en la ROM/archivo, se marcará en rojo hasta que sea guardado, como en la imagen:
Una vez guardado el archivo después de hacer cualquier cambio, éstos no son reversibles de ninguna manera.
Cortar: Nos cargamos el bloque de bytes que hayamos seleccionado, pero además lo copiamos. Es importante saber que cuando cortamos disminuye el tamaño del archivo, es decir, si cortamos 10 bytes en un archivo de 100, el archivo ocupará 90. Obvio, ¿no?
Copiar: Copia el bloque de bytes que hayamos seleccionado.
Pegar insertando (Ctrl+V): NO LO UTILICÉIS NUNCA en el medio de vuestra ROM, expanderéis el archivo y por tanto cambiaréis de posición los datos que haya delante de donde habéis copiado. Es decir, os cargáis vuestra ROM. De todas formas este cuadro de diálogo os avisará:
Es conveniente que no marquéis nunca el "No preguntar otra vez", por si alguna vez os equivocáis.
Pegar escribiendo: Pega, literalmente, ENCIMA, de donde tengas el cursor, es decir, sobreescribe.
Borrar: Como cortar, reduce el tamaño del archivo, sólo que no copia nada.
Insertar bytes: Aumenta el tamaño del archivo. Podéis ver cómo hacerlo con este tutorial, aunque voy a explicarlo yo también.
Cantidad: Obviamente, la cantidad de bytes que queremos insertar. En decimal SIEMPRE.
Patrón de Relleno: Para que programas como el FSF reconozcan espacios libres, deben ser valores hexadecimales FF. Los 00 dan problemas (cosa que no comenta el tutorial al que os linkeé)
Recordad que para aumentar el espacio de nuestra ROM siempre debemos ir con el cursor al último byte, de lo contrario sobreescribiremos datos y corromperemos el archivo.
Fin del tutorial (?)
Seleccionar Bloque: Selecciona un grupo de bytes de un offset determinado a otro. MUY útil.
Seleccionar todo: La verdad no sé para qué sirve esto(?)
Vámonos a la pestaña de Búsqueda...:
Buscar: Bueno, esto es de lo más útil que puede tener el HxD.
Antes de nada, aclaro que las opciones Todo, Adelante y Atrás nos sirven por si queremos buscar valores hexadecimales en cualquier lugar de la ROM, delante de donde tenemos posicionado el cursor en la tabla hexadecimal de nuestra ROM o detrás, respectivamente. Función útil para no perderse.
La opción "Cadena de Texto" nos sirve para buscar fragmentos de aquella columnita de texto en la que se encontraban varios carácteres sin sentido. No nos va a servir para mucho, pero para que lo sepáis (otra vez...)
Y las pestañas número entero y número de punto flotante nunca las he usado, y tampoco creo que nos sean de utilidad. Así que vámonos a valores hexadecimales:
Ahora, ¡ojo! con esta maravillosa opción no buscaremos offsets, si no algo mucho mejor: ¡Bytes dentro de la ROM! Es decir, si queremos encontrar donde se encuentra el puntero a algo, sólo basta con poner permutado el offset de eso que queremos buscar y voilà!
Por ejemplo, para buscar el puntero a un sprite que inserté en 850000, en el cuadro de búsqueda pondré 00 00 85 08 y...
¡Aquí lo tenemos! En el offset 4AB584. ¿Veis qué maravilla?
Y con esto, también podremos buscar las tablas de las que hablaba antes. Aquí viene otro...
Por ejemplo, yo voy a buscar la tabla de canciones de Pokémon Emerald. Según Sappy, la tabla...
...se encuentra en el offset 6B49F0.
Ahora vamos a utilizar el header de la canción que tengo seleccionada (que es el offset en el que se encuentra toda la "data" de la midi) y...
En efecto, hemos permutado el offset del header y ahora vamos a buscarlo. Nos encontraremos aquí:
Sí, ¿y qué forma tiene este conjunto de bytes? ¡Exactamente! La de una tabla, como os enseñé antes. Ahora sólo nos queda subir hasta el principio. Y ahí, no tiene pérdida, donde la estructura de tabla se deforma y deja de haber XX XX XX 08, tenemos el inicio de nuestra tabla, es decir, lo que es interpretado como nuestra tabla. En 6B49F0:
Bueno, ahora ya sabéis como buscar tablas para expandirlas, repuntearlas y cambiarlas de lugar, ver su expansión o simplemente entender de qué se habla cuando se habla de ello.
Ahora sí, continuemos con las pestañas. En las pestañas Ver, Ventanas y ? tenemos chorradas estéticas/inútiles (como lo que enseñé más arriba sobre el número de columnas) que ya investigaréis por vosotros mismos. La pestaña Extras es peligrosa, así que ni tocarla xD
Perfecto, vayámonos a Análisis. Aquí lo único que nos interesa (y tanto), es el glorioso Comparar Archivos. Este pequeño gadget os servirá de mucho, os lo aseguro.
Aquí va un ejemplo de cómo funciona:
Coged una PokéROM cualquiera, preferiblemente limpia y de plataforma GBA. Yo usaré la Emerald (U) que he estado usando en el resto del tutorial. Hacedle una copia, sin tocarla, y pegadla en la misma carpeta en la que tenéis la original. Cambiad cualquier cosa en la copia, preferiblemente un cambio pequeño desde Advance Map. Por ejemplo, yo cambiaré el clima de Villa Raíz a Tormenta.
Como podéis ver en la imagen, el byte del clima de Villa Raíz en la ROM original es 02 (clima normal) mientras que en la copia editada, es 05. Tormenta. Comprobemos si hay más diferencias con "diferencia siguiente". ¿No? Perfecto, ahora ya sabemos que los datos del clima de un mapa sólo vienen definidos por UN byte y que esa data climática del Mapa principal de Villa Raíz está en el offset 737288.
Quizás no os parezca muy útil al verlo en este ejemplo tan simple, pero que sepáis que esto os puede servir para encontrar cosas tan maravillosas como el offset de cualquier tontería que no encontráis en ningún lado o incluso para solucionar bugs/errores de cualquier tipo... Todo es cuestión de acordarse de las utilidades de esta herramienta nada más tener cualquier problema y sacarle el máximo partido.
En fin, quizás continúe con más extras y trucos próximamente, y jugar con el CSS y hacerlo bonito, pero por ahora, hemos finalizado. Espero que a pesar de lo que me he liado y las paranoias que os he contado valoréis lo que me he tomado en hacer el tuto xDD, (que no es una materia fácil de explicar y me ha llevado un mes aproximadamente) y sobre todo, que os valga.
Gracias a @BLAx301!-HSG- por hacerme de tutotester, corrector hortojrháfico y esa shit (;
Y ya sabéis, cualquier duda que tengáis, aquí abajo, por MP o mi perfil
INTRODUCCIÓN: ¿Qué es el sistema hexadecimal y para qué sirve?
El sistema hexadecimal, que a veces abreviamos como HEX, según la wikipedia [no sabría daros una definición técnica mejor] es el sistema de numeración posicional que tiene como base el 16.
Bien, entonces supongo que todos habréis deducido a partir de la definición anterior que el sistema decimal es el sistema de numeración posicional que tiene como base el 10.
¿Para qué fue inventado? Pues para simplificar las cosas en la informática, abarcar más datos con menos cifras, por así decirlo.
Pero por mucho que conozcáis la definición técnica, seguro que no os ha quedado demasiado claro qué es exactamente ni cómo utilizarlo.
Como dice la definición, "sistema que tiene como base el 16" en este sistema de numeración, por cada 10 números decimales, tendremos 16.
Pero, para representarlos hay que usar una especie de truquillo. ¿Por qué? Por que si para los números del 10 al 16 (o mejor dicho, del 10 al 15, porque en informática, [que es para lo que se inventó éste sistema], el 0 siempre es el primer número) usamos 2 carácteres, no simplificaríamos nada.
Quiero decir que el uso de 2 carácteres, complicaría todo y convertiría al sistema hexadecimal en algo aún menos práctico que el sistema decimal.
¿Y qué narices de caracteres utilizamos para esos números del 10 al 15? Pues tendremos que usar algo sencillo (que no ocupe más de 1 carácter) y fácil de recordar.
¡Exacto! Usaremos letras.
Pues bien, ahora que ya está todo claro, dejaré de liarla y pasaré a poner las correspondencias de cada número en decimal con cada número carácter en hexadecimal.
Iremos de 0 a 15, ya que como dije y repetí, esos son realmente los 16 primeros números. Recordad, SIEMPRE empezamos por el 0, y, si os fijáis, del 0 al 15 son 16 números, como del 0 al 9 son 10.
Decimal
Hexadecimal
0
0
1
1
2
2
3
3
4
4
5
5
6
6
7
7
8
8
9
9
10
A
11
B
12
C
13
D
14
E
15
F
Y tú dirás...
- Pero espera, espera... ¿Y después de F cómo seguimos?
- Tranquilo, es muchísimo más sencillo de lo que seguramente estés pensando. De F pasamos a 10, 11, 12, [...], 19, 1A, 1B, 1C, 1D, 1E, 1F, 20... ¿Tiene sentido, no?
Y así sucesivamente, haya el número de cifras a la izquierda que haya. De FF pasamos a 100, de FFF a 1000, etcétera.
¡OJO!: Sobre el 0x
Un dato muy importante que debéis saber es que cada vez que un número lleva un 0x delante, significa que está en HEX. No tiene por qué llevarlo (por ejemplo en Advance Map no aparece, y así ocurren problemas de confusiones con los minis, pero bueno, eso ya es cosa de los desarrolladores), pero otras herramientas, como el XSE trabajan con ello constantemente.
Por ejemplo, scripteando, setflag 0xFF será completamente equivalente a setflag 255.
LO BÁSICO: Convirtiendo de decimal a hexadecimal y viceversa
Las conversiones. Esto es algo que, como ROM hackers, tendréis que hacer infinidad de veces: al scriptear, trabajar con herramientas como FSF y UNLZ... Y que podéis hacer con la calculadora de Windows, del XSE, del NSE o incluso online. Pero si le queréis ver el sentido, aquí tenéis unas imágenes que os explican un poco por encima cómo hacerlo:
- Paso de decimal a hexadecimal. Es muy simple:
- Paso de hexadecimal a decimal. Más simple aún:
TERMINOLOGÍA DE ESTRUCTURACIÓN HEXADECIMAL: Del Bit a la DWord
Bueno, pues todos esos numeritos y letras preciosas de los que os he hablado funcionarán de alguna manera en la informática, ¿no?
Para explicar esto, debemos de irnos a un sistema mucho más simple que el hexadecimal, el decimal y la madre que los hizo a todos: el binario.
Como indica el nombre (o eso parece), el binario es un sistema numérico que tiene como base el 2, es decir, sólo muestra 2 cifras/estados diferentes y a partir de ahí va formando combinaciones de éstas para expresar distintos estados.
Y, como dije al principio, en informática los números siempre comienzan en el 0. Entonces, ¿cuáles serán 2 las cifras que usa el sistema binario y combina para formar lo que le de la gana? Exacto, el 0 y el 1.
Sólamente el 0 y el 1, sí. Son dos.
¿Pero por qué os hablo del sistema binario sabiendo que para el ROM hacking (o por lo menos lo que hacemos aquí) no nos hará falta? Pues porque es el sistema base, el que contiene a las unidades mínimas de la informática, el que usa la máquina para distinguir 2 únicos estados: 0 = apagado, 1 = encendido. (metáfora)
Y bit es como se llama la dichosa unidad mínima de éste sistema. Sí, la unidad mínima, la base de toda la informática.
Un ejemplo de bit:
0
Podía haber puesto 1 también, y no tendríamos más ejemplos diferentes. ¿Fácil, no? Una cifra con un valor o otro. Pero para representar un rango más amplio de valores, y que no indiquen solo que algo está x/y (como en la simplificación de la realidad que puse antes: encendido/apagado) estos bits se arrejuntan en grupos de 8, formando bytes.
Si elevamos 16 al número de cifras de un número hexadecimal nos daba el número de valores diferentes (en decimal) que toma ese número, ¿no?
Pues en el sistema binario ocurre exactamente lo mismo, y como hemos dicho que los bytes son grupos de 8 bits, y el binario es un sistema en base de 2 valores, ¿qué debemos hacer para conocer el número de valores de un byte?
Exacto; 2 elevado a 8, y eso hacen... ¡256 valores! (recordad, de 0 a 255).
Ejemplos de bytes en binario:
11111111 (255)
00000000 (0)
01011001 (89) (en homenaje a ayreon *-*)
Pero, como ya comenté, el sistema binario sólo le es útil a la máquina (procesador), en nuestra ROM no trabajaremos con los bytes en este sistema, si no en hexadecimal.
¿Y en 16 elevado a 2 no es 256 también? Entonces, ¿cuántas cifras tendrá un byte en hexadecimal? Sí, ¡2! Mirad qué simple... Y los valores de 0 a 255, ¿en hexadecimal de dónde a dónde irán?
¡Pues claro! De 00 a FF.
Y bien, como creo que ya he dicho, un byte encierra una serie de valores que indican una propiedad, las características de algo determinado o constituyen un sistema...
Ejemplos: Puede ser desde una imagen comprimida como el valor de algo concreto (por ejemplo; la amistad de un Pokémon [amistad FF=máxima=255]).
Agrupaciones de bytes
Cierto es que, estos bytes también podemos agruparlos en halfwords, words y dwords. (No confundir con las unidades de tamaño que explicaré después) Es bastante simple:
- Las halfwords son grupos de 2 bytes (16 bits). En el ROM Hacking, cada variable está asignada a una halfword, al igual que las flags y los valores que puede tomar una variable. De 0 (0000) a FFFF.
Esto quiere decir que hay 65536 variables diferentes (en decimal, de la 0 a la 65535), que hay las mismas flags y que las variables pueden tomar ese número de valores diferentes.
Fijaos en la cantidad de valores que puede adquirir una variable, eh?
- Las words son grupos de 4 bytes (32 bits). En el ROM Hacking, cada offset (si no lo sabéis, ya os explicaré con detenimiento qué es un offset, pero básicamente es un dirección en la que se almacena algo en el cartucho/.gba) tiene asignada una word. Y diréis... Que yo sepa la ROM va de 000000 a FFFFFF, (a no ser que la expandas), que son grupos de 3 bytes...
Pues no. ¿Nunca os habéis fijado en que muchos romhackers, para hablar de una dirección en la ROM (por ejemplo, 37D255) le ponen un 08 delante, quedando 0837D255?
- ¡¡¡ES VERDAD!!! ¿Por qué 08? ¿¿Por qué 08?? ¿¿¿POR QUÉ EL MALDITO 08???
- Tranquilo, no te sulfures. Ahora le daré sentido a tu vida... Llamémosle prefijos a ese numerito de delante a partir de ahora, ¿vale?
En el prefijo 08 (y en el 09 al exceder los 16 MB/al expandir ROMs en GBA, esto quiere decir si queremos buscar/llamar/lo que sea a una dirección más adelante de FFFFFF, pasaremos a poner un 09 delante en vez de un 08) es donde se encuentra la ROM. La read only memory.
Sí, lo que irónicamente (para nosotros), a pesar de llamarse "memoria de sólo lectura" aparece al abrir tu juego con cualquier editor hexadecimal (HxD por ejemplo) y puedes editar con él.
- ¿Pero entonces habrá algo detrás, no? ¿07, 06, 05, 04, 03, 02, 01 y 00 a qué corresponden?
- Buena pregunta. El "cartucho", el .gba, obviamente, tiene más cosas aparte de lo que viene siendo el juego en sí, la maldita ROM. Cosas que permiten que se pueda guardar la partida, que la pantalla se vea de cierta manera, que se puedan crear cheat codes y gamesharks...
En fin, metafóricamente hablando, la ROM sería el corazón del juego y el resto, (prefijos de 00 a 07) el cerebro.
Entonces, haré un esquema para marcar qué hay en cada lugar (recordad que es una word, 3 bytes mas los dichosos prefijos):
- 00xxxxxx > La BIOS del cartucho.
- 01xxxxxx > ¿?
- 02xxxxxx > Working RAM. (WRAM)
Aquí se encuentra todo lo relacionado con la RAM (memoria de acceso aleatorio) "principal" del juego (hay otros tipos de RAM en el cartucho que controlan otras cosas, por así decirlo).
Se puede leer y escribir en ella en cualquier momento, no es de sólo lectura como la ROM (aunque nosotros no hagamos caso a eso, por ello nos llamamos ROM hackers xD).
Jugando con la RAM podemos editar casi cualquier dato de nuestro archivo guardado (ojo, datos, no hablo de gráficos ni de cambiar la trama del juego), crear Gamesharks/cheat codes... También es aquí donde se almacenan las variables del juego, esas que utilizaremos en nuestros scripts. - 03xxxxxx > Parte de la WRAM...
- 04xxxxxx > I/O registers (registros de entrada y salida). Si sabéis de scripting avanzado os habréis fijado en que las direcciones (de 4 bytes, mantened eso siempre en mente) que empiezan por 04 son en las que se encuentran cosas tan interesantes como la data de las teclas de la Gameboy y gracias a ello podemos hacer scripts a lo @ReoNeky o @Jo7a. xD
- 05xxxxxx > Palette RAM (PRAM). Donde se encuentra la "data interna" de las paletas.
- 06xxxxxx > Video RAM (VRAM). Se deduce por el nombre que sin esto no podríamos ver el juego en pantalla.
- 07xxxxxx > Object attribute memory (OAM). Los atributos de los OBJ, es decir, la data interna de cada NPC del juego, por así decirlo.
- 08xxxxxx/09xxxxxxx > Como dije, repetí y recalqué, os recuerdo que aquí está la ROM, los datos con los que principalmente vais a trabajar en el ROM Hacking (si no no sería ROM Hacking, claro).
También repetir, por si no ha quedado claro, que el prefijo 08 sólo incluye 16 MB, es decir, bytes de 000000 a FFFFFF. A partir de 1000000 y hasta FFFFFFF (nótense los 7 carácteres), estaremos hablando de ROMs expandidas (GBA).
En la GBA, se dice que es imposible utilizar el espacio más allá de 1FFFFFF (32 MB) así que realmente, el FFFFFFF sobrepasa el límite útil del ROM.
Curiosidad: Y si sabéis de scripting avanzado, aparte del tema que comenté sobre la I/O os habréis fijado que todas las direcciones a las que se hace WBTO para editar los atributos de algunas cosas, tienen la siguiente estructura: 02xxxxxx/03xxxxxx
Esto es debido a que mediante el WBTO estamos jugando con datos de la RAM, así que ya sabéis, nunca, NUNCA pretendáis editar algo de la ROM mediante WBTO porque vais listos.
Eh... Bueno... Volvamos al tema que me he ido por las ramas... A pesar de ello habréis aprendido algo, ¿no?
- Las DWords (double-words) no os harán falta en el ROM Hacking (orientado a las plataformas con las que trabajamos aquí), pero por cultura general os puedo decir que son grupos de 8 bytes (64 bits).
Nota: Como estas unidades no están especificadas ni marcadas en ningún lado, hay gente que considera la Word a partir de 2 bytes, la DWord 4 y llama QWord al conjunto de 8 bytes. Pero el sistema que os he puesto yo es el más utilizado.
(Gracias a @BLAx301!-HSG- por comentármelo)
UNIDADES DE TAMAÑO: Lo más simple
Supongo que esto lo sabréis todos, pero nunca está de más explicarlo.
En fin, dijimos que los bits eran las unidades mínimas, y que 8 de ellos formaban un Byte. Pues bien, los bytes también pueden formar unidades más grandes, enormes, colosales... Que todos conocéis de sobra:
1024 bytes = 1 KB (Kilobyte)
1024576 bytes = 1024 KB = 1 MB (Megabyte)
1049165824 bytes = 1024576 KB = 1024 MB = 1 GB (Gigabyte)
Como podéis ver, para pasar de una a otra multiplicamos de 1024 en 1024. Y así, después del Gigabyte tenemos el Terabyte (TB), el Petabyte (PB), el Exabyte (EB)...
Eh! Olvidaba que estábamos trabajando con pequeños juegos... Tranquilos, con lo que trabajaremos no llegará ni al Gigabyte. Eso es todo. ¿Más que simple, verdad?
TERMINOLOGÍA TÉCNICA: Entre offsets y headers
Pero... Cada uno de los datos del cartucho/.gba, (pueda editarse, leerse o no, eso no nos importa ahora), se encontrará en algún lugar, ¿no? En efecto, aunque algunos datos se mueven de lugar (por ejemplo, ciertas cosas en la RAM son dinámicas), todo con lo que vamos a trabajar tiene una dirección asignada. Y esa dirección tiene un nombre: un offset.
Por ejemplo, la data de las teclas que pulsas de las que os hablé antes (en los registros de entrada y salida) están situadas en el offset 04000130.
Esa "data interna" de cada offset nosotros no la podremos manejar, es manejada por el procesador de la GBA/Emulador.
Si abrimos con el HxD nuestra ROM (virgen) Pokémon Ruby, Zafiro, Fire Red, Leaf Green o Emerald, podremos ver que hay unas columnas a la izquierda, horizontales, que empiezan en 000000 y terminan en FFFFFF. Combinándolas con las columnas verticales, tendremos una tabla preciosa con todos los offsets a los que podemos acceder en nuestra ROM.
Pero algunos de estos offsets no señalan la información directamente, también pueden apuntar a otros offsets, es decir, "contienen" otro offset para utilizar su información de alguna manera. Estos son los punteros de un offset, y siempre se encuentran de forma permutada.
Por ejemplo, necesitamos el puntero a una paleta que se encuentra en 3450BB en la ROM. Para hallarlo, debemos dividir el offset de la paleta de byte en byte (grupos de 2 cifras), añadir el 08 que nos indica que se encuentra en la ROM, y cambiamos la posición de estos bytes de izquierda a derecha, nos quedaría:
BB 50 34 08
Es importante que sepáis esto por que es terminología básica y lo podréis necesitar en cualquier momento, no os voy a poner un ejemplo de dónde se utiliza exactamente porque os liaría mucho más. Recordad que se permutan (se leen de derecha a izquierda) bytes, no dígitos.
Repuntear
Seguramente muchos habréis oído hablar de repuntear en este foro. Repuntear un sprite, cualquier gráfico, por ejemplo. Sí, muy bonito, ¿y qué narices es eso?
Es simple. Repuntear consiste en cambiar un puntero de lugar. Necesitaremos repuntear datos cuando éstos que insertamos son de mayor tamaño (más bytes) que la data original. Por ejemplo, si el sprite del prota ocupa un lugar de 300 bytes y queremos insertar uno que comprimido ocuparía 400 bytes, tendríamos que buscar un puntero nuevo para el sprite nuevo, ya que si no sobrescribiríamos 100 bytes extra que no tienen nada que ver con el sprite, con lo que nos arriesgaríamos a corromper nuestra ROM.
Ahora ya sabéis que cuando la herramienta UNLZ.GBA os avisa al intentar insertar algo de que "Compressed size is too long, aborting", significa que tenéis que buscar una dirección vacía lo suficientemente "extensa" donde quepa el gráfico que queremos insertar.
Tabla
Probablemente muchas veces habréis oído decir cosas como: "he expandido la tabla de nosequé", "para repuntear esto otro tienes que buscar su tabla..." Sí, sí, pero ¿qué es exactamente una tabla?
Una tabla es una especie de lista en la ROM donde se encuentran todos los punteros a una lista real de algo determinado, por ejemplo, los Background de Batalla.
Como he dicho, las tablas son listas de punteros a ciertas direcciones (en la ROM obviamente, por tanto, 08 al final),, por lo que suelen tener la siguiente forma:
Más adelante os hablaré más a fondo de esto y explicaré cómo buscar tablas.
Header
Un header (cabecera en español) es un grupo de bytes que forma una estructura determinada que controla cualquier cosa de nuestra ROM. Un ejemplo es el header de los tilesets:
[Gráficos, 3 bytes][Data del bloque, 3 bytes][Collision/effect data, 3 bytes][Animaciones, 2 bytes][00 00 (inutilizados), 2 bytes][Data de las paletas, 2 bytes]
Esto no tenéis por qué entenderlo, pero es útil que por lo menos sepáis qué es por si alguna vez os hablan/leéis sobre ello.
MANEJANDO EL SISTEMA HEXADECIMAL DE FORMA PRÁCTICA: HxD y uso del HEX orientado al ROM-Hacking
Nota: En esta sección hablaremos de direcciones en la ROM, es decir, con un 08 ó 09 delante, así que me ahorraré especificarlo.
Y todo este rollo del que os he hablado... ROMs, bytes, offsets, punteros, tablas... Tendremos que tocarlo físicamente, aunque sea para ver cómo es, ¿no? ¿Si no de qué os sirve (la mayoría) de lo que os he enseñado?
Bien, vale. Y... ¿con qué herramienta(s} lo hacemos?
Pues a mí, personalmente, HxD me parece la mejor herramienta para toquetear vuestra ROM hexadecimalmente hablando. Los hackers GBC suelen usar más Gold Finger, aunque yo no sé por qué así que si queréis saberlo preguntadle a @Chamber o a @Gallego13 xD
Vamos a comenzar descargando la herramienta, lo primero de todo. Podéis hacerlo aquí
Una vez descargada, OBVIAMENTE, la abrimos (sabéis cómo abrir archivos, ¿no?):
Bien, una vez abierta, seleccionáis abrir o pulsáis Ctrl+O y seleccionáis una PokéROM de GBA, GBC o NDS cualquiera (aunque con esta herramienta podéis editar la estructura de cualquier archivo existente, pero eso ahora no nos interesa).
Yo he elegido Pokémon Emerald (U). Veréis esto (o algo similar si no elegís la misma ROM que yo (?)):
Como veis, los bytes no van de uno en uno, (una sola columna) si no sería un auténtico coñazo moverse por este programa. Las filas contienen los bytes en las columnas, de 0 a F (en HEX), por tanto, van de 16 en 16 bytes (DEC y si contamos el 0). Las columnas, obviamente, si las filas van de 16 en 16, son 16, de 0 a F.
Veamos un ejemplo para que entendáis mi complicada manera de explicarme: ¿Cuál será el byte 2A?
Exactamente, es el que está en la fila 00000020 + en la columna A. Recordad, 0A es simplemente A, no os liéis.
Otra cosa: Si no os gusta esta disposición, podéis cambiarla con ésto:
Una vez entramos ahí, ponéis en DECIMAL el número de columnas que queráis ver. Obviamente, si ponemos 32, a partir de ahora las columnas irán de 32 en 32 bytes (DEC), osea, de 0 a 1F, y la siguiente columna comenzará en 20.
Lo que sí, mejor que no os compliquéis, el mejor sistema para trabajar con la ROM es el de 16 columnas de bytes. Y, haciendo clic en Offset (h), podéis ver la posición de cada byte en decimal o en octal, pero bueno, tampoco os lo recomiendo. Mejor dejarlo todo como está, sí, pero lo digo por curiosidad y por si hay algún experto rarito que no sabía esto.
En decimal, las filas y columnas se verían como en la siguiente imagen:
Vale, basta de chorradas estéticas, ahora vamos a ver lo que podemos hacer (de utilidad en el ROM Hacking, claro) con este programa, opción a opción.
Eh! espera, ¿qué son esos carácteres colocados sin ningún sentido aparente, a la derecha?
Realmente no es importante. Simplemente, es el carácter que corresponde a cada byte en el código ANSI (por default, aunque podéis cambiarlo a ASCII, etc.) que le corresponde a cada carácter, no nos sirve para el RH. Por ello, no lo toquéis.
(A no ser que os sepáis las correspondencias y lo que estáis haciendo, claro)
Bien, como dije, vamos a ver lo que podemos hacer con esta poderosísima herramienta.
Para empezar, en el menú Archivo creo que no hay nada que explicar, sólo especificar que la opción que tengo seleccionada (Exportar) no nos sirve para nada de lo que vamos a hacer romhackeando, así que pasad de ella.
Vale, ahora pasemos a la pestaña de Edición (aparece también al hacer click derecho sobre cualquier byte). Se nos desplegarán varias opciones, la mayoría de ellas sólo estarán disponibles cuando seleccionemos uno o varios bytes (clic izquierdo y cursor adelante):
Deshacer: Sólo funciona cuando hacemos algún cambio en el archivo (esc. Para cambiar uno o varios bytes por otro, escribís encima de él. Importante, si es sólo un dígito, poned un byte delante. Por ejemplo: para cambiar 00 por C deberemos escribir 0C, de lo contrario habremos puesto C0 que no tiene nada que ver. Esto parece obvio pero conozco a quien ha cometido fails graves por no fijarse en ésto (;
Por cierto, cualquier cambio que hagáis en la ROM/archivo, se marcará en rojo hasta que sea guardado, como en la imagen:
Una vez guardado el archivo después de hacer cualquier cambio, éstos no son reversibles de ninguna manera.
Cortar: Nos cargamos el bloque de bytes que hayamos seleccionado, pero además lo copiamos. Es importante saber que cuando cortamos disminuye el tamaño del archivo, es decir, si cortamos 10 bytes en un archivo de 100, el archivo ocupará 90. Obvio, ¿no?
Copiar: Copia el bloque de bytes que hayamos seleccionado.
Pegar insertando (Ctrl+V): NO LO UTILICÉIS NUNCA en el medio de vuestra ROM, expanderéis el archivo y por tanto cambiaréis de posición los datos que haya delante de donde habéis copiado. Es decir, os cargáis vuestra ROM. De todas formas este cuadro de diálogo os avisará:
Es conveniente que no marquéis nunca el "No preguntar otra vez", por si alguna vez os equivocáis.
Pegar escribiendo: Pega, literalmente, ENCIMA, de donde tengas el cursor, es decir, sobreescribe.
Borrar: Como cortar, reduce el tamaño del archivo, sólo que no copia nada.
Insertar bytes: Aumenta el tamaño del archivo. Podéis ver cómo hacerlo con este tutorial, aunque voy a explicarlo yo también.
Tutorial exprés: Aumenta tu ROM
Cantidad: Obviamente, la cantidad de bytes que queremos insertar. En decimal SIEMPRE.
Patrón de Relleno: Para que programas como el FSF reconozcan espacios libres, deben ser valores hexadecimales FF. Los 00 dan problemas (cosa que no comenta el tutorial al que os linkeé)
Recordad que para aumentar el espacio de nuestra ROM siempre debemos ir con el cursor al último byte, de lo contrario sobreescribiremos datos y corromperemos el archivo.
Fin del tutorial (?)
Seleccionar Bloque: Selecciona un grupo de bytes de un offset determinado a otro. MUY útil.
Seleccionar todo: La verdad no sé para qué sirve esto(?)
Vámonos a la pestaña de Búsqueda...:
Buscar: Bueno, esto es de lo más útil que puede tener el HxD.
Antes de nada, aclaro que las opciones Todo, Adelante y Atrás nos sirven por si queremos buscar valores hexadecimales en cualquier lugar de la ROM, delante de donde tenemos posicionado el cursor en la tabla hexadecimal de nuestra ROM o detrás, respectivamente. Función útil para no perderse.
La opción "Cadena de Texto" nos sirve para buscar fragmentos de aquella columnita de texto en la que se encontraban varios carácteres sin sentido. No nos va a servir para mucho, pero para que lo sepáis (otra vez...)
Y las pestañas número entero y número de punto flotante nunca las he usado, y tampoco creo que nos sean de utilidad. Así que vámonos a valores hexadecimales:
Ahora, ¡ojo! con esta maravillosa opción no buscaremos offsets, si no algo mucho mejor: ¡Bytes dentro de la ROM! Es decir, si queremos encontrar donde se encuentra el puntero a algo, sólo basta con poner permutado el offset de eso que queremos buscar y voilà!
Por ejemplo, para buscar el puntero a un sprite que inserté en 850000, en el cuadro de búsqueda pondré 00 00 85 08 y...
¡Aquí lo tenemos! En el offset 4AB584. ¿Veis qué maravilla?
Y con esto, también podremos buscar las tablas de las que hablaba antes. Aquí viene otro...
Tutorial exprés: Buscando tablas en la ROM
Por ejemplo, yo voy a buscar la tabla de canciones de Pokémon Emerald. Según Sappy, la tabla...
...se encuentra en el offset 6B49F0.
Ahora vamos a utilizar el header de la canción que tengo seleccionada (que es el offset en el que se encuentra toda la "data" de la midi) y...
En efecto, hemos permutado el offset del header y ahora vamos a buscarlo. Nos encontraremos aquí:
Sí, ¿y qué forma tiene este conjunto de bytes? ¡Exactamente! La de una tabla, como os enseñé antes. Ahora sólo nos queda subir hasta el principio. Y ahí, no tiene pérdida, donde la estructura de tabla se deforma y deja de haber XX XX XX 08, tenemos el inicio de nuestra tabla, es decir, lo que es interpretado como nuestra tabla. En 6B49F0:
Bueno, ahora ya sabéis como buscar tablas para expandirlas, repuntearlas y cambiarlas de lugar, ver su expansión o simplemente entender de qué se habla cuando se habla de ello.
Ahora sí, continuemos con las pestañas. En las pestañas Ver, Ventanas y ? tenemos chorradas estéticas/inútiles (como lo que enseñé más arriba sobre el número de columnas) que ya investigaréis por vosotros mismos. La pestaña Extras es peligrosa, así que ni tocarla xD
Perfecto, vayámonos a Análisis. Aquí lo único que nos interesa (y tanto), es el glorioso Comparar Archivos. Este pequeño gadget os servirá de mucho, os lo aseguro.
Aquí va un ejemplo de cómo funciona:
Coged una PokéROM cualquiera, preferiblemente limpia y de plataforma GBA. Yo usaré la Emerald (U) que he estado usando en el resto del tutorial. Hacedle una copia, sin tocarla, y pegadla en la misma carpeta en la que tenéis la original. Cambiad cualquier cosa en la copia, preferiblemente un cambio pequeño desde Advance Map. Por ejemplo, yo cambiaré el clima de Villa Raíz a Tormenta.
Como podéis ver en la imagen, el byte del clima de Villa Raíz en la ROM original es 02 (clima normal) mientras que en la copia editada, es 05. Tormenta. Comprobemos si hay más diferencias con "diferencia siguiente". ¿No? Perfecto, ahora ya sabemos que los datos del clima de un mapa sólo vienen definidos por UN byte y que esa data climática del Mapa principal de Villa Raíz está en el offset 737288.
Quizás no os parezca muy útil al verlo en este ejemplo tan simple, pero que sepáis que esto os puede servir para encontrar cosas tan maravillosas como el offset de cualquier tontería que no encontráis en ningún lado o incluso para solucionar bugs/errores de cualquier tipo... Todo es cuestión de acordarse de las utilidades de esta herramienta nada más tener cualquier problema y sacarle el máximo partido.
En fin, quizás continúe con más extras y trucos próximamente, y jugar con el CSS y hacerlo bonito, pero por ahora, hemos finalizado. Espero que a pesar de lo que me he liado y las paranoias que os he contado valoréis lo que me he tomado en hacer el tuto xDD, (que no es una materia fácil de explicar y me ha llevado un mes aproximadamente) y sobre todo, que os valga.
Gracias a @BLAx301!-HSG- por hacerme de tutotester, corrector hortojrháfico y esa shit (;
Y ya sabéis, cualquier duda que tengáis, aquí abajo, por MP o mi perfil
