R
Ray Laé Àlfori
Invitado
Portadas de más de 32 colores en Ruby USA
Introducción (también conocida como “Bla bla bla, me aburro”)
Las portadas de 256 (o 240) colores se han generalizado durante los últimos años, a medida que también lo ha hecho el uso de Fire Red USA como ROM base. Pero ¿qué pasa con los hackers que hemos optado por seguir usando la base clásica Ruby AXVE? ¿Nos tenemos que contentar con portadas de 16 o 32 colores como mucho?
Pues no señor. He estado investigando. La verdad es que no hay mucha documentación sobre el tema. Se supone que puede hacerse, de la misma forma en la que se hace en FireRed: usando la imagen del logo de Pokémon como tileset y reorganizando su raw para formar el tilemap correspondiente. Sin embargo, en ninguna parte se explica dónde está dicha raw, ni como resolver los problemas gráficos que sin duda surgirían al utilizar el logo para esta finalidad. Hay que recordar que, a diferencia de lo que ocurre en FireRed, el logo se desplaza de sitio en la pantalla, por ejemplo, lo cual necesariamente ha de causar problemas.
Esta cuestión no voy a resolverla aquí. Es decir: en el tutorial que leéis no os enseñaré a insertar una portada “genuina” de 256 colores en Ruby... básicamente, porque no sé cómo hacerlo. Pero sí que os mostraré otro sistema que, bien hecho, puede llegar a acercársele mucho, y que he usado para insertar mi portada de 43 colores con total fidelidad:
El objetivo, pues, será insertar una portada de más de 16 colores (pueden ser 17, 50, 80 o 200; cuanto menos sean, más fácil será insertarla, aunque esto también dependerá del tipo de portada) distribuidos de manera dispersa por la pantalla, en contraposición al sistema clásico de 32 colores, que solo permite dos bloques claramente diferenciados de paletas y ya está. No estamos hablando de una portada de 256 colores de esas súper espectaculares, pero sin duda supone una mejora notable y permite hacer portadas de lo más decentes.
Para este tipo de inserción, en lugar de usar como base el logo de Pokémon, vamos a usar la imagen de Groudon de toda la vida. Que ya sé que es una imagen de 16 colores, no de 256... pero ahí está el truco. Usaremos el sistema propio de las portadas a 32 colores, pero más “a lo bestia”, en el sentido de que habrá que dedicar mucho más tiempo al montaje del tileset y el tilemap. Así que, si no estáis dispuestos a meterle horas a vuestra portaday a leer párrafos y párrafos de tutorial infinito, mejor descartad este sistema ahora mismo y a otra cosa mariposa.
... ¿Aún seguís aquí? Perfecto, pues. Vamos por pasos.
¿Qué necesito saber?
Este es un tutorial de nivel medio. No es ROM-hacking súper avanzado, ni mucho menos, pero doy por descontado que el lector sabe:
—Indexar imágenes.
—Insertar imágenes y repuntearlas.
—Montar tilemaps.
—Montar tilesets.
—Insertar paletas, etc.
Es decir, doy por supuesto que ya sabéis aplicar métodos normales de inserción de fondos y tiles. Este es un tutorial destinado a explicar un método específico, no el concepto más general y básico. Para eso ya hay muchos otros manuales muy bien hechos.
¿Qué herramientas necesitaré?
—Un editor gráfico que pueda indexar imágenes o trabajar con imágenes indexadas. Yo uso Aseprite 0.9.5, MS Paint (el de Windows XP, los posteriores no sirven) y The Gimp, dependiendo de qué quiera hacer. Os recomiendo un programa que pueda mostrar “cuadrículas”, porque así es más fácil montar los tiles. Aseprite resulta perfecto para esto. También puede ser útil el típico Character Maker Pro para indexar.
—Unlz-GBA u otro programa equivalente para editar imágenes comprimidas (Nameless Sprite Editor, etc.). Yo uso Unlz por costumbre.
—APE.
—Nameless Tilemap Editor u otro editor de tilemaps.
—Un editor hex o un buscador de offsets libres para encontrar espacio donde repuntear.
—(opcional) Un generador automático de tilemaps, como Tilemap Creator o Sphere 1.5.
Paso 1: Diseño de la portada
Este es el clásico primer paso de todo tutorial de fondos... pero, ¡cuidado!, porque en nuestro caso será algo más complicado. El diseño debe cumplir unas condiciones concretas.
El tileset de la portada debe poder montarse en un tamaño de más o menos unos 176x176 px, 8 píxeles más 8 píxeles menos, que es el máximo para el tileset de portada que acepta Ruby. No he comprobado el tamaño exacto: hasta 176x184 px también parece funcionarme, pero con 176x200 px los últimos tiles se buggean. Experimentad y ya me diréis.
Hay que tener en cuenta, además, que existen 16 casillas del tileset que no podremos usar, correspondientes a las “burbujas” semitransparentes que salen en el original desplazándose por la pantalla. En el caso de querer evitar este efecto, habrá que dejarlas en blanco. Aquí tenéis una plantilla para un tileset de 176x176 px:
Los espacios en rojo son los que debéis dejar transparentes. Tampoco hace falta que utilicéis la plantilla si no queréis: si vuestro tileset ocupa 128 px de ancho, la posición de estos “espacios prohibidos” es la misma que en el original, y simplemente podéis ir alargando el tileset por abajo. Como prefiráis; como bien sabréis, resulta indiferente, el tileset es exactamente el mismo.
Esto se aplica a cualquier tipo de portada para Ruby, no solamente a este, pero no está de más recordarlo.
Para montar el tileset, podéis hacerlo a mano o hacer lo que hago yo, que es usar un generador automático de tilesets, como Sphere 1.5 o Tilemap Creator. No os explicaré aquí cómo se hace, este tutorial ya será lo bastante largo de por sí... podéis encontrarlo explicado en otros tutoriales de fondos. Una vez esté generado el tileset, solamente habrá que mover de sitio los tiles que ocupan las “zonas prohibidas” de las burbujas y ya está. Mi tileset ha quedado así:
¿Cuál es la particularidad de este tileset respecto a cualquier otro tileset que hayáis podido hacer antes en vuestra carrera hackera? Pues la asignación de paletas, que es la parte más difícil de este método y que os explico en el paso 2. De esta asignación de paletas dependerá vuestro tileset: no el tileset en sí, su ordenación y demás, que ya la tenemos hecha y en principio no la cambiaremos, pero sí el modo en el que tendrá que estar indexado. Id al paso 2 y entenderéis de qué os hablo. Vamos, id ya. Pero ya.
Paso 2: Diseño de paletas: concepto general y offsets
Paletas. Este es el punto clave. El tileset de la portada de Ruby tiene a su disposición exactamente 16 paletas, cada una de ellas de 16 colores; lo cual, aplicando la matemática más simple, nos da un total de 256 colores.
De estos, 224 se corresponden con el logo de Pokémon y el logo de Ruby Version, y 32, al gráfico original de Groudon. Estos últimos 32 (offsets 00393210 y 00393230 respectivamente) son los que se utilizan en el método de inserción de portadas tradicional de 32 colores. Pero no hay razón alguna para no usar los otros 224... bueno, si no nos importa cargarnos el logo de Pokémon y el logo de Ruby Version, claro.
Los offsets de estos otros 224 colores son estos:
01 00E9F624
02 00E9F644
03 00E9F664
04 00E9F684
05 00E9F6A4
06 00E9F6C4
07 00E9F6E4
08 00E9F704
09 00E9F724
10 00E9F744
11 00E9F764
12 00E9F784
13 00E9F7A4
14 00E9F7C4
¿Veis por dónde voy? Tenemos distintas opciones. Podemos cargarnos el logo de Pokémon y el de Ruby Version y hacer la portada al estilo FireRed, toda en una misma capa, usando los 256 colores en una sola imagen: esto es lo que haré yo. Pero también podemos mantener los logos, limitándolos a, por ejemplo, 40 colores, y quedándonos los otros 216 para la portada. O podemos compartir los colores usados por el logo y los usados por la portada. Como mejor nos funcione para nuestro diseño. La cuestión es que no hay razón alguna para no exprimir estos colores al máximo. ¿Para qué queremos un logo de Pokémon con tantos colores, de todas formas?
Por cierto, aprovecho para mencionar que hay colores “reservados”:
—El color que se utiliza originalmente para indicar las rayas del cuerpo de Groudon que se iluminan. Podemos usarlo si nos interesa este efecto, pero si no nos interesa hay que evitarlo o nos saldrán píxeles brillantes por ahí.
—El primer color de muchas de las paletas, que el juego no permite que sea otro que negro. No en todas, pero la mayoría sí, ya que los interpreta como “transparencia” y, por defecto, los pone en negro. Así que mejor no asignéis colores que no sean 0000 a la primera posición de ninguna paleta, porque os estropearán la imagen.
Paso 3: Diseño de paletas: organización y asignación
Muchos ya habréis entendido por dónde voy, pero otros os estaréis preguntando: sí, todo esto está muy bien, pero ¿cómo diablos vamos a usar todas estas paletas en una sola imagen de 16 colores?
Muy sencillo. Nameless Tilemap Editor, o cualquier otro editor de tilemaps que se precie, incluye una opción muy útil llamada palette map. Es esta:
Fijaos en el número de paletas entre las que se puede elegir. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. Exactamente 16, que en nuestro caso se corresponden con los offsets que ya os he indicado: 0 a D serían los 224 colores de los logos, E y F serían los 32 colores restantes. Por lo tanto, jugando con este método, podemos hacer que cada tile individual de la pantalla tenga asignada una paleta distinta de las 16 disponibles; de modo que ningún tile podrá tener, por sí solo, más de 16 colores, pero el conjunto de la pantalla podrá mostrar un total de 256 (por así decirlo; al final siempre serán necesariamente menos, ya que algunos de ellos se repetirán en más de una paleta para facilitar la “transición” entre unos tiles y otros). Es exactamente lo mismo que hacemos al crear tiles normales para mapas convencionales, solo que en este caso tenemos una sola capa disponible en lugar de dos. Observad mi asignación de paletas:
Y mi distribución de colores en las 16 paletas disponibles:
Viendo la portada no se notaba, ¿verdad?, pero no es más que un puzzle. No solamente está hecha de muchos pedacitos de tile, sino también de muchos pedacitos de paleta.
Diseñar y asignar estas paletas es la parte más costosa de todo el proceso. De ahí venía mi advertencia inicial de estar dispuestos a “echarle horas” al asunto, porque agrupar los tiles en 16 grupos diferentes según su paleta y que todo quede bien cuadradito es muy complicado. No difícil, pero sí costoso en tiempo y muy minucioso.
Sin embargo, con paciencia es perfectamente factible, y se agiliza notablemente con la práctica. Yo en mi caso he optado por trabajar añadiendo una capa translúcida sobre mi diseño de la portada y coloreando las distintas zonas de modos diferentes dependiendo de la paleta que les correspondiera, y así he ido diseñando y decidiendo los 16 “grupos” de tiles según lo que me ha parecido más conveniente:
(el programa usado en la imagen es Aseprite 0.9.5. Muy práctico. Tiene algunos bugs que hay que esquivar, pero por lo general va perfecto)
Una vez hechos estos grupos, he ido creando archivos individuales con cada una de las paletas en cuestión y los tiles a los que se encuentra asignada, para organizarme:
De modo que he terminado teniendo una carpeta con 16 archivos: color1.png, color 2.png, color3.png... hasta color 16.png. Los he llamado “packs” o “grupos” de tiles, organizados por paleta como si estuvieran en cajitas. El método es exactamente el mismo que uso para crear tiles normales para mapas, e imagino que muchos de vosotros seguís estrategias similares. Sea como sea, os lo explico por si a alguien le puede servir.
Paso 4: Diseño de paletas: indexación
Una vez montados estos archivos que he dicho, he ido indexando las imágenes de modo que el orden de la paleta de cada una de ellas fuera exactamente el de la paleta que tenía diseñada con anterioridad (es decir, esa paleta que habéis visto dibujada en la parte superior de cada imagen). Esto lo podéis hacer con distintos programas: el más típico es Character Maker Pro.
Es importantísimo estar al tanto de mantener la indexación exactamente en un orden y no cambiarla, porque es el orden que más tarde insertaremos en la ROM, y tiene que haber coherencia entre una cosa y la otra.
Una vez indexadas las 16 imágenes, he tomado una paleta como “referencia”, como paleta básica. Esta paleta de referencia tiene que ser la paleta con la cual indexemos el tileset que, finalmente, insertaremos en la ROM. Puede ser cualquiera de las 16 paletas que hemos elegido, pero, en este caso, he optado por una paleta en blanco y negro, la que da por defecto Unlz-GBA cuando exportas el tileset de Groudon en modo black and white, ya que es muy fácil trabajar con ella por el modo en el que está secuenciada (0000, 1010, 2020, 3030... y así hasta F0F0).
He exportado esta paleta y la he ido importando en los 16 “packs” de tiles que había diseñado, uno por uno.
Yo trabajo con Aseprite, pero, insisto, cada uno que use el programa que quiera.
Importar la paleta así es la manera más rápida, aunque la sustitución de colores también puede hacerse a mano, por supuesto. Hacerlo a mano es a menudo la mejor opción si no tenemos ningún programa que confiemos que reindexará la imagen en el orden adecuado. En este sentido, la gracia de tener la paleta manualmente dibujada en la parte superior de cada imagen es que me ha permitido comprobar que, efectivamente, la indexación es correcta y se mantiene exactamente el orden que yo había establecido antes para los colores, lo cual es muy importante.
Sigamos. Pues he ido haciendo esto hasta que finalmente he tenido 16 archivos individuales indexados con la paleta en blanco y negro de Groudon. Y entonces... ¿el paso final? Pues unir estos 16 archivos en un solo archivo hasta volver a montar el tileset original, solo que esta vez tendrá solamente 16 colores y estará, pues, listo para insertar en la ROM. Mi tileset ha quedado así:
Tachán. Espero haberme explicado bien... esta parte es un poco liosa. En este paso seguramente habréis cometido errores y tendréis que revisar y reinsertar el tileset una y otra vez, pero no os desesperéis. Con paciencia, funciona.
Paso 5: Insertar, insertar, insertar
Ya podéis insertar el tileset con Unlz. Seguramente será demasiado grande, así que habrá que repuntear, pero no problem. Buscáis espacio vacío y ya está.
Luego habrá que insertar las paletas. Si habéis usado mi método, podéis fácilmente coger los 16 archivos indexados individualmente que teníais antes, exportar sus paletas una por una e introducirlas en la ROM mediante APE en los 16 offsets que os he indicado más arriba. Si no habéis usado mi método, bueno, podéis igualmente introducir las paletas manualmente con APE, con su color picker o con un conversor a colores hexagesimales o alguna cosa por el estilo.
Ahora solo nos queda el tilemap. Doy por descontado que sabéis cómo montar un tilemap convencional de portada para Ruby, así que no lo explicaré. Lo que tiene de distinto este método de los otros es que, además de montar el tilemap normal, habrá que montar el tilemap de paletas. Lo mismo que con el método de 32 colores, pero mucho más intensivo. No debería resultar excesivamente problemático, sobre todo si habéis seguido mi método y habéis creado anteriormente una imagen en la que cada paleta se indica con una zona de color. Basta con utilizar esta imagen que teníais montada como referencia, ir asignando los numeritos con NTME y voilà.
Ya tenemos el tilemap. ¡Solamente hay que insertarlo y ya casi estamos! Nos queda sustituir el logo de Pokémon y el de Ruby Version por imágenes vacías (si es que no nos interesa utilizarlos) y nuestra portada está terminada:
Como nota final, añado que, evidentemente, en mi caso solo he podido usar 43 colores en total porque la distribución de colores en la pantalla es variadísima, como podéis ver. Con otro tipo de portadas, en las que los tonos se degraden de modo más progresivo y no haya un mosaico tan diverso, o en las que haya dos o tres zonas claramente delimitadas de color, puede llegar perfectamente a usarse 150 o 200 colores sin dificultades.
Referencia de offsets
—Paletas:
01(0) 00E9F624
02(1) 00E9F644
03(2) 00E9F664
04(3) 00E9F684
05(4) 00E9F6A4
06(5) 00E9F6C4
07(6) 00E9F6E4
08(7) 00E9F704
09(8) 00E9F724
10(9) 00E9F744
11(A) 00E9F764
12(B) 00E9F784
13(C) 00E9F7A4
14(D) 00E9F7C4
15(E) 00393210
16(F) 00393230
—Tileset:
(casilla 78 de Unlz en ROM virgen) (modo 16 colores)
00393250
—Tilemap:
(casilla 79 de Unlz en ROM virgen)
003939EC
—Logo de Pokémon:
(casilla 1637 de Unlz en ROM virgen) (modo 256 colores)
00E9D8CC
—Logo de Ruby Version:
(casilla 1638 de Unlz en ROM virgen) (modo 256 colores)
00E9EFD0
FAQ de posibles problemas
—No entiendo ni papa de tu tutorial =B
Te recomiendo que leas antes algún tutorial de inserción de portadas de 32 colores en Ruby y de inserción de portadas de 240 colores en FireRed. Este método es una mezcla de los dos, de modo que eso te ayudará a comprenderlo mejor. Si aún así no lo entiendes, puedes comentarme tu problema y veré qué puedo hacer, pero probablemente lo mejor será que esperes a tener más experiencia antes de probarlo.
—¡Los colores salen horribles, ninguno de ellos parece encajar!
Eso es que has indexado mal las imágenes. El orden de las paletas tiene que ser exactamente le mismo que introduces en la ROM mediante APE, y el orden de las paletas individuales de cada “pack” de tiles tiene que ser exactamente el mismo que el orden de la paleta “general” con la que indexas el tileset completo. Si no, no habrá correspondencia. Te recomiendo que mires otros tutoriales de edición de gráficos y te familiarices más con el concepto de indexación antes de probar este método. Es algo retorcido, lo admito, y requiere una exactitud absoluta.
—Me salen tiles raros y translúcidos moviéndose por encima de la pantalla.
Eso es que no has respetado los “espacios prohibidos” que indico en el paso 1. Revísalo y, en caso de dudas, usa mi plantilla.
—Los tiles salen todos desplazados de sitio o desordenados.
Eso es que, o bien estás usando el modo equivocado con NTME al crear el tileset (el modo es 4BPP), o bien el tamaño del tileset es incorrecto. Es un error general de inserción de portadas, no limitado a este método. Revisa otros tutoriales más generales del tema para asegurarte de que lo estás haciendo bien.
—Algunos tiles están como “mezclados” entre ellos o se han convertido en glitches...
Esto es o bien que has sobreescrito una parte del tileset con otra cosa, o bien que has hecho un tileset demasiado grande.
—La mayoría de colores se ve bien, pero algunos colores concretos se ven mal.
Eso probablemente significa que has tocado alguno de los colores reservados de las paletas. En casos como este, no hay más remedio que utilizar otro color de la paleta y dejar ese aparte y sin usar.
—¡No tengo suficientes paletas/tiles! asdgadghklgd
Mala suerte. Tendrás que cambiar el diseño de la portada para adaptarla a este límite. Con un poco de ingenio todo se puede.
Fuentes
—El proyecto 256 de @WilliamGJ.
—Muchos otros tutoriales que debo haber leído y que no recuerdo.
—Visual Boy Advance.
—La experiencia.
Descargar el tutorial en pdf
Click, click.
--
Aquí lo tenéis. No he descubierto nada y tengo bastante claro que muchas personas han usado este método antes, pero no está de más tener un tutorial para ello. Que yo sepa (y he hurgado mucho), no existe ninguno.
Este método en principio debería servir igual para Emerald/Esmeralda (y para Rubí en español, por supuesto), solamente habría que buscar los offsets correspondientes. En Emerald/Esmeralda, además, hay la ventaja que las nubes que pasan por encima de la pantalla están en una imagen aparte, de modo que no hay “zonas prohibidas” del tileset.
Espero que os resulte útil... y que se entienda. Bastante me partí la cabeza con la cuestión de la indexación al hacerlo yo, y explicarlo para que lo haga otro es un verdadero reto, jaja. Si hay alguna parte del tutorial que os parezca errónea o mejorable, comentádmelo y lo reviso.
Saludos,
A.
Introducción (también conocida como “Bla bla bla, me aburro”)
Las portadas de 256 (o 240) colores se han generalizado durante los últimos años, a medida que también lo ha hecho el uso de Fire Red USA como ROM base. Pero ¿qué pasa con los hackers que hemos optado por seguir usando la base clásica Ruby AXVE? ¿Nos tenemos que contentar con portadas de 16 o 32 colores como mucho?
Pues no señor. He estado investigando. La verdad es que no hay mucha documentación sobre el tema. Se supone que puede hacerse, de la misma forma en la que se hace en FireRed: usando la imagen del logo de Pokémon como tileset y reorganizando su raw para formar el tilemap correspondiente. Sin embargo, en ninguna parte se explica dónde está dicha raw, ni como resolver los problemas gráficos que sin duda surgirían al utilizar el logo para esta finalidad. Hay que recordar que, a diferencia de lo que ocurre en FireRed, el logo se desplaza de sitio en la pantalla, por ejemplo, lo cual necesariamente ha de causar problemas.
Esta cuestión no voy a resolverla aquí. Es decir: en el tutorial que leéis no os enseñaré a insertar una portada “genuina” de 256 colores en Ruby... básicamente, porque no sé cómo hacerlo. Pero sí que os mostraré otro sistema que, bien hecho, puede llegar a acercársele mucho, y que he usado para insertar mi portada de 43 colores con total fidelidad:
El objetivo, pues, será insertar una portada de más de 16 colores (pueden ser 17, 50, 80 o 200; cuanto menos sean, más fácil será insertarla, aunque esto también dependerá del tipo de portada) distribuidos de manera dispersa por la pantalla, en contraposición al sistema clásico de 32 colores, que solo permite dos bloques claramente diferenciados de paletas y ya está. No estamos hablando de una portada de 256 colores de esas súper espectaculares, pero sin duda supone una mejora notable y permite hacer portadas de lo más decentes.
Para este tipo de inserción, en lugar de usar como base el logo de Pokémon, vamos a usar la imagen de Groudon de toda la vida. Que ya sé que es una imagen de 16 colores, no de 256... pero ahí está el truco. Usaremos el sistema propio de las portadas a 32 colores, pero más “a lo bestia”, en el sentido de que habrá que dedicar mucho más tiempo al montaje del tileset y el tilemap. Así que, si no estáis dispuestos a meterle horas a vuestra portada
... ¿Aún seguís aquí? Perfecto, pues. Vamos por pasos.
¿Qué necesito saber?
Este es un tutorial de nivel medio. No es ROM-hacking súper avanzado, ni mucho menos, pero doy por descontado que el lector sabe:
—Indexar imágenes.
—Insertar imágenes y repuntearlas.
—Montar tilemaps.
—Montar tilesets.
—Insertar paletas, etc.
Es decir, doy por supuesto que ya sabéis aplicar métodos normales de inserción de fondos y tiles. Este es un tutorial destinado a explicar un método específico, no el concepto más general y básico. Para eso ya hay muchos otros manuales muy bien hechos.
¿Qué herramientas necesitaré?
—Un editor gráfico que pueda indexar imágenes o trabajar con imágenes indexadas. Yo uso Aseprite 0.9.5, MS Paint (el de Windows XP, los posteriores no sirven) y The Gimp, dependiendo de qué quiera hacer. Os recomiendo un programa que pueda mostrar “cuadrículas”, porque así es más fácil montar los tiles. Aseprite resulta perfecto para esto. También puede ser útil el típico Character Maker Pro para indexar.
—Unlz-GBA u otro programa equivalente para editar imágenes comprimidas (Nameless Sprite Editor, etc.). Yo uso Unlz por costumbre.
—APE.
—Nameless Tilemap Editor u otro editor de tilemaps.
—Un editor hex o un buscador de offsets libres para encontrar espacio donde repuntear.
—(opcional) Un generador automático de tilemaps, como Tilemap Creator o Sphere 1.5.
Paso 1: Diseño de la portada
Este es el clásico primer paso de todo tutorial de fondos... pero, ¡cuidado!, porque en nuestro caso será algo más complicado. El diseño debe cumplir unas condiciones concretas.
El tileset de la portada debe poder montarse en un tamaño de más o menos unos 176x176 px, 8 píxeles más 8 píxeles menos, que es el máximo para el tileset de portada que acepta Ruby. No he comprobado el tamaño exacto: hasta 176x184 px también parece funcionarme, pero con 176x200 px los últimos tiles se buggean. Experimentad y ya me diréis.
Hay que tener en cuenta, además, que existen 16 casillas del tileset que no podremos usar, correspondientes a las “burbujas” semitransparentes que salen en el original desplazándose por la pantalla. En el caso de querer evitar este efecto, habrá que dejarlas en blanco. Aquí tenéis una plantilla para un tileset de 176x176 px:
Los espacios en rojo son los que debéis dejar transparentes. Tampoco hace falta que utilicéis la plantilla si no queréis: si vuestro tileset ocupa 128 px de ancho, la posición de estos “espacios prohibidos” es la misma que en el original, y simplemente podéis ir alargando el tileset por abajo. Como prefiráis; como bien sabréis, resulta indiferente, el tileset es exactamente el mismo.
Esto se aplica a cualquier tipo de portada para Ruby, no solamente a este, pero no está de más recordarlo.
Para montar el tileset, podéis hacerlo a mano o hacer lo que hago yo, que es usar un generador automático de tilesets, como Sphere 1.5 o Tilemap Creator. No os explicaré aquí cómo se hace, este tutorial ya será lo bastante largo de por sí... podéis encontrarlo explicado en otros tutoriales de fondos. Una vez esté generado el tileset, solamente habrá que mover de sitio los tiles que ocupan las “zonas prohibidas” de las burbujas y ya está. Mi tileset ha quedado así:
¿Cuál es la particularidad de este tileset respecto a cualquier otro tileset que hayáis podido hacer antes en vuestra carrera hackera? Pues la asignación de paletas, que es la parte más difícil de este método y que os explico en el paso 2. De esta asignación de paletas dependerá vuestro tileset: no el tileset en sí, su ordenación y demás, que ya la tenemos hecha y en principio no la cambiaremos, pero sí el modo en el que tendrá que estar indexado. Id al paso 2 y entenderéis de qué os hablo. Vamos, id ya. Pero ya.
Paso 2: Diseño de paletas: concepto general y offsets
Paletas. Este es el punto clave. El tileset de la portada de Ruby tiene a su disposición exactamente 16 paletas, cada una de ellas de 16 colores; lo cual, aplicando la matemática más simple, nos da un total de 256 colores.
De estos, 224 se corresponden con el logo de Pokémon y el logo de Ruby Version, y 32, al gráfico original de Groudon. Estos últimos 32 (offsets 00393210 y 00393230 respectivamente) son los que se utilizan en el método de inserción de portadas tradicional de 32 colores. Pero no hay razón alguna para no usar los otros 224... bueno, si no nos importa cargarnos el logo de Pokémon y el logo de Ruby Version, claro.
Los offsets de estos otros 224 colores son estos:
01 00E9F624
02 00E9F644
03 00E9F664
04 00E9F684
05 00E9F6A4
06 00E9F6C4
07 00E9F6E4
08 00E9F704
09 00E9F724
10 00E9F744
11 00E9F764
12 00E9F784
13 00E9F7A4
14 00E9F7C4
¿Veis por dónde voy? Tenemos distintas opciones. Podemos cargarnos el logo de Pokémon y el de Ruby Version y hacer la portada al estilo FireRed, toda en una misma capa, usando los 256 colores en una sola imagen: esto es lo que haré yo. Pero también podemos mantener los logos, limitándolos a, por ejemplo, 40 colores, y quedándonos los otros 216 para la portada. O podemos compartir los colores usados por el logo y los usados por la portada. Como mejor nos funcione para nuestro diseño. La cuestión es que no hay razón alguna para no exprimir estos colores al máximo. ¿Para qué queremos un logo de Pokémon con tantos colores, de todas formas?
Por cierto, aprovecho para mencionar que hay colores “reservados”:
—El color que se utiliza originalmente para indicar las rayas del cuerpo de Groudon que se iluminan. Podemos usarlo si nos interesa este efecto, pero si no nos interesa hay que evitarlo o nos saldrán píxeles brillantes por ahí.
—El primer color de muchas de las paletas, que el juego no permite que sea otro que negro. No en todas, pero la mayoría sí, ya que los interpreta como “transparencia” y, por defecto, los pone en negro. Así que mejor no asignéis colores que no sean 0000 a la primera posición de ninguna paleta, porque os estropearán la imagen.
Paso 3: Diseño de paletas: organización y asignación
Muchos ya habréis entendido por dónde voy, pero otros os estaréis preguntando: sí, todo esto está muy bien, pero ¿cómo diablos vamos a usar todas estas paletas en una sola imagen de 16 colores?
Muy sencillo. Nameless Tilemap Editor, o cualquier otro editor de tilemaps que se precie, incluye una opción muy útil llamada palette map. Es esta:
Fijaos en el número de paletas entre las que se puede elegir. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. Exactamente 16, que en nuestro caso se corresponden con los offsets que ya os he indicado: 0 a D serían los 224 colores de los logos, E y F serían los 32 colores restantes. Por lo tanto, jugando con este método, podemos hacer que cada tile individual de la pantalla tenga asignada una paleta distinta de las 16 disponibles; de modo que ningún tile podrá tener, por sí solo, más de 16 colores, pero el conjunto de la pantalla podrá mostrar un total de 256 (por así decirlo; al final siempre serán necesariamente menos, ya que algunos de ellos se repetirán en más de una paleta para facilitar la “transición” entre unos tiles y otros). Es exactamente lo mismo que hacemos al crear tiles normales para mapas convencionales, solo que en este caso tenemos una sola capa disponible en lugar de dos. Observad mi asignación de paletas:
Y mi distribución de colores en las 16 paletas disponibles:
Viendo la portada no se notaba, ¿verdad?, pero no es más que un puzzle. No solamente está hecha de muchos pedacitos de tile, sino también de muchos pedacitos de paleta.
Diseñar y asignar estas paletas es la parte más costosa de todo el proceso. De ahí venía mi advertencia inicial de estar dispuestos a “echarle horas” al asunto, porque agrupar los tiles en 16 grupos diferentes según su paleta y que todo quede bien cuadradito es muy complicado. No difícil, pero sí costoso en tiempo y muy minucioso.
Sin embargo, con paciencia es perfectamente factible, y se agiliza notablemente con la práctica. Yo en mi caso he optado por trabajar añadiendo una capa translúcida sobre mi diseño de la portada y coloreando las distintas zonas de modos diferentes dependiendo de la paleta que les correspondiera, y así he ido diseñando y decidiendo los 16 “grupos” de tiles según lo que me ha parecido más conveniente:
(el programa usado en la imagen es Aseprite 0.9.5. Muy práctico. Tiene algunos bugs que hay que esquivar, pero por lo general va perfecto)
Una vez hechos estos grupos, he ido creando archivos individuales con cada una de las paletas en cuestión y los tiles a los que se encuentra asignada, para organizarme:
De modo que he terminado teniendo una carpeta con 16 archivos: color1.png, color 2.png, color3.png... hasta color 16.png. Los he llamado “packs” o “grupos” de tiles, organizados por paleta como si estuvieran en cajitas. El método es exactamente el mismo que uso para crear tiles normales para mapas, e imagino que muchos de vosotros seguís estrategias similares. Sea como sea, os lo explico por si a alguien le puede servir.
Paso 4: Diseño de paletas: indexación
Una vez montados estos archivos que he dicho, he ido indexando las imágenes de modo que el orden de la paleta de cada una de ellas fuera exactamente el de la paleta que tenía diseñada con anterioridad (es decir, esa paleta que habéis visto dibujada en la parte superior de cada imagen). Esto lo podéis hacer con distintos programas: el más típico es Character Maker Pro.
Es importantísimo estar al tanto de mantener la indexación exactamente en un orden y no cambiarla, porque es el orden que más tarde insertaremos en la ROM, y tiene que haber coherencia entre una cosa y la otra.
Una vez indexadas las 16 imágenes, he tomado una paleta como “referencia”, como paleta básica. Esta paleta de referencia tiene que ser la paleta con la cual indexemos el tileset que, finalmente, insertaremos en la ROM. Puede ser cualquiera de las 16 paletas que hemos elegido, pero, en este caso, he optado por una paleta en blanco y negro, la que da por defecto Unlz-GBA cuando exportas el tileset de Groudon en modo black and white, ya que es muy fácil trabajar con ella por el modo en el que está secuenciada (0000, 1010, 2020, 3030... y así hasta F0F0).
He exportado esta paleta y la he ido importando en los 16 “packs” de tiles que había diseñado, uno por uno.
Yo trabajo con Aseprite, pero, insisto, cada uno que use el programa que quiera.
Importar la paleta así es la manera más rápida, aunque la sustitución de colores también puede hacerse a mano, por supuesto. Hacerlo a mano es a menudo la mejor opción si no tenemos ningún programa que confiemos que reindexará la imagen en el orden adecuado. En este sentido, la gracia de tener la paleta manualmente dibujada en la parte superior de cada imagen es que me ha permitido comprobar que, efectivamente, la indexación es correcta y se mantiene exactamente el orden que yo había establecido antes para los colores, lo cual es muy importante.
Sigamos. Pues he ido haciendo esto hasta que finalmente he tenido 16 archivos individuales indexados con la paleta en blanco y negro de Groudon. Y entonces... ¿el paso final? Pues unir estos 16 archivos en un solo archivo hasta volver a montar el tileset original, solo que esta vez tendrá solamente 16 colores y estará, pues, listo para insertar en la ROM. Mi tileset ha quedado así:
Tachán. Espero haberme explicado bien... esta parte es un poco liosa. En este paso seguramente habréis cometido errores y tendréis que revisar y reinsertar el tileset una y otra vez, pero no os desesperéis. Con paciencia, funciona.
Paso 5: Insertar, insertar, insertar
Ya podéis insertar el tileset con Unlz. Seguramente será demasiado grande, así que habrá que repuntear, pero no problem. Buscáis espacio vacío y ya está.
Luego habrá que insertar las paletas. Si habéis usado mi método, podéis fácilmente coger los 16 archivos indexados individualmente que teníais antes, exportar sus paletas una por una e introducirlas en la ROM mediante APE en los 16 offsets que os he indicado más arriba. Si no habéis usado mi método, bueno, podéis igualmente introducir las paletas manualmente con APE, con su color picker o con un conversor a colores hexagesimales o alguna cosa por el estilo.
Ahora solo nos queda el tilemap. Doy por descontado que sabéis cómo montar un tilemap convencional de portada para Ruby, así que no lo explicaré. Lo que tiene de distinto este método de los otros es que, además de montar el tilemap normal, habrá que montar el tilemap de paletas. Lo mismo que con el método de 32 colores, pero mucho más intensivo. No debería resultar excesivamente problemático, sobre todo si habéis seguido mi método y habéis creado anteriormente una imagen en la que cada paleta se indica con una zona de color. Basta con utilizar esta imagen que teníais montada como referencia, ir asignando los numeritos con NTME y voilà.
Ya tenemos el tilemap. ¡Solamente hay que insertarlo y ya casi estamos! Nos queda sustituir el logo de Pokémon y el de Ruby Version por imágenes vacías (si es que no nos interesa utilizarlos) y nuestra portada está terminada:
Como nota final, añado que, evidentemente, en mi caso solo he podido usar 43 colores en total porque la distribución de colores en la pantalla es variadísima, como podéis ver. Con otro tipo de portadas, en las que los tonos se degraden de modo más progresivo y no haya un mosaico tan diverso, o en las que haya dos o tres zonas claramente delimitadas de color, puede llegar perfectamente a usarse 150 o 200 colores sin dificultades.
Referencia de offsets
—Paletas:
01(0) 00E9F624
02(1) 00E9F644
03(2) 00E9F664
04(3) 00E9F684
05(4) 00E9F6A4
06(5) 00E9F6C4
07(6) 00E9F6E4
08(7) 00E9F704
09(8) 00E9F724
10(9) 00E9F744
11(A) 00E9F764
12(B) 00E9F784
13(C) 00E9F7A4
14(D) 00E9F7C4
15(E) 00393210
16(F) 00393230
—Tileset:
(casilla 78 de Unlz en ROM virgen) (modo 16 colores)
00393250
—Tilemap:
(casilla 79 de Unlz en ROM virgen)
003939EC
—Logo de Pokémon:
(casilla 1637 de Unlz en ROM virgen) (modo 256 colores)
00E9D8CC
—Logo de Ruby Version:
(casilla 1638 de Unlz en ROM virgen) (modo 256 colores)
00E9EFD0
FAQ de posibles problemas
—No entiendo ni papa de tu tutorial =B
Te recomiendo que leas antes algún tutorial de inserción de portadas de 32 colores en Ruby y de inserción de portadas de 240 colores en FireRed. Este método es una mezcla de los dos, de modo que eso te ayudará a comprenderlo mejor. Si aún así no lo entiendes, puedes comentarme tu problema y veré qué puedo hacer, pero probablemente lo mejor será que esperes a tener más experiencia antes de probarlo.
—¡Los colores salen horribles, ninguno de ellos parece encajar!
Eso es que has indexado mal las imágenes. El orden de las paletas tiene que ser exactamente le mismo que introduces en la ROM mediante APE, y el orden de las paletas individuales de cada “pack” de tiles tiene que ser exactamente el mismo que el orden de la paleta “general” con la que indexas el tileset completo. Si no, no habrá correspondencia. Te recomiendo que mires otros tutoriales de edición de gráficos y te familiarices más con el concepto de indexación antes de probar este método. Es algo retorcido, lo admito, y requiere una exactitud absoluta.
—Me salen tiles raros y translúcidos moviéndose por encima de la pantalla.
Eso es que no has respetado los “espacios prohibidos” que indico en el paso 1. Revísalo y, en caso de dudas, usa mi plantilla.
—Los tiles salen todos desplazados de sitio o desordenados.
Eso es que, o bien estás usando el modo equivocado con NTME al crear el tileset (el modo es 4BPP), o bien el tamaño del tileset es incorrecto. Es un error general de inserción de portadas, no limitado a este método. Revisa otros tutoriales más generales del tema para asegurarte de que lo estás haciendo bien.
—Algunos tiles están como “mezclados” entre ellos o se han convertido en glitches...
Esto es o bien que has sobreescrito una parte del tileset con otra cosa, o bien que has hecho un tileset demasiado grande.
—La mayoría de colores se ve bien, pero algunos colores concretos se ven mal.
Eso probablemente significa que has tocado alguno de los colores reservados de las paletas. En casos como este, no hay más remedio que utilizar otro color de la paleta y dejar ese aparte y sin usar.
—¡No tengo suficientes paletas/tiles! asdgadghklgd
Mala suerte. Tendrás que cambiar el diseño de la portada para adaptarla a este límite. Con un poco de ingenio todo se puede.
Fuentes
—El proyecto 256 de @WilliamGJ.
—Muchos otros tutoriales que debo haber leído y que no recuerdo.
—Visual Boy Advance.
—La experiencia.
Descargar el tutorial en pdf
Click, click.
--
Aquí lo tenéis. No he descubierto nada y tengo bastante claro que muchas personas han usado este método antes, pero no está de más tener un tutorial para ello. Que yo sepa (y he hurgado mucho), no existe ninguno.
Este método en principio debería servir igual para Emerald/Esmeralda (y para Rubí en español, por supuesto), solamente habría que buscar los offsets correspondientes. En Emerald/Esmeralda, además, hay la ventaja que las nubes que pasan por encima de la pantalla están en una imagen aparte, de modo que no hay “zonas prohibidas” del tileset.
Espero que os resulte útil... y que se entienda. Bastante me partí la cabeza con la cuestión de la indexación al hacerlo yo, y explicarlo para que lo haga otro es un verdadero reto, jaja. Si hay alguna parte del tutorial que os parezca errónea o mejorable, comentádmelo y lo reviso.
Saludos,
A.
