inv_base
Thread Id: 12355
Thread Name: [GBC]Teoría de aumentar la Pokédex a 512 (por koolboyman)
Esta teoría no es mía, sino de koolboyman, la posteo aquí para que más gente la conozca y pueda ayudar en la investigación.
Iniciado por koolboyman
I had an idea a while back for what I believe, the easiest way to increase the maximum Pokemon slots to 512.
My idea was to make use of the Pokemon's level byte since it is defined every time a Pokemon is called. The highest bit of the byte is always off since the maximum level is 100 and for that bit to be on the level would have to be at least 128.
What need would be done:
- Special code every time a Pokemon is called to disregard the last bit of the level variable when assigning a level, and putting that bit to use. Wild Pokemon, Pokemon added to your party, Pokemon given as a gift, Pokemon in a trainer's party, etc.
- When the bit is on, to read from a separate table for the following:
* Names
* Base Stats table
* Crys
* Pictures
* Moves and Evolution Data
* Colors
* Icons on the menu
* RAM Addresses of the second Pokedex Seen/Own boolean arrays, or to just expand the existing ones.
* Print Pokedex Numbers + 256 whenever the Pokedex variable is displayed.
* Anything else I can't remember at the moment. Feel free to bring them up.
- The only instance I can think of at the moment where a Pokemon is defined without it's level is the new Pokedex Order and ABC order. You would have to write new code to accept a ninth bit for those, and additional code to support the new ID number order.
Easier said than done obviously. Would anyone be interested in it's implementation? I'm sure it can be used for Red as well (The workaround for the trainer bytes for Brown was that the Pokemon with index numbers C9 and above would never be encountered in the wild. When called any other way they appear as normal Pokemon).
Traduzco:
Tuve una idea hace un tiempo sobre la que creo que es la forma más simple de aumentar el número máximo de Pokémon a 512.
La idea es usar el byte del nivel del Pokémon, ya que es definido siempre que un Pokémon es llamado.
La parte alta del byte está siempre apagada porque el nivel máximo es 100, por lo que para que estuviera encendida, se necesitaría al menos que el nivel máximo fuera 128.
¿Qué se necesitaría hacer?
-Un código especial que, cada vez que un Pokémon es llamado, ignorara el último bit de la variable de nivel cuando se está asignando un nivel y usarlo para los pokémon salvajes, en tu equipo... etc
-Cuando el bit esté encendido, que lea de una tabla diferente las siguientes cosas:
•Nombres.
•Stats base.
•Gritos.
•Imágenes.
•Movimientos y datos de evolución.
•Colores.
•Iconos del menú.
•Direcciones de la RAM de las series de pokémon vistos y capturados o expandir la actual.
•Imprimir los números de la Pokédex mayores de 256 cuando la variable de la Pokédex aparezca.
•Alguna cosa más que se me escape, sois libres de añadir lo que veáis oportuno.
-El único lugar donde los Pokémon no aparecen es en el Nuevo Orden de la Pokédex y en el orden alfabético, ahí habría que añadir un código extra para aceptar un noveno bit y código adicional para permitir el nuevo orden de números de ID.
Es mucho más fácil decirlo que hacerlo, obviamente, ¿Estaría alguien interesado en su implementación?
Estoy seguro de que funcionaría también en Red.
Fin de la traducción, ahora hablo yo ;)
He posteado esto principlamente para que los interesados en este tema de WaH aporten sus ideas y ayuden al desarrollo de el RH de gbc (y quién sabe si del de gba también). Sé que hay gente aquí que sabe de scripting avanzado y ASM por lo que espero respuestas ^^
Pues eso esperemos, que en GBA también se pueda, porque en Oro, Plata y Cristal casi nadie se detiene a observar que son unos juegos que, con las herramientas adecuadas, sería maravilloso de Hackear. El problema no es de las herramientas, sino de el Juego en sí, y este es el primer paso para ampliar las fronteras del Juego. Enhorabuena a koolboyman y a ti, Gallego, que has posteado esta herramienta. El día en que exista una cosa similar para GBA, empezaremos una nueva era del Rom-Hacking.
@mikelan98: me alegro que te guste ^^
Esto no es una herramienta, es más bien una modificación que seguramente salga como un tutorial o un .ips y aún no está ni empezada, es sólo una idea genial con la que espero que colaboréis.
Te falto el link del tema original...
-On topic-
La idea es sencillamente genial, creo que me pondré a hackear el Pokémon Gold...
Iniciado por Tay
Te falto el link del tema original...
-On topic-
La idea es sencillamente genial, creo que me pondré a hackear el Pokémon Gold...
Ouch! Perdón, el link al tema original es este:
http://hax.iimarck.us/topic/1284/
Gracias Tay, toda ayuda es bienvenida :awesome:
La teoría es genial, intentare un poco con rom de GBC!!
Me parece super interesante, si lo pudiéramos adaptar a GBA sería sensacional, y daríamos un GRAN salto en lo que el hacking GBA se refiere.
Ojalá vaya bien las cosas, y se pueda realizar en un futuro no muy lejano. (:
La verdad que sí, concuerdo con Angelo, sería muy
bueno para el Hacking GBA, aunque preferiría Estudiar
más el NDS, se que no hay muchos, pero yo ahí estoy,
no hackenadolo, si no estudiándolo, y creo que adoptar
eso en el GBa, deberás si que sería muy bueno.
Eso es todo Gender
q tal muchachos , si en algo cuenta mi opinion.... ami me parece algo realmente fantastico , espero q no solo se quede como una teoria, si en algo puedo ayudar espero cuenten conmigo seria realmente genial poder insertar mas pokemon en el GBC ya que mas q el GBA me encanta el GBC porque es original y unico :P ... espero q continuen con este proyecto
Muy util en verdad, para agregar algunos Pokes de 3ra-6ta gen o incluso crear los tuyos. :D
que tal eliminar el sistema de leveo de por si? en ves de "raised" por peleas, hacerlo con iron y demas cosas que usan para aumentar stats (en un nivel mayor a lo que el juego permite) no se mucho sobre romhacks pero mientras leia eso, pense en esa posibilidad para reducir bytes. Es posible siquiera?
Pues no me parece una idea coherente para ningún RPG, siempre son necesarios los niveles para establecer el poder y la resistencia, asi como el crecimiento de algun personaje debil que derrota a uno mas fuerte, aunque he de decir que me parece curiosa la idea que planteas, pero al final no es la finalidad de este post.
Agrego que al momento, RED, de Sketeendo, por fin logro romper la barrera de los 254 pokemon y estaba trabajando en una base con 512 espacios, sin embargo su trabajo esta detenido (falta de interes) y no ha revelado la informacion.
Hablando en general, la idea de aumentar a 512 me parece factible pero lo veo mas como un proyecto enfocado a que trabajen varias personas debido a la cantidad de esfuerzo y sobre todo tiempo que requiere. Siendo sinceros, la única opción que me parece viable es trabajar sobre la dissasembly de crystal.
Yo no tengo ningún interés personalmente (hablando desde el punto de vista de posibles requerimientos o ideas para mis hacks), pero sin duda que puede ser un proyecto ambicioso en el que estar si se pudiese llevar a cabo entre varias personas y de forma organizada.
Iniciado por Crystal_
Hablando en general, la idea de aumentar a 512 me parece factible pero lo veo mas como un proyecto enfocado a que trabajen varias personas debido a la cantidad de esfuerzo y sobre todo tiempo que requiere. Siendo sinceros, la única opción que me parece viable es trabajar sobre la dissasembly de crystal.
Yo no tengo ningún interés personalmente (hablando desde el punto de vista de posibles requerimientos o ideas para mis hacks), pero sin duda que puede ser un proyecto ambicioso en el que estar si se pudiese llevar a cabo entre varias personas y de forma organizada.
Y si tu y yo trabajamos en eso?
De un tiempo para acá somos mas investigadores que nada, asi que seria un buen recurso para compartir con la internet. No me parece impedimento trabajar sobre el dissasembly de crystal y despues hacer una pequeña adaptación para GS.
Podemos ir publicando la investigación en el foro por si alguien mas esta interesado en unirse.
Una "pequeña adaptacion" a GS como dices tu lamentablemente no es posible. En inviable bajo mi punto de vista trabajar en esto sin algo capaz de compilar asm. Cada pequeño cambio que quieras hacer en un lio de hacer saltos aqui y alla y al final es facil perder el norte.
Creo que en general es mas trabajo de lo que piensas incluso sobre crystal ya que hay millones de referencias a pokemon en diferentes tipos de rutinas que habria que convertir de 8 a 9 bits de alguna manera. Personalemente me gustaria acabar mi hack antes de empezar a pensar en trabajar en esto de forma seria.
Debido a las insistencias de [MENTION=26330]Chamber[/MENTION] sobre llevar esta idea a la realidad, he decidido forkear (crear una copia) de pokecrystal.asm con objeto de trabajar sobre ella. Quien quiera apuntarse a este proyecto que me lo haga saber por VM/PM. Evidentemente se requieren conocimientos de asm. Es necesario que quien quiera contribuir se cree una cuenta en
Github para que yo luego pueda hacerle colaborador del repositorio.
La cantidad de trabajo es inimaginable debido a la cantidad de rutinas que va a haber que modificar. Por decirlo asi, hay que convertir cada mención de un Pokemon de 8 bits a 9 bits. Dad por hecho que seria un trabajo de años, si es que se termina.
https://github.com/xCrystal/pokecrystal511
Esto es lo que he hecho hasta ahora, simplemente por el hecho de empezar.
https://github.com/xCrystal/pokecrystal511/compare/kanzure:master...master
Mi idea es llevar las tables de basedata a una bank vacia (bank 79) y añadir la segunda tabla inmediatamente despues (los cambios en getbasedata estan hechos en base a esto). El espacio libre de la bank donde se encontraban los base stats (bank 14) se puede usar por ejemplo para ampliar la tabla de nombres en ese mismo banco y puede que para otras cosas.
Estoy teniendo problemas para editar main.asm debido a su tamaño; simplemente habria que llevar los includes de las dos tablas a la bank 79 (y quitar el include de la bank 14).
Ese [MENTION=26330]Chamber[/MENTION] es un enfadoso...
Iniciado por Crystal_
Por decirlo asi, hay que convertir cada mención de un Pokemon de 8 bits a 9 bits....
Creo que la cosa no deberia ser asi.
Convertir las menciones a 9 bits implica muchismo tiempo y esfuerzo, eso lo comprendio KBC y supongo que RED. Lo mas facil es lo que Koolboyman plateo, usar el ultimo bit del nivel de cada pokemon para indicar a que tabla pertenece, de esta manera cubres la gran mayoria de las tablas, como la de pokemon salvajes y entrendores/gym leaders, asi incluso la edicion de cada pokemon solo implicaria sumarle 128 niveles si se tratase de un pokemon por encima del +257.
En lo que tu preparas el repositorio yo puedo empezar a investigar cuantas rutinas son las que hay que modificar.
Por cierto, le pedi a RED si nos facilitaba una copia de su trabajo para usarlo de comparativa, espero nos sirva.
Creo que la cosa no deberia ser asi.
Convertir las menciones a 9 bits implica muchismo tiempo y esfuerzo, eso lo comprendio KBC y supongo que RED. Lo mas facil es lo que Koolboyman plateo, usar el ultimo bit del nivel de cada pokemon para indicar a que tabla pertenece, de esta manera cubres la gran mayoria de las tablas, como la de pokemon salvajes y entrendores/gym leaders, asi incluso la edicion de cada pokemon solo implicaria sumarle 128 niveles si se tratase de un pokemon por encima del +257.
En lo que tu preparas el repositorio yo puedo empezar a investigar cuantas rutinas son las que hay que modificar.
Por cierto, le pedi a RED si nos facilitaba una copia de su trabajo para usarlo de comparativa, espero nos sirva.
Era solo una forma de hablar. El noveno bit es necesario venga de donde venga. Es algo asi lo que he pensado, pero es mas complejo de lo que piensas. Hay varias direcciones RAM u estructuras que pueden albergar el numero de la especie del pokemon con que se esta tratando.
Estas son las relaciones a las que he llegado hasta ahora:
CurPartySpecies <-> CurPartyLevel MSB
(Temp)EnemyMonSpecies <-> EnemyMonLevel(?)
(Temp)BattleMonSpecies <-> BattleMonLevel(?)
Box struct: Species <-> Level MSB
Battle struct: Species <-> Level MSB
CurSpecies <-> BaseStatsTableNo LSB
Es decir, cada vez que species se carga en curspecies, cargar 0 o 1 en c840 en funcion del bit mas significativo del nivel que corresponda. He modificado la rutina GetBaseLevel para que lea los base stats de una u otra tabla segun ese bit:
https://github.com/xCrystal/pokecrystal511/blob/master/home.asm#L1768
Esto seria un ejemplo de como llamar al nuevo GetBaseLevel
Functiond906: ; d906
ld e, l
ld d, h
push hl
ld a, [CurPartySpecies]
ld [CurSpecies], a
call GetBaseData
becomes:
Functiond906: ; d906
ld e, l
ld d, h
push hl
ld a, [CurPartySpecies]
ld [CurSpecies], a
ld a, [CurPartyLevel]
and 1
ld , a
call GetBaseData
Puedes empezar a contribuir en pokecrystal511.asm desde ya. Tan solo necesitas crear una cuenta en github y decirme tu nick para hacerte colaborador.
Lo de llevarlo a la RAM me parece una gran idea, por que asi se arregla lo que mencionas de "curspecies".
El otro detalle es el del espacio en la ram para albergar la info del pokedex, aunque en GOLD si hay espacio en blanco no se si sea el mismo caso que Crystal.
Ojala mas gente se una a este proyecto, aunque en realidad es reducido el mundo GBC-ASM hispano.
No es que sea una gran idea o que no, es simplemente lo que hay que hacer. Es lo que implica requerir un bit adicional para cada instancia de pokemon. La especie de un pokemon puede pasar a traves de varias direcciones ram en funcion de para que se utilize y que rutina lo requiera. Evidentemente que si tomasemos el bit indistintamente de la estructura de las cajas en sram o de battlemon no cubririamos todos los casos.
Lo de la pokedex no me lo habia planteado pero ya llegaremos a eso. Bajo mi punto de vista es mejor dejar lo de la pokedex para el final cuando ya este organizado lo mas complejo. De todas formas se podria emplear otro banco de la wram.