¡Vamos a agregar más colores por paleta!
Bien, como lo dice el titulo, coloco esto como una guía para extender la cantidad de colores que posee una paleta.
La razón por la que publico esto aquí en el subforo de investigación, es porque no he podido comprobar si el método funciona del todo, eso se debe a que estoy de vacaciones y para comprobar el resultado tendría que ponerme a insertar gráficos con lo cual soy muy malo. Así que si alguien desea, por favor que compruebe si este método es servible y para que podría aplicarse (Entiéndase que tal vez funcione para algunos gráficos y para otros no…)
Antes de empezar decirles que ESTE METODO NO SE APLICA A MINIS, TILES Y SPRITES. Solo funciona con gráficos formados por “un tileset” y un “Raw”. (Entiéndase portada, worldmap, mochila, mensaje de la intro, etc…). No obstante, recuerden que no he podido comprobarlo del todo así que, no está de más que lo intentéis…
Otro punto a recalcar es que e usado Ruby para investigar esto, sin embargo creo que puede funcionar para cualquier rom base.
En fin, comencemos…
Empezamos tomando el offset de la paleta que vamos a expandir, y acto seguido lo permutamos. Entiéndase por permutar, a voltear los bytes de forma que el primero quede de último y el último quede de primero. Ejemplo, si el offset es 30AF35, permutado seria 35AF30.
Perfecto, ahora nos metemos en el HxD y buscamos los bytes que permutamos. Si no suelta algún resultado, es posible que el offset que tengáis no sea el origen de la paleta (Pues también hay paletas de 32 colores, como la del Worldmap, y es posible que no buscases con el offset adecuado). Si en cambio, el HxD localiza los bytes, anota la dirección.
Esta dirección será, como yo la llamo, nuestro punto de anclaje…
Ahora nos vamos al VBA, abrimos nuestro rom, y nos vamos a Tools/Disassemble… Entonces marcamos la opción “thumb” y en el cuadro blanco al lado del botón “go”, escribimos nuestro punto de anclaje. Acordaros que nuestro punto de anclaje está en la ROM, así que siempre deberá comenzar con un “08”. Ejemplo, si es 1FE34D, en el disassemble ponéis 081FE34D.
Solo por si tenéis dudas, el disassemble, como su nombre lo dice, traduce los bytes hexadecimales en código asm, que es eso que se ve en la ventana.
Ahora vamos a movernos hacia arriba usando el scroll vertical ubicado a la derecha. Nos moveremos hacia arriba hasta encontrar algo parecido a esto:
Ldr r0, [08XXXXXX] (=$08YYYYYY)
Mov r1, # 0xZZ
Mov r2, # 0xZZ
Antes que nada dejadme explicar:
XXXXXX = Esto debería ser igual a nuestro punto de anclaje
YYYYYY = Esto debería ser igual a la dirección de la paleta
ZZ = Esto es variable. En el primer Mov no se cómo puede variar, pero en el segundo este valor cambia según el numero de paletas.
Por lo que tomando en cuenta que mi paleta seria de 16 colores, en mi caso sería:
Ldr r0, [081FE34D] (=$0830AF35)
Mov r1, # 0x70
Mov r2, # 0x20
Si usamos la calculadora de Windows, sabremos que 20 en decimal es 32, esto indica que la paleta carga 32 bytes que serian un total de 16 colores (Acordaos que cada color ocupa 2 bytes).
Entonces, si yo quiero expandir la paleta hasta un total de 32 colores lo que tengo que hacer es cambiar ese Mov r2, #0x20, por un mov r2 #0x40.
40 en hex, vendría siendo 64 en decimal, esto significa que tomara 64 bytes para un total de 32 colores (2 bytes por color)
Muy bien, pero ¿Cómo cambiamos ese mov?, bueno, justo al lado izquierdo de esa línea de código, deberíamos ver la dirección en donde se encuentra (Recordad que es una dirección en la ROM así que el disassemble la mostrara con un “08” al comienzo).
Lo que hacemos es anotar esa dirección e irnos hacia ella con HxD. Entonces, justo en ese mismo offset debería estar el valor del mov.
Por lo que si la dirección fuese 17B15F, en esa dirección debería ver el valor del mov que en mi caso es 20. Lo que hacemos es cambiarlo por otro valor para aumentar los colores, si queréis 32 colores ponéis 40, si queréis 64 colores ponéis 80 y si queréis 128 colores ponéis FF.
Perfecto, con eso hacemos que el juego cargue mas paletas, pero ahora necesitamos repuntear la paleta original a un lugar vacio para poder meterle mas colores. Lo que hacemos es irnos hasta nuestro punto de anclaje con HxD y cambiamos la dirección por una dirección vacia (Recordad que es Hex y que debe ir permutado).
Una vez hecho eso, solo tenemos que copiar los bytes de la paleta desde su antigua posición a la nueva, y una vez allí ya podríamos comenzar a agregar colores con APE.
Con eso nuestra paleta extendida ya estaría insertada, y para insertar el grafico con mas colores, me imagino que seria de la misma forma en que se insertan las portadas de 32 colores, o los worldmaps.
Sinceramente no estoy del todo seguro, podeis probar a insertar el grafico usando el método de Koder para las portadas de 32 colores, o bien podeis insertarlo como si fuese un worldmap. Si no sirve de una, probad de la otra.
En fin, lamento no poder comprobar esto. En teoría debería ser cierto, ya que otros Asmers como Driver y Sonicarvalho me han confirmado que debería poder extenderse los colores de esta forma.
De todas formas recordad que es algo que no he podido comprobar debido a que estoy de vacaciones, pero agradezco a cualquiera que lo pruebe y exponga sus resultados en este tema.
Y como no podia faltar:
¡Que siga el auge investigativo en wah!
:furia:
En fin, lo siento también por no haber testado esto, pues no estoy en condiciones de lo hacer.
Si, en teoría es posible. Solo hay un pequeño problema que no te he hablado por no me haber recordado. No sé si conoces las áreas de memoria del GBA.
Esas son:
00000000-Bios (16kb)
02000000-EWRAM (256kb)
03000000-IWRAM (32kb)
04000000-I/O (Input/Output) (1kb)
05000000-Palette RAM (1 KB)(256 BG colors, 256 OBJ colors)
06000000-VideoRAM (96 KB)
07000000-OAM (object attribute memory) (1 KByte)
08000000-ROM (32Mb's MAX)
0E000000-Save RAM (32/64 Kb)
Como te he dicho en MSN, las 256 colores (excluido 8Bpp's) son posibles usando 16 palletas de 16 colores cada una (16*16=256).
Si, tengo cuasi la certeza que esto resulta pero, en teoria, al cargar 2 palletas, vas a sobrescribir la paleta 2 que ya estaba usada por otra cosa cualquier (toma de ejemplo las paletas del OverWorld, de los tilesets. Solo hay 12. Porque? Porque las otras 3 son para las cajas de mensaje y otras cosas), pues la area de palletes del GBA no "incrementa" solo por se cargar 2 paletas.
Así que este método debe ser utilizado con precaución, solo en situaciones especiales, como en portadas, que las paletas son utilizadas todas para la portada, o el WorldMap, y nunca cuando la paleta siguiente es utilizada por otras cosas.
Atención: Esto es todo teoría, entonces no sé si el metodo funciona.
Bueno, es solo para dejar ese aviso. ;)
Saludos de Sonicarvalho
Bueno amigo, es cierto que el apartado de la ram dedicado a las paletas es bastante bajo en comparación con el resto.
No obstante, debo recordarte que nintendo rara vez aprovecha al maximo la capacidades de sus consolas (En espacial hablando de Pokemon), esto significa que a pesar de ser solo 1 Kb de memoria libre para paletas, aun hay mucho espacio libre en ese unico kb.
Solo fijate en el palette viewer del VBA y mira las paletas para el worldmap, con eso veras que hay muchos espacios en negro, espacios que son perfectamente aprovechables para meter mas paletas por grafico.
Algo parecido ocurre con la portada, el logo de pokemon practicamente se come toda la memoria de las paletas, sin embargo, si miras bien, veras que muchos de los colores que consume ni los utiliza, o solo se muestran en unos pocos pixeles. Estos colores inutiles pueden ser reemplazados para extender la paleta de la portada. Y de hecho, scarex hizo eso en su hack "Pokemon Mirage", solo que no fue cambiando el mov, pero en efecto, uso parte de los colores del logo de pokemon para hacer un total de una portada de 64 colores (Esto lo hizo sin joder el logo, OJO).
Esto nos deja con algo sencillo, siempre que querais expandir una paleta, mirad primero cuanto consume en PRAM (Usad el palette viewer para eso), asi sabran cuanto espacio les queda para meter mas colores.
:D