Foros de tiflojuegos
Pokemon Access
-
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 respondamos
nuive
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 bien te pasarías
Esop ¡saludos! -
-
Hola.
Este post va a ser un poco largo, así que vamos por partes.
Me acabo de leer las 16 páginas del hilo, si, más de 400 mensajes, pero tenía que ponerme al día y valía la pena.
Primero que nada, creo que no alcanza poner en palabras el agradecimiento que te merecés @nuive por este trabajo inmenso y fantástico, hace un par de semanas empecé con rojo fuego, y es maravilloso poder volver a jugar a los clásicos pokemon después de años, y de forma autónoma, de verdad que ya por lo que hiciste habría que hacerte un monumento, porque como dijeron antes, fue bastante decepcionante cuando Rachel descontinuó el Braillemon, ya que aunque no era el pokemon original como tal, la experiencia era la misma y hasta donde llegó, yo la re disfruté.
Imagino que por un tema de universabilidad no agregaste el readme en español, pero debido a que hay partes que son igual que el del scribt del cristal original, y este había sido traducido por @corona en su momento, traduje y corregí los nuevos comandos del pokemon access, más la parte que pusiste en el primer post de la página 7, y se lo voy a pasar a @sanslash332 ,junto con las guías del rojo fuego, y el acceso directo a la del esmeralda de @randal ,así como una pequeña guía perdida que hay al principio del hilo, sobre la guarida rocket en el pk amarillo.
Esto mas que nada para tener el paquete en tfj lo más completo posible, para que nadie tenga excusas o problemas para poder jugarlo a fondo.
Por cierto @caspian ,me parece que la guía de como intercambiar sería muy útil, al menos mientras el emulador principal del script no tenga esa función.
Yendo a un par de dudas, que te las mencionaron, pero muy al principio y después no se volvió a comentar, no hay ninguna manera de jugar en el casino? Porque intenté probar la máquina traga monedas en ciudad asulona, y nada, la única es seguir los pasos de la guía de @randal ,por eso pregunto si al final se implementó algo para esta parte o no.
Por último, y esto si se comentó en la última actualización que lanzaste, hay indicios de mejoría para la lectura de movimientos y algunos menús en el esmeralda?
Yo aún no lo jugué, pero me comentaron que el problema principal es cuando un pokemon aprende un nuevo ataque, y tiene que olvidar uno, en esa parte no se puede leer con las flechas como en rojo fuego, amarillo etc, y toca tirar de OCR, porque por alguna razón, los ataques parece que tampoco se muestran en el mismo orden que aparecen cuando estás en una batalla.
En fin, fue un mensaje muy largo, pero tenía que agradecerte y decirte que por lo menos de parte de todo tiflojuegos.com, tenés nuestro apoyo y cualquier cosa en lo que podamos ayudarte, no dudes en decirlo.
Un saludo. -
¿Hola!
FabiG94
Imagino que por un tema de universabilidad no agregaste el readme en español, pero debido a que hay partes que son igual que el del scribt del cristal original, y este había sido traducido por @corona en su momento, traduje y corregí los nuevos comandos del pokemon access, más la parte que pusiste en el primer post de la página 7
Solo una cosa, con el readme actual traducido, el post de la página 7 ya no es necesario, puesto que las instrucciones para añadir hacks (el post de la página 7 es sobre esto ¿no?) ya están en el readme.
FabiG94
Yendo a un par de dudas, que te las mencionaron, pero muy al principio y después no se volvió a comentar, no hay ninguna manera de jugar en el casino? Porque intenté probar la máquina traga monedas en ciudad asulona, y nada, la única es seguir los pasos de la guía de @randal ,por eso pregunto si al final se implementó algo para esta parte o no.
No, por ahora no. Si te fijas, hay muchas cosas de las maquinitas esas del casino que no se leen ni al leer toda la pantalla. Lo tengo apuntado en la lista de cosas por hacer, pero la verdad que está en la lista de cosas poco prioritarias, al menos por ahora. En esta lista también están cosas como la función esta de contestar preguntas con 4 palabras (el Easy Chat en inglés, no recuerdo como se llama en español). Si bien son cosas importantes para acciones como la activación del regalo misterioso o la obtención de Pokémon y MTs, requieren una dedicación que en este momento no le puedo dedicar al script.
FabiG94
Por último, y esto si se comentó en la última actualización que lanzaste, hay indicios de mejoría para la lectura de movimientos y algunos menús en el esmeralda?
Yo aún no lo jugué, pero me comentaron que el problema principal es cuando un pokemon aprende un nuevo ataque, y tiene que olvidar uno, en esa parte no se puede leer con las flechas como en rojo fuego, amarillo etc, y toca tirar de OCR, porque por alguna razón, los ataques parece que tampoco se muestran en el mismo orden que aparecen cuando estás en una batalla.
Cierto, este problema con Esmeralda es una lata importante. Justo ahora, cuando puedo dedicarle un poco de tiempo al script es en lo que estoy trabajando. No solo en que se puedan leer estos menús, sino también en que se puedan leer mejor otros, como la selección de movimientos en combate, la selección de oponente en combates dobles... este tipo de cosas.
Y ya para terminar aprovecho la respuesta para confirmar que no, el script no está abandonado. Si bien hace más de un año que no publico versión nueva, sigo trabajando en el script cuando mi tiempo me lo permite. Creo que no es mucho arriesgar afirmar que pronto habrá nueva versión. Eso sí, será una versión centrada en solventar este tipo de problemas como menús que no se leen y cosas así, así como otros múltiples bugs que fui arreglando durante este tiempo. Así que no, por ahora no habrá inclusión de Rubí y Zafiro, y obviamente, mucho menos nada de generaciones más recientes. Pero el desarrollo del script sigue activo, y siempre que publico una nueva versión ya tengo cosas desarrolladas para la siguiente. Por ejemplo, el soporte para Rubí y Zafiro está a medias pero es bastante inestable, a la vez sigo trabajando en mGBA para ver si hay alguna forma de que podamos dejar estos VBA arcaicos atrás peeeeeero... no promete mucho la cosa.
mGBA es muy amigable para el desarrollo, pero por mucho que pido ayuda en el discord a nadie le interesa colaborar con la inclusión de LuaJIT en el emulador, con lo que estoy yo solo trabajando en esto. También me planteé añadir Lua a VBA-M, que es el único VBA decente que sigue en desarrollo actualmente, además de que también tiene emulación de cable link, pero es un caos. Sería necesario portar la estructura Lua de VBA-Rr a VBA-M, y VBA, sea la versión que sea, es un caos de código, además de que es impreciso. Respeto muchísimo más el trabajo que se está haciendo con mGBA, y si bien no recibo apoyo por parte de los desarrolladores, creo que es más inteligente volcar el esfuerzo en un emulador prometedor que no en otro que es un esqueleto que tiene 20 años sobre el que se van haciendo añadidos que cada vez lo convierten en más pesado.
