El raw es otra imagen/fichero que está en un offset diferente al del tileset. Simplemente busca el offset del tilemap (raw) y sustituye la información por tu nuevo tilemap// inserta tu nuevo tilemap y repuntea.
El raw es otra imagen/fichero que está en un offset diferente al del tileset. Simplemente busca el offset del tilemap (raw) y sustituye la información por tu nuevo tilemap// inserta tu nuevo tilemap y repuntea.
No creo por que aunque no lo creas aparece como si fuera un un raw sin comprimir y pregunte a ruki y al parecer es como si fuera el raw solito pero en hexadecimal.
Además de que ese raw no se encuentra lo he buscado tanto en la carpeta graphic como en la rom mediante hex y con programas y nada.
Como ya comenté en otro tema, te recomendaría mirar esos ficheros en pokeruby, para ver rápidamente que es lo que ocurre en realidad.
En cualquier caso, abre los tools del emulador y abre el log/registro. Tienes que seleccionar únicamente SWI para que en el log aparezcan las instrucciones de la BIOS.
La idea es que vacíes el log y lo abras mientras estás cargando el menú que contiene la imagen. De esta manera, en alguno de los CpuSet o de los LZ77UnCompVram tiene que haber una referencia a los datos del tileset y del tilemap (Al producirse la carga de estos de ROM a VRAM).
Enhorabuena, el offset del tilemap es 0x8E8CAC0 y no está comprimido en lz77. (esto lo he hecho para la trainer card).
Ambas instrucciones (CpuSet y Lz77...) lo que hacen es pasar información de una dirección de memoria a otra. Puedes ver la dirección de memoria del tileset y el tilemap en la VRAM (por lo que tendrás la dirección de destino), ahora ya solo queda buscar una instrucción con ese destino y ver la dirección de origen. Esta operación se repites hasta que la dirección de origen sea una dirección del ROM (el offset donde se encuentra la información).
Si la información es pasada por un LZ77UnCompVram, está comprimida en lz77. Si es pasada por un CpuSet no está comprimida.
PD: Los tilemaps y tilesets de tilemap creator son generados sin compresión lz77. Es bastante probable que el programa que uses para insertarlos sea el que está generando la compresión.
Como ya comenté en otro tema, te recomendaría mirar esos ficheros en pokeruby, para ver rápidamente que es lo que ocurre en realidad.
En cualquier caso, abre los tools del emulador y abre el log/registro. Tienes que seleccionar únicamente SWI para que en el log aparezcan las instrucciones de la BIOS.
La idea es que vacíes el log y lo abras mientras estás cargando el menú que contiene la imagen. De esta manera, en alguno de los CpuSet o de los LZ77UnCompVram tiene que haber una referencia a los datos del tileset y del tilemap (Al producirse la carga de estos de ROM a VRAM).
Enhorabuena, el offset del tilemap es 0x8E8CAC0 y no está comprimido en lz77. (esto lo he hecho para la trainer card).
Ambas instrucciones (CpuSet y Lz77...) lo que hacen es pasar información de una dirección de memoria a otra. Puedes ver la dirección de memoria del tileset y el tilemap en la VRAM (por lo que tendrás la dirección de destino), ahora ya solo queda buscar una instrucción con ese destino y ver la dirección de origen. Esta operación se repites hasta que la dirección de origen sea una dirección del ROM (el offset donde se encuentra la información).
Si la información es pasada por un LZ77UnCompVram, está comprimida en lz77. Si es pasada por un CpuSet no está comprimida.
PD: Los tilemaps y tilesets de tilemap creator son generados sin compresión lz77. Es bastante probable que el programa que uses para insertarlos sea el que está generando la compresión.
Hice eso y solo aparece la imagen en ningún momento aparece el raw y descubrí que solo hay 3 raws pero no se explicar como funcionan, el caso es que esos 3 raws solo sirven para la caja que serian estos:
Aunque no parezcan son dos diferentes dentro de la rom y hay un tercero que no carga tmc que corresponde a estos:
Por desgracia el raw de este no se encuentra:
Ni buscando con Logging ni en los archivos de pokeruby.
Por eso pedi ayuda por que los busco y los busco y nada que aparece
Estos son los archivos:
Estos son los raws y la imagen:
El de color rojo es el Tileset
Los de color azul son los Raws, pero son los que ya mencione anteriormente.
ahora acerca de lo que mencionas de el programa que comprime los raws así se modifican generalmente pero descubrí que este pasa el raw directamente osea en formato hex sin pasarlo por un programa de compresión del raw y en los documentos de pokeruby hace lo mismo lee el codigo completo y lee 1200 bytes lo que vendría siendo la mitad por que son pares de bytes.
Por ejemplo este es el raw de las imágenes que mostre:
Pensé que estabas mirando el archivo erróneo en el repositorio de github.
Ese enlace que te pasé es el código de la naming screen de pokemon ruby, si quieres entender algo (como por ejemplo cómo y cuándo se carga el bg y el tilemap que buscas) deberías echarle un ojo.
Pensé que estabas mirando el archivo erróneo en el repositorio de github.
Ese enlace que te pasé es el código de la naming screen de pokemon ruby, si quieres entender algo (como por ejemplo cómo y cuándo se carga el bg y el tilemap que buscas) deberías echarle un ojo.
No, pero aun asi vere como funciona con ese que manaste muchas gracias, el problema es que no solo pasa con este gráfico hay varios que se manejan así tanto en FR como en Ruby, preguntando a ruki me dijo que esa era la manera antigua en gbc tanto en binario como decomp para crear los raws, lo cual hace mas complicado saber donde estan y como formarlos ya que no todos aparecen, en este momento me veo en el mismo caso con los datos de la trainer card de pokeruby y la pokedex de pokefirered
Oh ya veo, la ultima duda espero la puedas responder, supongo que este método fue usado para la pokedex significa que si busco en el archivo pokedex_screen.c podre saber todos los datos de los gráficos ¿cierto?
Oh ya veo, la ultima duda espero la puedas responder, supongo que este método fue usado para la pokedex significa que si busco en el archivo pokedex_screen.c podre saber todos los datos de los gráficos ¿cierto?
Lo que han hecho con el naming screen de ruby es una chapuza, seguramente lo hicieron en fases tempranas y se quedó así (en emerald refactorizaron el código).
He revisado por encima la parte de la pokedex (pokedex.c), y el cargado de los gráficos sigue un proceso normal.
El primero es el tileset y los otros dos parecen ser tilemaps, por las direcciones de VRAM en las que se descomprimen. En este caso tanto tileset como tilemap llevan compresión Lz77.
Oh ya veo, la ultima duda espero la puedas responder, supongo que este método fue usado para la pokedex significa que si busco en el archivo pokedex_screen.c podre saber todos los datos de los gráficos ¿cierto?
Lo que tienes que hacer es mirar el archivo para ver cómo se cargan, Samu te ha explicado que esa sigue el proceso normal.
Me hace mucha gracia que tengas "el puto amo del rom hacking" en tu canal de youtube pero no entiendas cosas básicas de la carga de tilemaps o cómo funciona una capa de vídeo en GBA, curioso cuanto menos.
Lo que tienes que hacer es mirar el archivo para ver cómo se cargan, Samu te ha explicado que esa sigue el proceso normal.
Me hace mucha gracia que tengas "el puto amo del rom hacking" en tu canal de youtube pero no entiendas cosas básicas de la carga de tilemaps o cómo funciona una capa de vídeo en GBA, curioso cuanto menos.
Que mal andas jaizu, es obvio que soy nuevo en esto, eso del "puto amo" es un banner hecho por un sub que me dijo que si lo podia poner y lo hice en agradecimiento no significa que me lo crea, ahora les agradezco a ambos por la ayuda y si ves algun mensaje mio jaizu pues dejalo asi no pasa nada prefiero a que me vengas a quere sobajar.
@Samu Muchas gracias por ayudarnos a buscar el gráfico debido a que kakaroto también había querido ese dato.
@Jaizu Gracias también a ti aunque tu manera de ver a los demás sea como tontos.
¡Es más fácil en nuestro Discord! Actualmente la comunidad está más activa en nuestro Discord oficial. Todavía puedes crear tu duda aquí si lo prefieres, pero recuerda que estamos en Discord para poder ayudarte de una forma más ágil.