vale, voy respondiendo:
De hecho ahí viene la pregunta noov de turno.... ¿qué implica el CFRU? ¿Qué hackroms conocidos hay implementando ello?
sanslash332
El CFRU (Complete Fire Red Update) suele ser lo que se utiliza en el caso de Rojo Fuego para añadir lo típico de nuevas generaciones. Separación de movimientos en físico-especial, tipo Hada, megaevoluciones, movimientos Z...). Hay muchísimos hacks que lo utilizan a día de hoy, pero si tuviera que mencionar mis dos favoritos son Pokémon Unbound y el más que repetido Radical Red. El Unbound tiene una historia simplemente brutal, todo lo que mencioné anteriormente, pokémon hasta la 8ª generación, una especie de frente de batalla... Radical Red es simplemente Pokémon Rojo Fuego pero con un buen reto que superar solamente en su modo de juego normal, tiene varios además de este. La diferencia fundamental con el Unbound en cuanto a características es que incluye Pokémon y movimientos hasta la 9ª generación. Todos los movimientos, habilidades y objetos no, pero sí incluye los 1025 pokémon existentes. Si bien falta alguna forma por ahí, son las formas que solo presentan un cambio estético (las formas de Vivillon, por ejemplo).
también ¿sabes si el pokemon ketzal está hecho de un decompilado? o es un hackrom clásico.
Porque el script no detecta nada, pero no crashea. y con la t, sí lee la pantalla jaja.
sanslash332
No, nunca lo probé, pero si con la T lee está clarísimo que no es un decompilado. Si fuese un decompilado lo más seguro es que lo primero que dejara de funcionar fuese la lectura de pantalla completa.
Ya pasando eso...
Veamos si hjay cositas que citar:
hum. sugerencia loca...
¿no existiría quizás... una manera de crear una expanción para estas decopilaciones que ayude con la accesibilidad?
Si el juego está decompilado completo. y se tiene acceso a su código...
Jugando con ese código base, y toda la programación que tienes dentro del juego por ejemplo... ¿no se podría transcribir todo el script y sus funcionalidades a una expanción para aplicar a firered y emerald?
Y para tirar el texto al lector de pantalla, ahí es donde puedes jugar con lua. Si tienes el código a tu mano, podrías reserbar un bloque pequeño de memoria, que sea para mensajes de salida de la expanción del lector. así el script lo único que haría sería monitorear ese espacio de memoria, y cada vez que cambie, manda el contenido de ese espacio de memoria al lector de pantalla.
Pero todo el códiogo del path finder, lectura de pantalla y tal (menos el OCR de la t) podría ir dentro del juego. Teniendo acceso a las funciones directamente y pudiendo interceptarlas para mandar su contenido a este espacio de memoria, quedaría una expanción ultra poderosa y aplicable a cualquier hackrom.
Claro, requiere que los devs tomen esta expanción y la quieran aplicar, pero la opción estaría ahí.
Y obviamente dejas que se active / apague con un flag, o no sé, una convinación de botones rara de la GBA.
Es ultra loco lo que digo, pero no lo veo imposible.
sanslash332
Mmm... se podría diseñar algo como lo que hay en la GB. Un espacio de RAM en el que se guarde una copia de la pantalla en todo momento y ya, sin tener que andar a vueltas con menús, listas, ventanitas, backgrounds y todo el circo que eso conlleva. El problema es que la GBA funciona de forma muy distinta. Habría que ir modificando cada una de esas funciones, crear un espacio completamente nuevo para eso... no tengo claro hasta que punto sería viable. Además, si luego un desarrollador no lo aplica, no se podría hacer nada con ese juego. Básicamente, habría que coger las decompilaciones y crear juegos nuevos con ellas. Eso ya sin contar todo lo que implicaría el buscarrutas. Y lógicamente, para que el juego no casque, eso habría que configurarlo con combinaciones de teclas de la GBA. Obviamente no se puede diseñar desde el punto de vista de un emulador, porque todo esto se programa pensando que va a ir a una GBA y ya. Ciertamente lo más viable sería hacer algo estilo Manamon, con soniditos en el ambiente para ubicarnos y esas cosas, pero poco más, la verdad.
En resumen, no vale la pena en lo absoluto.
Al menos que... no sé ubiese una manera de que el juego imprimiese la lista de sus direcciones de memoria después de una compilación y parchease el script automáticamente. jajajaja
sanslash332
Y la hay. No es que la haya, sino que es que cuando compilas una ROM, quieras o no el compilador te tira ese archivo con todas las direcciones. Sí, algo así automatizaría el proceso de forma interesante. Se le pasa el archivo con las direcciones de la versión que tiene Pokémon Access, se le pasa el archivo con las direcciones de la nueva versión, se le pasa el memory.lua y que trabaje. El problema es que todo lo que son funciones static no figuran como direcciones de memoria. Eso sin contar que en muchísimas funciones no vale con la dirección de memoria de la función, hay que utilizar un punto concreto en la función cuando se ejecuta x instrucción, porque es ahí y no antes ni después, por ejemplo, cuando se puede acceder al ID del movimiento que se está seleccionando para que el script sepa como manejarlo.
Pero sí, estoy diseñando, entre mis múltiples proyectos relacionados con esto, un adivinador de funciones. De hecho en la versión de desarrollo que tengo para CFRU ya lo tengo integrado y es capaz de adivinar dos o tres funciones con total precisión.
Esto lo hice porque el CFRU, aunque en su mayoría no toca las direcciones de memoria originales, para cosas nuevas que añade sí hacen falta nuevas direcciones de memoria. Y claro, como cada hacker el CFRU dentro de la ROM lo mete donde le da la gana pues... no creo que haya dos ROMs que comparta alguna de estas direcciones de memoria. Así, por ejemplo, hay un par de funciones que en Pokémon Unbound y Radical Red están en sitios totalmente distintos, pero la expansión del CFRU no necesita ni saber que dirección tienen en cada juego. Simplemente le paso a la función ubicadora unos parámetros identificativos y ella sola obtiene la dirección de cada juego.
Anda, esto ya suena aún más profundo.
Te estás metiendo muy, pero que muy abajo. ahora más allá de la memoria...
¿como que cosas has podido entender de las instrucciones del procesador?
Para lo que es la nintendo ds ¿tendrías que estudiar también el otro procesador?
sanslash332
Bueno, tengo el ARM7 bastante controlado, por lo menos en lo que se refiere a instrucciones de 16 bits. Para mis investigaciones estuve meses toqueteando el Radical Red porque tenía bugs (sí, lo menciono mucho, pero al final para hacer este tipo de experimentos los hacks son los más idóneos, y más teniendo el código base del CFRU que también tiene partes en ASM. Tenía alguna que otra función bugueada (el sonido del movimiento vozarrón metía unos petardazos espectaculares, y cabe destacar que esto no es fallo del hack, sino del Rojo Fuego original. Estudié el código del mismo movimiento en Esmeralda, y rediseñé la función por completo en ensamblador.
Sí, la DS usa muchísimo más el ARM9 que el 7. El 7 creo que lo usa para leer los cartuchos de GBA (obviamente) y luego dentro del sistema DS para emular sonido, Wi-Fi y no sé si alguna cosa más. En resumen, que cuando los juegos de DS estén aptos para toquetearlos y el script también... habrá que aprender otra arquitectura.
Hum...
supongo que la segunda medición eran 16.x MS y no S, porque cuando leí solo segundos.... Uf ¡si que se demora!
Fuera del chiste... claramente ahí hay algo mal xd.
sanslash332
Mmm... sip, me faltó una m jajajajajaja. Según el desarrollador principal de mGBA lo que falla es la optimización de Lua en mGBA. Pero vamos, que revisando el script entero, incluso la base que utilicé del viejo Crystal Access, no está nada bien optimizado. Sí que trabajé en la optimización del motor de textos en GBA, pero la gestión de mapas, listas de objetos, buscarrutas... podía estar muchísimo mejor.
A ver, te comento lo que yo me acuerdo.
Lo que más han dicho la gente, es la falta de lectura en el menú de esmeralda cuando hay que reemplasar un ataque por otro.
Ya luego lo que yo detecté, es que la función del shift+0 para asignar hacks nunca he podido hacerla funcionar correctamente.
En muchos roms que el script no los detecta para nada como un pokemon, al precionar el comando el script crashea y se cierra. Solo el script, no el emulador.
Lo reinicializas, y si pulsas shift+cero, no pasa nada.
Por lo mismo no entiendo cuál es el sha1 que hay que sacar del rom info para incertar en la lista de hacks uwu.
Lo cyurioso, si no mal recuerdo el aniversary edition.o el clear cristal (uno de esos dos que no logro echar a andar con la versión actual del script) me pareció que sí tiró con la vieja versión de tspivey.
¿por qué eso?
sanslash332
Porque ese script se centraba solamente en Cristal. No se andaba con rollos de comprobar si checksums, si hack, si no hack... Cargaba el juego y si el código coincidía con cristal tiraba para adelante, si no te mandaba a paseo.
Ah, y lo del shift +0 que a veces no iba ya está solucionado. Actualizados los links en el primer post (bueno, el de drive no que ese no hace falta actualizarlo, se actualiza solo jajajajaja).
ah! que bueno que mencionaste al tipejo ese del script del vizhawk... ¿sabes que onda con eso?
Lo siguió trabajando? o se quedó solo como un experimento que nunca más compartió?
sanslash332
Mmm... no, este no es el del script de BizHawk, este es el que mezcló cosas del Crystal Access y Pokémon Access para sacar un Emerald Access para VBA-RR. No sé, supongo que le gusta hacer experimentos varios, pero imagino que solo saca algo cuando es usable. Recuerdo que en su momento hizo cosas que desde mi punto de vista eran bastante extrañas (añadir teclas para saber que objeto tenía cada pokémon salvaje en combate y cosas así que el juego no te deja ver hasta que lo capturas) pero bueno, ni idea. Dice que tiene un script de accesibilidad para pokémon que funciona en BizHawk, VBA-RR y mGBA pero es lo que decía, a costa de no tener sincronía con el emulador, con Lua yendo un poco por libre. Sí, a mí me parece muy interesante que Lua tenga su propio proceso, pero siempre que esté en sincronía con el emulador, y eso es lo que le decían el otro día los desarrolladores de mGBA en el discord.
La verdad todo sea dicho, en su momento consiguió el código fuente de las DLLs del Crystal Access original (creo que se lo había pedido al propio Tyler Spivey) y hablando con él me los pasó. Simplemente no compartimos las mismas prioridades en cuanto a programación.
*En muy contadas ocasiones había que mover al personaje de lugar para que detecte un camino. No recuerdo si me ocurrió en un juego principal o en un hack, probablemente fue lo segundo jajaj.
Alejandro73
Seguramente en Esmeralda. Creo que había por ahí un bug con los árboles de bayas, que por algún motivo el script asumía que se ponían a pasear como si fueran entrenadores, no sé en que momento asumió que nos habíamos cambiado de franquicia al Señor de los anillos...
Este bug, si es lo que creo, no lo voy a poder arreglar del todo hasta la próxima actualización oficial. Recuerdo que había que crear varias funciones nuevas, variables, direcciones de memoria para cada juego... en la versión de desarrollo sé que está arreglado, pero se me hizo ahí tal lío que ni recuerdo qué toqué.
*en ocasiones no se leen los menús al mover el cursor, me ha pasado con Radical Red y Esmeralda en español.
Alejandro73
Y Esmeralda en inglés. Sobre todo con los menús de aprender movimientos, es una auténtica pesadilla. Es una de las cosas que me tienen el código más desgraciado. Hasta hoy aún no lo pude solucionar como me gustaría.
*No sé si esto puede cambiarse, pero hay un punto en la ruta 111 que no te deja avanzar por la tormenta de arena, pero si vas a la derecha se puede continuar a la siguiente ruta sin problemas. EL juego no detecta esta posible salida. Creo que hay un caso similar con la Ruta 5 de Rojo Fuego en donde sí detecta los diferentes caminos. En todo caso, es posible que el jugador pueda crear un nuevo objeto para buscar? Podría servir para aquellas cosas que el juego detecta como un sprite y no como un objeto rastreable, como trepa rocas o los dinamax en Pokemon Unbound o el NPC de la casa treta en Esmeralda.
Alejandro73
Sí, se podrá cambiar. Habrá una nueva tecla que alternará entre Camino 1 y Camino 2 para ir a una Ruta, eso es la solución a este problema.
*Recuerdo que en audiogames pasaste una carpeta para que Crystal Clear funcione mejor. ¿Hay chance de agregarla al script base?
Alejandro73
Ya estuvo en el script base. Como la gente empezó a volverse loca con los hacks, quité todo lo que no fueran oficiales. De ahí la idea de las expansiones. Cada uno tiene eso, que lo use como quiera. Pero la carpeta del Crystal Clear que compartí se puede añadir sin problema al script y funciona, solo hay que copiarla y pegarla en la carpeta game (creo que era, porque actualmente la estructura de eso cambió un poco).
Yo creo que tengo por ahí algunos otros. Tengo una para el Radical Red (al margen de las expansiones), otra para el Unbound.... Pero tienen lo básico, si no recuerdo mal.
Y ahora que acabé con las respuestas...
enlaceQuería hacer una demo un poco en orden en base a todo lo comentado. Empezar por el CFRU mostrando el funcionamiento del Radical Red y englobar también los cambios que le realicé (que los notará sobre todo quien ya haya jugado a esto) y luego seguir ya con Rojo Fuego y Esmeralda mostrando las nuevas funciones. Sin embargo, este pedazo audio de 13 minutos se convirtió en un par de combates en el Radical Red y luego una incursión Dinamax que... bueno, dura más de 10 minutos pero no quería cortarla. Así que iré por fascículos y ya puestos, para quien no conozca estos hacks los puede ir conociendo un poco jajajajaja.
En estos días subiré lo que no pude grabar de los oficiales como Rojo Fuego y Esmeralda.
¡Saludos!
