Bennu GP2X

[DCelso]

ninguno de los seis tests?, no me lo puedo de creer, jo.

[SplinterGU]

ninguno de los seis tests?, no me lo puedo de creer, jo.

DCelso, porque no pones el script que usaron para probar lo del LD_LIBRARY_PATH, esa version que usaron copiando las .so que hacia falta?

puede que sea un error en las pruebas y no en los binarios.

ya ha pasado que hay dicho que algo no funcionaba y tenian mal los scripts, son cosas que suelen pasar, y a veces un 3er ojo ayuda a detectar esos fallos.

[FreeYourMind]

De los ultimos 3, sólo probé el ultimo (lite).

[Drumpi]

Mañana pruebo estos tres últimos. Por espacio no hay problema, estoy probando en la SD que acabo de liberar de sus anteriores necesidades, por lo que son 2GB de espacio :P

Respecto al script de prueba, es este:

Code Select Expand

#!/bin/sh
LD_LIBRARY_PATH_BAK=$LD_LIBRARY_PATH
PATH_BAK=$PATH

LD_LIBRARY_PATH=../bgd-runtime:$LD_LIBRARY_PATH
PATH=../bgd-runtime:$PATH

echo 2 > /proc/cpu/alignment

for prg in *.prg; do
    name=`basename $prg .prg`
    bgdc $prg 1> bgdc_stdout.txt 2>bgdc_stderr.txt
    bgdi $name 1> bgdi_stdout.txt 2>bgdi_stderr.txt
done

sync

LD_LIBRARY_PATH=$LD_LIBRARY_PATH_BAK
PATH=$PATH_BAK

cd /usr/gp2x
exec /usr/gp2x/gp2xmenu

No lo he sacado de la SD, pero juraría que es exactamente el mismo.

Por cierto, yo no me fijo mucho de los tiempos de carga, a mi siempre me tarda como unos 2 o 3 segundos en ejecutar cualquier cosa, falle o funcione.

[SplinterGU]

ese script, si tenes las dependencias del runtime en la carpeta ../bgd-runtime deberia funcionar, chequealo en la SD...

[Drumpi]

En la raiz de la SD tengo la carpeta bgd-runtime con los ejecutables y las librerías de Bennu que me pasa DCelso (o XCelso, por lo bien que trabaja ;D) y otra con este gpe y los demás ficheros del ejemplo que intento ejecutar.
Vamos, como con el resto de juegos, incluido los míos (de vez en cuando pruebo con ellos, pero con idéntico resultado).

No, no he probado nada aun, estoy con una tos que no me deja dormir.

[SplinterGU]

En la raiz de la SD tengo la carpeta bgd-runtime con los ejecutables y las librerías de Bennu que me pasa DCelso (o XCelso, por lo bien que trabaja ;D) y otra con este gpe y los demás ficheros del ejemplo que intento ejecutar.
Vamos, como con el resto de juegos, incluido los míos (de vez en cuando pruebo con ellos, pero con idéntico resultado).

No, no he probado nada aun, estoy con una tos que no me deja dormir.

a que nivel estan las carpetas?

deberia ser...

...
|-> [bgd-runtime]
|-> [sample]
            |-> sample.gpe


los que estan entre [] son folders, lo demas archivos.

imagino que lo tenes asi, pero nunca esta demas aclarar.

[Drumpi]

Sí, lo tengo como dices, Splinter. Lo he revisado varias veces para asegurarme.

Bien tengo noticias buenas a medias: parece que BGDI funciona, pero BGDC es un desastre. Bueno, iré diciendo una a una las pruebas que he hecho:

Empecé con los tres últimos ficheros subidos en el mismo orden, usando el test antiguo:
-el GP2Xtest4 (mensaje 84) seguía dando los problemas de los últimos.
-el monoholithictest5 (mensaje 85) dejó de dar errores por el BGDC, pero no generó ningún DCB.
-el GP2Xlitetest6 (mensaje 87) volvió a dar errores:
bgdcerror: : error while loading shared libraries: cannot create search path array: Cannot allocate memory

Bueno, como decías que había que probar con el nuevo test de esta última versión (que por cierto, el .GPE está mal escrito, en BGD?_lite, no BGD?-lite, y el programa no se puede salir) lo hice. El BGDC seguía dando error... pero el juego FUNCIONABA perfectamente, daba los botones pulsados (que por cierto, si no me falla la memoria tiene los mismos números que en WIZ y que se han usado siempre) y en bgdi_error.txt obtuve:

Code Select Expand

SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physical screen = 320x240 (ilace = 0)
SDL_GP2X: Looking for a mouse
SDL_GP2X: No mice found
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x22ad60 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=0
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: InitHWSurfaces 0x4002d800, 5085184
SDL_GP2X: Screen bucket 0x22a2e4
SDL_GP2X: First free bucket 0x22ad60 (size = 5085184)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x22ad78 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5084928 bytes @ 0x22ad90
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x4002d800
SDL_SYS_JoystickInit

Don't panic, es la salida normal de SDL.

Ilusionado, probé el Echo tal cual y:

Code Select Expand

sh-3.2# cat log2.txt
Unsupported module: mod_debug.so
Esto se lo achaco a un DCB demasiado antiguo.

Total, que me dije de probar el DCB del test nuevo con los anteriores BGDI, y sí, funciona igual de bien en todos los mencionados anteriormente. Así que quise comprobar hacia atrás hasta donde funcionaba:

monoholithicv3 (mensaje 79, creo): Funciona.
devkit_test5 (¿mensaje 64? tambien es monolítica, sin .so): Funciona.
devkit_test4 (última versión basado en librerías .so): mal, da el siguiente error

Code Select Expand

sh-3.2# cat bgdi_std*
bgdi: error while loading shared libraries: libbgdrtm.so: cannot open shared obj
ect file: No such file or directory

En fin, que las versiones monolíticas funcionan bien mientras que las que usan .so fallan. Ya pasaba algo así con las librerías de Fenix, creo recordar, hay algo raro en eso.

Pues eso, que hay que probar aun el BGDI más a fondo con DCBs más modernos, y corregir el BGDC para que compile... aunque no pasaría nada malo si sólo tenemos el BGDI (incluso sería recomendable, puesto que ahora no hay librerías que actualizar a mano, y son 6MB ocupados menos del BGDC).

NOTA: ¡¡¡la última versión del BGDI también funciona en el firm OPEN2X!!!
NOTA 2: karma para DCelso, aunque creo que a partir de ahora lo llamaré XCelso (/excelso/) ;D

[DCelso]

Olee, menos mal, algo que va :D.

Ilusionado, probé el Echo tal cual y:
Código:

sh-3.2# cat log2.txt
Unsupported module: mod_debug.so

Esto se lo achaco a un DCB demasiado antiguo.

Esto no lo achaques a un dcb demasiado antiguo, lo escribí yo (no es del código de bennu original).

Seguro que estabas usando la versión lite, en ella no está mod_debug ni muchísimas otras, ademas he visto que los módulos son las cosas que menos ocupan, una versión lite con un solo módulo y una versión completa con todos los módulos se diferencian en poquito no llega ni a unos megas, lo que verdaderamente ocupa espacio en las versiones monoliticas son las librerias de gcc y las librerias sdl y sdl mixer.

Intenta probar la penúlitima versión que subí (que es justo la anterior a la versión lite)  con tu dcb de echo.

[Drumpi]

Creo que lo probé, pero no recuerdo el resultado, sé que fallaba pero no recuerdo por qué. Te lo miro mañana.

[DCelso]

Drumpi, llegaste a probar tu drumpi con estas versiones?

monolithicTest5.tar.gz: http://www.mediafire.com/?t566l2536eeq6zw
De esta me interesaría saber si va el bgdc (es la version que depende de un libc.so) y el log de stdout y stderr



GP2Xtest4.zip: http://www.mediafire.com/?nlbjuz7u4z8jp54
De esta me interesaría saber si va el dcb  de drumpi con el bgdi adjunto. (es la versión completa de bennu para devkitgp2x usando el método estático de librerías.)

[josebita]

SplinterGU, la mia es mas fiel a tu código, no hay que tocar todos los módulos como en la de josebas, solo el bgdc, y respeta la forma interna de tratar la búsqueda de módulos existente y carga de éstos, simplemente meti unos cuantos ifdef __STATIC__ no conflictivos para crear la versión dináimica o monolíticica ( metí dos nuevos archivos .h y .c para simular la librería libdl en modo estático).
Estoy terminando el tuto, pero te puedo pegar ya una preview, por si te apetece verla.

Le echaré un ojo, si es como dices, será más fácil de mantener que la mía y adaptaré tu código para la Wii y iOS. De todas formas, el método es basicamente el mismo. Yo tuve problemas con los prototipos de las declaraciones de los módulos y por eso tuve que tocarlos. Si tú has conseguido arreglar eso, te copiaré con descaro :P

[Drumpi]

Uf, no, lo siento, XCelso, se me pasó. Intentaré hacerlo a la mayor brevedad posible, pero se que fallaban, al menos el BGDC.
El BGDI me soltaba lo de DCB incompatible, supongo que por los últmos cambios que hizo Splinter en la r200. Tendría que compilarlo con la r201 de windows y pasarlo a la negrita para comprobarlo.

De todas formas, ya digo, lo que tengo es un firm 2.1.1 emulado, el real daba más problemas... y el de Futu más aun ;D

[DCelso]

SplinterGU, la mia es mas fiel a tu código, no hay que tocar todos los módulos como en la de josebas, solo el bgdc, y respeta la forma interna de tratar la búsqueda de módulos existente y carga de éstos, simplemente meti unos cuantos ifdef __STATIC__ no conflictivos para crear la versión dináimica o monolíticica ( metí dos nuevos archivos .h y .c para simular la librería libdl en modo estático).
Estoy terminando el tuto, pero te puedo pegar ya una preview, por si te apetece verla.

Le echaré un ojo, si es como dices, será más fácil de mantener que la mía y adaptaré tu código para la Wii y iOS. De todas formas, el método es basicamente el mismo. Yo tuve problemas con los prototipos de las declaraciones de los módulos y por eso tuve que tocarlos. Si tú has conseguido arreglar eso, te copiaré con descaro :P

:D, cagoen, quería contactar contigo por privado para proponerte eso mismo, que adaptaras tu monolítico de wii a mi forma de hacerlo, porque es mas cómoda. Pero tonto de mí estaba intentando hacer mi versión de wii antes para verificar que funcionaba en wii antes de decirte nada :D.
Pero veo que compilar para wii con sdl no es tan fácil como yo creía,(así que te lo dejo a ti que estás mas docto :D) si quieres te comento básicamente los cambios que hay que hacer al código de splinter para hacer versiones monolíticas, ahora mismo puedes ver el contenido del .patch y ver los cambios, o bien bajarte con svn el código de splinter, aplicarle el patch y hacer un sincronize contra svn o un svn diff.
En resumidas cuentas, se usa el module_def.c en el que he hecho lo siguiente:
he creado un struct en el que guardo los punteros a funciones, a constantes y a variables de un módulo y su nombre del modulo.
he creado un array de 44 structs de ese tipo
relleno el array de structs con los datos de los módulos a usar.
Y finalmente sustituyo el dl_open (de los códigos fuentes de bgdrtm y bgdc) con un find_module (nombre_modulo) y extraigo la información que necesita bgdrtm (o bgdc) de la estructura correspondiente al módulo seleccionado.

[DCelso]

por cierto, también tengo una modificación que no he subido para añadir game.prg y game.dcb como parámetro por defecto.