- Welcome to Bennu Game Development.
Recent posts
#1
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
#2
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.
#3
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.
#4
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
#5
Sugerencias / Re: Bugs que van apareciendo a...
Last post by Futu-block - September 29, 2024, 11:00:30 AMBuena pregunta, lo investigo y te cuento
#6
Sugerencias / Re: Bugs que van apareciendo a...
Last post by FreeYourMind - September 25, 2024, 04:24:33 AMy donde defines la posicion de la rana en el codigo ?
#7
Sugerencias / Bugs que van apareciendo al ca...
Last post by Futu-block - September 23, 2024, 08:50:09 AMHola gente, sigo malviviendo por algunos lares y, ya que estoy recopilando mis juegos en una página wel me estoy encontrando con algunas cositas que me están pasando con respecto al bennu antiguo, que es el que estoy usando, pues no es el 2, el nuevo...
Aquí iré recopilando lo que me va pasando sobre la marcha y de paso me paso por aquí a echar unas charlas.
Pd: estoy en (sigh) windros 10...
You cannot view this attachment.
al cambiar de 16 a 32 en el set_mode me desconfigura la posición de inicio de la rana
You cannot view this attachment.
lo que me repercute que no pueda salir del nivel.
No es un problema que me traiga loco, pues lo que estoy haciendo es exportar el juego sin modificar prácticamente nada, pero es algo que quería comentar por aquí.
Aquí iré recopilando lo que me va pasando sobre la marcha y de paso me paso por aquí a echar unas charlas.
Pd: estoy en (sigh) windros 10...
You cannot view this attachment.
al cambiar de 16 a 32 en el set_mode me desconfigura la posición de inicio de la rana
You cannot view this attachment.
lo que me repercute que no pueda salir del nivel.
No es un problema que me traiga loco, pues lo que estoy haciendo es exportar el juego sin modificar prácticamente nada, pero es algo que quería comentar por aquí.
#8
Playstation 2 (homebrew) / Re: Bennugd - Playstation 2 Po...
Last post by Gabysantof - August 23, 2024, 10:26:59 PMHay algun paso a paso para poder compilar mi juego y crear la iso para ps2?
Estoy viendo los ejemplos pero no termino de entender que tengo que editar y que archivos copiar al generar la iso.
gracias!
Estoy viendo los ejemplos pero no termino de entender que tengo que editar y que archivos copiar al generar la iso.
gracias!
#9
Mesa de Ayuda / Re: Preguntas sobre una novela...
Last post by Kalas - July 30, 2024, 10:06:29 PMMil gracias Drumpi!! wow de hace 15 años!, pero se ve cool, ya lo ando estudiando aunquesea los avances que anotabas, muy amable de tu parte! espero lo encuentrés aún los archivos, estoy atento, si no pues gracias de igual forma, ya me has ayudado mucho con decirme que tengo que aprender
#10
Offtopic / Re: [Consola paperactiva] Game...
Last post by SplinterGU - July 25, 2024, 01:18:36 AMmuy bien!!!