Buenas @nuive
Cuando leí esto que dijiste me puse a investigar, y pos. al menos a día de hoy, luajit sí sigue en desarrollo en su repositorio oficial:
luajit/luajit
El problema, que mandaron a tomar por culo las releases, y literal dicen que si quieres lo más nuevo, compílo usted mismo. Y están así como desde 2017...
Lo bueno, es que literal el último cambio fue desde hace dos días. No sé eso sí si habrán aumentado la lversión base de lua al cual le dan soporte, pero al menos muerto, que muerto no está el proyecto. Eso es bueno saberlo.
Y bueno también está el fork de openresti openresty/luajit2 pero que es más de lo mismo; se tiene que compilar uno mismo.
Vamos, es un problema pero no una barrera infranquiable, pero hay que estudiar que lua usan, y bueno... si te es fácil o no implementarlo con MGBA, si ellos aceptan dicho fork y tal. Pero tener que estar manteniendo el emulador paralelamente eternamente por el desarrollo del script.
Está bien feo. uwu
AHora ya poniéndonos estúpidamente más exquisitos... aparte de lua ¿no hay manera de optimizar los scripts de lua pero mediante una librería de c?
Porque. qué es lo más lento? la lectura de los datos en memoria? o los procesamientos de estos. Porque claro, es una cagada del porque de un portaaviones, pero si la lectura de la memoria es rápida y lo lento es su procesamiento, bien que puedes leer solo en lua, pero el procesamiento pasárselo directamente a un módulo nativo en c que se encargue de hacer la operación correspondiente. Puede que lo acelere un poco, pero claro, desarrollar en c es un dolor de cabeza en si mismo. uwu
En fin, ahí hay varias ideas...
Ahora ¿no hay ninguna otra opción dando vueltas por ahí que aguante lua y sea emulador de GBA?
Saludos!
Grande @nuive, una vez más
La cosa es que estamos hablando de milisegundos. Cualquier cosa va a ser más rápida directamente en lua que usar lua para leer, pasárselo a una librería en C que procese los datos, devolver los resultados a lua...
Y en caso de hacer esto, la cosa se traduciría en portar todo el script a C, vaya dolor de cabeza...
Esto de las librerías sí que me funcionó una vez. Cuando añadí la compatibilidad con Rojo Fuego implementé en lua una función para diferenciar los hacks de ROMs originales. Sin embargo, directamente al cargar el script lua se quedaba ahí pensando y un rato después decía que el script tardaba en responder. Esto lo solucioné con una librería en C, y de ahí el motivo por el que apareció el famoso crc32.dll que tantos problemas dio en las primeras releases del script con GBA.
Pero claro, esta DLL solo recibe unos datos, calcula el CRC32 de esos datos y lo devuelve. Para casos como este, en los que la librería externa tiene que hacer una operación o dos no hay problema, pero depender de una DLL para todo el script... el problema principal aquí es que ni en VBA-Rr ni en mGBA ejecutan el motor lua en un proceso separado, con lo que cada vez que lua procesa algo se para la emulación hasta que termina.
De ahí que en las últimas versiones el script haga que los juegos se lagueen bastante más. Se está volviendo demasiado pesado, y seguramente en el futuro haya que dividirlo, y no sé si para plataformas más complejas que la GBA esto será suficiente.
Y otros emuladores... está BizHawk, pero eso con NVDA funciona fatal, y a fin de cuentas no ofrece nada que no tengamos en VBA-Rr, al menos por ahora.
La única ventaja que tiene con respecto a VBA-Rr es que sigue en desarrollo.
Buenas @nuive
yep, de hecho es demasiado interesante.
Pero no, la idea no sería devolver nunca el resultado a lua; o al menos dependiendo qué es lo que haga.
Si como dijiste tú el script entero está en c, el mismo dll recibe datos, los procesa los manda a NVDA y termina sin devolverle nada más a lua que el control de ejecución.
Pero claro, sigue siendo lento; la única opción quizás de acelerarlo y dejando el proceso independiente de lua, es hacer una cochinada más o menos estilo lo que lanzaron para el primer intento de script de esmeralda antes de que llegases tú; un proceso totalmente independiente y el script de lua es una cosa pequeña que envía mediante un request (ya sea IPC, http, com o socket a pelo) los datos capturados, y el script en c (o ya en este punto cualquier otro lenguaje quetenga el programa corriendo en background) recibe los datos, los procesa y decide.
Pero claro, eso ya es complejizar las cosas para el usuario final; que tenga que echar a correr otro proceso primero, y bueno, tiene puntos de fallo como que lua no mande todos los bits necesarios en algún request y cosas así.
Claramente te permitiría optimizar el procesamiento e incluso usar threading, pero claro es complicar las cosas.
Supongo que te tocará ir analizando a futuro a medida que las cosas se complejicen y claro, vayan mostrando un mejor o peor rendimiento.
Saludos.
@nuive ¿qué pasó bro?
¿estás bien?
Noté que se borró tu perfil en github y con él el proyecto.
¿todo bien? o pasó algún problema?
¡Hola!
No, ningún problema, pero gracias por preguntar jajajaja.
Pues la verdad no tenía ni idea de esto, me acabo de llevar una sorpresa.
Por algún motivo que no acabo de entender, mi perfil y mis repositorios se pusieron en privado, y como yo puedo acceder a ellos sin problema no tenía ni idea de que no estaban públicos. Veré qué está pasando a ver si puedo solucionarlo.
Por otra parte y aprovechando que ya ando por aquí, actualizo un poco con el progreso.
El proyecto no está muerto, simplemente ahora mismo tengo bastantes más proyectos entre manos y lo tengo un poquito aparcado.
Sin embargo, no me olvidé de él, y de hecho uno de los proyectos que ahora mismo me quita más tiempo es el mGBA.
Así es, estoy trabajando para hacerlo compatible con Lua 5.1 y LuaJit, y con un poco de suerte, podremos utilizarlo como sustituto al VBA-Rr.
No me atraía mucho la idea teniendo en cuenta que los desarrolladores principales no tienen interés en mantener Lua 5.1, pero sí que si alguien lo hace, el autor dice que añade el soporte al master en github, así que yo me pongo a ver que consigo. Eso sí, no sé cuanto tardaré, puesto que estoy encontrándome unos cuantos problemas, y como digo, aunque estoy intentando solucionarlos, queda bastante poca gente interesada en la integración de Lua 5.1 y sus variantes con otras aplicaciones.
Aún así pues eso, aprovecho para comentar que el proyecto sigue vivo, y yo también jajajajajaja.
Editado: Definitivamente, en GitHub me bloquearon la cuenta sabrá dios por qué... Ya envié una solicitud de restauración y me estuve informando. Supongo que algún bot muy majo decidió que mi cuenta era SPAM, parece ser que este suele ser el motivo, falsos positivos en SPAM y ala, a bloquear cuentas de manera indiscriminada.
Uff @nuive menos mal que era algo así.
Primero y lo más importante, que bueno que tú estés bien, y no haya sido nada jeje.
Ya en segundo lugar. Pues a ver que pasa, ya algunos pensaban que a nintendo se le hubiese ocurrido avisar a github sobre tu cuenta y te mandasen un C&D por el contenido de pokemon en el repositorio.
igual habría sido raro e hipócrita, porque no están las roms ni nada en el repositorio; con suerte un par de hash de algunos roms y no mucho más.
ya respecto de la información, qué bueno que sigas avanzando; ya sea lentamente igual que hayan novedades siempre es agradable jeje.
Lo que me quedan dudas es ¿por qué tanta reticencia de los devs a trabajar con luajit en vez de lua?
Siendo que a pesar de lo dicho, luaJit sí sigue desarrollándose y está avanzando poco a poco luajit 2.1. Fíjate en la actividad del repositorio
enlace
Que ventajas trae 5.4 sobre luajit 2.1? Siendo que para cálculo pesado luajit es mejor... Y dado eso ¿cómo rayos en MGBA van a soportar los dos motores? tendrían que buscar una manera de diferenciar qué motor de lua es el que tengan activo. xd
En fin, ahí anda contando qué cositas van saliendo, y lo más importante. cómo te va con lo de github.
Saludos!
El problema es que el desarrollo en mGBA se basa en Lua 5.4, por ser la versión oficial de Lua.
En cuanto a lo de la compatibilidad, la cosa es que mGBA no funciona como VBA-Rr, en el que le ponemos la DLL de Lua que nos da la gana y la coge (siempre que sea Lua 5.1 o sus variantes como LuaJIT).
mGBA ya integra la versión de Lua elegida, por lo que las versiones oficiales nunca tendrán LuaJIT, puesto que utilizan Lua oficial, es decir, Lua 5.4.
Lo que yo estoy haciendo es añadir el soporte para que mGBA se pueda compilar y funcione con LuaJIT. Una vez que consiga esto, generaré mi propia build con LuaJIT, y será la que utilicemos para ejecutar el script.
Como una vez que esto funcione el desarrollador de mGBA me aseguró que se añadirá al repositorio, cuando haya alguna actualización importante de mGBA solo tendré que actualizar el repo local, volver a compilar y ya.
¡Hola!
Traigo otra pequeña actualización sobre el desarrollo, y me temo que no muy buena, en este caso relativa a los juegos que faltan de GameBoy Advance, Rubí y Zafiro.
En su momento pensé que sería cosa de adaptar los scripts de Esmeralda y poco más, puesto que los juegos son prácticamente iguales.
Y cuando me pongo a ver si en un par de tardes lo finalizo... me doy cuenta de que no.
Muchas cosas sí que son iguales entre los 5 juegos de esta consola, como el formato de los mapas, eventos, scripts... y la verdad que ya es bastante.
El problema es... bueno, una vez más, con el procesador de la pantalla. Sí, el dolor de cabeza permanente. Diseñé uno para Rojo Fuego y Verde Hoja; como recordaréis, debido a que no entendía muy bien ciertas cosas de este procesador, a la hora de sacar la compatibilidad con Esmeralda hubo que rediseñar todo el motor (sí, eso me generó muchas quejas sobre el rendimiento del script, pero por ahora, es lo que hay...) y el rediseño de este, comprendiéndolo ya mucho mejor, parece que resultó efectivo, puesto que tenemos el mismo procesador para RF, VH y Esmeralda.
Por todo esto, como decía, y entendiendo que esmeralda está basado en Rubí y Zafiro, esto bastaría para portar la compatibilidad a estos. Y... no.
Según parece, Esmeralda se desarrolló utilizando el código de Rojo Fuego y Verde Hoja como base, supongo que porque al desarrollar estos últimos, se darían cuenta de que el código de Rubí y Zafiro no era muy eficiente o algo así... no lo sé, la cosa es que el código base de FR y VH es prácticamente el mismo que en Esmeralda, mientras que el de Rubí y Zafiro es bastante diferente.
Y aquí es donde deduzco lo de la eficiencia. El problema no es que el código sea muy diferente, se adapta y ya. El problema es que es un caos.
Aviso: A partir de aquí, chapa para quienes entiendan de programación.
Ejemplos: En RF, VH y Esmeralda los textos se manejan por medio de clases que el código llama ventanas. Las ventanas se agrupan en la RAM por medio de un array que contiene las 32 ventanas que puede manejar el juego como máximo de forma simultánea.
En Rubí y Zafiro, el texto se maneja también con ventanas, pero las ventanas en vez de ser 32 fijas y agrupadas en array, son ventanas que aunque comparten estructura, están tiradas por la RAM del juego de forma caótica. Imagino (porque aún no lo acabo de confirmar) que todas tienen una misma estructura, pero cada una está por una esquina de la RAM, con lo que acceder a ventana[1], ventana[13] o ventana[30]... casi que es imposible.
Debido a esto, RF, VH y Esmeralda llaman a las funciones con índices, por ejemplo printText(1) para poner texto en la ventana 1. Rubí y Zafiro llaman a la función como printText(messageWindow) o printText(menuWindow). Vamos, que llaman a la función pasándole un puntero constante.
Junto con esta, la otra gran diferencia es como se manejan las capas de vídeo. En RF, VH y Esmeralda el juego guarda en la RAM cada capa de la pantalla (4 en total), las modifica sobre la RAM, copia cada ventana a la capa que le pertenece, y luego ya cuando el juego lo requiere, se copian a la VRAM para que el usuario pueda visualizar el resultado.
El proceso de copia a la VRAM tiene que estar en alguna parte para Rubí y Zafiro, puesto que es una función básica para que la GameBoy Advance muestre algo en pantalla. Sin embargo, en la RAM no hay ninguna copia de las 4 capas. Eso sí, sospecho que también estarán desperdigadas por la misma como las ventanas. En RF, VH y Esmeralda es habitual ver referencias desde bg[0] hasta bg[3]. En todo este caos, supongo que en algún momento encontraré algo como mainBG, secondaryBG o algo así.
Pero vamos, que para acabar con el rollo que acabo de meter, toca diseñar un nuevo procesador de texto, pantalla o como queramos llamarle, solo para estos dos juegos. Lo que me alegra es saber que en este caso no fue error mío, sino que los juegos trabajan de forma diferente.
Así que ya iré contando por aquí como se va resolviendo todo este cirio.
¡Saludos!
Editado: Tras investigar un poco más sobre las diferentes capas de vídeo de los juegos... me cuesta más dar crédito a lo que me encuentro.
No hay referencias a las capas en la RAM como en RF, VH y Esmeralda, básicamente porque el juego cada vez que modifica una capa lo hace directamente sobre la VRAM. No sé si es que al ser los primeros juegos de GBA que diseñaron en GameFreak no tenían ni idea de como iban las cosas en esta plataforma o qué, pero quemar la escritura en VRAM de esta manera...
Para los no entendidos en programación, lo que se hace en RF, VH y Esmeralda es como se suele imprimir en una impresora. El ordenador prepara la página, y la envía a la impresora ya lista para imprimir.
Lo que se hace en Rubí y Zafiro es, básicamente, enviar a la impresora letra a letra, indicando para esto en que coordenadas de la hoja imprimir cada una de ellas.
No había visto el primer mensaje xd, pero bueno respondamosnuive
El problema es que el desarrollo en mGBA se basa en Lua 5.4, por ser la versión oficial de Lua.
Y tienen alguna razón para preferir esa versión?
Si miras en stack overflow o redits de programación, como que todo el mundo dice que no existe una razón real viable para escojer lua 5.4.
Si sabes que tu requieres lua para un procesamiento pesado anda por luajit. En el caso de que no sea así, puedes utilizar otras variantes como lua.
Dada la naturaleza del scripting en un emulador... que es para puro hacer TAS ¿por qué escojer el motor más lento?
Entendería que me dijesen que luajit está descontinuado, pero... no lo está
Y si me dicen es que no se actualiza a lua 5.4, es que no, y no lo va a ser jamás; luajit irá sacando cada vez más y más cosas nuevas, pero que se van a ir bifurcando cada vez más del lua original. puede que saquen ciertas compativilidades como con lua 5.2 y algo de lua 5.3, pero a medida que luajit optimice o cambie cosas... se irá convirtiendo en otro lenguaje.
Pero bueno, MGBA ponchos.nuive
mGBA ya integra la versión de Lua elegida, por lo que las versiones oficiales nunca tendrán LuaJIT, puesto que utilizan Lua oficial, es decir, Lua 5.4.
Ah! más encima lo enlazan de manera estática en tiempo de compilación! aaaa... mátenlos.nuive
Como una vez que esto funcione el desarrollador de mGBA me aseguró que se añadirá al repositorio, cuando haya alguna actualización importante de mGBA solo
tendré que actualizar el repo local, volver a compilar y ya.
Supongo que es lo mejor. Al final habrá que tener nuestra propia versión de MGBA xd.Mira tú que verdad más divertida, así que al final FR y LF son los que en realidad son juegos nuevos, y esmeralda se agarra de ellos, mientras que rubí y safiro son los viejos hmmm Curioso.nuive
Según parece, Esmeralda se desarrolló utilizando el código de Rojo Fuego y Verde Hoja como base, supongo que porque al desarrollar estos últimos, se darían
cuenta de que el código de Rubí y Zafiro no era muy eficiente o algo así... no lo sé, la cosa es que el código base de FR y VH es prácticamente el mismo
que en Esmeralda, mientras que el de Rubí y Zafiro es bastante diferente.nuive
Pero vamos, que para acabar con el rollo que acabo de meter, toca diseñar un nuevo procesador de texto, pantalla o como queramos llamarle, solo para estos
dos juegos. Lo que me alegra es saber que en este caso no fue error mío, sino que los juegos trabajan de forma diferente.
Auch, no deja de ser harta pega. más aún con lo que viene.nuive
No hay referencias a las capas en la RAM como en RF, VH y Esmeralda, básicamente porque el juego cada vez que modifica una capa lo hace directamente sobre
la VRAM. No sé si es que al ser los primeros juegos de GBA que diseñaron en GameFreak no tenían ni idea de como iban las cosas en esta plataforma o qué,
pero quemar la escritura en VRAM de esta manera...
jajajajaja
Y oprobablemente habrían seguido así de mal si es que no les funcionaba más adelante xd.
probablemente en lg o esmeralda por animaciones y cosas que querían hacer no les daba el procesamiento para manejar la vram dinámicamente y a tiempo real y por eso manejaron las capas en ram. sino quizás habrían seguido haciendo eso.
En fin ¿y qué idea tienes para hacer?
leer la vram directamente nomás?
Conocer pequeñas estructuras o formato de memoria para reconocer que tipo de pantalla puede ser y arreglártelas con eso? o intentar capturar información desde otro lugar primero.
En fin. gracias por la información jeje.
a... ¿y qué pasó con tu githu? ya lo recuperaste?
Saludos!
No, el github aún nada. Mandé tickets al soporte pero ya leí en varios sitios que se lo toman con calma, un mesecito de espera no me lo quita nadie.
En cuanto a lo otro... estos días que estoy sacando un poco más de tiempo le estoy metiendo caña pero puf.
Ya hice referencia unas páginas atrás a como en GBA todo se complicaba porque mientras que en GB en la RAM se guardaba un tilemap de la pantalla, en la GBA no.
Pues se ve que lo que quisieron hacer con Rubí y Zafiro fue mantener la estructura lo más fiel a la GB (obviamente de locos, porque son máquinas muy distintas) y sí, como lógicamente escriben tanto los mapas de tiles como los píxeles propiamente dichos a la VRAM, habrá que tirar de VRAM más que de RAM.
Y esto va a suponer un problemón no con los textos, sino con los menús. En RF, VH y Esmeralda, como ya comenté hay una serie de ventanas virtuales en la RAM. Fue una auténtica tortura que me llevó más de un año entender, pero algo que se entiende por qué está hecho y que es muy útil cuando se entiende como funciona.
Por ejemplo, la mochila está formada por varias ventanas: una para la lista de objetos, otra para el título de la ventana (el nombre del bolsillo en el que estamos), otra para la descripción del objeto seleccionado... así mismo, cuando se pulsa A sobre un objeto, se crea una nueva ventana para el menú con mayor prioridad (lo que quiere decir que va por encima de las demás y aplastará todo texto que tenga que aplastar para mostrar el menú correctamente), y así con todos los menús, submenús, y submenús de submenús.
Esto lo facilitaba todo muchísimo porque cuando el script detectaba una ventana con prioridad pues leía esa ventana e ignoraba lo de las que están debajo (todo esto simplificando mucho la explicación). Al pulsar la letra T para leer toda la pantalla, eso sí, se lee la pantalla tal cuál se ve, por eso a veces al estar en un menú de la mochila con la letra T lee nombres de objetos cortados, porque el menú se superpone y así es como se ve, trocitos de los nombres puesto que partes de los mismos están tapadas por el menú.
Ahora bien, esto en GB era mucho más simple. Una copia de la pantalla en la RAM y ya. Con eso, el script tiene que monitorizar a cada paso si aparece un menú, y si aparece, pues decidir que leer y que no en base a los bordes del menú, que también tiene que buscarlos en la copia de la pantalla.
Es decir, mientras que en la GBA el script tira de mucho dato interno, en la GB tiene que hacer como si estuviera viendo la pantalla y deducir qué es texto, qué es lista, que es menú...
Y ahora, trabajando con Rubí y Zafiro me encuentro con que el código es un híbrido entre la GB y la GBA.
Mientras que todo lo que no es texto e iconos se maneja igual que en RF, VH y Esmeralda, parece que con el texto quisieron hacer, supongo que por como manejaban todo en la GB, algo similar. Con lo que no, al contrario de lo que puse en el post anterior, no hay una ventana para cada cosa en la RAM.
Hay unas cuantas ventanas por ahí desperdigadas como dije, pero hasta ahora todo en lo que estoy trabajando se maneja solo con una triste ventana en RAM, que va mandando todo a la VRAM y ya, sean textos, menús, o el maldito árbol genealógico desde el Señor Peñas hasta Groudon y Kyogre, yo que sé.
Conclusión, esto es una locura, y para no cargarme todo el script estoy desarrollando en un archivo a parte que unificaré cuando tenga totalmente claro como funcionan estos juegos.
Parece que lo de las capas de vídeo ya lo solucioné, pero no puedo probarlo porque... bueno, las capas de vídeo en teoría funcionan, pero como aún no sé como capturar el texto que se envía a la VRAM pues... por ahora solo recibo pantallitas muy bien formadas pero totalmente en blanco.
hola! creo que este es el lugar indicado para preguntar...
con el emulador que trae el tfj en la descarga oficial, se pueden hacer intercambios o por lo menos para completar la pokedex? si sí, como se hace? y si no, se puede intercambiar de forma acccesible? igual si por ahí existe una guía taría bueno que lo publiquen
matias1912
hola! creo que este es el lugar indicado para preguntar...
con el emulador que trae el tfj en la descarga oficial, se pueden hacer intercambios o por lo menos para completar la pokedex? si sí, como se hace? y si no, se puede intercambiar de forma acccesible? igual si por ahí existe una guía taría bueno que lo publiquen
No, no se puede. Creo que había por ahí una guía para intercambiar con mGBA, pero no recuerdo muy bien donde estaba.
Siento el doble post, pero como no tiene que ver con lo anterior... solo escribía para notificar que finalmente, mi cuenta de github vuelve a estar puesta como pública.
Que buena noticia @nuive
Pucha que se demoraron!
Y te dieron alguna explicación... creíble?
Porque ya de razonable. difícil. con creíble bastaría.
Y por la explicación. muchas gracias por los detalles técnicos, bien entendibles.
Lástima nomás por todo el trabajo que hay que realizar; es cuasi como que tener que rehacer y retroceder a los viejos scripts de gb con detallitos de GBA jajaja.
Supongo que problemas de los juegos primerizos.
En fin. a esperar novedades
sí, me dijeron que alguien se había colado en mi cuenta y empezó a hacer cosas en repositorios como marcarlos como favoritos y cosas sin ningún tipo de sentido, la verdad. Por suerte desde GitHub deshicieron todo lo que se había tocado y ya está todo como antes.
respondo a matias por lo de los intercambios. Si, efectivamente hay una guía hecha por mi, pero el link caducó. Hace poco hice otra, esta vez en texto, pero el link era de fromsmash y también ha caducado. no sé si la borré o todavia la conservo. De cualquier modo, si veo que interesa la vuelvo a escribir y la subo aquí.
a bueno @nuive menos mal que era solo eso y nada de otra índole.
Supongo que a cuidar más las contraseñas y no mucho más. para evitar que indeseables se metan a hacer porquerías
@caspian Deberías de hacer la guía jaja, y subirla al foro de guías y tal, para que quede así registrada en texto y guardada en el mismo foro
muchos la agradeceríamos que quedaría súper biente pasarías
Esop ¡saludos!
