Ver la versión completa : He portado el Echo a la RG350, pero va muy bien
Hola a todos:
Bueno, ha costado lo suyo, pero ya podéis descargaros una beta de THE AMAZING ADVENTURES OF ECHO para la RG350 desde mi página de GameJolt (no sé si hay un repositorio oficial para ello, pero bueno, :spam: )
https://gamejolt.com/games/the-amazing-adventures-of-echo/170481
53334
Al lado del botón de descarga hay tres puntos en vertical. Seleccionais la versión de RG350 y a disfrutar.
Si es compatible con otras versiones de Dingux... ¿por qué no? :D No lo sé, no puedo probarlo, y ya he dicho que, por experiencias pasadas, no voy a hacer ports oficiales a ninguna consola que no posea.
Digo que es una beta porque no es una versión estable, probada ni nada. He cogido la útima versión estable que tenía, y he "forzado" la versión del Sistema Operativo a que sea la de Dingux, y he añadido algo de código para que actúe con los controles de PC, pero con la resolución de GP2X.
Vais a notar que hay algunos problemas con la configuración, de hecho no recomiendo tocar la configuración de los controles. Por alguna razón, se pueden configurar los botones X e Y pero no A y B, y los botones de arma siguiente y anterior se configuran al revés, así que he asignado el salto al X y el disparo al Y ¿o era al revés? en cualquier caso, se pueden intercambiar desde el menú de configuración (moveis el cursor sobre la acción, pulsais START y seleccionais el nuevo botón).
Si no, lo que hay que hacer es modificarlo desde el fichero de configuración con un editor hexadecimal. Si necesitáis una guía, decidlo y os la escribo en este mismo mensaje.
El resto de opciones (el estilo gráfico, fondos de scroll y primer plano de scroll) sí se pueden cambiar al gusto. Los he dejado activados y la consola no se resiente ni un ápice.
Como bonus, he dejado el fichero de guardado que os dará acceso a todos los niveles, todas las armas y toda la energía posible desde el menú de selección de nivel (aun en desarrollo... aunque lo que falta por desarrollar es un fondo con scroll al más puro estilo Sonic 2 :D).
Quedará algún fleco por pulir, y hay ciertos defectos gráficos que son cosa del port de Bennu, pero como ahora mismo no dispongo de una versión estable de la última versión, ya que estoy en pleno desarrollo, no puedo hacer un port propiamente dicho, pero los cambios de esta versión se trasladarán al código principal y se añadirá código para que sea más sencilla la transición a otras máquinas por el estilo.
PD: Los que no hayais seguido el culebrón de los cambios rumbo a la 1.4, podréis ver por primera vez al bueno de Doggy por los niveles :D Es el perro de Echo, y sobre el que iba a girar todo el argumento del juego antes de cambiar de "aventura" a "arcade". Aquí os servirá para guardar partida a mitad del nivel, y estaba pensando en que rellenase la vida o la experiencia del arma... pero dado que funciona tan bien en la RG350, se pueden dejar las melees de enemigos como estaba previsto inicialmente.
Para la 1.4 aun tengo que corregir un bug que he introducido con los cambios en la detección de durezas de los enemigos, que es lo más costoso de arreglar. El resto consiste en... desarrollar los tres niveles nuevos :D
Y si queda tiempo, hacer finalmente el nivel 2 perdido. Se saltó porque requería cambiar la mecánica jugable y no me daba tiempo a programarlo.
Muchas gracias Drumpi, hoy mismo lo pruebo!!
Como repositorio "oficial" supongo que puedes usar el de gcw-zero
fbustamante
11/01/2020, 22:20
Gracias chavalote. :brindis:
Lo voy a probar en la Bittboy a ver si va. :)
He estado jugando y vaya currazo que debe tener el juego, impresionante
fumaflow
12/01/2020, 22:02
Que pasada de juego has “echo” tío
fbustamante
12/01/2020, 22:35
Probado en la BittBoy y hace lo mismo:
"segment fault" cuando sales del menú, le dices si quiere grabar o no, y realiza el fundido en negro. :(
fbustamante Puede ser que la versión de BennuGD de tu máquina no sea la misma que la de la RG350. Por eso quería que funcionase el GPE y que llevase su propia versión de Bennu en el zip.
Si tienes el runtime de la versión 263, prueba a ponerlo como runtime y a escribir lo mismo que en el GPE de Wiz para que lo coja, si no, cuando llegue a casa, te mado el código modificado para que puedas compilarlo tú, en la máquina, en el PC o donde tengas la versión correcta del compilador :D Sólo he modificado un fichero al final.
A ver si tengo tu e-mail a mano :P
Al resto, parece que en estos... casi 10 años no lo habéis probado y... Espera ¿Van a hacer 10 años en Marzo? Pensaba que era más antiguo y... qué rápido ha pasado el tiempo :S
Me habéis hecho ir a buscar el concurso donde participó el juego y recordar aquellos dos meses tan intensos de trabajo, mientras hacía el TFM, para al final, con la ayuda de _-Caleb-_ quedar tercero a un punto del segundo (una frikada con un mono nos ganó a todos). Me hace gracia volver al hilo y leerme cuando me "quejaba" de ganar los accesorios de Wiz sin tener la Wiz y... Sí, desarrollé el juego en Wiz sin la Wiz, y milagrosamente ¡FUNCIONABA! (salvo ciertos problemas con los controles y los mandos).
Hilo del concurso: http://forum.bennugd.org/index.php/topic,893.0.html
Hilo de resultados del concurso: http://forum.bennugd.org/index.php/topic,1210.0.html
No encuentro el hilo del desarrollo, donde se iban comentando todos los cambios que se iban haciendo (era obligatorio ir documentando los progresos que se hacían en un hilo que teníamos cada uno).
EDIT: ¡Lo encontré! http://forum.bennugd.org/index.php/board,47.0.html
Voy a tener que ponerme las pilas si quiero aprovechar el 10º aniversario y lanzar algo nuevo :D
Bueno, pues se supone que este sábado debería lanzar la nueva versión... pero no sé si me va a dar tiempo a tener algo que sea "lanzable".
A duras penas tengo terminado el nivel 4-2... el nuevo nivel 4-2, porque el anterior ahora es el nivel 5, y no sé si funciona con todos los cambios que he hecho al "modo historia".
Los cambios para RG350 están hechos, pero hay algún problema para redefinir los controles. Por alguna razón, la función "scan code" que he programado identifica el botón R1 como el B, cosa extraña ya que la key _backspace está asignada sólo y exclusivamente al R1. No me va a dar tiempo a depurar esto.
Sin embargo, ya tengo algo del 4-3, y casi la mitad del boss... Bueno, los detalles, lo dicho, en el foro de BennuGD :D
De aquí al sábado, apenas tendré 30 minutos diarios para hacer algo. Me temo que, si lanzo algo, será una beta privada, nombre en clave, "versión 1.3.1", y ya casi mejor que no saque nada hasta que tenga bastante avanzada la "segunda temporada" (al menos los niveles 4 y 5) y el port a RG350 completo al 100%
fbustamante
03/03/2020, 21:24
Eres la repera. :D
Te tiras 3 años sin hacer nada y quieres sacar un juego en 3 días. :D
Anda que si programaras más uniformemente.... :)
Si programara más uniformemente, este juego ya tendría cerca de 30 capítulos, que serían como dos o tres temporadas de una serie normal :D
Aunque en realidad le pega más el concepto de mini-serie, por el tiempo que necesita para "rodarse" un capítulo... Es que los extras no nos duran ni dos días y hay que irlos reponiendo. El primo del Chuache ya dimitió una semana antes de terminar el de "2012: Alien Invasion" :lol:
En realidad, el desarrollo "comenzó" de nuevo por tu culpa con el port "no oficial" :D :D :D Una cosa ha llevado a la otra, y como yo no sé hacer las cosas sencillas, es decir, dejar los niveles como estaban, añadirles 4 tonterías, completar la tercera parte y tirar para adelante, pues así estamos, que tengo que hacer en menos de dos meses tres niveles completos y no se cuántas mecánicas nuevas :P
Pero bueno, al final la versión 1 se hizo en dos meses (tres si contamos la reestructuración del scroll tileado y la detección de durezas) reales de desarrollo, y la 1.3 para el concurso del Hamster creo que fue 1 mes, aunque aprovechando muchas cosas que ya estaban hechas... y siempre con varias horas diarias de desarrollo, y no a ratos de tiempo libre :D
Y entre medias de estos 3 años, hay varios proyectos: el que empecé con Futublog, el GoBaUg, diversas GameJam, Space 52... e incluso el Tilemap Editor 2, que fue el principal responsable de los retrasos del Echo. Hubo un intento de recuperar el Screen Break Time, haciendo yo mismo los gráficos que faltaban, pero la falta de un motor o algo que me ayudase a realizar las animaciones entre niveles del modo historia, y el hecho de que ya nadie usase la Wiz ni la Caanoo, pues se canceló... y no veo que se vaya a recuperar a corto plazo, ya que ninguna de las Dingux-Consolas trae pantalla táctil, ni sé usar el port de BennuGD a Android.
...y programar 9 horas diarias en el trabajo tampoco ayuda :lol:
Lo mismo hay suerte, y al final, puedo subir algo el sábado, aunque sigo viendo que es demasiado precipitado.
fbustamante
04/03/2020, 14:31
Lo mismo hay suerte, y al final, puedo subir algo el sábado, aunque sigo viendo que es demasiado precipitado.
Pues desde aquí mucho ánimo. Y que conste que nadie te está apretando. :brindis:
josepzin
04/03/2020, 14:37
Yo sí le metería un poco de caña... estos programadores vagos se piensan que vamos a vivir para siempre.
Pues desde aquí mucho ánimo. Y que conste que nadie te está apretando. :brindis:
¿Que no? Ya he tenido que reportar un par de veces a un tal Drumpi, porque está todos los días metiendo buya.
Yo sí le metería un poco de caña...
Está bien, esta tarde mismo les mando un correo a los de Sega, a ver si me dan una licencia y puedo meter a Big, the cat, en el juego :awesome:
Buenas noticias, parece que he podido solucionar la mayoría de los problemas que tenía con el código de la RG350 y el nivel 4-2 está casi terminado. Me hubiese gustado tener terminado al menos todo el nivel 4, pero es posible que pueda subir una versión 1.3.3 (beta) este fin de semana.
Aun tengo que pulir detalles del nivel pero me preocupa el port de la consola con Dingux: por alguna razón que aun desconozco, los controles para cambiar de arma están invertidos, y Gravor, el dragón del final de la fase 1-3, se ha vuelto invencible (ignoro si será cosa de los defectos gráficos que se ven al hacer rotaciones y escalados que provoca colisiones no deseadas contra los "escudos" de la boca del dragón u otra cosa).
NO es una versión final, es sólo un avance para sacar algo por el 10º aniversario. El desarrollo seguirá adelante, espero que al mismo ritmo o un poco más suave, y ya lanzaré algo en cuanto se termine el nivel 4 y alguno más.
Ojo, estoy probando con el firm oficial de diciembre. No sé si con el Rogue actualizado irá mejor, pero hasta que no consiga que se ejecute la última versión de BennuGD de forma independiente al del firm, el port aun está "cogido con pinzas". Otros ports de OpenDingux podrían funcionar con esta versión, pero como ya he comentado, sin tener la consola objetivo, no puedo probar.
Buenas a todos:
Finalmente, hoy... bueno, ayer, he subido la nueva beta de "the Amazing Adventures of Echo". Está disponible para PC, Wiz, Caanoo y la prometida versión RG350.
https://gamejolt.com/games/the-amazing-adventures-of-echo/170481
Como novedades, teneis un nuevo nivel, el 4-2, que nos introduce en un pasadizo subterráneo hacia una entrada secreta de la Gran Pirámide. El level select os permitirá ejecutar cualquier nivel que hayais desbloqueado, con las armas que hayais conseguido llevar al final del episodio, y con la energía que hayais encontrado a lo largo del episodio. Pero como es el 10º aniversario de la publicación del juego para el concurso de Wiz, su primera release, os he añadido un fichero de salvado que os dará acceso inmediato a todos los niveles, armas y energías del juego en dicho modo; si no os gusta, podéis borrarlo y jugar tal como se diseñó; además, superar la historia es la única manera de acceder a los créditos y ver el auténtico final del juego, por _-Caleb-_ que merece la pena :D
La versión para PC es la de Windows, pero el DCB y lo demás es compatible con Linux, sólo depende de cómo tengais instalado el runtime de BennuGD.
Las versiones de Wiz y Caanoo se han subido de acuerdo a lo que ya comenté hace tiempo en la encuesta, que se seguiría el desarrollo y que se intentaría mantener la compatibilidad con esas consolas, por lo que el rendimiento no es el óptimo, pero se puede jugar (se le puede añadir un frameskip si eso no os molesta).
La de RG350 en teoría es compatible con cualquier OpenDingux. Se ha añadido un parámetro en el script de arranque que fuerza al código a ejecutarse en el OS_ID de Dingux. Sólo hay dos problemas con el port a día de hoy: no puedo prometer que los controles funcionen en todas las máquinas, se han usado los códigos de teclas de RG350, por lo que si en otra portátil se han mapeado de forma diferente, no va a funcionar; Gravor, el jefe que se encuentra al final del nivel 1-3, el dragón, no puede ser derrotado, ignoro el por qué, aunque puede tener que ver con los defectos que se muestran al rotar los gráficos, que estén provocando malas colisiones (puede que versiones más modernas de BennuGD solucionen este problema).
Estaré atento a cualquier tipo de bug que encontréis, abierto a cualquier tipo de sugerencia, y agradecido de cualquier tipo de crítica, especialmente las positivas :lol:
Esto no significa que esto se pare aquí, ni hablar. Esta versión es más una "beta" de lo que está por llegar: aun hay que hacer los niveles 4-3 y el boss (que están a medio hacer), arreglar el nivel 5 (más puzles, más largo, más dificultades aprovechando los nuevos elementos), hacer ciertas modificaciones al 3, y diseñar los niveles 6 y 2.
Pero ya sin fecha de entrega y sin agobios :D
futu-block
10/03/2020, 09:18
Si programara más uniformemente...
Y entre medias de estos 3 años, hay varios proyectos: el que empecé con Futublog, el GoBaUg, diversas GameJam, Space 52... e incluso el Tilemap Editor 2, que fue el principal responsable de los retrasos del Echo. Hubo un intento de recuperar el Screen Break Time, haciendo yo mismo los gráficos que faltaban, pero la falta de un motor o algo que me ayudase a realizar las animaciones entre niveles del modo historia, y el hecho de que ya nadie usase la Wiz ni la Caanoo, pues se canceló... y no veo que se vaya a recuperar a corto plazo, ya que ninguna de las Dingux-Consolas trae pantalla táctil, ni sé usar el port de BennuGD a Android.
te comprendo, llevo con el editor de caras liadisimo, cada vez que saco una especie de versión estable se me ocurren nuevas caracteristicas que añadir...
...y eso que no es un juego, es un programa, un click and point como se suele decir...
...y eso que ya hay una versión to puerca ya hecha
Bueno, yo he descubierto que la clave del éxito de hacer un programa es hacerlo lo más modular posible, es decir, crear un "núcleo" al que se le puedan ir añadiendo cada vez más cosas, sin que unas no influyan con otras.
Con un videojuego, eso se traduce en crear las mecánicas de forma independiente, intentando mantener las partes que interactúan con otras (si las hubiera) en una zona muy concreta del código, y luego que cada nivel sea totalmente independiente del resto, y que el hilo conductor lo lleve un método/proceso/función, que sea quien gestione las variables "globales" (vidas, energías, qué nivel cargar a continuación...). Es por eso que ahora estoy ampliando el Echo, a ver si hago de él un "juego completo", que sólo dos niveles se me antojan cortos, y cada mes se me ocurre un nuevo nivel que añadirle :D
En cuanto a programas, aunque sea un sistema anticuado, el modelo-vista-controlador se me ha revelado como el mejor sistema para poder crear utilidades que se pueden ampliar hasta el infinito.
Si no lo conoces, es un sistema que divide el código en tres niveles diferentes:
- Modelo: son el código destinado a almacenar los datos, y a gestionarlos. Por ejemplo, tus caras, ojos, cuerpos... No es sólo el load_fpg o el unload_fpg, si te creas una lista de gráficos es el código que gestiona el añadir o quitar elementos a esa lista, cambiarlos, ordenarlos. Generalmente son funciones, nunca procesos.
- Vista: es el código que controla la interfaz, es decir, lo que se ve. Es lo que reacciona cuando se pulsa un botón, lo que maneja el scroll de la pantalla, y el que tiene los procesos con gráficos. En este caso sólo son procesos, rara vez necesitas funciones.
- Controlador: el lo que realiza las acciones. Se sitúa entre la vista y el modelo, y no usa ni gráficos ni variables que no sean privadas, nunca (o casi). La idea es que si pulsas el botón de "cargar gráfico", el proceso de la vista llame a una función del controlador, diciendo "me han pulsado" o "quieren cargar", el controlador llama al modelo de carga de ficheros para obtener el FPG y luego se los pasa al modelo que guarda la lista de FPGs para que lo añada
La idea es que el código de la vista nunca usa los datos directamente, los del modelo nunca usan gráficos, y rara vez se comunican entre ellos. Por ejemplo, una vez hecha la carga del FPG ¿cómo actualizas la lista que hay en pantalla? Pues el controlador, tras enviar el dato a la lista, le solicita la lista completa, y se la pasa al proceso que controla todos los gráficos de la lista para que se actualice.
Puede parecer mucho trabajo, y un poco confuso al principio, y el proceso de control se puede ir haciendo enorme si no tienes cuidado, pero créeme, se lo he aplicado al Tilemap Editor 2, y actualmente puedo añadir tantas cosas como quiera. Es cierto que terminas loco de tanto ir de un lado a otro para hacer algo tan "sencillo" como poner un tile, pero si el día de mañana decido que se pueda usar los cursores en lugar del ratón, sólo tengo que cambiar el proceso de la vista, sin tocar el controlador, con todo lo gordo que es, ni los datos.
Hay mucha documentación en Internet sobre ello, mucho mejor explicado que yo. Échale un vistazo.
Y seguro que por aquí alguno me dirá que hay otros esquemas más simples, eficientes o mejores, y puede que tengan razón (o no, recordemos que BennuGD usa procesos, no programación secuencial), pero por el momento, para aplicaciones, es el mejor sistema que he visto. Y con una búsqueda rápida, parece que también es el que más se usa hoy día para la programación Web.
^MiSaTo^
10/03/2020, 12:13
Dado que sacas el tema te recomiendo que leas Game Programming Patterns (https://gameprogrammingpatterns.com/ gratis en la web, pero lo puedes comprar en kindle o en papel).
Para juegos usar MVC es un poco meh aunque es un principio para separar cosas. Pero te recomiendo Entity-component system por ejemplo. Aun así echa un ojo a ese libro que hay un monton de patrones que se pueden usar no solo en juegos ;)
Te puedo recomendar otros libros si quieres aprender más sobre arquitectura y/o patrones de diseño porque es un tema que a mi personalmente me fascina y en mis ultimos curros por cuenta ajena he sido arquitecta de software así que se un poco del tema.
Pues muchas gracias, seguro que es una lectura muy interesante :)
Más que nada porque de toda la gente con la que he hablado, ninguno ha sabido darme patrones de programación, de diseño o de organización de videojuegos. Cada uno tenía sus sistema, y los que habían estudiado un poco el tema me comentaban que no había sistemas "estandar" o más efectivos que otros, y que cada equipo trabaja como mejor le viene.
De todas formas, no, MVC no lo uso con los juegos, sólo con las aplicaciones de escritorio ;)
También es verdad que el programar con procesos de DIV/Fenix/BennuGD es diferente a la programación secuencial... más o menos. Hay similitudes, pero para según qué cosas, el tratamiento es diferente (concretamente con la forma de interactuar).
Yo ya más o menos tengo mi método: un proceso principal que llama a las funciones de carga de datos, inicializa resolución, teclas, etc, muestra logos, y luego tiene una máquina de estados para el menú principal, el menú de configuración del juego, jugar un nivel suelto, empezar la partida, créditos...
Luego tengo eso, un proceso que controla el juego en sí, que llama a "play_level" que ya se encarga de gestionar recursos, crear prota, enemigos, etc, y esperar que alguien le diga si el nivel ha terminado satisfactoriamente (y cómo), si el prota ha muerto, o se ha cancelado la partida, y en función de esos datos, pasar al siguiente nivel con los datos del anterior (vidas, energías...) o salir de nuevo al menú.
Ya cada proceso se gestiona las cosa por su cuenta: comprobar los controles y actuar en consecuencia, usar los datos de velocidad para mover al personaje, comprobar colisiones con objetos, enemigos y amenazas, y finalmente seleccionar el frame de animación a mostrar en función de la máquina de estados y el momento dentro del mismo. Es casi el esquema que se sigue en Unity.
Si hubiera algo de MVC, sería con la interfaz, pero al final termino por un tratamiento más directo entre vista y modelo, estilo "bindings" de C#.
Como los procesos son independientes, añadir un nivel al final se reduce a añadir al "play_level" los nuevos recursos, al motor de scroll tileado los nuevos enemigos (la información de enemigos, items, y demás las guardo en los mapas de tiles, por lo que el motor de scroll es quien genera dichos procesos) y los tipos al gestor de señales (el que hace la pausa, mata los procesos al final del nivel...), y luego indicarle al proceso "game" en qué orden cargarlo y qué hacer cuando se sale del mismo.
Volviendo al libro, tengo curiosidad por ver cómo administra motores tipo Unity, que es un motor que veo muy fuertemente atado a su interfaz gráfica. A ver, se puede hacer todo programando, pero he visto que, a la larga, es más funcional programar "herramientas" que se puedan modificar visualmente, y que permita a grafistas tener más control sobre la edición de niveles... más que nada para repartir el trabajo, que ya bastante tiene el programador con el trabajo de integrar gráficos, música, animaciones y de programar todos los eventos :D
^MiSaTo^
10/03/2020, 13:16
Pues muchas gracias, seguro que es una lectura muy interesante :)
Más que nada porque de toda la gente con la que he hablado, ninguno ha sabido darme patrones de programación, de diseño o de organización de videojuegos. Cada uno tenía sus sistema, y los que habían estudiado un poco el tema me comentaban que no había sistemas "estandar" o más efectivos que otros, y que cada equipo trabaja como mejor le viene.
De todas formas, no, MVC no lo uso con los juegos, sólo con las aplicaciones de escritorio ;)
También es verdad que el programar con procesos de DIV/Fenix/BennuGD es diferente a la programación secuencial... más o menos. Hay similitudes, pero para según qué cosas, el tratamiento es diferente (concretamente con la forma de interactuar).
Yo ya más o menos tengo mi método: un proceso principal que llama a las funciones de carga de datos, inicializa resolución, teclas, etc, muestra logos, y luego tiene una máquina de estados para el menú principal, el menú de configuración del juego, jugar un nivel suelto, empezar la partida, créditos...
Luego tengo eso, un proceso que controla el juego en sí, que llama a "play_level" que ya se encarga de gestionar recursos, crear prota, enemigos, etc, y esperar que alguien le diga si el nivel ha terminado satisfactoriamente (y cómo), si el prota ha muerto, o se ha cancelado la partida, y en función de esos datos, pasar al siguiente nivel con los datos del anterior (vidas, energías...) o salir de nuevo al menú.
Ya cada proceso se gestiona las cosa por su cuenta: comprobar los controles y actuar en consecuencia, usar los datos de velocidad para mover al personaje, comprobar colisiones con objetos, enemigos y amenazas, y finalmente seleccionar el frame de animación a mostrar en función de la máquina de estados y el momento dentro del mismo. Es casi el esquema que se sigue en Unity.
Si hubiera algo de MVC, sería con la interfaz, pero al final termino por un tratamiento más directo entre vista y modelo, estilo "bindings" de C#.
Como los procesos son independientes, añadir un nivel al final se reduce a añadir al "play_level" los nuevos recursos, al motor de scroll tileado los nuevos enemigos (la información de enemigos, items, y demás las guardo en los mapas de tiles, por lo que el motor de scroll es quien genera dichos procesos) y los tipos al gestor de señales (el que hace la pausa, mata los procesos al final del nivel...), y luego indicarle al proceso "game" en qué orden cargarlo y qué hacer cuando se sale del mismo.
Volviendo al libro, tengo curiosidad por ver cómo administra motores tipo Unity, que es un motor que veo muy fuertemente atado a su interfaz gráfica. A ver, se puede hacer todo programando, pero he visto que, a la larga, es más funcional programar "herramientas" que se puedan modificar visualmente, y que permita a grafistas tener más control sobre la edición de niveles... más que nada para repartir el trabajo, que ya bastante tiene el programador con el trabajo de integrar gráficos, música, animaciones y de programar todos los eventos :D
Lo que te he pasado son patrones de diseño. No son específicos a ningún motor, pero sí son los que más se usan en juegos.
Y los que te han dicho eso no tienen ni zorra de programar xD Claro que hay cosas estandard! Precisamente por eso se inventaron los patrones de diseño! Esos son los estándares. Un patrón de diseño es precisamente una manera de resolver un tipo de problema en programación. Es algo más o menos "universal", no atado a cierto lenguaje o motor sino para un tipo de problema "universal". Yo los he usado haciendo webs, haciendo apps de movil y haciendo juegos ;)
futu-block
11/03/2020, 09:48
bueno, lo que uso yo es mas o menos parecido; un proceso para controlar que botón se ha pulsado que lo que hace es regular que valor tiene determinada variable. Luego están los testigos de botones que muestran según la variable si el botón está pulsado o el selector está en tal posición, etc (si, esto no es visual basic que lo hace automáticamente, hay que programarlo) y por último un proceso por cada parte que se muestra según la variable un gráfico u otro...
En cuanto a videojuegos, pues llevo tiempo replanteando eso, varios módulos, uno para la situación de los elementos, otro para el régimen del juego donde da igual en que ronda esté siempre actuará de la misma forma, y otro para la visualización de los elementos que se limita a mostrar el primer módulo simplemente
A pesar de ello me leeré lo que ha puesto Misato porque me gusta tener una ''formación'' a que agarrarme, lo de programar por mi cuenta no termina de cuajar (y eso que ahora le estoy dando pequeñas pinceladas al pitón, lol)
Lo que te he pasado son patrones de diseño. No son específicos a ningún motor, pero sí son los que más se usan en juegos.
Y los que te han dicho eso no tienen ni zorra de programar xD Claro que hay cosas estandard! Precisamente por eso se inventaron los patrones de diseño! Esos son los estándares. Un patrón de diseño es precisamente una manera de resolver un tipo de problema en programación. Es algo más o menos "universal", no atado a cierto lenguaje o motor sino para un tipo de problema "universal". Yo los he usado haciendo webs, haciendo apps de movil y haciendo juegos ;)
¡Ah! Claro, pero tu hablas de patrones de tipo algoritmo, como singleton, búsqueda de caminos, etc. Yo me refería a patrones tipo MVC, modelo-nosequé-negocio... de cómo se organiza el código en general, si se agrupa por capas, por funcionalidad, por la parte de la secuencia :D
También es verdad que yo vengo de una época donde lo más visual que había para programar videojuegos era Visual Studio, Eclipse, y algún caso raro Vim. Hoy día, con Unity o Unreal Engine, eso es diferente.
Cuando yo hablaba con los programadores de videojuegos, les preguntaba si había alguien encargado de crear el motor, alguien con las físicas, otro con los controles, o si por el contrario había quien se dedicaba al prota, otro a los props, otro a las acciones del escenario... O sea, si se dividían el trabajo por el nivel de profundidad en el código o por la función que desempeñan directamente en el juego. O bien si se asignaban las tareas a los miembros del equipo o hacían una lista y cada uno escogía la que tenía ganas de implementar, o había una lista de prioridades y el primero que llegaba es el que la hacía... Y ahí es donde no se ponían de acuerdo.
En las empresas, normalmente tienen a alguien que sabe más de una parte que de otra (por lenguaje, por cliente, por proyecto, por complejidad...), y se le añaden tareas específicas a su lista, y cuando terminan, se le asigna el código al tester, luego el despliegue... está más organizado.
bueno, lo que uso yo es mas o menos parecido; un proceso para controlar que botón se ha pulsado que lo que hace es regular que valor tiene determinada variable. Luego están los testigos de botones que muestran según la variable si el botón está pulsado o el selector está en tal posición, etc (si, esto no es visual basic que lo hace automáticamente, hay que programarlo) y por último un proceso por cada parte que se muestra según la variable un gráfico u otro...
En cuanto a videojuegos, pues llevo tiempo replanteando eso, varios módulos, uno para la situación de los elementos, otro para el régimen del juego donde da igual en que ronda esté siempre actuará de la misma forma, y otro para la visualización de los elementos que se limita a mostrar el primer módulo simplemente
A pesar de ello me leeré lo que ha puesto Misato porque me gusta tener una ''formación'' a que agarrarme, lo de programar por mi cuenta no termina de cuajar (y eso que ahora le estoy dando pequeñas pinceladas al pitón, lol)
Hombre, Futu, un periodo de adaptación es necesario, hasta para gente que sabe.
Primero tienes que tener una base teórica. Luego tienes que tener un periodo de aprendizaje con el lenguaje, y ya después empiezas a hacer las cosas por tu cuenta.
En mi caso personal, cuando me enfrento a un lenguaje nuevo, en el caso ideal (me pasó con Java y PHP) primero me busco un curso que me enseñe las bases, para aprender la sintaxis, cómo funcionan los bucles while, for..., si es programación secuencial, orientada a objetos, si tiene algún elemento nuevo que lo distinga... y así estoy uno o dos meses. Luego me busco algún proyecto ya empezado y me pongo a trastear con él a hacer cosas sencillas hasta que entiendo la forma en la que se organiza el código y los patrones que dice Misato, propios del lenguaje, y después hago uno o dos programas sencillos antes de lanzarme al gran proyecto.
En el caso no ideal, como ha sido con C# y Xamarin en el trabajo, te lanzan de cabeza a un proyecto de demostración, te piden que le cambies los colores o la Base de Datos con la que trabaja, y vas modificando partes hasta que empiezas a añadir cosas nuevas.
Nunca te pones desde el minuto cero con un proyecto grande, y hay que dedicarle tiempo... cosa que a los programadores, en general (por lo que he visto) no nos gusta :lol: Queremos picar código desde ya, y luego pasa lo que pasa.
Por eso me gustan las Crap Compo: haces juegos sencillos, cortos, y no importa que tenga fallos, puedes experimentar y si te sale un churro, ya sabes que en el siguiente no lo vas a hacer así... y encima te desahogas de las normas y el libro de estilo de programación (aunque cuando terminas entiendes por qué se han escrito :D :D :D )
^MiSaTo^
11/03/2020, 11:34
¡Ah! Claro, pero tu hablas de patrones de tipo algoritmo, como singleton, búsqueda de caminos, etc. Yo me refería a patrones tipo MVC, modelo-nosequé-negocio... de cómo se organiza el código en general, si se agrupa por capas, por funcionalidad, por la parte de la secuencia :D
También es verdad que yo vengo de una época donde lo más visual que había para programar videojuegos era Visual Studio, Eclipse, y algún caso raro Vim. Hoy día, con Unity o Unreal Engine, eso es diferente.
Cuando yo hablaba con los programadores de videojuegos, les preguntaba si había alguien encargado de crear el motor, alguien con las físicas, otro con los controles, o si por el contrario había quien se dedicaba al prota, otro a los props, otro a las acciones del escenario... O sea, si se dividían el trabajo por el nivel de profundidad en el código o por la función que desempeñan directamente en el juego. O bien si se asignaban las tareas a los miembros del equipo o hacían una lista y cada uno escogía la que tenía ganas de implementar, o había una lista de prioridades y el primero que llegaba es el que la hacía... Y ahí es donde no se ponían de acuerdo.
En las empresas, normalmente tienen a alguien que sabe más de una parte que de otra (por lenguaje, por cliente, por proyecto, por complejidad...), y se le añaden tareas específicas a su lista, y cuando terminan, se le asigna el código al tester, luego el despliegue... está más organizado.
Hombre, Futu, un periodo de adaptación es necesario, hasta para gente que sabe.
Primero tienes que tener una base teórica. Luego tienes que tener un periodo de aprendizaje con el lenguaje, y ya después empiezas a hacer las cosas por tu cuenta.
En mi caso personal, cuando me enfrento a un lenguaje nuevo, en el caso ideal (me pasó con Java y PHP) primero me busco un curso que me enseñe las bases, para aprender la sintaxis, cómo funcionan los bucles while, for..., si es programación secuencial, orientada a objetos, si tiene algún elemento nuevo que lo distinga... y así estoy uno o dos meses. Luego me busco algún proyecto ya empezado y me pongo a trastear con él a hacer cosas sencillas hasta que entiendo la forma en la que se organiza el código y los patrones que dice Misato, propios del lenguaje, y después hago uno o dos programas sencillos antes de lanzarme al gran proyecto.
En el caso no ideal, como ha sido con C# y Xamarin en el trabajo, te lanzan de cabeza a un proyecto de demostración, te piden que le cambies los colores o la Base de Datos con la que trabaja, y vas modificando partes hasta que empiezas a añadir cosas nuevas.
Nunca te pones desde el minuto cero con un proyecto grande, y hay que dedicarle tiempo... cosa que a los programadores, en general (por lo que he visto) no nos gusta :lol: Queremos picar código desde ya, y luego pasa lo que pasa.
Por eso me gustan las Crap Compo: haces juegos sencillos, cortos, y no importa que tenga fallos, puedes experimentar y si te sale un churro, ya sabes que en el siguiente no lo vas a hacer así... y encima te desahogas de las normas y el libro de estilo de programación (aunque cuando terminas entiendes por qué se han escrito :D :D :D )
mmm.. estas mezclando cosas, como siempre drumpi xD
Mirate el libro que te he dicho y luego ya comentamos cosas. También puedes leerte cosas sobre arquitectura (que es lo de que sea MVC, ECS, etc) de software.
Y no tienes que explicarme como se trabaja en empresas de videojuegos: mi novio ha trabajado en Guerrilla Games haciendo el Killzone, yo he trabajado en otro estudio en España haciendo juegos para DS (por desgracia no tan famosos). Y ahora hago juegos yo por mi cuenta. Vamos que se un poco de qué va el tema xD
PD. usar un engine u otro no te condiciona a usar ciertos patrones o cierta arquitectura (hasta cierto punto). Todo eso es independiente de lo que uses
mmm.. estas mezclando cosas, como siempre drumpi xD
Mirate el libro que te he dicho y luego ya comentamos cosas. También puedes leerte cosas sobre arquitectura (que es lo de que sea MVC, ECS, etc) de software.
Y no tienes que explicarme como se trabaja en empresas de videojuegos: mi novio ha trabajado en Guerrilla Games haciendo el Killzone, yo he trabajado en otro estudio en España haciendo juegos para DS (por desgracia no tan famosos). Y ahora hago juegos yo por mi cuenta. Vamos que se un poco de qué va el tema xD
PD. usar un engine u otro no te condiciona a usar ciertos patrones o cierta arquitectura (hasta cierto punto). Todo eso es independiente de lo que uses
Estoy en ello :D
No, no intento decirte cómo se trabaja en la industria, sólo intento aclarar lo que he hablado con otra gente, para que quede claro si estamos hablando de lo mismo o no. A partir de ahí entramos a valorar quien tiene razón o no ;)
De todas formas, yo soy de los que prefieren experimentar, más que de leer. No me vale que me digan "esto se hace así" o "esta forma es mejor", prefiero probarlo y ver si es verdad o no. Creo que ya lo comenté alguna vez, que hace tiempo hice una especie de compilador, algo que cogía texto y lo convertía en bytecode para un intérprete que hice, sin haberme leído nada previamente de compiladores, y llegué a muchas conclusiones que leí a posteriori, pero si no, no hubiese visto necesaria la compilación en dos pasos, por ejemplo.
Y aquí es donde mucha gente me dice que lo hago mal, que lo suyo es primero leer y estudiar y luego aplicar, pero prefiero hacer así las cosas: aprendo de mis errores, tengo más flexibilidad y en ocasiones se me ocurren ideas que son mejores que las que aprendo, porque tengo una visión "out of the box". Quizás por eso tengo una forma tan "peculiar" de pensar. También tiene su lado malo: aprendo más despacio que apoyándome en la experiencia general.
Ojo, es una preferencia, no lo hago siempre así. También leo y aplico.
Respecto al postdata, estoy de acuerdo, pero no estoy seguro del todo. Mi experiencia con Unity, por ejemplo, es limitada, y cuando he trabajado con él me he limitado a crear módulos para integrarlos en los assets, nunca he trabajado a bajo nivel ni a medio nivel, porque ya te lo da hecho, y sin embargo, en BennuGD, todo, absolutamente todo (bueno, casi, que por debajo hay una capa de SDL que dibuja y pone la música por mi) me lo tengo que guisar y comer yo: motor de scroll tileado, control de colisiones, desarrollo del juego, máquinas de estados de los enemigos, qué gráfico seleccionar...
En el primer caso, sólo me he preocupado de mantener los módulos independientes los unos de otros, o de asegurarme de que se ponen juntos, o de que pueden ser reutilizables. En el segundo ya entramos que si MVC, que si módulos de control/juego/música...
Y dada la cantidad de tipos lenguajes, que aunque conozco unos cuantos, aun hay muchos que ni los he olido, así que eso de que "usar un engine u otro no te condiciona a usar ciertos patrones o cierta arquitectura" lo pondría en unas comillas sujetas con pinzas. Ya el cambio de mentalidad de C a Div es brutal, como pasar de programación "normal" a manejar hilos. O cómo acostumbrado a hacer programas que si te dan A produces B, de pronto te metes en interrupciones, o señales enviadas desde la interfaz de Visual Basic, y al día siguiente estás con una WebApi respondiendo a una petición que funciona como si fuera un programa diferente a la siguiente o la anterior petición.
Probablemente los patrones sean usables en todos los lenguajes, pero ¿es recomendable? ¿permiten usar toda la potencia del mismo? ¿O por adaptarnos a una forma de pensar que conocemos y nos recomiendan, estamos pasando por alto un esquema nuevo más eficiente para ese caso?
^MiSaTo^
11/03/2020, 15:10
Es que creo que estás mezclando conceptos. Los patrones de diseño son más o menos universales. (Digo más o menos porque quizá no todos funcionen para todos los paradigmas de programación, pero dentro del mismo da igual el lenguaje). Usarlos o no claro que permiten usar toda la potencia del lenguaje! Es que eso es independiente de la arquitectura que desarrolles. Y bueno un consejo: no trates de reinventar la rueda. Todos hemos pasado por ello pero NO compensa. Esto lo digo por la última frase que dices que si estamos pasando por alto un esquema nuevo más eficiente: seguramente no. Seguramente ninguno de los que estamos aquí pueda hacer un esquema nuevo más eficiente (sea lo que sea eso).
Y sobre la comparación de bennu/SDL con Unity... bueno son dos cosas muy distintas. Unity/Unreal son un motor completo. Mientras que Bennu no lo es y SDL son directamente unas librerías (que ni siquiera un motor).
Yo también aprendo haciendo, pero la experiencia me ha demostrado que es mejor primero leer e informarse antes de experimentar cosas. Así pierdes menos tiempo.
Creo que es bueno llegar a cosas estandarizadas, al igual que pasa con los lenguajes y con las API es importante que, ya que existen soluciones generales a ciertos problemas pues se apliquen, si hay gente que prefiere reinventar la rueda es su problema, ademas que te ahorras mucho tiempo diciendo, las clases tipo manager están implementadas como un singleton y la implementación de las operaciones sobre las entidades he usado el patron visitador.
No os voy a quitar la razón, y más cuando hoy día se tiende a usar lenguajes muy similares (C++, C#, Objetive-C...) o motores creados por terceros, es más obvio que los patrones van a ser muy útiles.
Pero el ingeniero que hay en mí siempre tiene dos palabras resonando en la cabeza y que pueden ser una pesadilla: "¿Por qué?" :D
No es que no me fíe de años de experiencia de miles de personas con más idea que yo, es por la curiosidad... y por las malas experiencias que he tenido, y sigo teniendo, con esos códigos en plan "caja negra", que una librería no hace lo que le pido y no sé por qué (bindings en C# que no generan el evento "OnPropertyChange", cobros que meto en un programa de contabilidad y que se inventa valores en campos que ni he tocado...)
También puede ser culpa de la cantidad de lenguajes que he aprend... bueno, más bien, usado de aquella manera :lol:. De la secuencia de C a los procesos de Fenix, y de pronto OOP con java (sumándole SQL y alguno más), y un salto al C# de Unity, para meterme en C# a pelo (con sus bindings, sus hilos y la madre que parió al LinQ) y VB.Net antes de tocar Xamarin o VB6. Cada dos años es un paradigma nuevo, vamos, que no me aburro :D (pero tampoco avanzo demasiado).
Me gustaría poneros un ejemplo de lo que digo de que, en ocasiones, los patrones no sirven, pero como nunca doy con el ejemplo bueno, prefiero no decir nada, pero se me ha dado el caso.
^MiSaTo^
11/03/2020, 18:31
Cuando lees buenos libros al respecto explican el por qué se hace una cosa u otra. A ver si te crees que el resto de ingenieros no tenemos en la cabeza ese por qué xD
Y te puedo dar ejemplos de por qué un patrón u otro no sirve. No todos los patrones sirven para resolver todos los problemas. Precisamente un buen arquitecto de software sabe cuándo usar uno u otro y cuándo no usarlos ;)
A ver si te crees que el resto de ingenieros no tenemos en la cabeza ese por qué xD
Viendo el código de algunos, las preguntas de otros, y el desinterés demostrado por según qué sujetos (con frases "si funciona, déjalo así, cuando haya tiempo se arregla"), y sin referirme a nadie en concreto de este foro, permíteme que lo ponga en duda :D
^MiSaTo^
12/03/2020, 07:54
Viendo el código de algunos, las preguntas de otros, y el desinterés demostrado por según qué sujetos (con frases "si funciona, déjalo así, cuando haya tiempo se arregla"), y sin referirme a nadie en concreto de este foro, permíteme que lo ponga en duda :D
Es que a lo mejor con los que has dado no son ingernieros. O bueno si consideras ingeniero a tener un papel... porque para mi esos no lo son tengan papel o no (yo por cierto no lo tengo)
Es que a lo mejor con los que has dado no son ingernieros. O bueno si consideras ingeniero a tener un papel... porque para mi esos no lo son tengan papel o no (yo por cierto no lo tengo)
¡Aaaaah! ¡Eres ^MiSaCío^ Monasterio! :quepalmo:
Tengo algunos compañeros que estudiaron carrera o ciclos superiores de informática y si te descuidas no saben encender un ordenador
^MiSaTo^
12/03/2020, 10:12
¡Aaaaah! ¡Eres ^MiSaCío^ Monasterio! :quepalmo:
Tengo algunos compañeros que estudiaron carrera o ciclos superiores de informática y si te descuidas no saben encender un ordenador
No he pillado el chiste sorry :/
En cualquier caso si, tener un papel o no no significa que seas bueno en lo que haces.
Aquí consideran a alguien ingeniero basado en las habilidades que demuestres, no en si tienes un papel o no. De todos modos en Madrid tb he trabajado en puestos así sin tener el papel, nunca en mi vida me lo han pedido en ningún sitio xD
No he pillado el chiste sorry :/
En cualquier caso si, tener un papel o no no significa que seas bueno en lo que haces.
Aquí consideran a alguien ingeniero basado en las habilidades que demuestres, no en si tienes un papel o no. De todos modos en Madrid tb he trabajado en puestos así sin tener el papel, nunca en mi vida me lo han pedido en ningún sitio xD
Una tal Rocío Monasterio, una política de VOX que al parecer se dedicó a trabajar y firmar proyectos como si fuese arquitecta sin tener el título. Años despues se lo sacó (no lo tengo claro pero vamos a suponer que sí), pero al parecer dio el visto bueno y firmo muchas cosas sin el título.
^MiSaTo^
12/03/2020, 10:38
Una tal Rocío Monasterio, una política de VOX que al parecer se dedicó a trabajar y firmar proyectos como si fuese arquitecta sin tener el título. Años despues se lo sacó (no lo tengo claro pero vamos a suponer que sí), pero al parecer dio el visto bueno y firmo muchas cosas sin el título.
vaya tela
Es que a lo mejor con los que has dado no son ingernieros. O bueno si consideras ingeniero a tener un papel... porque para mi esos no lo son tengan papel o no (yo por cierto no lo tengo)
:lol: :lol:
He conocido todo tipo de fauna entre telecos e informáticos, pues compartíamos facultad :D Desde informáticos que no saben montar una torre, telecos que te programan un robot en 15 minutos, cerebritos que te monitorizaban un marcapasos por bluetooth con un móvil de politonos, gente que obviamente se equivocó de carrera...
Porque entiendo que si te metes en teleco, puede que no te guste programar (como el 80% de los casos que conozco, y nosotros éramos de la especialidad de electrónica, que programamos sí o sí) pero ¿te metes en informática y no te gustan las matemáticas? :lol2:
No, yo distingo a los programadores por lo que escriben. He visto códigos super complejos, de los que no te lo hace un novato o "alguien con un papel", pero al mismo tiempo estar lleno de líneas temporales, ficheros que no se usan, o cosas del tipo "esto funciona, no tocar que se rompe" :D También por lo que hablo con ellos.
Aunque me he encontrado con algunos programadores muy raros, porque no entienden de videojuegos :D
Por cierto, en mi facultad, porque el nivel medio de "autismo" estaba por encima de la media, pero yo sería considerado un intruso entre los informáticos, por meterme en sus competencias :D Se supone que estoy a medio camino entre informática y electrónica.
No he pillado el chiste sorry :/
En cualquier caso si, tener un papel o no no significa que seas bueno en lo que haces.
Aquí consideran a alguien ingeniero basado en las habilidades que demuestres, no en si tienes un papel o no. De todos modos en Madrid tb he trabajado en puestos así sin tener el papel, nunca en mi vida me lo han pedido en ningún sitio xD
Mujer, claro, en España es la gente más solicitada :D: gente con las capacidades de un ingeniero que no puede cobrar como un ingeniero :D Le cogí mucho asco a Infojobs, porque "empresas líderes en el sector" siempre contrataban a gente a falta de una o dos asignaturas o el PFG para terminar la carrera/grado antes que a alguien con el título recién sacado o con menos de 5 años de experiencia demostrables.
^MiSaTo^
12/03/2020, 11:22
No se si te das cuenta de que he currado más tiempo en España que aquí en Holanda xD Y que también fui a la uni, solo que dejé la carrera porque no me gustó.
Osea se muy bien todo eso de lo que hablas XD
EDIT: de programadora tengo unos 17 años de experiencia demostrable. Llevo solo 8 aquí xD
Sólo te respondía sobre los "ingernieros" con los que he tratado :D
Tampoco me tienes que demostrar nada sobre ti ;) aunque agradezco los datos, porque en todos estos años que llevo viniendo al foro, nunca me habías dado esa información :lol: Ahora te conozco un poquito mejor :D :D :D
A todo esto ¿alguien ha probado el juego? No sé si está todo bien o si metí la pata con los ficheros en algún cambio de última hora. Yo creo que estaba todo cuando subí los ficheros.
^MiSaTo^
12/03/2020, 12:30
Pues solo decirte que por suerte hay otra gente que sí es válida y no unos gañanes como esos. Y en España! Pero por desgracia es verdad que no abundan en las cárnicas ni empresas de ese estilo (porque se frustran y se van como es normal)
Aqui un frustrado XD
¡Venga ya! Que el juego no es tan difícil :D
¿Es posible que la lista de cosas pendientes se haya multiplicado después de subir la última versión, sin haber añadido absolutamente nada a la lista?
Este fin de semana le he dedicado un ratillo, básicamente preparando los tiles interactivos del nivel 4-3. Intentaré comentarlo a lo largo del día en el hilo de desarrollo del otro foro.
saboteur
06/04/2020, 20:50
Drumpi he conseguido hacer un opk que funcione, sólo faltaba ponerle permisos de ejecución al archivo runme.gpe. Me ha vuelto loco, era tan obvio que ni siquiera lo tenía en cuenta.
Lo he metido en un repositorio de juegos que tengo para la consola, si no te importa: https://github.com/RafaVico/RG350_APPREPOSITORY si no, me dices y lo borro.
¡Oh! Por mi, genial :)
Ya me explicarás cómo se hace, para no tenerte repitiéndolo cada vez que saque una versión (aunque al ritmo que voy... :quepalmo:). Aun es una beta, y estoy trabajando en terminar el nivel 4 (muy poco a poco).
Lo ideal sería poder incluir el runtime de BennuGD actualizado, pero aun no me he puesto en serio con el desarrollo de RG350. De hecho, desde diciembre no he actualizado la consola, y no sé cómo anda la escena. De momento, me conformo con que funcione y se pueda jugar bien, que es lo importante.
Mmmm, tengo que actualizar el "log" de trabajo en el foro de BennuGD ^^U
EDIT: ¡UPS! ¿Dónde están mis modales? Muchas gracias por tomarte la molestia de hacer el paquete.
@Drumpi (https://www.gp32spain.com/foros/member.php?u=12408) he conseguido hacer un opk que funcione, sólo faltaba ponerle permisos de ejecución al archivo runme.gpe. Me ha vuelto loco, era tan obvio que ni siquiera lo tenía en cuenta.
Lo he metido en un repositorio de juegos que tengo para la consola, si no te importa: https://github.com/RafaVico/RG350_APPREPOSITORY si no, me dices y lo borro.
He visto que tienes muchas aplicaciones portadas a RG-350, ¿de donde has sacado el codigo fuente? En algunos casos es fácil de encontrar el codigo en GitHub o alguna pagina personal pero de otros juegos no he encontrado nada.
saboteur
07/04/2020, 22:12
En realidad la mayoría de los opk salen de estos otros repositorios:
https://github.com/SeongGino/RetroGame350-AppRepo
https://github.com/retrogamehandheld/OpenDingux
He creado un repositorio nuevo, añadido mis juegos y metido alguna cosa más. Sobre todo necesitaba añadir screenshots e info de cada opk para que el programa de descarga que estoy haciendo para la propia consola, a modo tienda, funcione de una manera intuitiva y coherente. Si necesitas el código fuente, la mayoría están por github como versión de gcw0 ( y alguna para rg350), sólo hay que buscarlo xD.
Yo a veces he buscado el código de alguna en especial y también me cuesta encontrarlo, pero muchas suelen ser compilaciones directas de las versiones de gcw. Se nota porque algunos botones están intercambiados, en gcw0 y rg350 tienen botones en posiciones distintas.
futu-block
08/04/2020, 11:21
perras, se me está antojando...
Venga, yo te des-antojo:
A menos que quieras emular SNES, PSX y los arcades más tochos a full speed, no creo que sea tu consola, mejor quédate con la Wiz.
A no ser que quieras desarrollar, entonces ya estás tardando, porque la potencia extra se agradece un montón :D :D :D
futu-block
13/04/2020, 10:13
nah, si tengo hasta raspberrys y no juego...
Por cierto, que ya te pasaré para que me portes juegos al bicho ese, pofavó
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.