Para aquellos que quieran adentrarse un poco más en el mundo del romhacking y aprender más allá de buscar gráficos y editarlos, es necesario tener claro varios conceptos con los cuales sería complicado seguir avanzando.
Aquí os dejo un listado y una breve explicación.
TÉRMINOS
ROM: Es la memoria que contiene el juego ubicada en cada cartucho de videojuego. De ahí que llamemos a nuestros archivos con extensión “gba” ROMs.
Emulador: Consola virtual con la que podemos ejecutar nuestras Roms. Normalmente viene con herramientas de depuración, por lo que sería más correcto llamarlo “Debugger”. Esas herramientas son imprescindibles para cualquier Romhacker.
Editor Hex: Programa con el que editaremos nuestras Roms. El código que veremos y utilizaremos será el hexadecimal.
Offset: Dirección. Coincide con el número de Byte en el que nos encontremos en el editor hexadecimal o visor de memoria de cualquier Debugger. Los juegos de GBA suelen pesar 8 MB, que serían 7FFFFF Bytes (este sería el offset del último Byte), aunque también los hay de 32 MB, e incluso los de 8 podemos ampliarlos a 16 o 32 MB.
Puntero/Pointer: Indica a la consola el Offset donde se encuentran los datos que necesita. Están formados por 4 Bytes y están escritos en formato Little-Endian.
Ejemplo:
Para saber el Puntero del Offset “24 82 00 “debemos escribir este offset copiándolo conforme lo leemos de derecha a izquierda: “00 82 24”. Esto es el formato Little-Endian.
Por último se le añade el Byte 08 al final, quedando “00 82 24 08”. Se añade “08” por ser la memoria de la consola en la que se encuentra el ROM, por lo que en un Debugger, para dirigirnos a cualquier posición de memoria de la ROM, deberíamos añadir “08” al principio del Offset.
Usando el Offset del ejemplo anterior, sería “08 24 82 00”.
Tabla de Punteros/Pointers: Son varios punteros agrupados que normalmente guardan relación. Textos de diálogos, paletas de colores, gráficos, etc.
Repointear: Es modificar el puntero de alguna dirección por el de otra en la que hayas introducido nuevos datos que por longitud de espacio no hayas podido reescribir en la original. Se usa sobre todo para traducciones de juegos ya que según el idioma, es necesario el uso de más caracteres o palabras.
Código Hexadecimal: Es un sistema de numeración que tiene como base el 16 y que se representan con los diez dígitos del sistema decimal (0-9), seguidos de las seis primeras letras del abecedario (A-F) siendo su equivalente decimal el intervalo 0-15 (16 números) respectivamente. Cada Byte (8 bits) es representado mediante la agrupación de 2 cifras hex (4 bits cada una), por lo que las combinaciones posibles combinaciones tienen su comienzo en 00 y su fin en FF, siendo 0 y 255 sus equivalentes decimales respectivamente o dicho de otra forma, los 256 valores posibles de un Byte. (editado)
Indexar: Limitar el número de colores en la paleta utilizada por una imagen.
Sprites: Son los gráficos de objetos y personajes de los juegos. Al igual que cualquier gráfico del juego, está divido en Tiles. Aunque hay métodos que puedan hacer que sean de mayor tamaño, sus dimensiones abarcan desde los 8x8 hasta 64x64.
Tile: Un azulejo, o para que nos entendamos mejor, un cuadrado de 8x8 píxeles que forma parte de cualquier tipo de gráfico.
Tileset: Es el conjunto de Tiles que forman un gráfico. Normalmente hay gráficos que contienen varios Tiles idénticos, por ejemplo la zona del cabello de Goku contiene varios Tiles de color negro, pues el Tileset tan solo necesitaría contener uno de ellos ya que su Tilemap es el responsable de hacer que se repitan las veces que sean necesarias en pantalla para formar el gráfico. Lo mismo ocurre con Tiles que al ser volteados, bien horizontalmente, bien verticalmente o incluso de ambas formas, coincida con otro Tile del gráfico.
Tilemap: Usado en los Backgorunds. No es más que una guía que contiene la información de la posición y otros atributos de cada Tile de los gráficos para que se muestren correctamente en pantalla.
Paleta: Son los colores de cada gráfico. Pueden ser de 16 o 256 colores, pero siempre uno de ellos, el primero de la paleta, es utilizado como color transparente, es decir, ese color, que puede ser cualquiera, no será visible durante el juego. Normalmente se usan colores que destaquen, muy saturados y con brillo. Pueden haber gráficos (backgrounds) que usen varias paletas de 16 colores, por lo que en caso de que quisiéramos modificarlos sería un proceso más laborioso tanto para elegir qué colores debe tener cada paleta, qué paleta usará cada Tile y posteriormente así reflejarlo en el Tilemap.
Muestra
TEXTOS
Texto simple
La forma más básica de almacenar el texto es introducirlo tal cual, por lo que serán visibles en nuestro editor hexadecimal pudiéndolos buscar bien mediante una cadena de texto o su equivalente en hexadecimal.
Este formato utiliza un Byte para cada carácter, pero podemos encontrarnos la situación de que utilice 2 Bytes, siendo el segundo Byte “00”, que en ASCII equivaldría a “0”, por lo que usando la palabra marcada en la imagen como ejemplo en hexadecimal quedaría “47 00 6F 00 6B 00 75 00” y en ASCII se leería “G0o0k0u0”. A este formato se le conoce como Texto Unicode o 16 bits.
Texto encriptado
Cabe la posibilidad de que el juego utilice una tabla de caracteres propia, es decir, el código ASCII no se corresponde con su código hexadecimal, por lo que si “a” corresponde a 61, en una tabla propia podría ser “14”por ejemplo, por lo que hay que averiguarla para poder hallar los textos. Hay programas de Búsqueda Relativa orientados a encontrar y elaborar dichas tablas, e incluso editores hexadecimales que cuentan con esta función.
Para más inri, puede ser que además de encriptado, esté en formato Unicode, lo que complicaría más aún las cosas, y no solo eso, si no que utilice combinaciones de Bytes específicos para espaciar palabras, indicar el fin del texto, que suele ser “00” , etc. pues esto hace que mientras no las conozcamos, no podamos buscar más de una palabra.
Compresión DTE
No he tenido mucha experiencia con este tipo de encriptación en mi corta carrera de Romhacker, pero es un método muy interesante que puede ahorrar espacio en el ROM y tiempo, pues son BYTES que se usan como comodines en sustitución, por lo general, de palabras que se repiten con frecuencia o muy largas. El único juego con el que he trabajado y utiliza este método es Yugioh Duel Academy. Resumiendo, puede ser uno, dos o varios Bytes que el juego representará según la palabra indicada en una tabla. Un ejemplo podría ser que si escribiéramos el código “10 9A” equivaliese a “Mutenroshi”.
Texto comprimido
No hay mucho que explicar más allá de que si el juego contiene mucho texto, varios idiomas, etc., este se encuentre comprimido con algún algoritmo, por lo que las posibilidades de poder modificarlo son muy remotas.
GRÁFICOS
Para entender cómo se almacenan los gráficos, es necesario diferenciar si estos usan una paleta de 16 o 256 colores. El concepto es el mismo, solo que en el segundo caso ocuparían el doble de espacio en el ROM.
Explicaré de una forma generalizada y los más comunes de dichos métodos, códecs a partir de ahora, pero se ha de saber que aunque el concepto es similar, hay variantes que hacen cambiar el orden de los Bits o Bytes en función de cómo se organicen los píxeles de los Tiles.
Paleta 16 coloresEl códec usado por norma general es el 4bpp lineal reverse order. Esto significa que el color de cada pixel se almacena en 4 BITS, o lo que es igual, 1 BYTE contiene la información de 2 Píxeles.
Para ello enumera los colores de la paleta de 0 a F.
Los datos se almacenan con la información de Tile por Tile de izquierda a derecha y fila tras fila de Tiles. Cada Tile configurado con un códec 4bpp, ocupa 32 Bytes (20 en hex), 32x2 píxeles = 64, que es el número de píxeles por Tile.
Al tratarse del Reverse Mode, significa que los píxeles se escribirán en orden inverso de a dos.
*4 BPP LINEAL 4BPP LINEAL RO**
11 11 61 11 11 11 16 11
11 11 11 16 11 11 11 61
11 15 11 11 11 51 11 11
11 54 51 34 11 45 51 43
01 54 53 34 10 45 35 43
11 15 64 56 11 51 46 65
00 01 15 43 00 10 51 43
00 BC 69 55 00 CB 96 55
* Cada fila corresponde a una fila de píxeles del gráfico.
Paleta de 256 colores
El códec usado es 8bpp lineal, y como se puede suponer, este códec usa 8 bits por píxel, por lo que cada Byte indicará un píxel distinto. Esto quiere decir que ocupará el doble de espacio que un gráfico que use una paleta de 16 colores, pero a cambio puede contener mucho más colores y quedar un diseño mucho mejor.
EL orden de almacenamiento en la ROM es exactamente igual al anterior, solo que los colores no compartirán Bytes. Supongamos que el Tile del ejemplo anterior dispone de una paleta de 256 colores, lo que haría que el código hex quedase de la siguiente forma:
01 01 01 01 06 01 01 01
01 01 01 01 01 01 01 06
01 01 01 05 01 01 01 01
01 01 05 04 05 01 03 04
00 01 05 04 05 03 03 04
01 01 01 05 06 04 05 06
00 00 00 01 01 05 04 03
00 00 0B 0C 06 09 05 05
Espero que os haya parecido interesante y sobre todo aprendáis.
¡Para cualquier duda, por aquí me tenéis!