- Welcome to Bennu Game Development.
Recent posts
#1
General / Re: BennuGD as libretro core
Last post by panreyes - March 08, 2025, 07:30:17 PMSounds amazing, thanks for testing! Would you mind sharing it?
#2
General / Re: BennuGD as libretro core
Last post by diekleinekuh - March 07, 2025, 03:07:31 PMAs far as I could see PiX Pang runs fine.
#3
General / Re: BennuGD as libretro core
Last post by panreyes - February 22, 2025, 06:09:18 PMGood work!
I suppose that Streets of Rage Remake is now available on RetroArch too :)
Feel free to port PiX Pang too if you will! That game doesn't have any licensing issues... yet
I suppose that Streets of Rage Remake is now available on RetroArch too :)
Feel free to port PiX Pang too if you will! That game doesn't have any licensing issues... yet
#4
General / BennuGD as libretro core
Last post by diekleinekuh - February 21, 2025, 08:54:45 PMHello,
I ported BennuGD to run as a libretro core.
https://github.com/diekleinekuh/BennuGD_libretro
One of the changes I made was adding support for native 64 bit builds. This is required as nowadays most systems run 64 bit retroarch, even Raspberry PIs. It is also still possible to build bgdi as standalone app.
I only ported the modules that came with BennuGD so far. More can be added later if somebody is interested.
Maybe somebody finds this useful to make the games made with BennuGD playable on all those retro gaming devices.
Best Regards
Markus
I ported BennuGD to run as a libretro core.
https://github.com/diekleinekuh/BennuGD_libretro
One of the changes I made was adding support for native 64 bit builds. This is required as nowadays most systems run 64 bit retroarch, even Raspberry PIs. It is also still possible to build bgdi as standalone app.
I only ported the modules that came with BennuGD so far. More can be added later if somebody is interested.
Maybe somebody finds this useful to make the games made with BennuGD playable on all those retro gaming devices.
Best Regards
Markus
#5
Mesa de Ayuda / Re: sobre el Rollback Netcode ...
Last post by Drumpi - February 18, 2025, 11:21:50 AMMe consta que alguno ha hecho algún juego en red, pero no es mi caso, por lo que poca ayuda te puedo dar.
No sé lo que es el Rollback netcode, ni si es compatible con BennuGD. Al menos, no he oído nada de que exista ninguna librería de ese estilo, o que alguien haya hecho algo. Si hay algo, puede que ColombianDevelopers sepa algo, ya que son los que más liberías de Bennu ha recopilado y compilado.
No sé lo que es el Rollback netcode, ni si es compatible con BennuGD. Al menos, no he oído nada de que exista ninguna librería de ese estilo, o que alguien haya hecho algo. Si hay algo, puede que ColombianDevelopers sepa algo, ya que son los que más liberías de Bennu ha recopilado y compilado.
#6
Mesa de Ayuda / sobre el Rollback Netcode y on...
Last post by Kalas - February 01, 2025, 06:47:39 AMHola espero les vaya bien a todos este inicio de año 2025 , quería preguntar algo casi random si alguien ya ha podido usar el famoso Rollback netcode alguna vez, que es para evitar el lag en partidas, más que todo en juegos de peleas como killer instinct, guilty gear etc..he visto que hay un platform fighter basado en smash bros en gamemaker que lo utiliza, no tengo idea de como lo implementaron, pero también he visto un par de juegos indie que utilizaron la lógica del rollback para aplicarlo en su juego sin necesidad de este y no les quedó mal, talvez alguien se ha animado hacer algún juego online por acá? o si podrian compartirme algún tutorial?
#7
XBOX (homebrew) / Matterrun Xbox Port
Last post by FusekiGames - December 28, 2024, 03:32:10 AMI've ported my Dreamcast game Matterrun to the original Xbox. Grab it at http://atari.vg-network.com/fuseki
#8
XBOX (homebrew) / Re: porting to XBox
Last post by FusekiGames - December 28, 2024, 02:55:24 AMSome gamepad info for those wishing to port Bennu games to the Xbox (currently porting Matterrun). I wrote a short program that told me what each button corresponded to:
Use joy_getbutton to map your controls.
0,0- A button
0,1- B button
0,2- X button
0,3- Y button
0,4- Black button
0,5- White button
0,6- L Trigger
0,7- R Trigger
0,8- Start
0,9- Back
I'll assume 1,0.. 1,1.. etc. correspond to the second controller.
There might be more, but I only mapped out those nine buttons. If you have a way to quit your program using ESC, the right stick hat will exit the program and boot back to your Xbox launcher.
Use joy_getbutton to map your controls.
0,0- A button
0,1- B button
0,2- X button
0,3- Y button
0,4- Black button
0,5- White button
0,6- L Trigger
0,7- R Trigger
0,8- Start
0,9- Back
I'll assume 1,0.. 1,1.. etc. correspond to the second controller.
There might be more, but I only mapped out those nine buttons. If you have a way to quit your program using ESC, the right stick hat will exit the program and boot back to your Xbox launcher.
#9
Proyectos / Re: Echo v1.4: road to season ...
Last post by Drumpi - October 07, 2024, 10:13:41 AMBuenas de nuevo, traigo noticias (sin exclamaciones, esto no es para tirar cohetes :D)
No sé si lo sabéis, pero durante el verano se ha organizado un concurso de minijuegos para la GP32, y cómo no, cuando queda poco tiempo para la entrega, es cuando me entran ganas de ponerme con algún otro proyecto distinto al que tengo que hacer :D
Al final no he podido terminar el minijuego (apenas tengo hecho el motor), pero han ampliado el plazo para participar hasta el 31 de diciembre, por lo que si alguien quiere desempolvar el Fénix 084, aún está a tiempo. Aprovechando la ampliación de plazo, quería terminar el vídeo que estoy haciendo del Dani Chase, que le quedan los créditos y pulir detalles, así que este fin de semana me he puesto... con el Echo ^^U
Bueno, el sábado no fue el único día que estuve con el Echo, ya la semana pasada le metí mano a un par de cosillas, y lo cierto es que traigo muy buenas noticias para los que aún lo jueguen en la Wiz. Aviso que los siguientes tres párrafos son cambios internos al motor y pueden ser muy aburridos para los que busquen cosas relacionadas con el juego, y no de la programación en sí.
Estuve revisando varias cosas del motor de scroll tileado por mi cuenta (no recordaba que tenía el código que me mandó Splinter), para ver si podía optimizar la función que actualiza el scroll cuando hay cambio de tile, ya que esta provocaba que hubiera tirones en el desplazamiento en la consola portátil.
Pues bien, el primer cambio que hice fue mover el bucle que recorre los datos del mapa de tile por capas al interior de los bucles de filas y columnas. Como este bucle no realiza ninguna instrucción propia (salvo incrementar el contador Z), al meterlo dentro de los otros dos, ahorramos que estas se repitan por cada capa que haya en el scroll, lo cual ya es un ahorro importante de cara a los mapas multicapa.
Pero claro, la última versión lanzada no usaba (aún) los mapas multicapa. Así que estuve revisando y, otro cambio que hice fue omitir la llamada a la función "obtener_tile" del motor de scroll tileado, que se ejecuta dentro del triple bucle que mencioné antes, y en su lugar copié directamente el código de la función. Estilísticamente no se debe hacer, porque se repite código, y a la hora de hacer mantenimiento, si se cambia código en un lado, hay que repetir los cambios en el otro...
Pero vaya cambio. El scroll ya no pega tirones, va suave independientemente que se esté desplazando dentro de un tile o se esté cambiando. No he implementado un cambio que me sugirió Splinter, de cambiar la lista enlazada de nodos Tile (o más bien que cada proceso tile enlace con el siguiente) por un array de memoria con REALLOC y procesos tile durmiendo, porque son cambios mayores que requieren darle una vuelta con más tranquilidad, y quizás generar una versión nueva del scroll... Aparte, que no sé qué impacto tendría en la Wiz, tener procesos dormidos sin usar, por un lado, de cara a buscar procesos tile, o algún tipo de envío de señales a estos procesos... y por otro, el tener más procesos en memoria de los que estoy usando.
También hay que tener en cuenta el impacto de REALLOC, porque si lo uso para hacer incrementos de unos pocos tiles (10, por ejemplo), y en el primer frame lo tengo que ejecutar 15 veces para tener disponibles 150 tiles, eso puede provocar un tirón. Es un ejemplo muy extremo que dudo que se de durante el juego, porque lo normal es mantener una cantidad media de tiles todo el rato, lo máximo que se va a añadir es una fila o una columna de tiles por capa (un mínimo de 15 y un máximo de 40, dado que es raro que el scroll se desplace más de un tile por frame), y nunca se eliminarían nodos ni procesos tile (quedarían dormidos).
El caso es que, viendo el cambio que se ha producido al cambiar las llamadas a una función por escribir el código directamente, hay otra función que es llamada decenas de veces por frame, y sólo contiene dos líneas: la que convierte coordenadas del scroll tileado en coordenadas de pantalla. Son sólo dos líneas, que contienen una multiplicación y una suma cada una de ellas, y son invocadas por todos los procesos dentro del scroll, una vez por frame. Si el simple hecho de quitar la función de obtener tile ha dado tan buenos resultados, creo que el omitir esta otra en las decenas de procesos enemigos que hay en pantalla puede mejorar muchísimo el rendimiento, pero odio la idea de no usar una función, dado que son ya más de 30 procesos diferentes los que la llaman, y cualquier modificación implicaría una pesadilla a la hora de mantener. Así que tengo dos opciones: o usar "include" en los procesos enemigos para añadir las dos líneas desde un fichero de código aparte, lo cual es feo de narices, o usar algo que creo recordar que se implementó en BennuGD en sus últimas versiones: una suerte de funciones pre-declaradas o algo así, no recuerdo cómo iba, a ver si SplinterGU me puede refrescar la memoria.
Pero bueno, dejemos las cosas aburridas a un lado, porque aquí habéis venido a saber qué cambios se le han hecho al juego.
Bien, pues resulta que, no sé si lo dije, el boss del nuevo nivel 4 debe ser derrotado con un arma que sólo podremos utilizar durante su combate, al estilo del cañón de Phazon de Metroid Prime. El sábado estuve realizando ya la implementación del arma en el código. Inicialmente iba a hacer un reemplazo del proceso "arma" por el de la nueva, pero ya había empezado el código para añadirlo al final de la lista de armas normales, y de no hacerlo así, sería un enorme problema de cara a la interfaz de usuario, pues depende del proceso "arma" y de los distintos arrays de datos globales que maneja (arrays de gráficos, arrays de animaciones, arrays de niveles de experiencia...).
En fin, que me he puesto con el proceso de coger el arma, y de su recarga, que debe hacerse en un punto concreto de la habitación del boss, y más o menos funciona. Aún me queda por añadir algunos gráficos de obtener el arma (que a ver cómo lo hago, si estos los generaba desde DIV2, y tengo la imagen del W98 en la máquina virtual corrupta), de la recarga del arma, y del arma en sí, pero otra tarde de trabajo como esa y la tendré lista.
Hablando de interfaz, estuve repasándola y aproveché para arreglar unos bugs y corregir algunas cosillas. Por lo visto, el código no permitía subir más de un nivel de experiencia el arma, y eso estaba provocando que las nuevas armas, al coger items de los gordos, hiciera estragos en la barra superior, y en algunos casos, hasta crashear el juego. Ya está corregido, pero debo optimizar el código un poco más, que se ve feo.
Y por esto, amigos míos, aunque en programación os digan "esa situación nunca se va a dar", no hagáis caso y haced las cosas bien, porque os va a ahorrar muchos quebraderos de cabeza en el futuro.
¡Ah! Dos apuntes más: he encontrado un error que hace que al cambiar la configuración de los controles, los botones arma sig. y anterior se guarden intercambiados. Creía que era cosa de la RG350, pero ya he visto el problema y lo he solucionado (un cambio en el orden de la declaración de unas constantes). También he cambiado los controles por defecto: Z y X ya no son salto y disparo, sino X y C. De no hacerlo así, la diagonal arriba-izquierda mientras saltamos con el botón de disparo pulsado, sería imposible, y es necesario para las dos nuevas armas que estoy desarrollando. Esto no afecta a Wiz, pero sí a los usuarios de PC con un teclado "normal".
Al final, no han sido más de 6h de trabajo en los últimos dos fines de semana, pero ha cundido. No sé lo que habré estado haciendo en los últimos años, pero puedo ver fallos en el código del Echo que antes no sabía ni que existían, y puedo verlos con muchísima claridad, así como sus posibles soluciones. No van a hacer que el juego mejore de cara al usuario, pero me permitirá optimizar algunas cosillas, aclarar un poco más el código, y facilitar el mantenimiento.
Debo terminar el vídeo en el próximo fin de semana, pero quién sabe, lo mismo termino el arma que estoy haciendo.
No sé si lo sabéis, pero durante el verano se ha organizado un concurso de minijuegos para la GP32, y cómo no, cuando queda poco tiempo para la entrega, es cuando me entran ganas de ponerme con algún otro proyecto distinto al que tengo que hacer :D
Al final no he podido terminar el minijuego (apenas tengo hecho el motor), pero han ampliado el plazo para participar hasta el 31 de diciembre, por lo que si alguien quiere desempolvar el Fénix 084, aún está a tiempo. Aprovechando la ampliación de plazo, quería terminar el vídeo que estoy haciendo del Dani Chase, que le quedan los créditos y pulir detalles, así que este fin de semana me he puesto... con el Echo ^^U
Bueno, el sábado no fue el único día que estuve con el Echo, ya la semana pasada le metí mano a un par de cosillas, y lo cierto es que traigo muy buenas noticias para los que aún lo jueguen en la Wiz. Aviso que los siguientes tres párrafos son cambios internos al motor y pueden ser muy aburridos para los que busquen cosas relacionadas con el juego, y no de la programación en sí.
Estuve revisando varias cosas del motor de scroll tileado por mi cuenta (no recordaba que tenía el código que me mandó Splinter), para ver si podía optimizar la función que actualiza el scroll cuando hay cambio de tile, ya que esta provocaba que hubiera tirones en el desplazamiento en la consola portátil.
Pues bien, el primer cambio que hice fue mover el bucle que recorre los datos del mapa de tile por capas al interior de los bucles de filas y columnas. Como este bucle no realiza ninguna instrucción propia (salvo incrementar el contador Z), al meterlo dentro de los otros dos, ahorramos que estas se repitan por cada capa que haya en el scroll, lo cual ya es un ahorro importante de cara a los mapas multicapa.
Pero claro, la última versión lanzada no usaba (aún) los mapas multicapa. Así que estuve revisando y, otro cambio que hice fue omitir la llamada a la función "obtener_tile" del motor de scroll tileado, que se ejecuta dentro del triple bucle que mencioné antes, y en su lugar copié directamente el código de la función. Estilísticamente no se debe hacer, porque se repite código, y a la hora de hacer mantenimiento, si se cambia código en un lado, hay que repetir los cambios en el otro...
Pero vaya cambio. El scroll ya no pega tirones, va suave independientemente que se esté desplazando dentro de un tile o se esté cambiando. No he implementado un cambio que me sugirió Splinter, de cambiar la lista enlazada de nodos Tile (o más bien que cada proceso tile enlace con el siguiente) por un array de memoria con REALLOC y procesos tile durmiendo, porque son cambios mayores que requieren darle una vuelta con más tranquilidad, y quizás generar una versión nueva del scroll... Aparte, que no sé qué impacto tendría en la Wiz, tener procesos dormidos sin usar, por un lado, de cara a buscar procesos tile, o algún tipo de envío de señales a estos procesos... y por otro, el tener más procesos en memoria de los que estoy usando.
También hay que tener en cuenta el impacto de REALLOC, porque si lo uso para hacer incrementos de unos pocos tiles (10, por ejemplo), y en el primer frame lo tengo que ejecutar 15 veces para tener disponibles 150 tiles, eso puede provocar un tirón. Es un ejemplo muy extremo que dudo que se de durante el juego, porque lo normal es mantener una cantidad media de tiles todo el rato, lo máximo que se va a añadir es una fila o una columna de tiles por capa (un mínimo de 15 y un máximo de 40, dado que es raro que el scroll se desplace más de un tile por frame), y nunca se eliminarían nodos ni procesos tile (quedarían dormidos).
El caso es que, viendo el cambio que se ha producido al cambiar las llamadas a una función por escribir el código directamente, hay otra función que es llamada decenas de veces por frame, y sólo contiene dos líneas: la que convierte coordenadas del scroll tileado en coordenadas de pantalla. Son sólo dos líneas, que contienen una multiplicación y una suma cada una de ellas, y son invocadas por todos los procesos dentro del scroll, una vez por frame. Si el simple hecho de quitar la función de obtener tile ha dado tan buenos resultados, creo que el omitir esta otra en las decenas de procesos enemigos que hay en pantalla puede mejorar muchísimo el rendimiento, pero odio la idea de no usar una función, dado que son ya más de 30 procesos diferentes los que la llaman, y cualquier modificación implicaría una pesadilla a la hora de mantener. Así que tengo dos opciones: o usar "include" en los procesos enemigos para añadir las dos líneas desde un fichero de código aparte, lo cual es feo de narices, o usar algo que creo recordar que se implementó en BennuGD en sus últimas versiones: una suerte de funciones pre-declaradas o algo así, no recuerdo cómo iba, a ver si SplinterGU me puede refrescar la memoria.
Pero bueno, dejemos las cosas aburridas a un lado, porque aquí habéis venido a saber qué cambios se le han hecho al juego.
Bien, pues resulta que, no sé si lo dije, el boss del nuevo nivel 4 debe ser derrotado con un arma que sólo podremos utilizar durante su combate, al estilo del cañón de Phazon de Metroid Prime. El sábado estuve realizando ya la implementación del arma en el código. Inicialmente iba a hacer un reemplazo del proceso "arma" por el de la nueva, pero ya había empezado el código para añadirlo al final de la lista de armas normales, y de no hacerlo así, sería un enorme problema de cara a la interfaz de usuario, pues depende del proceso "arma" y de los distintos arrays de datos globales que maneja (arrays de gráficos, arrays de animaciones, arrays de niveles de experiencia...).
En fin, que me he puesto con el proceso de coger el arma, y de su recarga, que debe hacerse en un punto concreto de la habitación del boss, y más o menos funciona. Aún me queda por añadir algunos gráficos de obtener el arma (que a ver cómo lo hago, si estos los generaba desde DIV2, y tengo la imagen del W98 en la máquina virtual corrupta), de la recarga del arma, y del arma en sí, pero otra tarde de trabajo como esa y la tendré lista.
Hablando de interfaz, estuve repasándola y aproveché para arreglar unos bugs y corregir algunas cosillas. Por lo visto, el código no permitía subir más de un nivel de experiencia el arma, y eso estaba provocando que las nuevas armas, al coger items de los gordos, hiciera estragos en la barra superior, y en algunos casos, hasta crashear el juego. Ya está corregido, pero debo optimizar el código un poco más, que se ve feo.
Y por esto, amigos míos, aunque en programación os digan "esa situación nunca se va a dar", no hagáis caso y haced las cosas bien, porque os va a ahorrar muchos quebraderos de cabeza en el futuro.
¡Ah! Dos apuntes más: he encontrado un error que hace que al cambiar la configuración de los controles, los botones arma sig. y anterior se guarden intercambiados. Creía que era cosa de la RG350, pero ya he visto el problema y lo he solucionado (un cambio en el orden de la declaración de unas constantes). También he cambiado los controles por defecto: Z y X ya no son salto y disparo, sino X y C. De no hacerlo así, la diagonal arriba-izquierda mientras saltamos con el botón de disparo pulsado, sería imposible, y es necesario para las dos nuevas armas que estoy desarrollando. Esto no afecta a Wiz, pero sí a los usuarios de PC con un teclado "normal".
Al final, no han sido más de 6h de trabajo en los últimos dos fines de semana, pero ha cundido. No sé lo que habré estado haciendo en los últimos años, pero puedo ver fallos en el código del Echo que antes no sabía ni que existían, y puedo verlos con muchísima claridad, así como sus posibles soluciones. No van a hacer que el juego mejore de cara al usuario, pero me permitirá optimizar algunas cosillas, aclarar un poco más el código, y facilitar el mantenimiento.
Debo terminar el vídeo en el próximo fin de semana, pero quién sabe, lo mismo termino el arma que estoy haciendo.
#10
Playstation 2 (homebrew) / Re: Bennugd - Playstation 2 Po...
Last post by Drumpi - October 02, 2024, 04:16:01 PMSiento no ser de mucha ayuda pero ¿no viene un fichero de texto que lo explica, o algún mensaje en este hilo o subforo?
Yo es que no uso este port.
EDIT: Búsqueda rápida, en el tercer mensaje te indica dónde está el "tutorial" con el paso a paso:
https://forum.bennugd.org/index.php/topic,3810.0.html
Yo es que no uso este port.
EDIT: Búsqueda rápida, en el tercer mensaje te indica dónde está el "tutorial" con el paso a paso:
https://forum.bennugd.org/index.php/topic,3810.0.html