Foros de tiflojuegos
Pokemon Access
-
ya decía yo que los gritos de NDS sonaban relativamente mejor que los de novena gen. Me alegro de que los hayan exportado de la DS y no resamplearon los modernos de X e Y.
-
@Alejandro73
Muuuuuchas gracias por el link del juego.
Voy a probarlo para ver como está. al menos esta versión.
Solo espero que el conocimiento lo liberen para poder agregarlo a los packs clásicos de construcción de estos juegos uwu.
¿Tiene soporte para lector de pantalla? o eso todavía es a puro OCR?
Y ¿¿en serio ya están disponibles por betas públicas?
¿No que eran solo para patreons?
nuive
Tengo una carpeta de Drive para las expansiones, sí, pero la verdad que no está como pública. Es buena
idea que la ponga y la añada al post principal, y así se pueden añadir más.
yep, hazlo. definitivamente es muy buena idea.
Ayudaría a mucha gente poder jugar esos hacks sin romperse mucho la cabeza. jaja
nuive
De alguna forma eso se podría utilizar, pero rompería toda la estructura de la pantalla (lo que viene
siendo el funcionamiento del motor de textos) y además estaríamos en las mismas. Como un hacker añada
más variables a su ROM no hay ninguna garantía de que la dirección de RAM sea algo constante. Por eso
sí, sería interesante un espacio fijo en la RAM para estas cosas, pero como digo, prácticamente habría
que crear otro motor específicamente para esto, y sería mucho más limitado. Mis esperanzas por ahora
están puestas en el ubicador este de funciones.
bueno. de partida sí que sería un motor completamente diferente jaja, estábamos hablando con el supuesto de trabajar con un nuevo motor convinado con código interno en los hackroms decompilados, básicamente. para poder hacerlos accesible de una manera, independientemente donde haya quedado la ram
pero na, no le des importancia aún a eso; es muy para el futuro.
Lo de la lectura eurística de la firma de funciones. tiene potencial. Bien algorítmico ese método realmente. xd
nuive
Hay que tener en cuenta que el CFRU es una expansión sobre la ROM original. Por esto, para llamar a las
nuevas funciones de una forma o de otra hay que modificar ciertas rutinas en las funciones originales,
pero como se modifican las funciones sobre la ROM original (no hay que recompilar nada) el único requerimiento
es que la modificación solo puede reemplazar bytes en la función original, no expandirse, y en esto me
baso.
Interesante. entonces el truco que hace esta gente, es agregar nuevas funciones en espacio del rom sin usar, y en las llamadas originales a la función, reemplasan el puntero viejo con el puntero hacia la nueva función, pero dicho puntero tiene que tener un tamaño similar al antiguo para que pueda calzar en ese lugar y funcionar sin inconvenientes. que interesante hmm
nuive
la dirección de la función original donde el CFRU almacenará la nueva dirección, y así calcula la dirección
de la nueva función para diferentes hacks o versiones, en tiempo real, cada vez que se carga el script.
simplemente hermoso. y se entiende perfectamente.
Esto lo hace en un startUp time?
el script cuando se inicializa hace una lectura de todo el rom buscando estos puntos dinámicos para prerar las funciones a tiempo?
O lo hace en runtime reconociendo un salto y yendo al salto a penas lo detecta, sin haberlo pre-procesado antes?
A lo que voy... ¿con lua tienes acceso a toda la memoria del juego?
O solo a la ram?
porque se me olvidó, la GBA carga todo el rom en ram a la hora de inicializarse? o el rom va cargando nuevos trozos a medida que son requeridos.
nuive
de operaciones en ensamblador para calcular donde termina esa función, y sabiendo donde comienza y termina,
utiliza dentro de esos límites diferentes estrategias como comparaciones de bytes, búsquedas de saltos
y cosas así.
sinceramente te fuiste a un nivel muy potente he.
Como se va dando vcuenta qué tipo de operación utilizar?
generaste algún algorítmo de cálculo, o un árbol de desición para saber como ir trabajando la función hasta que el script pueda reconocer todo lo que le interesa?
nuive
No es solo ese parche. Tanto CFRU como DPE (que es la parte de la expansión que se encarga de añadir
Pokémon, movimientos con sus animaciones, habilidades...) tienen algunos bugs. Por ejemplo, los gritos
de los Pokémon de cuarta y quinta generación están directamente extraídos de los juegos de DS sin modificar
la calidad. Si bien los gritos tienen una calidad máxima de 22kHz y por esto suenan mejor que los que
ya incluye Rojo Fuego (que son a 10,512kHz) esto implica ocupar más espacio en la ROM. Por este motivo,
en hacks como Radical Red, al añadir la novena generación (CFRU/DPE solo incluye hasta la octava) tienen
que hacer apaños que para nosotros, teniendo el sonido como fuente de información principal, no nos interesan.
En Radical Red 4.0 los Pokémon de la novena generación estaban a 44,1 kHz (quien fue el loco? ni idea)
y obviamente ocupaban casi todo el espacio de la ROM. En la 4.1 de repente todos los pokémon de la novena
tenían los gritos a 8kHz y eso se convirtió en un estropicio, empezando por el hecho de que sonaban muy
bajos y distorsionados. Ah, otra cosa, obviamente, es que las formas con gritos propios como las megas
no tenían esos gritos, solo los gritos normales con variación de tono.
Lo que hice yo fue equilibrar todos los gritos en volumen y frecuencia a 10,512kHz, de forma que quedaran
exactamente igual que los de las primeras generaciones que ya trae el juego. Con esto, incluso añadiendo
los gritos de las evoluciones, el espacio que ocupan los gritos es ahora de 5 mb aproximadamente (en
la 4.1 de Radical Red, aún con gritos a 8kHz los gritos ocupaban casi 8 mb). Y sí, aunque 3 mb parezca
una tontería, en una ROM donde el espacio máximo son 32 es una grandísima diferencia.
Definitivamente harto trabajo. mucho trabajo.
Tienen que amar tus pull-requests a estas alturas jaja.
Lo único fome de este método de hacking, si lo piensas, es el límite de tamaño de los roms.
Llegará algún momento en que ya simplemente no podrán añadir más pokemon sin sacrificar, y eso de "hackrom con el 100% de los pokemon" no será más posible.
Me dices 5mb por el tamaño... de solo los sonidos de los gritos de los pokemon y es harto. sigue siendo harto; es un poco menos del 15% del rom solo gastado en gritos.
Luego vienen gráficos, sprites.... al final esos 32mb se pueden ir rápido, súper rápido.
Ahora bien... ¿no pueden haber roms de 64mb en GBA?
existe algún límite del procesador como tal para la lectura del tamaño del cartucho?
nuive
Lo que hice por ahora fue guardar todos los cambios que realicé en el hack, y como Radical Red es un
hack que tampoco se actualiza mucho, si sale una nueva versión pues los vuelvo a aplicar y ya. Será mucho
más rápido puesto que solo tendría que pasar el código que yo añadí a la nueva versión, y lo mismo con
los gritos.
Es una pena que no lo añadan al CFRU para que esto se pueda solucionar en otros hacks pero bueno... habrá
que trabajar con las posibilidades que tenemos.
bro, te pones la soga al cuello tú solo.
ya rugiste, radical red nuive edition en el primer post. ya xd
Vas a tener que ir dándole mantención. y en serio, que chafas, queeeee chafas.
Al final no son tan opensource como dicen serlo
nuive
Sí, toda la gestión de sonidos que tiene el script se hace a través de un minirreproductor que está formado
por dos DLLs que están en la carpeta lua, audio.dll y bass.dll. La DLL bass es una biblioteca de audio
que anda por ahí, la audio.dll es la que Tyler Spivey creó para comunicar Lua con Bass.
El texto a voz también se hace a través de otra DLL, la tolk, que es un proyecto que también anda por
GitHub.
Va, creí que era una implementación normal de bass. bass la conozco, sin drama.
¿pero por qué tuvo que crear una interfás intermedia?
Si llama a audio.dll desde lua ¿por qué no llamó entonces a bass directo desde lua?
Por qué darse esa vuelta con una envoltura?
Sip, tolk la conozco. incluso la he usado.
es boneeta
nuive
No hay commit 😢. Si recuerdas, hace un año me bloquearon el GitHub varios meses, y tuve que depender
de la copia local. Durante ese tiempo formateé el ordenador y al querer actualizar esa copia me empezó
a tirar errores de permisos y propietarios y más locuras que le dieron. Pude salvar todo el proyecto
sin problemas, todo menos el historial de commits y esas cosas de GitHub.
se me había olvidado que según github, nuive es un hacker ultra peligroso xd
Pos nada. simplemente f. ultra f.
¿aunque cuando pasó lo de github? ¿no se te ocurrió tirar commits de mientras a gitlab? jaja
nuive
Ah, la cámara efectúa un sonidito indicando hacia que dirección se puede mover una puerta, pero como
digo, es que ni siquiera es fácil de explicar.
a ok. ya entiendo. simplemente debo probarlo para entederlo xd
Pero se comprende por qué pidieron ayuda jaja
nuive
Lo de la lista de movimientos es algo que aún no está solucionado. Las listas de movimientos en Esmeralda
tienen doble pestaña por lo de movimientos de combate y movimientos de concurso, y con los métodos que
intenté hasta ahora al cambiar de pestaña se desmadra todo de una manera bastante dramática.
Lo del Pokénav... creo que eso funcionó en algún momento, no recuerdo muy bien, pero se rompió una de
tantas veces que tuve que rehacer el motor de textos. Toca revisarlo.
no entendí lo de la lista de movimientos con doble pestaña
te refieres a la lista de movimientos en el menú status de cada pokemon y donde salen sus movimientos?
O en todo momento tienen dos listas separadas de movimiento, una para peleas y otra para concursos. con set de conocimiento diferente para cada ocación? jajaj
y yap!
eso por ahora!
gracias por todo nuive! y gracias alejandro por el link jueguito! -
El NVDA está activo desde que se abre el juego, por suerte a la mayoría de menús y diálogos te los detecta sin problemas. La contraseña blindstep solo se encarga de agregar los sonidos extra.
sanslash332
¿Tiene soporte para lector de pantalla? o eso todavía es a puro OCR?
Las únicas cosas importantes que aún no lee son los datos del entrenador (muestra el próximo nivel de desobediencia de los pokemon) y la pantalla de resumen de cada miembro del equipo (los EVS e IVS son visibles y bastante necesarios en este juego).
edit: te arreglé los corchetes del quote xd
-
estoy probando reborn y bueno, la verdad que lo de la accesibilidad promete bastante, aunque personalmente encuentro un poco verde la orientación, supongo que lo irán mejorando segun actualicen los parches. Un buen método es ir viendo las coordenadas, pero aun así creo que es bastante mejorable. Sin embargo esto promete y espero que sigan trabajando en ello.
-
¡Hola!
Sigo respondiendo dudas:
sanslash332
Interesante. entonces el truco que hace esta gente, es agregar nuevas funciones en espacio del rom sin usar, y en las llamadas originales a la función, reemplasan el puntero viejo con el puntero hacia la nueva función, pero dicho puntero tiene que tener un tamaño similar al antiguo para que pueda calzar en ese lugar y funcionar sin inconvenientes. que interesante hmm
No exactamente. Imagina, por ejemplo, que cuando lanzas una Poké Ball para capturar un pokémon, cuando la Ball falla y se abre, el hacker añade el sonido del pokémon al sonido de la Ball al romperse (como pasa en 4ª y 5ª generación). Lo que se hace en ese caso es crear el código para que se reproduzca el grito en una zona libre del juego, y posteriormente se copia esa dirección de memoria.
En este caso no es reemplazar una función por otra, es añadir algo a la función original. Pero claro, como no se puede modificar el espacio que ocupa la función original, por eso hay que crear el nuevo fragmento de código en una zona libre del juego. Posteriormente, hay que realizar una llamada a esa función desde el punto de la función original donde queremos que se salte a la nueva (en este caso, tras el sonido de la poké ball al romperse). Aquí hay que reemplazar lo que normalmente suelen ser entre 8 y 12 bytes de memoria con las instrucciones necesarias para saltar al nuevo fragmento de código. En este punto es donde se almacena, además de la instrucción de salto, la dirección al nuevo código.
Pero claro, aquí la cuestión. Si se reemplazan bytes para poder hacer posible este salto, que pasa con los bytes reemplazados? Serán órdenes que se pierden, no? Pues... sí, y no. Se pierden en la función original, y por eso es importante, una vez se decide donde irá el nuevo código, contemplar cuantos bytes habrá que reemplazar y estos bytes convertirlos también en parte del nuevo código.
Un ejemplo:
Función original:
call sonido_pokeball();
call muestra_sprite();
call actualiza_ps();
Función modificada (sin modificar el tamaño):
call sonido_pokeball();
call sprite_grito(); // esta sería la nueva función
call actualiza_ps();
sprite_grito:
call muestra_sprite();
call reproduce_grito();
return; // volvería a la función modificada, con lo que procedería con la siguiente instrucción a la llamada (la llamada a actualiza_ps)
Básicamente es algo así, pero en ensamblador es mucho más complejo de diseñar, claro.
sanslash332
Esto lo hace en un startUp time?
el script cuando se inicializa hace una lectura de todo el rom buscando estos puntos dinámicos para prerar las funciones a tiempo?
O lo hace en runtime reconociendo un salto y yendo al salto a penas lo detecta, sin haberlo pre-procesado antes?
A lo que voy... ¿con lua tienes acceso a toda la memoria del juego?
O solo a la ram?
porque se me olvidó, la GBA carga todo el rom en ram a la hora de inicializarse? o el rom va cargando nuevos trozos a medida que son requeridos.
Lo hace al cargar la expansión correspondiente (en este caso CFRU), pero no recorre toda la ROM. Simplemente en la expansión se hace una lista de funciones que tiene que buscar, donde se le aporta la dirección base para iniciar la búsqueda de cada una, siendo la dirección base una dirección de la ROM que se mantendrá en diferentes hacks y versiones, como por ejemplo la dirección de la función original que se modificará.
En este tipo de plataformas (GB/GBA, no sé en nintendo DS) esto no funciona cargando ROM a RAM. El hecho de que los juegos sean cartuchos implica que se conectan directamente al espacio de memoria de la plataforma, y se puede acceder a los mismos de la misma forma que se accede a la RAM. En el caso de GB/C el espacio de memoria ROM es de 32kb, con lo que ROMs de tamaño mayor (la mayoría, entre ellos los de Pokémon, obviamente) tienen que realizar un cambio de banco de memoria, donde cada banco de memoria de la ROM son 16kb, lo que implica que como máximo habrá disponible el acceso a 2 bancos de memoria. El primero siempre será el banco 0, que nunca se cambia. El segundo va del banco 1 al 127, y se cambia el banco según la ROM lo necesite. Esto implica que 32*128=4096kb=4mb de tamaño máximo de ROM para GB/C.
En la GBA directamente se mapea en memoria el acceso completo a la ROM, y no hay posibilidad de realizar cambio de bancos de memoria. El tamaño de mapeo es de 32768kb (32 mb).
sanslash332
sinceramente te fuiste a un nivel muy potente he.
Como se va dando vcuenta qué tipo de operación utilizar?
generaste algún algorítmo de cálculo, o un árbol de desición para saber como ir trabajando la función hasta que el script pueda reconocer todo lo que le interesa?
En ensamblador hay comandos en binario que indican un salto, el inicio de una función, el final de la misma... Esto se utiliza para delimitar donde comienza y acaba cada función. Luego del final de la función suelen estar las constantes que utiliza esa función. A partir de ahí, es mi trabajo estudiar la función (si tengo el código C es mucho más fácil, pero si no, toca desensamblar) e indicarle al script como procesar todos esos datos y las modificaciones que hace en la RAM (las constantes que hay al final de cada función suelen ser direcciones de la ROM donde lee datos y direcciones de RAM donde los escribe).
sanslash332
Me dices 5mb por el tamaño... de solo los sonidos de los gritos de los pokemon y es harto. sigue siendo harto; es un poco menos del 15% del rom solo gastado en gritos.
Luego vienen gráficos, sprites.... al final esos 32mb se pueden ir rápido, súper rápido.
Ahora bien... ¿no pueden haber roms de 64mb en GBA?
existe algún límite del procesador como tal para la lectura del tamaño del cartucho?
Sí, parece mucho ya que es como un 15% de la ROM o más. Pero piensa que son más de 1000 gritos, luego megas, formas alternativas... según se agote el espacio los gritos será lo primero que se sacrifique. Se almacenan en wav comprimido en una variante de dPCM un poco extraña, optimizando la compresión a cambio de perder calidad. Al final un grito ocupa más que varios sprites juntos. Y no, a menos que alguien diseñe un decompresor de mp3 en ASM que pueda funcionar con las ROMs de pokémon, por ahora no hay otra alternativa. Estas ROMs solo leen wav sin comprimir o wav comprimido en la variante esta rara de dPCM.
El límite es el que comentaba anteriormente. Solo hay un espacio de acceso a memoria designado para la ROM, un espacio de 32mb. Hay que imaginar esta arquitectura como si se tratara de una serie de dispositivos interconectados. Para la memoria supongamos que hay un conector de 8 pines, y le queremos conectar algo que tiene 10. No encajará, obviamente. Otra opción es conectar los 8 pines, y hacer que ese conector sepa redigir esas lecturas a un rango mayor (lo que explicaba de la GB/C, el banking, por ejemplo). El problema es que para la GBA esa estructura no está implementada. Sería como diseñar un nuevo concepto de ROM, un concepto en el que los 16 primeros mb se mantengan en memoria y se vaya cambiando de banco en los 16 siguientes como hace la GB. Sí, se podría, pero sería eficiente? Funcionaría? Ni idea... quizás ya lo haya probado alguien por ahí, es muy probable, pero si a día de hoy no se implementó supongo que es porque por lo que sea, no compensa.
Ah, y si un emulador carga una ROM de 64 mb, por ejemplo, simplemente cargará los primeros 32 y el resto lo ignorará como si no hubiera nada.
sanslash332
bro, te pones la soga al cuello tú solo.
ya rugiste, radical red nuive edition en el primer post. ya xd
Vas a tener que ir dándole mantención. y en serio, que chafas, queeeee chafas.
Al final no son tan opensource como dicen serlo
CFRU es open source pero lleva bastante tiempo desatendido. Al final es algo que se hizo principalmente para Pokémon Unbound, y el desarrollador decidió liberarlo como expansión. Además yo todo lo hice en ensamblador y CFRU es C. Escribí al desarrollador porque una vez hecho en ensamblador portarlo a C es simple, pero como no mostró ningún interés pues...
Radical Red no es open source. Si lo fuera, podría directamente coger su código, modificarlo, y aunque no quisieran añadirlo al master, siempre sería tan simple como combinar cambios en cada nueva versión y corregir lo que hubiera que corregir. Mi ofrecimiento fue el mismo, aportar tanto mis modificaciones en ensamblador como en C para acoplarlas al juego (aún no siendo open source) pero es lo que digo, ni caso.
No tengo problema en añadir la ROM modificada al primer post. De hecho estoy arreglando un problema de sonido porque a veces, por algún motivo que desconozco petardea bastante incluso con sonidos originales de Rojo Fuego cuando el propio Rojo Fuego no lo hace. Una vez solucione esto (si se puede) lo añadiré.
sanslash332
Va, creí que era una implementación normal de bass. bass la conozco, sin drama.
¿pero por qué tuvo que crear una interfás intermedia?
Si llama a audio.dll desde lua ¿por qué no llamó entonces a bass directo desde lua?
Por qué darse esa vuelta con una envoltura?
Sip, tolk la conozco. incluso la he usado.
es boneeta
Supongo que para simplificar las llamadas desde Lua, y porque bass es un módulo C, no Lua. La diferencia la ejemplifica perfectamente Tolk. Tolk es una DLL común en C, y por este motivo hay un tolk.lua en la carpeta Lua. Este archivo es el que convierte la DLL de C tolk.dll en un módulo Lua. Con Bass hizo algo similar, pero en vez de crear un archivo .lua, utilizó directamente un módulo Lua que está en DLL y vincula la biblioteca C Bass con Lua.
La diferencia parece una tontería pero es muy importante. Si se crea un módulo Lua en DLL, al margen de que sea compatible con versiones de Lua, por ejemplo, desde 5.1 a 5.4 siempre pedirá la DLL para la que se vinculó, por ejemplo Lua 5.1. Eso es un poco desastre, porque en el caso de mGBA, por ejemplo, que ya integra Lua sin requerir DLLs, para este tipo de módulos tienes que incluir una DLL de algo que el propio emulador ya integra en su ejecutable. Es por esto que yo estoy totalmente en contra de esta decisión y prefiero utilizar las DLL originales de C y vincularlas a Lua mediante un .lua que puedo editar para diferentes versiones sin necesidad de añadir bibliotecas redundantes.
sanslash332
se me había olvidado que según github, nuive es un hacker ultra peligroso xd
Pos nada. simplemente f. ultra f.
¿aunque cuando pasó lo de github? ¿no se te ocurrió tirar commits de mientras a gitlab? jaja
No, en ese momento lo único que se me ocurrió fue tirar piedras a GitHub.
sanslash332
no entendí lo de la lista de movimientos con doble pestaña
te refieres a la lista de movimientos en el menú status de cada pokemon y donde salen sus movimientos?
O en todo momento tienen dos listas separadas de movimiento, una para peleas y otra para concursos. con set de conocimiento diferente para cada ocación? jajaj
En el resumen del Pokémon hay 4 pestañas, siendo las dos últimas una para movimientos de combate y otra para movimientos de concurso. Los movimientos obviamente son los mismos para ambas pestañas pero cambian el resto de campos. En la pestaña de combate se muestra lo típico de PP, Potencia, precisión, descripción y esas cosas. Mientras en la de concursos en la descripción figura el efecto que tiene cada movimiento en un concurso, y en vez de los datos de combate aparecen los datos de concursos (los corazoncitos y esas cosas que dan, que la verdad ahora mismo no recuerdo como les llama el juego).
Esta doble pestaña es igual para cuando se quiere enseñar un movimiento. Con las flechas izquierda y derecha se cambia entre info de combate y de concurso, y el problema es que además de cambiar los campos reinicia las listas de una forma rarísima que hace que el script enloquezca.
Y creo que no me dejo nada.
¡Saludos!
Edito: Por cierto, me encanta ver como la gente escribe en el tema de audiogames para pedir soporte del script para Negro y Blanco...
Si no fuera porque rebajarme a ese nivel me parece penoso, los animaría a probar a diseñarlo ellos mismos. -
¡Hola!
Siento el doble post, pero creo que esto merece el suyo propio.
sanslash332
da lo mismo, la diferencia ya entre emuladores es avismal. aunque lograses reducir a unos 5MS las funciones de buscaobjetos ultra optimizadas con luajit, en mGBA, seguiría estando entorno a los 30 o 40ms.
lo que sigue siendo aún mucho más que lo que tenemos a día de hoy
A ver, con respecto a esto... bueno, hice unas pequeñas optimizaciones en el script pensadas para mGBA. No toqué nada en el emulador, usa su motor nativo de Lua 5.4. Lo único que se modificaron aquí fueron un par de funciones (sí, un par) en el script.
Lo importante de esto es que... bueno, en la lista de objetos, solo estas modificaciones redujeron los 70 y pico ms del mGBA a una media de 30, lo que es algo menos de la mitad. No quiero prometer nada puesto que estoy haciendo pruebas, pero está claro que el lag de mGBA está en como accede a la memoria de las consolas. Lua funciona todo lo rápido que debería, el problema parece que está en que el emulador tiene lag con las llamadas externas a Lua, aunque se hagan desde el propio motor. Ahora bien, no sé hasta que punto esto se puede optimizar más, si la optimización será igual de potente que hasta ahora, no sé como tomará esto el buscarrutas... Pero la cosa es que con un par de cambios las cosas pintan muchísimo mejor.
De todos modos, ahora que sé donde está la raíz del problema lo comunicaré en el discord de mGBA. Imagino que a los desarrolladores les interesa tener un emulador optimizado.
Edito: Efectivamente, ya me respondió el desarrollador principal de mGBA bastante alarmado por el overhead que supone esto. Hice pruebas con VBA-RR usando tanto LuaJIT como Lua 5.1 y es muy gracioso lo que pasa. Mientras que en mGBA esas modificaciones alteraron el rendimiento haciendo que tarde menos de la mitad, en VBA con ambas variantes de Lua lo máximo que conseguí en un momento muy puntual fue una variación de 5 ms. Así que sí, confirmado. El problema está en como mGBA accede a la memoria. -
Holiii @nuive
Perdón por la demora en responder; me fui a hacer otras cosas y bue... hay harto hilo por donde cortar por aquí, mucha cosita interesante. jeje
nuive
Básicamente es algo así, pero en ensamblador es mucho más complejo de diseñar, claro.
Se entiende perfectamente el cómo se hace. Se reemplazan llamadas a funciones (o expresiones) por una llamada a una nueva función en un espacio libre, donde se coloca el código nuevo, y bueno. parte del código reemplazado si es que se necesita.
Supongo eso sí, que tienes que hacer que coincidan, al menos en cantidad de bits a utilizar las llamadas a las funciones. para poder hacer un reemplazo limpio en el espacio acotado del espacio cambiado.
¿Esto no tiene problema cuando tienes que llamar a una función con parámetros?
O lo que reemplaces sea algo con parámetros.
¿En ese caso no te toca ser mucho más cuidadoso con el juego de movimiento de las firmas de las llamadas?
O incluso te podría tocar hacer un reemplazo más grande para poner parámetros en espacio de memoria que la función llamada luego pueda leer.
Es... interesante el rompecabezas que se arma ahí. muy interesante.
En la GBA directamente se mapea en memoria el acceso completo a la ROM, y no hay posibilidad de realizar cambio de bancos de memoria. El tamaño de mapeo
es de 32768kb (32 mb).
Es interesante este límite. porque en parte eso explica por qué los juegos de GBA no pueden expandirse más allá de ese límite de 32MB, al menos claro que se modificase el hardware.... o la emulación del hardware al menos.
¿Las consolas más nuevas como ds / 3ds tendrán ese mismo tipo de limitaciones?
O ya tratarán al carcucho más como un disco y podrán intercambiar datos con el cartucho de manera mucho más libre y sin esos límites.
Es muy interesante.
nuive
En ensamblador hay comandos en binario que indican un salto, el inicio de una función, el final de la misma... Esto se utiliza para delimitar donde comienza
y acaba cada función. Luego del final de la función suelen estar las constantes que utiliza esa función. A partir de ahí, es mi trabajo estudiar la función
(si tengo el código C es mucho más fácil, pero si no, toca desensamblar) e indicarle al script como procesar todos esos datos y las modificaciones que
hace en la RAM (las constantes que hay al final de cada función suelen ser direcciones de la ROM donde lee datos y direcciones de RAM donde los escribe).
¿EN serio? al revéz de la lógica que uno regularmente hace al programar
Si usarás constantes globales, las declaras antes de la función a utilizar y no al final.
Interesante.
nuive
Sí, parece mucho ya que es como un 15% de la ROM o más. Pero piensa que son más de 1000 gritos, luego megas, formas alternativas... según se agote el espacio
los gritos será lo primero que se sacrifique. Se almacenan en wav comprimido en una variante de dPCM un poco extraña, optimizando la compresión a cambio
de perder calidad. Al final un grito ocupa más que varios sprites juntos. Y no, a menos que alguien diseñe un decompresor de mp3 en ASM que pueda funcionar
con las ROMs de pokémon, por ahora no hay otra alternativa. Estas ROMs solo leen wav sin comprimir o wav comprimido en la variante esta rara de dPCM.
Bueno, siempre tienes la alternativa de volver a hacer los gritos de pokemon como se hacían en gb/gbc.
Que no eran archivos de sonido directamente, sino que eran una función de reproducción de ciertos patrones de sonidos sinusoidales, los cuales eran modificables por parámetros. que cambiaban velocidad, pich, si eran más planos o móviles. etc.
Eran como... 13 o 16 funciones y así hicieron los sonidos de los 151. jajaja.
Hay hasta en javascript programadas esas mismas funciones.
teóricamente probablemente lo hicieron, pero no lo explotan porque generarías rom no aprobechables en GBA.
nuive
explicaba de la GB/C, el banking, por ejemplo). El problema es que para la GBA esa estructura no está implementada. Sería como diseñar un nuevo concepto
de ROM, un concepto en el que los 16 primeros mb se mantengan en memoria y se vaya cambiando de banco en los 16 siguientes como hace la GB. Sí, se podría,
pero sería eficiente? Funcionaría? Ni idea... quizás ya lo haya probado alguien por ahí, es muy probable, pero si a día de hoy no se implementó supongo
que es porque por lo que sea, no compensa.
Al menos claro no sé, que funcionase directamente con alguna función especial...
Tipo... algo pensado para trabajar con algún tipo de flashkart, que dada cierta instrucción, el procesador de la flashkart cambie un espacio de la memoria rom con el contenido de un archivo cargado desde la sd.
Y se guarde precisamente un espacio chiquito de la memoria para mandarle esas isntrucciones al procesador interno que suelen tener las flashKarts.
Así hackroms grandes serían compatibles con emulador (que implementase ello, obviamente) y los modelos de flashkarts que implementasen ese protocolo.
Supongo que es parecido a lo que hicieron con la extención MSU1 para la snes. Que funciona tanto en flashkarts como emuladores para básicamente. reproducir música mediante streaming durante el juego.
nuive
CFRU es open source pero lleva bastante tiempo desatendido. Al final es algo que se hizo principalmente para Pokémon Unbound, y el desarrollador decidió
liberarlo como expansión. Además yo todo lo hice en ensamblador y CFRU es C. Escribí al desarrollador porque una vez hecho en ensamblador portarlo a C
es simple, pero como no mostró ningún interés pues...
¿Y forkearlo derechamente?
Si ya está tirado ¿por que no sacas tu fork?
O buscar un fork que tenga desarrollo activo. si tantos hackroms lo usan, alguien debe de estar toqueteándolo. con la constate salidas de generaciones pokemon y cosas así
nuive
Radical Red no es open source. Si lo fuera, podría directamente coger su código, modificarlo, y aunque no quisieran añadirlo al master, siempre sería tan
simple como combinar cambios en cada nueva versión y corregir lo que hubiera que corregir. Mi ofrecimiento fue el mismo, aportar tanto mis modificaciones
en ensamblador como en C para acoplarlas al juego (aún no siendo open source) pero es lo que digo, ni caso.
na, ya conoces a los del mundo closed-source. son así
nuive
No tengo problema en añadir la ROM modificada al primer post. De hecho estoy arreglando un problema de sonido porque a veces, por algún motivo que desconozco
petardea bastante incluso con sonidos originales de Rojo Fuego cuando el propio Rojo Fuego no lo hace. Una vez solucione esto (si se puede) lo añadiré.
te tomo la palabra
nuive
La diferencia parece una tontería pero es muy importante. Si se crea un módulo Lua en DLL, al margen de que sea compatible con versiones de Lua, por ejemplo,
desde 5.1 a 5.4 siempre pedirá la DLL para la que se vinculó, por ejemplo Lua 5.1. Eso es un poco desastre, porque en el caso de mGBA, por ejemplo, que
ya integra Lua sin requerir DLLs, para este tipo de módulos tienes que incluir una DLL de algo que el propio emulador ya integra en su ejecutable. Es por
esto que yo estoy totalmente en contra de esta decisión y prefiero utilizar las DLL originales de C y vincularlas a Lua mediante un .lua que puedo editar
para diferentes versiones sin necesidad de añadir bibliotecas redundantes.
Eso es interesante...
No sabía que podías compilar módulos lua a DLL directamente.
¿Esos dlls resultantes son exclusivamente de uso para lua? O igual siguen siendo dlls normales y si incluyesen más funciones que el módulo lua son importables por otro tipo de programas?
nuive
Si no fuera porque rebajarme a ese nivel me parece penoso, los animaría a probar a diseñarlo ellos mismos.
jajajaja good luck
Por cierto, hace unos días andaba pensando...
Si los juegos de pokemon están ya ultra desensamblados. con código c inclusive...
¿por qué no han salido ports para pc funcionales al 100%?
Si hay ports de juegos como el mario64 o el zelda ocarine of time. Que se construyeron a partir de desensamblajes y el código sacado desde las entrañas de nintendo...
¿por qué con los pokemon no han intentado lo mismo si ya tienen juegos absolutamente compilables?
Con los disasembled projects, puedes bajarlos, correr un compilador y generar los archivos .gba.
¿Nadie ha modificado ese código fuente para vincular las funciones importantes a librerías gráficas de pc para generar el juego con un ejecutable directo?
POrque... vamos, si hiciesen eso, meterle accesibilidad sería... algo más interesante de programación directa.
nuive
Siento el doble post, pero creo que esto merece el suyo propio.
sí tranquilo, no te morderé
nuive
Lo importante de esto es que... bueno, en la lista de objetos, solo estas modificaciones redujeron los 70 y pico ms del mGBA a una media de 30, lo que
es algo menos de la mitad. No quiero prometer nada puesto que estoy haciendo pruebas, pero está claro que el lag de mGBA está en como accede a la memoria
de las consolas. Lua funciona todo lo rápido que debería, el problema parece que está en que el emulador tiene lag con las llamadas externas a Lua, aunque
se hagan desde el propio motor. Ahora bien, no sé hasta que punto esto se puede optimizar más, si la optimización será igual de potente que hasta ahora,
no sé como tomará esto el buscarrutas... Pero la cosa es que con un par de cambios las cosas pintan muchísimo mejor.
Igual, es como te dije xd; lo redujiste a la mitad, entre 30 a 40 ms. Pero si lo revisas en tus propios números, eso sigue siendo aún peor que el escenario no obtimizado del VBA-RR jajajaja.
ojalá se pudiese correjir aunque sea un poco el m-GBA para que esos números desendiecen; por tu parte al menos lo has optimizado mucho, pero mucho.
nuive
De todos modos, ahora que sé donde está la raíz del problema lo comunicaré en el discord de mGBA. Imagino que a los desarrolladores les interesa tener
un emulador optimizado.
Si es un emulador pro-tas-community, sí. les interesa xd
nuive
Edito: Efectivamente, ya me respondió el desarrollador principal de mGBA bastante alarmado por el overhead que supone esto. Hice pruebas con VBA-RR usando
tanto LuaJIT como Lua 5.1 y es muy gracioso lo que pasa. Mientras que en mGBA esas modificaciones alteraron el rendimiento haciendo que tarde menos de
la mitad, en VBA con ambas variantes de Lua lo máximo que conseguí en un momento muy puntual fue una variación de 5 ms. Así que sí, confirmado. El problema
está en como mGBA accede a la memoria.
jajajajaja. bien bien.
¿Dijo que tenía alguna idea de por donde comenzar a atacarlo?
¿Te han dicho algo más sobre ello?
Porque será muy interesante ver como sigue evolusionando
Y bueeeno.
Eso es todo por ahora.
Como siempre Nuive, gracias por todo este trabajo; perdón por demorarme, andaba con otras cosas y quería tiempito para responder esto tan técnico jeje.
¡Saludos!
edit: El generador de sonidos de la gen1
Me encanta esa cosa xD
-
¡Hola!
A ver, tengo bastante información además de las respuestas...
sanslash332
Se entiende perfectamente el cómo se hace. Se reemplazan llamadas a funciones (o expresiones) por una llamada a una nueva función en un espacio libre, donde se coloca el código nuevo, y bueno. parte del código reemplazado si es que se necesita.
Supongo eso sí, que tienes que hacer que coincidan, al menos en cantidad de bits a utilizar las llamadas a las funciones. para poder hacer un reemplazo limpio en el espacio acotado del espacio cambiado.
¿Esto no tiene problema cuando tienes que llamar a una función con parámetros?
O lo que reemplaces sea algo con parámetros.
¿En ese caso no te toca ser mucho más cuidadoso con el juego de movimiento de las firmas de las llamadas?
O incluso te podría tocar hacer un reemplazo más grande para poner parámetros en espacio de memoria que la función llamada luego pueda leer.
Es... interesante el rompecabezas que se arma ahí. muy interesante.
No, no. Piensa que esto no es lenguaje de alto nivel, es ensamblador. Aqquí la llamada a una función se realiza con una instrucción de 32 bits que suma o resta a la dirección donde se encuentra la ejecución actualmente (contador de programa o pc) los bytes necesarios para acceder a la función a llamar. Evidentemente, con 32 bits (de los que 10 se utilizan para indicar que la instrucción es una llamada) el rango del salto se limita a +-0x3FFFFF. Como una ROM puede ocupar hasta 0x2000000 bytes, no se puede utilizar esta instrucción para ir a cualquier lugar de la ROM. Para esto hay que combinar las llamadas con los saltos. Un salto, por decirlo de forma muy simplificada, en lugar de utilizar posiciones relativas al PC utiliza la dirección absoluta del inicio de una función. Pero claro, una llamada implica volver a donde estabas con un simple return, un salto no. Por eso en muchos casos hay que combinar ambos tipos de llamadas para obtener el resultado deseado.
En cuanto a la parametrización, eso en ensamblador no existe como tal. La GBA tiene una serie de registros de memoria (16) de los que los 8 primeros son los que se suelen usar para pasar los parámetros a cada función. Si es necesario, se utiliza la pila (Stack) para guardar otros valores que se utilizarán como parámetros. No porque se usen más de x parámetros, sino porque quizás x registros no se pueden tocar al llamar a una función porque la función que llama a la función que llama a esta función los necesita. Es bastante complicado de explicar sin trabajar con esto a diario. Supón que tienes una función getPKMNData(int index, void* dest)
Lo habitual es que esa función utilice el registro r0 como index y r1 como pointer, pero lo que pasa es que en ensamblador los registros son globales a todo el programa. Lo que se hace es, antes de llamar a la función, asignar a r0 el valor de id y a r1 el valor (dirección) de dest. Pero y si al terminar la función getPKMNData la función que la llamó necesita acceder al valor que tenía en r1 antes de asignarle dest? Pues... habría que guardar r1 en la pila antes de asignarle dest, y tras volver de getPKMNData cargar el antiguo valor desde la pila y asignarlo a r1 otra vez.
Y esto sin ir más allá porque claro, y si se modifica la pila en getPKMNData? Son muchas cosas a tener en cuenta a la hora de diseñar una función en ensamblador.
sanslash332
¿Las consolas más nuevas como ds / 3ds tendrán ese mismo tipo de limitaciones?
O ya tratarán al carcucho más como un disco y podrán intercambiar datos con el cartucho de manera mucho más libre y sin esos límites.
Es muy interesante.
Sí, las nuevas consolas ya tiran muchísimo más de RAM y esto no es un problema. No tengo ni idea sobre si hay algún tipo de limitación en cuanto al tamaño o no, pero piensa que desde 3DS ya se pueden descargar juegos de forma legal desde la e-shop de Nintendo sin necesidad de un cartucho físico.
sanslash332
Bueno, siempre tienes la alternativa de volver a hacer los gritos de pokemon como se hacían en gb/gbc.
Que no eran archivos de sonido directamente, sino que eran una función de reproducción de ciertos patrones de sonidos sinusoidales, los cuales eran modificables por parámetros. que cambiaban velocidad, pich, si eran más planos o móviles. etc.
Eran como... 13 o 16 funciones y así hicieron los sonidos de los 151. jajaja.
Hay hasta en javascript programadas esas mismas funciones.
Podría valer para los Pokémon de las dos primeras generaciones, copiando sus sonidos originales de los juegos de GB/c, pero los más recientes ya utilizan sonidos irrecreables con ese método. Sin contar con que habría que diseñar todo un nuevo reproductor en ensamblador para ese tipo de sonidos. Visto así no compensa mucho, no?
sanslash332
teóricamente probablemente lo hicieron, pero no lo explotan porque generarías rom no aprobechables en GBA.
Al menos claro no sé, que funcionase directamente con alguna función especial...
Tipo... algo pensado para trabajar con algún tipo de flashkart, que dada cierta instrucción, el procesador de la flashkart cambie un espacio de la memoria rom con el contenido de un archivo cargado desde la sd.
Y se guarde precisamente un espacio chiquito de la memoria para mandarle esas isntrucciones al procesador interno que suelen tener las flashKarts.
Así hackroms grandes serían compatibles con emulador (que implementase ello, obviamente) y los modelos de flashkarts que implementasen ese protocolo.
Supongo que es parecido a lo que hicieron con la extención MSU1 para la snes. Que funciona tanto en flashkarts como emuladores para básicamente. reproducir música mediante streaming durante el juego.
Claro, sería cosa de diseñar un emulador que los soportara o diseñar un hardware que simulara ese tipo de funciones.
De hecho, lo que hacen las flashcarts es esto, tanto en GBA como en DS y 3DS. Guardas una serie de juegos, eliges con la interfaz de la flashcart cuál quieres, y la tarjeta utilizando su hardware y software propios asigna ese juego a la memoria correspondiente.
Lo que creo que no hay diseñado (o al menos yo no tengo ni idea de eso) es algún tipo de hardware y software (porque seguramente haría falta un componente físico en caso de una GBA física) que por ejemplo, teniendo ROMs de 64 mb puedan asignar los 16 primeros mb a la región de memoria fija y los otros 16 irlos alternando según haga falta.
Esto es lo que hacen los juegos de GB/GBC, pero por ese motivo, programar para esas plataformas es muchísimo más complejo en este aspecto. Hay que asegurarse de que cada función esté en su minibanco de memoria correspondiente, que todas las funciones críticas estén en un minibanco que vaya a estar dentro del banco que quedará asignado de forma fija, que cada minibanco no desborde bytes porque tiene un tamaño fijo... eso sí que es de locos. Y claro, en la GBA pues dices... en 16 MB? se mete todo lo crítico en los primeros 16 y el resto de datos (gráficos, sonidos...) van para el resto de bancos.
Sí, en la GBA quizás sería más fácil, no lo tengo claro. Pero en GB/GBC el banco fijo es de 16 kb (imagina como será cada minibanco).
sanslash332
¿Y forkearlo derechamente?
Si ya está tirado ¿por que no sacas tu fork?
O buscar un fork que tenga desarrollo activo. si tantos hackroms lo usan, alguien debe de estar toqueteándolo. con la constate salidas de generaciones pokemon y cosas así
Como dices, cosas del Closed source. No encontré ninguna rama del CFRU a parte de la original (aunque seguramente mil hacks la implementen) y si alguno es open source lo que será open source será el propio hack, no la expansión CFRU como tal.
Como decía, no hice fork básicamente porque tendría que pasarlo todo a C y mis modificaciones están realizadas sobre Radical Red, que por ejemplo tiene todos los pokémon existentes hasta el día de hoy. El CFRU original solo tiene hasta la 8ª generación.
Como digo, podría pasar mi código a C, pero muchas de las cosas que toqué en lo que a CFRU se refiere son cosas que Radical Red estropea en la expansión, o cosas específicas relacionadas con Pokémon exclusivos de Radical Red.
En Radical Red, por ejemplo, se sacrifican muchas cosas relacionadas con el sonido con la única intención de no complicar tanto las llamadas a funciones de las que hablaba antes. Por ejemplo: anda, aquí hay código que se repite, porque se utiliza para el sonido que sale por el canal derecho y el que sale por el izquierdo. ¿Que lo que suena por ambos canales es distinto? No pasa nada, que suene todo por el derecho y código que nos ahorramos, total no se va a morir nadie.
Sí, son tonterías minúsculas, pero a mí me gusta que el sonido del juego suene por donde tiene que salir, no que me suenen los dos Pokémon por el lado derecho. En una ocasión ocurrió que sacamos al mismo pokémon el rival y yo y claro, cuando cayó uno, puesto que los dos suenan por el lado del rival, no sabía si era el mío o el suyo hasta que me apareció la pantalla de elegir otro pokémon. Cosas como esto son lo que yo estoy arreglando en Radical Red.
sanslash332
Eso es interesante...
No sabía que podías compilar módulos lua a DLL directamente.
¿Esos dlls resultantes son exclusivamente de uso para lua? O igual siguen siendo dlls normales y si incluyesen más funciones que el módulo lua son importables por otro tipo de programas?
No, solo valen para Lua. Necesitando además la DLL de la versión específica de lua para la que se compila cada módulo, poca utilidad tendrían en C, ya que los módulos no son DLLs útiles, son como una especie de interfaces.
Poniendo como ejemplo el script, para aclarar un poco todo esto:
-Tenemos la DLL audio.dll. Eso es un módulo Lua que el script carga y gestiona. Pero esta DLL no vale para nada sin...
-la DLL bass.dll: esta es la biblioteca C como tal. Lo único que hace audio.dll es permitir que bass.dll se pueda utilizar con Lua. Sin embargo, es posible (aunque no fácil) deshacernos de audio.dll y crear un audio.lua que interactuará con bass.dll por su cuenta como si se tratara de audio.dll.
¿Ventajas?
Pues que si vamos a diseñar un script que queremos que sea compatible con varias versiones de Lua necesitaríamos bass.dll para la arquitectura (32 o 64 bits) del emulador donde se vaya a utilizar el script (si quisiéramos poder utilizarlo tanto en 32 como en 64 bits necesitaríamos ambas DLLs (bass32.dll y bass64.dll o algo así).
Ahora vamos con audio.dll. Necesitaríamos una DLL por cada arquitectura y versión de Lua, junto con la DLL de Lua también por cada arquitectura y versión. Obviando las 8 DLLs de Lua (de 5.1 a 5.4), que siempre que se utilice un módulo DLL serán necesarias) necesitaríamos las 2 DLLs de BASS y otras 8 para el módulo. Suma a esto que habría que realizar 8 compilaciones y reubicación de DLLs por cada modificación que se haga en el código C del módulo.
Sin embargo, con audio.lua... necesitaríamos las 2 DLLs de BASS y... ya. Luego solo el archivo audio.lua, que además si hay que hacer alguna modificación se modifica el archivo, se guarda y fuera.
Ah, y otras 8 DLLs. Sí, me olvidaba. Las DLLs del módulo FFI, que es lo que permite que Lua se comunique con DLLs de C sin utilizar módulos de C.
Vale, a estas alturas... estamos como estábamos.
Peeeeero... y si necesitamos otro módulo, como por ejemplo el que comunicará Lua con la DLL en C de Tolk? Pues si dicho módulo fuera otra DLL necesitaríamos las 2 DLLs de Tolk (una por arquitectura) y... los 8 módulos en DLL (uno por versión y arquitectura), y otra vez el lío que sería recompilar los 8 cada vez que se modifique.
Sin embargo, con un módulo .lua necesitaríamos las 2 DLLs de Tolk y... ya. Las 8 DLL de FFI ya las incluimos por el módulo de audio, las 8 DLL de la versión de Lua también, y el módulo nuevo será otro archivo .lua.
Esto implica que trabajar con Lua en vez de con DLLs facilita la gestión de los módulos. Las DLL de FFI y Lua no será necesario recompilarlas salvo casos excepcionales, por lo que simplemente será cuestión de colocarlas en el proyecto una vez y olvidarnos de que están ahí.
Ahora bien... no todo es tan bonito. El trabajo de un módulo en Lua es bastante menos eficiente que en C. Bueno, el módulo como tal no, pero por poner un ejemplo, yo intenté eliminar la DLL crc32 y convertir el módulo crc32.lua en un módulo que ya hiciera el cálculo CRC32 de las ROMs, y funcionó perfectamente. Claro, sin contar que los 2 o 3 segundos que tardaba en inicializarse el script se convirtieron en casi 20 😂. Por eso, aunque si bien como módulos no suele haber diferencias, siempre es importante probar, teniendo en cuenta el rendimiento, qué compensa más.
sanslash332
Por cierto, hace unos días andaba pensando...
Si los juegos de pokemon están ya ultra desensamblados. con código c inclusive...
¿por qué no han salido ports para pc funcionales al 100%?
Si hay ports de juegos como el mario64 o el zelda ocarine of time. Que se construyeron a partir de desensamblajes y el código sacado desde las entrañas de nintendo...
¿por qué con los pokemon no han intentado lo mismo si ya tienen juegos absolutamente compilables?
Con los disasembled projects, puedes bajarlos, correr un compilador y generar los archivos .gba.
¿Nadie ha modificado ese código fuente para vincular las funciones importantes a librerías gráficas de pc para generar el juego con un ejecutable directo?
POrque... vamos, si hiciesen eso, meterle accesibilidad sería... algo más interesante de programación directa.
Supongo que a nadie le interesó, la verdad. Sería un trabajo avismal. No solo es redirigir cosas a bibliotecas, es que Nintendo para los juegos de Pokémon tira muchísimo de SDKs propios de Pokémon, y es bastante complejo. Quizás sería mucho más fácil portar los Mundo misterioso. De todos modos, cuando acabe las respuestas tengo que añadir unas cuantas cosas a este respecto.
sanslash332
Igual, es como te dije xd; lo redujiste a la mitad, entre 30 a 40 ms. Pero si lo revisas en tus propios números, eso sigue siendo aún peor que el escenario no obtimizado del VBA-RR jajajaja.
ojalá se pudiese correjir aunque sea un poco el m-GBA para que esos números desendiecen; por tu parte al menos lo has optimizado mucho, pero mucho.
Bueno, en el VBA sin LuaJIT no se nota la diferencia, la verdad. De hecho yo me pasé unos días utilizando el script sin recordar que había deshabilitado el JIT, y no me di cuenta hasta que un día cascó todo porque Lua llamaba a una función que en el estándar no existía, solo en el Git. Me costó media hora darme cuenta de que estaba usando el Lua oficial sin optimizaciones porque mi cabeza estaba en bucle pensando a ver por qué de repente cascaba eso si yo no lo había tocado y siempre había funcionado bien.
sanslash332
¿Dijo que tenía alguna idea de por donde comenzar a atacarlo?
¿Te han dicho algo más sobre ello?
Porque será muy interesante ver como sigue evolusionando
No volví a saber nada ni vi nada a este respecto en el GitHub de mGBA. Lo volveré a comentar a ver.
Bien. Ahora que acabé con las respuestas... el script.
No está abandonado, por supuesto. De hecho estoy trabajando en él más que en mucho tiempo. Sin embargo, no me voy a atreber a dar ni una aproximación de fecha de siguiente actualización. Estoy intentando darle un enfoque diferente, y esto implicará cambios. Ojo, no en el uso del script, que seguirá siendo como hasta ahora. Esto más bien es cosa del desarrollo.
Lo único que creo que puedo decir es que si mi idea sale bien (por ahora va por buen camino, pero aún está en las primerísimas fases del desarrollo) el script cobrará una nueva dimensión. Si no... pues seguiré como hasta ahora.
Es lo único que creo poder asegurar a estas alturas. Decir más sería como poner la fecha de salida de un juego del que se está empezando a concretar la idea.
Y para finalizar...
¡LEAAAAAAAAAAAK!
Aunque supongo que todo aquel que esté un mínimo al día de las noticias de Pokémon tiene alguna idea de esto, lo resumo un poco.
Hace aproximadamente 3 semanas (algo más) Game Freak fue hackeada. Y no, los hackers no se hicieron con 4 estupideces. Los rumores dicen que sacaron de GF 1 tb de datos.
Sí, por ahí hay muchos rumores que cualquiera puede encontrar. Cosas beta, diseños internos, proyectos interrumpidos, datos sobre los próximos juegos de Pokémon... de hecho yo tengo ciertas sospechas de que a Game Freak todo esto le da bastante igual (eso suponiendo que no hayan permitido ellos mismos el hackeo o que hayan pasado de detenerlo) ya que tampoco se filtró nada relevante. El usuario que está filtrándolo todo asegura tener el próximo juego de Pokémon (Leyendas Z-A) casi en su versión final y muchos datos sobre la décima generación, pero dice que de eso no va a filtrar nada (qué cosas).
Pero bueno, una vez un poco puestos en contexto... hay cierto foro por ahí, cuyo nombre empieza por 4 y acaba por chan, en el que vuelan los leaks. Y según el filtrador lo va subiendo todo por sitios como discord o telegram aparece todo en ese bendito foro. Para abreviar, foro gracias al que dispongo de...
-Repositorios completos (ojo, repositorios, no solo código fuente) de Pokémon Platino, HeartGold/Soul Silver, Blanco y Negro, Blanco y Negro2 y Rubí Omega/Zafiro Alfa. Además de esto, los códigos fuente de Let's Go, X e Y, Ultrasol y Ultraluna, Espada y escudo (con sus DLCs) y Leyendas. Arceus.
Y lo más llamativo. Un código fuente de las primerísimas versiones de Leyendas Arceus... para PC. Sí, yo no sé para qué o para qué no, pero resulta que eso existe. No el juego final, pero sí una versión que de una forma o de otra podría servir como punto de partida para cosas... interesantes de ports para PC.
Y volviendo a lo de antes de los ports... este juego, el Leyendas Arceus, requiere un montón de SDKs de Nintendo e incluso hasta de NVIDIA. Por eso decía, que por mucho que haya decompilaciones que se pueden compilar para GBA... no creo que la cosa sea tan simple en PC.
Ah, y encontré por ahí, en un leak anterior, el repo completo de Diamante y Perla.
Pero ahora bien, lo que nos interesa... para qué nos vale todo esto?
¿Sinceramente? Ni idea.
Por como funciona el script y los emuladores con Lua, nuestra mejor opción sigue siendo el GitHub PRET, donde decompilan todo, ya que los scripts funcionan a nivel de memoria y esas decompilaciones también. Mapear un código fuente nativo a direcciones de memoria sería una odisea.
Pero bueno, si por ejemplo en algún punto del diseño del script para futuros juegos me encuentro con x función que aún no está decompilada, sé que tengo el código fuente por ahí, en el que si bien no voy a encontrar una equivalencia, sabiendo a que parte del juego pertenece la función sin decompilar puedo ir a una parte del código original para comparar. Y he de decir que en leer C y ensamblador a la vez es algo en lo que cogí práctica gracias a los fixes de Radical Red así que...
La verdad es que por ahora apenas tuve tiempo de toquetear un poco los repositorios. Todo está muy empaquetado, y por ejemplo, el repo de Rubí Omega y Zafiro Alfa ocupa 290 gb sin descomprimir. Vamos, que meterse a hurgar en todo eso no es algo que se pueda hacer en 5 minutos.
Pero quien sabe... es algo útil de tener. Estas son las típicas cosas que hacen falta o vendrían bien dentro de 5 años, cuando ya sea complicadísimo encontrarlas por ahí. De hecho, todo lo estaban subiendo a un Drive, y en un momento puntual me cuadró presenciar como según yo descargaba cosas, lo que había descargado el día anterior iba desapareciendo según lo eliminaban desde google.
Ah, y por cierto, desde el equipo PRET (los del desensamblado) están en contra de utilizar el código fuente para acelerar su trabajo. Dicen que lo hacen precisamente para entender como funciona el proceso de compilación, y que tener ya el código original quitaría todo el sentido al proyecto. Y sinceramente... yo lo agradezco muchísimo. Mientras sigan haciéndolo, será lo más cercano que estaremos de la memoria de las ROMs oficiales. Si en determinado punto no entiendo alguna sección, pues al código oficial, que yo no tengo esos escrúpulos jajajaja.
Ahora bien, que en un futuro hay alguna iniciativa para portar algo de esto a PC? Pues ahí estaremos para meterle accesibilidad! Me encantaría crear yo esa iniciativa, pero en este momento es algo que está completamente fuera de mi alcance. Por ahora, el script y yo somos muy felices dedicándonos a trabajar con Lua.
Y nada, luego de este macropost que me llevó varios días hacer... me despido hasta el siguiente desvarío.
¡Saludos!
P.D.: Lo que tengo yo de las filtraciones ocupa 650 gb, y todo muy comprimido. Me faltarían como 200-250 gb de ROMs sin código fuente que no vi la necesidad de descargar. Con todo lo que dice el filtrador que tiene y no va a publicar... o se lo está inventando o me da a mí que lo que salió de Game Freak fue más de 1 tb...
Edito: Nuevas noticias de mGBA.
Acabo de hablar con el desarrollador principal del proyecto por Discord (publiqué unas pruebas que había hecho) y conseguimos encontrar dónde está el problema del overhead en mGBA. Diseñé un loop que lee un byte 10000000 de veces y otro que consulta la plataforma otros 10000000 de veces (sí, se me fue un poquito la mano con la cantidad) y llegamos a la conclusión de que el problema es cómo gestiona mGBA las llamadas. Cada loop tardaba sobre 300ms en VBA-RR (con LuaJIT, sin LuaJIT sobre 600) y mGBA tarda entre 12 y 15 segundos. Sí, en serio. 20 veces más que Lua y 40 veces más que LuaJIT. No quiero ni imaginar cuanto tardaría en buscar un camino de esos que el uscarrutas tarda 5 o 10 segundos en VBA!
También probamos llamando funciones que no son de los emuladores (sumas, restas, loops vacíos) y los tiempos de mGBA coinciden con los de Lua normal (sin JIT).
Por cómo está diseñada la integración de Lua con mGBA va a ser difícil lograr la misma eficiencia que con VBA-RR pero bueno, se puede mejorar bastante con respecto a como está ahora. Sólo con que quede, por ejemplo, 5 veces más lento que VBA-RR sin LuaJIT yo creo que sería suficiente, contando con las optimizaciones que espero poder aplicarle al código del script, claro.
Es importante tener en cuenta que solo optimizando el script sin tocar mGBA pude reducir el tiempo de 8 veces el de VBA-RR a 4 veces, y sin tocar gran cosa la verdad.
Así que aunque parezca que la cosa pinta fea, yo tengo bastantes esperanzas.
-
Hola!
Yo otra vez, esta vez con un minimensaje para no colapsar el anterior que ya es un buen testamento...
Solo venía para decir, así brevemente, que ayer descubrí que el pathfinder está totalmente roto.
Esto es un módulo que como funcionaba, yo jamás toqué. No es original ni del Crystal Access, es un módulo Lua que anda circulando por ahí desde hará más de 10 años, y de hecho se usa en numerosos proyectos tal cuál está.
Sin embargo, ayer se me ocurrió estudiarlo. De buscadores de caminos yo apenas sabía nada, pero con revisar un poco por Internet y centrarme en el algoritmo que usa ese módulo, cualquiera que conozca un poco ese algoritmo puede ver que está totalmente hecho una chapuza.
Para no liar el mensaje, simplemente decir que intentaré reconstruir el módulo con un algoritmo eficiente y adecuado, lo que si resulta aportará grandes beneficios al script. Eso sí, seguramente lleve tiempo, puesto que esto no es solo ajustar el algoritmo, es un efecto dominó que hará que tenga que cambiar las funciones de búsqueda de caminos por completo, de primera a tercera generación, así que no creo que sea una cosa de 2 días.
Y por ahora eso. Seguiré reportando por aquí de vez en cuando como va todo.
Saludos!
