Pero ya es la buena ? Oficial, que no va brickar mis gp2x ?
Yo conozco un port de un tarado llamado Drumpi que hizo un port a GP2X, pero no a GP32, que no son lo mismo ;D
Respecto si enladrilla o no las negritas, yo llevo con él desde hace 2 ó 3 meses y he portado FenixLand, el motor de tiles v3, alguna cosilla más y ahora el Doggy!!! y de momento sigue funcionando.
El ladrillo de animanegra sucedió porque tenía el firm oficial y le pasé las librerías que eran incompatibles, y él las copió a la NAND, sobreescribiendo las ya existentes y se cargó el sistema (se suponía que en la misma carpeta del runtime deberían haber funcionado pero no era así).
O sea, que si tienes el firm open2x, no debe haber peligro ninguno, mientras no escribas en la NAND.
Y con los otros firmware funciona ? Lo puedo probar sin miedo ?
Puedes probar sin miedo (teóricamente), porque no escribe en la NAND (a menos que tu lo hagas), pero te digo desde ya que me sorprendería MUCHIIIIIIIIIIIIIIIIIIIIIIIIIIISIMO que te funcionase.
Como mucho, debería pasarte lo mismo que si haces un programa en Bennu con un bug gordo: se sale de la aplicación y aqui no ha pasado nada.
Si no, si vives cerca, yo tengo la craddle oficial.
Vale, voy a probarlo, tengo aqui mis dos gp2x, las versiones del firmware son las siguientes:
Gp2x: Firmware 1.2.1
Gp2x F-200: Firmware 4.0
Acabo de probar mis 3 juegos + los 2 que pones en el Runtime, no funcionan nada de nada, ni los que pones...
Porque los has puesto ? A ti te funcionan esos 2 ??? O mejor, existe alguna cosa que te funcione ? Que version tienes de Firmware ?
Saludos.
Yo no los he puesto, los puso splinter en el pack de WIZ, a modo de demo, y sí, me funcionan ambos (en el segundo se retarda un poco el sonido, pero no es algo crítico).
Y como he dicho, tengo el firm Open2X, que es con el que funciona. Están los oficiales, que son el 1.0.0, el 1.0.1, el 1.1.0, el 2.0, el 2.1.1, el 3.0.0, el 4.0, etc, etc. Y luego el Open2X, hecho por la scene, con librerías más nuevas, compilador más moderno, totalmente compatible (en el 98% de los casos) con todo lo que hay para los firms oficiales, y con nuevas utilidades muy interesantes (un programa que configura los mandos USB para usarlos con esos programas que no redefinen las teclas, un lanzador en el que puedes establecer la velocidad del micro y de la RAM para esos juegos que tampoco lo traen, soluciona cierto bug que tenía yo con el sonido, por el que se invertían los canales del estereo cuando le daba la gana, se cuelga mucho menos...).
Tiene muchos pros y algunos contras (no tengo internet), hay que mirarlo. Si no fuera por Bennu ya me habría vuelto al firm oficial. Es por lo de la conexion wifi, que si no lo mismo me quedaba :D :D :D
mi negrita se enladrilló en el verano, lastima, y me sobra una craddle...
espero conseguir pronto la wiz :)
¿Y no te has puesto a desenladrillarla, o a mandárselo donde la compraste? HG te la desenladrilla si se la mandas, y en el foro hay información de cómo hacerlo si tienes una cradle.
no, gracias, le dió un golpe de calor que mejor pasarse a la wiz...
quien la quiera así se la envio de vuelta, que está en el servicio tecnico y va siendo hora que la devuelvan, valga la rimbandoncia...
Mándasela a SplinterGU, a ver si con suerte nos da soporte oficial para la gp2x ;D
si la echa a andar...
Hola a todos los que posean una GP2X, necesito que me probeis este paquete de bgd-runtime en vuestas negritas para ver si va.
Lo he recompilado con el devkitgp2x para linux, a ver que tal rula (y de no rula qué dependencias os da para pasaroslas)
Gracias de antemano por vuestra ayuda.
http://www.mediafire.com/?fx6s8ubnv1ub0yc
Ahora mismo! Pero si me briqueas la consolas ya sabes lo que te espera :)
¡Leches! Yo tambien andaba liado con esto. Ahora me estaba dando problemas con las dependencias, que no me encuentra la zlib :D
Tranqui Drumpi, la de DCElso no funciona ni en F100 ni en F200. He vuelto a probar la tuya para confirmar y la tuya si que chuta xDD
dime que falta o que te dice o que error da, saca los logs si puedes.
Vale, voy a probar poniendo logs y te cuento.
Ni siquiera me crea los logs, o sea ni siquiera el bgdi funciona xDDD
cagoen
osti tu,no me extraña que no vaya el bgdi, como que es un script linux, cagoe, me confundí al copiarlo.
A ver te paso el bgdi bueno, y porfi, pruebame en la gp2x el bgdc con un prg a ver si crea su dcb. y este nuevo bgdi que te adjunto.
Asias por tooo.
No me pillas a modo de compilar un prg con el bgdi.
He puesto tu nuevo bgdc y sigue igual, tampoco genera los logs.
:o, supongo que invertistes bgdc y bgdi en el anterior post.
A ver que tal ahora, he recompilado todo, y he insertado unos módulos que me faltaban,
http://www.mediafire.com/?znj74zcotka3zu1
Me encantaría que probases un script que compile un .prg (con bgdc) en la gp2x y que usara el dcb generado (con el bgdi), e intentar sacar logs de todo con "1> stdout.xt 2>stderr.txt"
Bueno, voy a ver si puedo sacar un ratillo y probarlo yo también, aunque mi test no va a servir de mucho, pues tengo el firm open2x (bueno, así probamos si también sirve para este firm) y el modo compatibilidad no es exactamente el firm oficial... creo, porque mi versión oficial no le funciona a futublog.
Free, ponte en contacto con futu y pásale el bennu que tienes tu, a ver si así le funciona, porque me pareció muy raro.
Es la tuya. Cuando llegue a casa.
Bueno, pues no me va.
En el caso del firm open2X, el único mensaje que he obtenido es el error del bgdi:
./bgd-runtime/libvideo.so:undefined symbol: _floatsidf
Supongo que será alguna incompatibilidad entre el dcb que estaba compilado y esta versión del intérprete. Por lo demás, el log de BGDI está en blanco, y el BGDC no indica nada de nada.
Ejecutando el .gpe a través de telnet sólo he obtenido un vago mensaje: "segmentation fault", y de ahí se ejecuta el gmenu2x (quitándome el control por comandos).
He intentado ejecutarlo a mano (invocando al bgdc/bgdi) pero aun estableciendo PATH y LD_LIBRARY_PATH no me encuentra las librerías.
En el modo compatibilidad es un poco más parlanchin. El BGDC me manda el siguiente mensaje de error:
bgdc: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ../bgd-runtime/libcrypto.so.0.9.8)
El BGDI lanza lo siguiente:
bgdi: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ../bgd-runtime/libbgdrtm.so)
bgdi: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ../bgd-runtime/libcrypto.so.0.9.8)
Y el script que uso:
#!/bin/sh
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../bgd-runtime
PATH=$PATH:../bgd-runtime
export LD_LIBRARY_PATH
export PATH
echo 2 > /proc/cpu/alignment
for prg in *.prg; do
name=`basename $prg .prg`
bgdc $prg 1>log1.txt 2>err1.txt
bgdi $name 1>log2.txt 2>err2.txt
done
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
Tiene mala pinta, porque esos mensajes me suenan. Como empiece a pedir ciertas librerías con rutas absolutas la habremos liado.
Umn, pues a mi me parece correcto, sabría que pediría más librerías ya que está compilado con gcc4 y las librerías que trae la gpx son del gcc2.
Te las busco y las adjuntamos a ver si salen más o son esas las únicas necesarias.
Drumpi, para no tener que ir pidiendo y tardar tanto te paso todas las libs, hay dos formas de probar si valen:
La forma correcta sería ir metiendo poco a poco las que te vaya pidiendo bgdc y bgdi en el directorio bgd-runtime.
La forma drástica y rápida es meterlas todas en el directorio bgd-runtime (inconveniente, ocupa un huevo más debido a, entre otras cosas, los enlaces simbólicos fueron remplazados por copias de los archivos originales )
sysroot_libs
http://www.mediafire.com/?tsp8pb96jeujeep
arm-linux_libs
http://www.mediafire.com/?klgs33i7umpvlk0
amo a ver que pasa aqui, me voy a cagar en la mas hoia... [chanclas teme]
bueno, a mi no me funcionaba porque tengo el firm 3.0.0 y no le he puesto el 2x ese como se llame porque no me he puesto un ratillo... ah! que eso es pereza, bueno por pereza; y por no saber si hay un tuto de ello
si quereis que pruebe cosas con el firm 3.0.0 decidlo
Probado, ni compila ni ejecuta dcb's, ni crea logs en los 2 casos...
DCelso, es que ese es el problema que tiene la versión que compilé con las toolchains Open2X, el del GCC4 frente al GCC2, y por eso estoy intentando hacerlo con las toolchains oficiales pero con las liberías aceleradas de paeryn (que son las que se han usado en los juegos antes de que existiera el firmware open2X).
A mi me pedía la siguiente lista de librerías (para la versión r142, después con el cambio de librerías en Bennu no sé):
ld-2.2.5.so
libc-2.2.5.so
libcrypt-2.2.5.so
libdl-2.2.5.so
libm-2.2.5.so
libnsl-2.2.5.so
libnss_dns-2.2.5.so
libnss_files-2.2.5.so
libresolv-2.2.5.so
librt-2.2.5.so
libutil-2.2.5.so
Y la cosa va bien cuando le meto la primera, pero la segunda la busca en /lib, da igual el orden de PATH o de cualquier cosa, es como si la libc buscase el resto de librerías en /lib usando rutas absolutas, no relativas ni con variables del sistema.
No obstante, intentaré probarlo de nuevo, a ver si hay más suerte.
Futu, HAY que probarlo con los firms 2.x y 3.0, pues si funciona en estos deberían funcionar en Open2X. El de Open2X es fácil de hacer... solo que tengo que migrar las toolchains de windows a Linux, pero me interesa que antes funcione el oficial, que es el que da más problemas (y porque me estoy planteando el volver al firm oficial, porque el open2X sólo me está aportando Bennu y algo más de velocidad, pero me está quitando el WIFI, 10MHz y mi mando USB).
llevo intentando compilar con el firmware oficial ya un tiempo, pero es que el problema reside en que el SDK oficial no trae nada de nada, está mas vació que la ostia y hay que recompilar todísimo para éste, además no se que p..yas le pasa al configure oficial que al compilar con este sdk te dice que el gcc no puede crear binarios, y pruebas a compilar cualquier .c a manini con el SDK y te da incompatibilidad de binarios,así que algo se me escapa de cómo usar el sdk oficial, estoy intentando buscar ejemplos de como compilar cosas con el sdk oficial, pero todo lo que encuentro en openhandhedls parece para devkit, cagoen.
Hablo yo con poco conocimiento, no tendrias que usar la misma version de sdl que el usado en el firmware de Gp2x ?
SDL no es SDK, por si por ahí te confundiste.
Y claro, hay que usar por narizes el mismo SDL independientemente del SDK usado si quieres que corra con las librerías que tiene instaladas GP2X.
No me he confundido, me referia al SDL si señor.
Por eso mismo se creó el devkitpro, para suplir el infierno que era usar el SDK oficial.
Yo sólo lo usé una vez tratando de obtener una librería para Fenix, pero hasta los ejemplos debía compilarlos por comandos, ya que el Dev-c++ que traía no compilaba nada.
Misato dijo que había un script que te instalaba el devkitpro con librerías y demás, y te las dejaba listas para tu SO, pero a mi, todo lo que huela a instalador y "copia automatizada de ficheros" me da yuyu, no quiero tener por ahi ficheros que no sé lo que son.
Pero bueno, es lo que hay, yo también tuve que compilar e instalar algunas librerías para el SDK de Open2X, pero como usaba cygwin (un sistema emulado) pues me daba igual.
Hoy se me ha hecho tarde ya para hacer nada (juer, cómo pasa el tiempo en invierno).
pues vete al otro hemisferio :)
vale, soy torpon y repasandoo el hilo veo muchos enlaces, ponedme lo que sea que haya que probar que lo pruebo con el firm 3.0.0
pues mira, te he hecho un megapack para megatontos :P, simplemente es descomprimir el zip adjunto en la SD y te aparecera en la sección de juegos de la GP2X un juego llamado bgd-test, pues es ejecutar y listo.
* Si todo funcionase correctamente se vería una pantalla en negro en la que pone press START, pulsas START y te vas al menu de GP2X.
* Si algo va mal, copiame aquí la información de cuatro txt que se han creado en el directorio /bgd-test de tu SD.
http://www.mediafire.com/?ka0azf3sz14x763
NOTA: ocupa un huevo esta versión de bgd-runtime porque es una prueba drástica de funcionamiento que trae bastantes archivos repetidos en vez de softlinks y bastantes librerías de gcc4 para así intentar ejecutarse en cualquier versión de GP2X, independientemente de su firmware.
Subo otro pack, esta vez creo que el definitivo, Drumpi, he eliminado (creo) las dependencias contra las libs
ld-2.2.5.so
libc-2.2.5.so
libcrypt-2.2.5.so
libdl-2.2.5.so
libm-2.2.5.so
libnsl-2.2.5.so
libnss_dns-2.2.5.so
libnss_files-2.2.5.so
libresolv-2.2.5.so
librt-2.2.5.so
libutil-2.2.5.so
Pruebalo
http://www.mediafire.com/?eld4xc20j2ch6aj
Okis, mañana lo miro, que no son horas ^^U
Si funciona, ya te pediré los pasos para hacer yo la compilación, al menos, que seamos dos los que llevemos la versión no oficial para GP2X.
Lo que no entiendo es que hayas podido quitar las dependencias si Bennu usa funciones de estas librerías. De todas formas, lo que suelen hacer todos los programadores de GP2X es compilar las SDL de forma estática, para ganar rendimiento. De ahí que el 95% de las utilidades no fuesen compatibles con WIZ, algunas compatibles que yo haya sabido fueron la máquina virtual de Java y (curiosamente) mi versión open2x de Bennu ^^U
Lo he mirado en un momento usando tu código de test: el BGDC se queja (en el log de error) de que no encuentra la libcrypto.so.0.9.8, aun renombrando la libcrypto.so, mientras que el bgdi lo hace por la libbgdrtm.so, tanto en firm open2x como en modo compatibilidad. Hubo un momento en que parecía que arrancaba, pero se quedó la pantalla en negro. Aun así, no ha llegado a generarse ni el dcb.
A ver si esta tarde hago pruebas más serias (es que conectar la GP2X en red USB al PC me quita la red wifi :S).
bgdi, que raro que no encuentre libbgdrtm, curioso, de todas formas prueba a subir también el dcb aunque sea compilado desde windows o linux, y bueno lo negro es buena señal, se veían algunas letras?
Quote from: DCelso on December 15, 2010, 09:46:23 PM
...
* Si todo funcionase correctamente se vería una pantalla en negro en la que pone press START, pulsas START y te vas al menu de GP2X.
* Si algo va mal, copiame aquí la información de cuatro txt que se han creado en el directorio /bgd-test de tu SD.
...
en cuanto a bgdc, va a ser que la he cagao con la libcrypto, mientras la recompilo puedes probar con alguna que tengas, si dices que algunos binarios son compatibles con wiz quizas esta vaya, no usa SDL.
¿Puedes pasarme exactamente la información de los cuatro logs?
No, no salía nada: pantalla negra y respuesta cero a los botones (vamos, un cuelgue en toda regla).
Por desgracia no he podido probar nada de nada, porque ha venido a mi casa un señor con bigote y ha recalificado una mesa grande y me ha pedido que le ayude a montar la red eléctrica en su nueva urbanización "Belén, ciudad de adoraciones".
Sí, a mi padre le entusiasman las manualidades, en eso he salido a él, y le encanta montar su Belén tamaño XL.
Bueno, al lio. Logs de la última ejecución infructuosa:
BGDC_STDERR.TXT
bgdc: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
BGDI_STDERR.TXT
bgdi: error while loading shared libraries: libbgdrtm.so: cannot open shared object file: No such file or directory
El resto, en blanco.
hoy he tenido una mijita de pilas para probarlo y...
Quote from: DCelso on December 15, 2010, 09:46:23 PM
pues mira, te he hecho un megapack para megatontos :P, simplemente es descomprimir el zip adjunto en la SD y te aparecera en la sección de juegos de la GP2X un juego llamado bgd-test, pues es ejecutar y listo.
* Si todo funcionase correctamente se vería una pantalla en negro en la que pone press START, pulsas START y te vas al menu de GP2X.
* Si algo va mal, copiame aquí la información de cuatro txt que se han creado en el directorio /bgd-test de tu SD.
NOTA: ocupa un huevo esta versión de bgd-runtime porque es una prueba drástica de funcionamiento que trae bastantes archivos repetidos en vez de softlinks y bastantes librerías de gcc4 para así intentar ejecutarse en cualquier versión de GP2X, independientemente de su firmware.
nada, me devuelver al menú principal
errores:
bgdc: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libc.so.6)
bgdc: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libdl.so.2)
bgdi: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libc.so.6)
bgdi: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libdl.so.2)
Quote from: DCelso on December 16, 2010, 12:18:26 AM
Subo otro pack, esta vez creo que el definitivo, Drumpi, he eliminado (creo) las dependencias contra las libs
ld-2.2.5.so
libc-2.2.5.so
libcrypt-2.2.5.so
libdl-2.2.5.so
libm-2.2.5.so
libnsl-2.2.5.so
libnss_dns-2.2.5.so
libnss_files-2.2.5.so
libresolv-2.2.5.so
librt-2.2.5.so
libutil-2.2.5.so
Pruebalo
idem de idem
errores:
bgdc: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
bgdi: error while loading shared libraries:
libcrypto.so.0.9.8: cannot open shared object file:
No such file or directory
futu, prueba esa última copiando el archivo bgd-runtime/libcrypto.so que va adjunto por bgd-runtime/libcrypto.so.0.9.8, a ver si así no se queja de esta librería.
Asias de antemano.
soy torponcio, ¿donde está 'bgd-runtime/libcrypto.so.0.9.8'? no la encuentro..,
que la tienes que crear, pixa, osea haces una copia de la libcrypto.so y la renombras por libcrypto.so.0.9.8. ¿Sabrás hacer eso?
eso si, pero no la he copiado sino sustituido ¿vale asi?
creo que sí, y que resultados te dió?
bgdc: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ../bgd-runtime/libcrypto.so.0.9.8)
y
bgdi: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ../bgd-runtime/libbgdrtm.so)
bgdi: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ../bgd-runtime/libcrypto.so.0.9.8)
umn, que raro, pues si , ese error me bloquea del todo, (se supone que ya tenías el libc.so.6 en el megapack, cagoen).
A ver borra todo y prueba con este nuevo pack, a ver si es autosuficiente (en teoría elimina dependencias de la libc).
http://www.mediafire.com/?9xynnd9kavwf89p
Me temo que vas a tener que usar las librerías del SDK oficial para la libc. Por eso estoy buscando una alternativa al open2x.
Sorry, pero llevo una semana sin tocar esto ^^U
okis, pues prueba este último pack y me cuentas a ver si se solucionan los problemillas :D.
diyei, me quedé sin pilas y no lo pude probar, mañana te comment
Yo lo probaré pasado mañana, que mañana me doy una vuelta por Málaga, que tengo que recoger un papel.
(Fede, si estás libre me das un toque, aunque voy a hacer turismo después de atar cabos administrativos :D).
Al final, con los avisos de lluvia y demás, no he salido (y empiezo a arrepentirme, porque ha dejado de llover hace una hora), así que tras el madrugón y la leche manchada que me he hecho (nunca bebo café, y las pocas veces que lo he hecho no me ha afectado... salvo hoy), me he puesto a mirar esto.
Es rarísimo, lo he revisado 20 veces y me da el mismo mensaje una y otra vez en los *std_error.txt:
"../gbd-test-gpe: ../bgd-runtime/bgdc: No such file or directory"
He comprobado la ruta y los nombres varias veces, sólo he copiado la carpeta bgd-runtime tal cual (supongo que el bgd-test no ha cambiado). No hay forma, ni con open2X ni con el modo compatibilidad.
Incluso he probado con TAAoE con idéntico resultado.
A ver si a Futu le pasa lo mismo.
la madre del topo, pues joe, o por una cosa o por la otra nunca funciona, leñes.
A empezar de cero, por cierto, aún tienes acceso a tu entorno que compila bien el bennu para gp2x?
Tendría que mirarlo, porque la versión instalada sí que tengo acceso (al menos, la de las toolchains open2x, y la oficial con cygwin válida hasta la r147) pero a los instaladores los tendré que buscar.
Sé que seguí un tutorial por josebita o animanegra (creo) para instalar cygwin, y luego descomprimir las toolchains del open2x en una carpeta, y las oficiales en otra, pero te tendría que buscar cual de los zips en concreto usé (porque tengo un lío de tres pares, hasta que encuentre la definitiva ^^U).
no,no, simplemente saber si tienes ya configurado el equipo para compilar para comentarte algunos cambios en tus archivos de configuración y que recompilases.
El de Linux sigo sin poder probarlo.
Los de windows sí que están funcionando, pero no me va a dejar compilar las últimas versiones, ya lo dije antes, el salto a openSSL, cygwin es incompatible con su código fuente.
Viene días muy malos para probar nada, pero podría intentarlo con las versiones antiguas.
okis, tonces luego te comento.
pos yo me he llevado dos dias cargando pilas y no he podido encender la gp2x...
diooooooooooooos, mi reino por un adaptador de corriente
a ver si el inventillo de las pilas funciona...
Nueva y espero que redefinitivísima versión para gp2x independiente del sistema, probadla futu, drumpi y free, a ver que tal.
La he compilado con devkitgp2x, y me ha costado el ciento y la madre hacer que no dependa de libc6, las versiones de gcc y ld del devkitgp2x no soportan mezclar librerias estáticas y dinámicas, cosa que me complicó la vida bastante :'(.
http://www.mediafire.com/?hel76jaa6ehtt36
muy bueno DCelso, karma!
hacete un tuto (o mandamelo por PM) de como armar el entorno y que cambios hay que meter asi la incluimos como oficial...
En 12 horas tendrás la respuesta :D
Splinter, no creo que te guste, es un bennu monolítico, es la única forma por ahora posible para eliminar las dependencias dinámicas de las libs de gcc, al menos usando la versión de devkitgp2x. :). Y por cierto, me vi negras para unir bgdc con bgdrtm, no veas la de variables y funciones redeclaradas que se forman, encima se necesitan las dos formas de cada cosa ya que no son exactamente iguales y bgdrtm tira de unas y bgdc de otras :D.
Como ventaja, irá mucho más rápido en la negrita.
Por cierto, pregunta: ¿Como estarán mapeadas las teclas de la GP2X? yo puse como parámetro para compilar -DTARGET_GP2X y veo en el código que solo sirve para definir el OS_ID.
Quizas necesitemos un programa para que nos las chive mientras las vamos tocando, creo que ya teníamos por aquí alguno, pero no lo encuentro.
bueno, si es asi no me gusta...
tampoco tendria eso que significar que vaya mas rapido.
por otro lado, si lo que vas a usar es una version monolitica, podrias usar la de josebita, que al menos respeta la filosofia de bennugd de carga de modulos, aunque no los este cargando...
aunque quizas convenga esperar la siguiente release oficial de bennugd, que falta poco para salir, porque el sistema interno cambia un poco (aca josebita me va a odiar).
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.
Compilar Bennugd para devkitGP2X de forma estática (o monolítica)
Creación de entorno de compilación.
1. Bajar archivo "devkitPro.tar.gz" de openhandhelds.com
2. Descomprimir en /SDKs/devkitpro/devkitGP2X
3. Bajar archivo "sdl-libs-211006.zip" de openhandhelds.com
4. Decomprimir en /SDKs/devkitpro/devkitGP2X/sdl-libs-211006
La estructura final de directorios sería la sliguiente:
/SDKs/devkitpro/devkitGP2X
/libexec
/man
/sysroot
/bin
/info
/share
/lib
/sdl-libbs-211006
/devkitGP2X
/bin
/etc
/include
/info
/lib
/man
/share
/arm-linux
/include
Puede que parezca un poco rara pero es muy cómoda de trabajar y modificar.
Modificación del código bennu.
1. Bajar el código bennu de SVN, en /home/usuario/workspace/bennugd
2. Entrar en el directorio de bennugd y aplicar el archivo patch adjunto a este documento llamado GP2Xmonolithic.patch.
cd /home/usuario/workspace/bennugd
patch -p0 < ../GP2Xmonolithic.patch
3. Descargar código fuente de openssl "openssl-0.9.8q.tar.gz".
4. Descomprimir en /home/usuario/workspace/bennugd/openssl-0.9.8q
5. Compilar openssl.
cd /home/usuario/workspace/bennugd/openssl-0.9.8q
. ../devkitGP2X-vars.sh
./config no-asm no-dso no-krb5 --prefix=$PREFIX
6. Modificar la ruta de openssl de los Malefiles que hay en el directorio monolithic
gedit /home/usuario/workspace/bennugd/monolithic/Makefile.devkitGP2X
y poner la ruta en la que descomprimimos openssl en la variable SSL_INSTAL_DIR
7. Compilar bennugd con los nuevos scrips
cd /home/usuario/workspace/bennugd/monolithic
make -f Makefile.devkitGP2X create_links
make -f Makefile.devkitGP2X all
muy bueno entonces, luego lo revisare...
supongo entonces que no te sera complicado adaptar el nuevo codigo que estoy terminando...
nada en absoluto :D, lo bueno es que tengo ya casi preparada versión para psp :D.
estaria bueno que en consolas como gp2x se use una version shared, por el tema de la memoria, para no ocupar en memoria con cosas que no se usaran.
Pues de momento tengo malas noticias: sigue sin ir :(
bgdc_stderr.txt me da un ": error while loading shared libraries: cannot create search path array: Cannot allocate memory"
bgdi_stdout.txt me da un obvio "bgd-test: doesn't exist or isn't version 7 DCB compatible".
Y el resto de ficheros de salida en blanco, así que, seguimos igual, pero con un error distinto.
En serio, empiezo a pensar que necesitamos mano profesional aquí, porque como a mi me de también error por "vete tú a saber qué", estamos perdidos.
De todas maneras, vamos a esperar a ver qué dicen los que tienen el firm oficial de verdad.
cagoen. pues el de linux me iba :'(
Probado en la F200 (firmware 4.0). No chuta pero eso si, tiene pinta de estar cerca ya que la pantalla se queda algun tiempo en negro (no he podido mirar logs, hoy estoy sin tiempo).
voy a intentar recompilarlo sin optimización a ver si es que es esta quien la caga. Drumpi, prepárate que en breve la subo :D.
Optimización 0:
**************
http://www.mediafire.com/?i318w79k93mj9sj
Y otra más con otros parámetros de optimización distintos, en esta versión he usado los mismos parámetros que tu usaste en las tuyas drumpi.
Optimización 2
**************
http://www.mediafire.com/?732i90wvxf87srp
Probaré esta tarde, lo que pasa es que la optimización0 no me deja descargarla, no sé por qué.
EDIT: Bueno, tenía un momento antes de comer, así que he hecho la prueba con la optimización 2 con idéntico resultado:
bgdc_stderr.txt me da un ": error while loading shared libraries: cannot create search path array: Cannot allocate memory"
bgdi_stdout.txt me da un obvio "bgd-test: doesn't exist or isn't version 7 DCB compatible".
Conste que sigo sin cambiar nada, ni del test ni de las carpetas.
umn, entonces el bgdi tiene buena pinta, ese error lo suelta éste mismo :D.
Quizás sea culpa de memoria, voy a ponerte dos tests más, uno con un .dcb a ver si lo rula el actual bgdi y otro con bgdc y bgdi menos pesado con algunas librerías menos.
Tiene buena pinta sin duda, porque si la pantalla se queda algun tiempo en negro es porque algo esta cargando...
yo tambien creo que es problema de memoria, como habia dicho, no es bueno por cuestiones de memoria que en las consolas como gp2x se use una version monolitica.
quizas debas modificar algunos limites (procesos/etc) para hacer esto mas liviano...
Sip, yo estoy con vos Splinter, pero la versión dinámica tira de libc6.0.so y de un sin fin mas de .so que son del gcc4 y no vienen en el sistema de gp2X a no ser que actualices el firmware a una versión open2x más moderna :'(, esa limitación es la que estábamos intentando salvar para tener una versioncilla de bennu para las gp2x no modificadas :D.
Bueno, siguiente testeo.
He visto en una recompilación que faltaba enganchar con una librería así que se la he añadido, a ver si con suerte es la que le faltaba al bgdc para rular. Subo como test la versión del nim que he hecho para la crapcombo, como añadido también le he puesto que ponga en pantalla un número cada vez que pulsas una tecla, para identificar así el mapeo de teclas de GP2X, así que si free o drumpi o futu conseguís rularlo me encantaría que sacárais el mapeo de teclas, sería pulsar una tecla y guardar el nombre de la tecla y el número que pone en pantalla y luego pasarme toda esa info, asias de antemano.
http://www.mediafire.com/?nlbjuz7u4z8jp54
Quinto GP2X bgd test :D, (por lo menos de esta tirada :))) ) no veas tu, necesito una GP2X como el comer para asi no necesitar subir tantas pruebas :D.+
En este caso, como bgdc se queja de que no tiene librerías dinámicas he linkado contra libc dináimicamente pero no debería de usarla porque también lo hice con ella estáticamente, solo es para que tuviera el bgdc y bgdi una sección de librerías dinámicas y que no se quejase el sistema operativo, si no va, y solo si no va el cuarto test, probad este :D.
http://www.mediafire.com/?t566l2536eeq6zw
Quote from: DCelso on January 04, 2011, 04:31:43 PM
Sip, yo estoy con vos Splinter, pero la versión dinámica tira de libc6.0.so y de un sin fin mas de .so que son del gcc4 y no vienen en el sistema de gp2X a no ser que actualices el firmware a una versión open2x más moderna :'(, esa limitación es la que estábamos intentando salvar para tener una versioncilla de bennu para las gp2x no modificadas :D.
Bueno, siguiente testeo.
He visto en una recompilación que faltaba enganchar con una librería así que se la he añadido, a ver si con suerte es la que le faltaba al bgdc para rular. Subo como test la versión del nim que he hecho para la crapcombo, como añadido también le he puesto que ponga en pantalla un número cada vez que pulsas una tecla, para identificar así el mapeo de teclas de GP2X, así que si free o drumpi o futu conseguís rularlo me encantaría que sacárais el mapeo de teclas, sería pulsar una tecla y guardar el nombre de la tecla y el número que pone en pantalla y luego pasarme toda esa info, asias de antemano.
http://www.mediafire.com/?nlbjuz7u4z8jp54
probaron copiando todas las .so necesarias (de la gcc que corresponda) en la carpeta del runtime y setear el LD_LIBRARY_PATH en el script que llaman al bgdc/bgdi?
Sip, esa fue la primerísima opción, justo lo que dices, si chequeas este hilo podrías comprobarlo. Drumpi seguia teniendo problemas de dependencias y eso que le pasé más de 16 megas de .so :D.
Bueno, otra nueva versión, esta vez lite, le he dejado solo los mods que necesita el bgd-test adjunto, a ver si esta no da problemillas de memoria :D.
http://www.mediafire.com/?0z5tzaghh03m1ch
proba una simple version con mod_say unicamente, y hace un hello world con redireccion de la salida...
si, me parecio leer eso, pero lo volvi a preguntar...
ademas, segun como setean el LD_LIBRARY_PATH puede no funcionar, tenes colgado aca el script donde lo seteas?
No funciona. Para que pienses, la otra se queda mas tiempo la pantalla en negro, esta sale casi al instante, no he mirado logs.
ninguno de los seis tests?, no me lo puedo de creer, jo.
Quote from: DCelso on January 04, 2011, 11:40:19 PM
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.
De los ultimos 3, sólo probé el ultimo (lite).
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:
#!/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.
ese script, si tenes las dependencias del runtime en la carpeta ../bgd-runtime deberia funcionar, chequealo en la SD...
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.
Quote from: Drumpi on January 05, 2011, 02:12:07 PM
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.
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:
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:
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
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
Olee, menos mal, algo que va :D.
Quote
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.
Creo que lo probé, pero no recuerdo el resultado, sé que fallaba pero no recuerdo por qué. Te lo miro mañana.
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.)
Quote from: DCelso on January 03, 2011, 05:17:41 PM
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
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
Quote from: josebita on January 09, 2011, 05:47:25 PM
Quote from: DCelso on January 03, 2011, 05:17:41 PM
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.
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.
Sí, compilar con SDL se las trae. Por eso me hice mis makefiles. En general, compilar contra cualquier cosa que tenga unas cuantas dependencias que encima dependen las unas de las otras estaticamente tiene su aquel y encima puede depender de la plataforma DESDE la que estés compilando.
Ya te digo que tu implementación y la mía son conceptualmente idénticas, pero me da que tú la has hecho de forma más limpia.
No lo voy a poder probar en unos días (estoy hasta arriba de trabajo en la universidad y lo voy a seguir estando durante algo de tiempo) pero de verdad que lo miraré, porque me facilitaría mantener la sincronización entre mi repositorio y el oficial.
Pruebas realizadas, pero con malos resultados:
MonolithicTest5:
El BGDC no da ningún tipo de error, pero no compila.
El BGDI da el siguiente mensaje de log: Unsupported module: libdraw.so
GP2XTest4:
El BGDC se queja de lo de siempre:
: error while loading shared libraries: cannot create search path array: Cannot
allocate memory
El BGDI de: Unsupported module: libdraw.so
Una cosa rara para SPLINTER:
He intentado compilar el Echo con la r201 y me ha dado un error muy raro:
\echo.prg:126: error: Data type not accepted here, found ")"
La línea en cuestión es:
enem_grafs[0]=load_fpg("grafs/blobo.fpg");
Si la comento va bien (no afecta al juego, es sólo una línea de la sección de debug).
La descarga del código, etc, en http://projects.bennugd.org/?details=39 (sí, es el mismo, no he tocado nada... al menos nada importante).
umn, ultrarraro libdraw está en los módulos soportados :D, te compilo una version nueva con todos los módulos en breve, a ver si es que subí sin querer dos veces la versión lite, que no te estriña.
ostras tu, soy un panelo, resulta que libdraw no exporta nada y no lo añadí a la lista de módulos soportados :D, bueno ya lo metí, ahora sí que sí, versión refinitiva monolítica para gp2x.
http://www.mediafire.com/?d5375rdm5wd031l
Minteresaría que probarais cuanto antes el bgdc y el bgdi para cerrar este tema ;D (que me lleva escamaoooo con tantas reversiones :) )
Luego lo pruebo :D
asias apañao, a ver si logras ganar al nim.
A mi me extraña que haya tantos problemas, yo lo compilé sin tener que cambiar nada, pero claro, usando los entornos preparados y virtualizados (para instalar las librerías que falten y eso), y sin usar librerías aceleradas, que es el mayor problema, que esas librerías parecen ser incompatibles con las del sistema (¿incluso las SDL?).
Ahora estoy demasiado liado con bennu y con "lo otro" para seguir intentándolo por mi cuenta, lo siento (es más, ni siquiera consigo instalar eclipse para programar en java ^^U). Pero al menos sí puedo ir haciendo de betatester.
:D, no pasa res, conque me hagas de betatester podemos ir tirando :D, ya me dirás si va o no tu drumpi y si va bien o que :D.
(http://forum.bennugd.org/index.php?action=dlattach;topic=1144.0;attach=1722)
(http://forum.bennugd.org/index.php?action=dlattach;topic=1144.0;attach=1726)
entonces funciona!
que version es esa free?
por que a drumpi no le va?
Quote from: Drumpi on January 11, 2011, 02:11:29 PM
Pruebas realizadas, pero con malos resultados:
MonolithicTest5:
El BGDC no da ningún tipo de error, pero no compila.
El BGDI da el siguiente mensaje de log: Unsupported module: libdraw.so
GP2XTest4:
El BGDC se queja de lo de siempre:
: error while loading shared libraries: cannot create search path array: Cannot
allocate memory
El BGDI de: Unsupported module: libdraw.so
Una cosa rara para SPLINTER:
He intentado compilar el Echo con la r201 y me ha dado un error muy raro:
\echo.prg:126: error: Data type not accepted here, found ")"
La línea en cuestión es:
enem_grafs[0]=load_fpg("grafs/blobo.fpg");
Si la comento va bien (no afecta al juego, es sólo una línea de la sección de debug).
La descarga del código, etc, en http://projects.bennugd.org/?details=39 (sí, es el mismo, no he tocado nada... al menos nada importante).
increible que eso haya compilado anteriormente... es correcto que falle, puf, no entiendo como eso no genero errores...
tu declaracion es:
int enem_grafs[1][cte_enem_last];
y estas queriendo usarlo asi:
enem_grafs[0]=load_fpg("grafs/blobo.fpg");
te falta 1 dimension, por eso no da error.
me alegra saber que sin querer se soluciono un bug no reportado.
Esta es la mia...
Es broma xDDD
Es la DCElso, no he visto a Drumpi decir que no le va....
La voy a probar en la F100 a ver si chuta.
El Deadly Eye funciona perfectamente, sonido y todo (logicamente el juego es lentito y no tiene mapeados los botones, ya que lo detecta como version PC o desconocida, habria que ver como lo tiene Novern en su codigo).
Los mios no van (igual porque son compilados viejos).
He probado el que estoy desarrollando y tambien funciona, pero se sale al reproducir un flc, no se si DCElso le ha puesto todos los modulos, depues le paso el log.
Curioso que haya puesto todos los modulos embutidos en el interprete y compilador....
supongo falta incluir un nuevo os_id para la consola, asi no lo reconoce como pc.
seguro ya lo pregunte, pero ahora que sabemos funciona la version gp2x, recuerdenme cual era el impedimiento para compilar la version con .so?
tooma geroma pastillas de goma, el que la persigue la consigueeee.
uf menos mal que sirvió para algo esto :D.
SplinterGU, en principio nunca fue mi intención hacerlo monolítico para gp2x, las primeras versiones eran normales, pero no rulaban porque iban pidiendo ".so" del compilador GCC y libc6 que vienen en el devkitGP2X último, yo le iba pasando una a una al principio a drumpi y no conseguía él ecarlo a andar, así que le pasé el paquete completo de ".so" del GCC y libc6 y con eso el directorio bennugd para GP2X terminaba ocupando unos 28 megas y aún así seguía pidiendo más ".so". Mi primera opción para eliminar las dependencias de gcc y libc6 fue linkar con estas estáticamente y con las de bennu de forma dinámica, pero el cabrón del compilador (y linker) de devkitGP2X no soporta mezclar librerías estáticas con dinámicas, el muy cacho perra, entonces como segunda opción me quedó compilarlo todo estáticamente para ver si desaparecían las dependencias de los .so del sistema gcc y libc y así poder tener una versión GP2X independiente del firmware instalado en ella, oficial o open2x o el que sea no oficial.
Ahora queda saber qué firmware tiene free en su gp2x :D.
Por otro lado free, ¿el compilador bgdc fue? es decir ¿creaste el .dcb en la gp2x? o se lo pasaste ya desde el PC.
En cuanto a las teclas, se supone que son las mismas que para WIZ, al menos eso me dijo Drumpi, así que mirate el jkeys de splinter, o usa mod_joy, básicamente son 10 teclas del joy 1, es decir joy_getbutton(0,0), joy_getbutton(0,1), ....,joy_getbutton(0,9).
Ya dije las versiones de mis firmware en otros hilos (en los intentos de Drumpi), mañana lo confirmo, pero es la 1.2.1 para la negrita F100 (mañana la pruebo) y 4.0 para la F200 (la de las fotos). Sólo ejecute dcb's que ya tenia, pero tu demo, si el gpe hace el compilado, pues entonces funciona tanto el compilador como el interprete...
Mañana pongo logs a los juegos que no van y te comento, lo que si me parece raro son los logs que generas, me parecen más mensajes de debug que sólo mensajes de errores...
Toma geroma pastillas de goma, esta frase mola, es la primera vez que la oigo!!!
:), oirla oirla...
umn, pues puede ser que se me escapase alguna que otra traza de depuración :D.
Por cierto, no tendrás una psp por casualidad no?
Estas de suerte, vete al hilo repectivo xDDD
A mi, el ejemplo que me pasó no me compilaba, daba error, pero cargaba del DCB
Lo dicho, mañana pruebo esta última versión con un DCB "completo" (hablando de número de funciones) a ver si rula.
Respecto a las librerías, es que al compilar las libc, tienen la manía de linkar con rutas ABSOLUTAS a las que dependen, y cogen las del sistema, y ya puedes poner en el PATH que busquen las nuevas, que seguirán pensando en las del sistema. Por eso quería usar el SDK oficial, para que bennu se compilase usando las libc que usa el sistema, y no las mas nuevas (sólo usar las librerías "externas", como las SDL aceleradas de Paeryn u otras que no estuvieran en el Linux de la consola).
Quote from: DCelso on January 11, 2011, 07:59:59 PM
:D, no pasa res, conque me hagas de betatester podemos ir tirando :D, ya me dirás si va o no tu drumpi y si va bien o que :D.
Por última vez, que el Juego no es Drumpi, que es Echo, "The amazing adventures of Echo", para el Drumpi aún me queda un poco ;D (por lo menos, que funcione en parte el motor de Sonic).
Quote from: SplinterGU on January 11, 2011, 10:15:26 PMincreible que eso haya compilado anteriormente... es correcto que falle, puf, no entiendo como eso no genero errores...
tu declaracion es:
int enem_grafs[1][cte_enem_last];
y estas queriendo usarlo asi:
enem_grafs[0]=load_fpg("grafs/blobo.fpg");
te falta 1 dimension, por eso no da error.
me alegra saber que sin querer se soluciono un bug no reportado.
No volveré a reciclar variables, usaré nuevas.
No volveré a reciclar variables, usaré nuevas.
No volveré a reciclar variables, usaré nuevas.
No volveré a reciclar variables, usaré nuevas.
No volveré a reciclar variables, usaré nuevas.
...
^^U
Supongo que antes tomaba la referencia como enem_grafs[0][0], igual que hacía "array[0]" cuando se escribía "array" a secas, y al cambiarse el sistema pues se mosqueó.
PD: no lo había mencionado, pero creo que un DCB de la versión r131 (o más antigua, no recuerdo de cuando era) me ha funcionado en la r201 (es el Echo, que me dió el error de compilación, y a pesar de eso, el juego funcionaba) (usa una versión tan antigua porque no he cambiado el script de compilación desde que lo terminé ^^U).
PD2: a mi me reconocía el sistema como una WIZ (supongo que por no haber tocado nada) y nunca se me ha quejado ningún programa. Hasta los controles funcionan igual que en WIZ, es más, funcionan mejor, porque me detecta una dirección y una diagonal a la vez (por aquello de tener 8 botones) y el clic central como el número 9 (valor que la WIZ no usa).
Quote from: DCelso on January 11, 2011, 10:58:20 PM
tooma geroma pastillas de goma, el que la persigue la consigueeee.
uf menos mal que sirvió para algo esto :D.
SplinterGU, en principio nunca fue mi intención hacerlo monolítico para gp2x, las primeras versiones eran normales, pero no rulaban porque iban pidiendo ".so" del compilador GCC y libc6 que vienen en el devkitGP2X último, yo le iba pasando una a una al principio a drumpi y no conseguía él ecarlo a andar, así que le pasé el paquete completo de ".so" del GCC y libc6 y con eso el directorio bennugd para GP2X terminaba ocupando unos 28 megas y aún así seguía pidiendo más ".so". Mi primera opción para eliminar las dependencias de gcc y libc6 fue linkar con estas estáticamente y con las de bennu de forma dinámica, pero el cabrón del compilador (y linker) de devkitGP2X no soporta mezclar librerías estáticas con dinámicas, el muy cacho perra, entonces como segunda opción me quedó compilarlo todo estáticamente para ver si desaparecían las dependencias de los .so del sistema gcc y libc y así poder tener una versión GP2X independiente del firmware instalado en ella, oficial o open2x o el que sea no oficial.
Ahora queda saber qué firmware tiene free en su gp2x :D.
Por otro lado free, ¿el compilador bgdc fue? es decir ¿creaste el .dcb en la gp2x? o se lo pasaste ya desde el PC.
En cuanto a las teclas, se supone que son las mismas que para WIZ, al menos eso me dijo Drumpi, así que mirate el jkeys de splinter, o usa mod_joy, básicamente son 10 teclas del joy 1, es decir joy_getbutton(0,0), joy_getbutton(0,1), ....,joy_getbutton(0,9).
no, lo que hiciste esta perfecto, no es en vano... aun o mire el codigo, pero la idea sirve, asi que no es trabajo al pedo.
con respecto a la version dinamica, no probaste actualizando tu entorno de compilacion a las librerias necesarias?
estaria bueno tener las 2 opciones, pero vamos que no es tan importante ahora mismo.
ah, con respecto a la mezcla de estaticas y dinamicas, no se el caso bien de que librerias exactamente te referis, pero en la mayoria de los casos es un problema de la libtools, y si compilas a mano, podes hacer la mezcla perfectamente... el problema puede existir cuando el mismo statico se usa en varias dlls y necesitan compartir datos de la lib entre las dlls.
no se si me explico.
Te explicaste perfectamente. :D, quizás no esté tan docto en el tema para hacer todo lo que dices :(.
necesitaría que alguien lo probase en firwares oficiales para corroborar que se solventa el problema de dependencias, porque de no ser así sería trabajo perdido :'(
Yo lo he probado en el oficial... :(
Luego te la pruebo en la F100 (firmware 1.2.1).
Yo nunca les he puesto firmwares no oficiales...
ah, okis, pues perfect entonces, pensaba que el 4.0 era open2x o así.
Nop, el 4 creo que fue la ultima version, y logicamente ya venia con las ultimas Gp2x que eran las F200 tactiles, pero las anteriores tambien se podian actualizar. Tengo otras Gp2x's, una de ellas le tengo pendiente poner el open2x, y a otra tengo que mirar el firmware, que es otra version intermedia de las que te he dicho, y que aún no he probado.
http://www.youtube.com/watch?v=u94h6JJOVPw
Muy interesantes :) Ponle un par de etiquetas al vídeo en plan "bennu" "bennugd" y similares, para que salgan cuando la gente nos busque.
No se como va eso.
En las propiedades del vídeo, te deja añadir etiquetas. Símplemente escribe las etiquetas que quieras, entre comas.
Quote from: DCelso on January 03, 2011, 05:20:59 PM
Compilar Bennugd para devkitGP2X de forma estática (o monolítica)
Creación de entorno de compilación.
1. Bajar archivo "devkitPro.tar.gz" de openhandhelds.com
2. Descomprimir en /SDKs/devkitpro/devkitGP2X
3. Bajar archivo "sdl-libs-211006.zip" de openhandhelds.com
4. Decomprimir en /SDKs/devkitpro/devkitGP2X/sdl-libs-211006
La estructura final de directorios sería la sliguiente:
/SDKs/devkitpro/devkitGP2X
/libexec
/man
/sysroot
/bin
/info
/share
/lib
/sdl-libbs-211006
/devkitGP2X
/bin
/etc
/include
/info
/lib
/man
/share
/arm-linux
/include
Puede que parezca un poco rara pero es muy cómoda de trabajar y modificar.
Modificación del código bennu.
1. Bajar el código bennu de SVN, en /home/usuario/workspace/bennugd
2. Entrar en el directorio de bennugd y aplicar el archivo patch adjunto a este documento llamado GP2Xmonolithic.patch.
cd /home/usuario/workspace/bennugd
patch -p0 < ../GP2Xmonolithic.patch
3. Descargar código fuente de openssl "openssl-0.9.8q.tar.gz".
4. Descomprimir en /home/usuario/workspace/bennugd/openssl-0.9.8q
5. Compilar openssl.
cd /home/usuario/workspace/bennugd/openssl-0.9.8q
. ../devkitGP2X-vars.sh
./config no-asm no-dso no-krb5 --prefix=$PREFIX
6. Modificar la ruta de openssl de los Malefiles que hay en el directorio monolithic
gedit /home/usuario/workspace/bennugd/monolithic/Makefile.devkitGP2X
y poner la ruta en la que descomprimimos openssl en la variable SSL_INSTAL_DIR
7. Compilar bennugd con los nuevos scrips
cd /home/usuario/workspace/bennugd/monolithic
make -f Makefile.devkitGP2X create_links
make -f Makefile.devkitGP2X all
Creo que mañana podré echarle un ojo a esto. ¿Te importaría subir un parche con respecto a la última versión de SVN?. Es que he intentado aplicar el parche sobre el código, pero obtengo varios conflictos... y no estoy para andar haciendo el merge a mano. Además, así tendría el código de la versión para PSP integrado tb y podría subirlo a mi repo.
si mas que un patch me pasan un mail describiendo con que cosas modificaron y como, puedo ver de integrar los cambios monoloticos al svn.
un patch esta lindo cuando alguien quiere aplicar un cambio, pero no para analizar los cambios.
gracias.
Probada versión test10:
Empecé con Echo, que tenía ganas de probarlo, así que, mensajes del BGDC:
File echo.dcb compiled (997664 bytes):
Processes 157
Global data 3580 bytes
Local data 244 bytes
Private data 5588 bytes
Public data 0 bytes
Code 800016 bytes
System processes 342
Globals vars 72
Locals vars 34
Private vars 1116
Publics vars 0
Identifiers 1395
Structs 10
Strings 239 (2497 bytes)
Sí, se ha generado un DCB, así que a continuación intento ejecutarlo y:
sh-3.2# cat *2.txt
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 @ 0x41a7c0 (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 0x419d84
SDL_GP2X: First free bucket 0x41a7c0 (size = 5085184)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x41aa98 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5084928 bytes @ 0x41aab0
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x4002d800
SDL_SYS_JoystickInit
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=80000000
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x41a7c0 (size 256)
SDL_GP2X: Freeing bucket 0x41aab0 (size 5084928)
SDL_GP2X: InitHWSurfaces 0x4002d800, 5085184
SDL_GP2X: Screen bucket 0x419d84
SDL_GP2X: First free bucket 0x41aab0 (size = 5085184)
SDL_GP2X: Freeing cursor 0x41aa98
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x4002d800 from bucket 0x41a7c0
SDL_GP2X: merging with next bucket (0x41aab0) making 5085440 bytes
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x41a7c0 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
Hace el amago de arrancar, pero se queda unos segundos en negro y acto seguido, se sale al menu :(
Así que, por si acaso, volví a probar el test de los botones. Ejecutando sólo el BGDI funcionó perfecto y obtuve:
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 @ 0x32b878 (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 0x32adfc
SDL_GP2X: First free bucket 0x32b878 (size = 5085184)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x32b890 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5084928 bytes @ 0x32b8a8
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x4002d800
SDL_SYS_JoystickInit
Así que ejecuté otro script que compilaba y ejecutaba. Sí, compila y ejecuta, pero...
Ejem, no se genera ningún DCB ??? y sin embargo ejecuta ??? ??? Lo he probado tres veces, he borrado incluso el DCB. El script es este:
#!/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
La salida del bgdi_stderr.txt es esta:
SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physica
Pero la del bgdc_stderr.txt... no la puedo leer, el gedit dice que no lo entiende, y un CAT sólo me devuelve el texto "DCB". Parece como si hubiese compilado el DCB y lo hubiese llamado bgdc_stderr.txt. Lo adjunto. El DCB original era de 39'4KB, este de 60KB.
El GPE del Echo es este:
#!/bin/sh
LD_LIBRARY_PATH=../bgd-runtime:$LD_LIBRARY_PATH
PATH=../bgd-runtime:$PATH
export LD_LIBRARY_PATH
export PATH
echo 2 > /proc/cpu/alignment
for prg in *.prg; do
name=`basename $prg .prg`
bgdc $prg 1>log1.txt 2>err1.txt
bgdi $name 1>log2.txt 2>err2.txt
done
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
PD: aun me queda por probar el DCB generado en el Echo en el Bennu actualizado de Windows, pero ahora estoy en Linux y no puedo ^^U
Hombre, el DCB generado en linux vale igual que el generado en windows :)
Sí, siempre que las versiones coincidan, que no es el caso ;D.
Añado una nota más al misterio: en el firm Open2X, el Echo sigue sin funcionar, y el test funciona ¡¡¡y genera el DCB!!! No sé si tendrá algo que ver el que en el modo compatibilidad no puedo salir del test sin apagar la consola, y que el firm open2X tiene el demonio para forzar el cierre de la aplicación actual y volver al menú.
Quote from: Drumpi on January 13, 2011, 06:29:28 PM
Sí, siempre que las versiones coincidan, que no es el caso ;D.
Añado una nota más al misterio: en el firm Open2X, el Echo sigue sin funcionar, y el test funciona ¡¡¡y genera el DCB!!! No sé si tendrá algo que ver el que en el modo compatibilidad no puedo salir del test sin apagar la consola, y que el firm open2X tiene el demonio para forzar el cierre de la aplicación actual y volver al menú.
lamento decir que no, ya hace unas cuantas versiones que no importa con que version se genero el dcb...
corregiste el codigo del prg que tenias mal en el echo?
La verdad es que este patch en particular se entiende muy bien :) Si DCelso no te lo explica, por la tarde te lo cuento.
tendria que recuperar una version anterior del svn... y ando siempre a las corridas.
Drumpi, me da la impresión que el stderr.txt que genera bgdc es el binario, por eso que comentas.
Necesito más tests. Por ejemplo, renombra el archivo ese (que no te abre y parece que tiene el MAGIC DCB) a .dcb e intenta rularlo en windows o linux a ver que pasa.
Y otro test, es quitar el 1> stdout.txt 2>stderr.txt de los scripts e intentarlos lanzar, a ver si por algún motivo la redireccion en la gp2x o tu firmware se está haciendo mal..
cuidado que si generan un dcb con las 2 ultimas versiones del bennu oficial no les va a funcionar con versiones anteriores de bennugd, si funcionara a la inversa, o sea, viejos dcb con la ultima version de bennu.
Splinter, te mandé un privi con el pdf que me pediste.
Por cierto, he descubierto que para psp y gp2x la definición de tus funciones main para bgdc y bgdi dan problemas al usar argv[0].
Resulta que cambiando la definición a int main( int argc, char *argv[] ), se arregla el problema, por eso verás esa modificación en el código que te mandé. Ostras y se me olvidó mandarte las modificaciones del main.c del bgdi, te lo mando en breve también.
la definicion actual es:
int main( int argc, char **argv )
eso te da problemas o warning? porque no deberia dar para nada problemas, es basicamente lo mismo.
eso pensaba yo, pero parece ser que al menos para gp2x y psp no es lo mismo, probablemente tema de lo que ocupa un puntero char o bien de considerar constante uno u otro, no se, la verdad es que si pones la definicion que tienes tu, el bgdi al llegar a argv[0] casca y se cierra y al poner la que yo te digo sigue para adelante y ejecuta bien. Nose, misterios de la ciencia, quizas se pueda solucionar con algún parámetro extraño de bgdc relaccionado con chars, pero probé todos los que vi en el man de gcc sin éxito, así que al final opté por cambiar la definición del main. Si a ti te da igual una que otra, pues pon esta que he visto que funciona, ya sabemos todos que es lo mismo pero a mis pruebas me remito .D.
que va, cambiamos el main como dios manda, siempre uso char *[] para los argv, pero esto estaba en fenix asi, y la verdad que ni lo cambie.
gracias!
Quote from: SplinterGU on January 13, 2011, 07:12:16 PM
Quote from: Drumpi on January 13, 2011, 06:29:28 PM
Sí, siempre que las versiones coincidan, que no es el caso ;D.
Añado una nota más al misterio: en el firm Open2X, el Echo sigue sin funcionar, y el test funciona ¡¡¡y genera el DCB!!! No sé si tendrá algo que ver el que en el modo compatibilidad no puedo salir del test sin apagar la consola, y que el firm open2X tiene el demonio para forzar el cierre de la aplicación actual y volver al menú.
lamento decir que no, ya hace unas cuantas versiones que no importa con que version se genero el dcb...
corregiste el codigo del prg que tenias mal en el echo?
Tendría que revisarlo, pero creo que estas versiones para GP2X no admiten binarios anteriores a la r200.
Sí, corregí el fallo, me lo volvió a decir el stderror en una de las compilaciones y lo cambié.
Miraré a ver qué hace el stderr raro si lo uso con BGDI, pero se me acumulan las pruebas y empiezo a liarme entre versiones ^^U Tampoco es muy cómodo estar encendiendo y apagando la consola, metiendo y sacando la SD, el lector de SD del PC... Como el firm oficial no desmonta la SD y el samba no he conseguido que me funcione con este firm... (en serio, si Bennu funcionase definitivamente en el firm oficial, me cambio al 2.1.2, a menos que pille una de segunda mano casi regalada).
funciona en el firmware original, al menos a free le fue, así que cambia si quieres, asi podemos probar que a ti también te va. :D.
DCelso, vos tenes gp2x?
nou :(, tuve una en mis manos por poco tiempo pero se la llevó su dueño. :D
Lo que tengo es la psp, que me la regalaron los reyes :D, yo esperaba una caanoo, pero al final fue esta otra.
De ahí tanto empeño de sacar el port :D.
Hombre, yo te digo que a mi, el ejemplo de los botones de la consola me funciona (reconoce los 19 botones del joy), pero el Echo no va, se sale y no sé por qué.
Aun tengo que comprobar lo del DCB que se ha generado, lo del txt raro y alguna cosilla más, pero no me pidas demasiado porque no ando con demasiado tiempo para pruebas de este tipo (es 1 hora probar cada versión que me pasas).
juas, no me digas, yo tardo 15 min o menos en probar cada mia en la psp.
Cuando te acercas por málaga? :D.
Pues si no hay ningún problema, el lunes debería tirar para allá, para recoger un papelito, luego tengo todo el día libre.
Tenía pensado hacer una visitilla al centro, pero si quieres y andas por allí, podemos pasar la tarde haciendo pruebas, así me evito la tentación de gastar dinero comprando vicio ;D
por mi ok.
Es curioso, porque me pueden llamar friki pero yo no llego a tanto xDD
Yo esa tarde me la pasaria tomando cañas xDD
Hola. Drumpi avisó en el foro de gp32spain que hacían falta betatesters por estos lares. Tengo una gp2x-f200 con firmware oficial 4.1.1 y ganas de ayudar. También quería agradecer a DCelso por su trabajo :)
pues si puedes probar este port de bennugd para gp2x
http://www.mediafire.com/?d5375rdm5wd031l
lo agradecería.
Sería probar el juego, o test adjunto y ver que va bien con tu firmware y luego probar cualquier otro juego tuyo o de alguien que tengas su .prg y esté preparado para gp2x. Na mas :d.
Quote from: DCelso on January 16, 2011, 10:42:43 AM
pues si puedes probar este port de bennugd para gp2x
http://www.mediafire.com/?d5375rdm5wd031l
lo agradecería.
Sería probar el juego, o test adjunto y ver que va bien con tu firmware y luego probar cualquier otro juego tuyo o de alguien que tengas su .prg y esté preparado para gp2x. Na mas :d.
El test incluido compiló y se ejecutó sin problemas. Luego hice un programa extremadamente simple y tampoco hubo fallas. Por último intenté con el Echo de Drumpi (http://www.gp32spain.com/foros/attachment.php?attachmentid=22509&d=1295109154) que anunció en http://www.gp32spain.com/foros/showthread.php?t=80148&page=2 y dió un problema de compilación
bgdc_stdout.txt >> /tmp/mnt/sd/game/GP2XTest10/bgd-test/echo.prg:3: error: tmapa.h: file not found, found ";"
Soy extremadamente novato con Bennu y de .prg sólo suelo tener el código del ejemplo que esté estudiando en la guía de Oscar. ¿Me recomiendas alguno para realizar las pruebas?
ump, pues no se, cualquier ejemplo del tuto de osk vale, por ejemplo el laberinto, o el matamarcianos o el rpg o cualquier otro.
Pero lo que has hecho es una gran prueba porque has probado que funciona tanto el bgdc como el bgdi en otro firmware oficial.
Kloppix, ese error es raro, parece que no encuentra el fichero tmapa.h, y me consta que está incluido en el juego completo ¿no habrás intentado compilar sólo el PRG, sin los FPGs y demás? ;D
¿Y no funciona el DCB? Según Splinter, debería.
El error que daba antes era por una línea bastante más abajo, pero ya publiqué el parche para estas pruebas.
Quote from: FreeYourMind on January 15, 2011, 03:53:02 PM
Es curioso, porque me pueden llamar friki pero yo no llego a tanto xDD
Yo esa tarde me la pasaria tomando cañas xDD
Hombre, tu no se, a mi me entretiene programar, proyectar, y ya que estamos, pues aprovechamos para darle un empujoncillo al port y, si sobra tiempo, meterle mano a otra cosa que tenemos aparcada y que me muero de ganas por usar ;D
drumpi, te repito lo que te dije en el otro foro... ahora podes volver a compilar tu version gp2x, ya no usa mas openssl.
Quote from: Drumpi on January 16, 2011, 04:09:52 PM
Kloppix, ese error es raro, parece que no encuentra el fichero tmapa.h, y me consta que está incluido en el juego completo ¿no habrás intentado compilar sólo el PRG, sin los FPGs y demás? ;D
¿Y no funciona el DCB? Según Splinter, debería.
El error que daba antes era por una línea bastante más abajo, pero ya publiqué el parche para estas pruebas.
Quote from: FreeYourMind on January 15, 2011, 03:53:02 PM
Es curioso, porque me pueden llamar friki pero yo no llego a tanto xDD
Yo esa tarde me la pasaria tomando cañas xDD
Hombre, tu no se, a mi me entretiene programar, proyectar, y ya que estamos, pues aprovechamos para darle un empujoncillo al port y, si sobra tiempo, meterle mano a otra cosa que tenemos aparcada y que me muero de ganas por usar ;D
Que verguenza, si. El prg y todos los directorios y archivos adicionales no estaban en el mismo sitio. Tengo 2 teorías. Una es que algún vecino entró por la ventana, se metió en mi laptop y movió los archivos de sitio. La otra es que fui muy torpe y en vez de copiar todo al directorio "game>>echo" lo hice a "game" :-[
Ahora compila sin problemas...y de vuelta al menú. Además de echo_gp2x.gpe utilicé el lanzador de DCelso y obtuve esto en bgdi_stderr.txt (no se si servirá de algo)
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 @ 0x41a7f8 (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 0x40029800, 5085184
SDL_GP2X: Screen bucket 0x419dbc
SDL_GP2X: First free bucket 0x41a7f8 (size = 5085184)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x41aad0 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5084928 bytes @ 0x41aae8
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x40029800
SDL_SYS_JoystickInit
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=80000000
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x41a7f8 (size 256)
SDL_GP2X: Freeing bucket 0x41aae8 (size 5084928)
SDL_GP2X: InitHWSurfaces 0x40029800, 5085184
SDL_GP2X: Screen bucket 0x419dbc
SDL_GP2X: First free bucket 0x41aae8 (size = 5085184)
SDL_GP2X: Freeing cursor 0x41aad0
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x40029800 from bucket 0x41a7f8
SDL_GP2X: merging with next bucket (0x41aae8) making 5085440 bytes
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x41a7f8 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
pero funciona el juego?, osea aparece algo en la pantalla al ejecutar el script de ejecución?.
¿se crea el archivo .dcb?
Quote from: DCelso on January 16, 2011, 08:13:04 PM
pero funciona el juego?, osea aparece algo en la pantalla al ejecutar el script de ejecución?.
¿se crea el archivo .dcb?
El juego en la gp2x ni hace el intento en cargar, pero al parecer compila correctamente. Al correr el script que me pasaste se crea echo.dcb. Lo he borrado y vuelto a ejecutar y siempre pasa lo mismo. La pantalla se pone negra por unos 15 segundos y de vuelta al menú. Pero el .dcb se generó todas las veces.
Para probar el .dcb puse la SD en la laptop y al ejecutar "bgdi echo.dcb" funcionó el juego. De hecho cargué un juego salvado. Aunque se cuelga si se mueve el personaje.
Quote from: SplinterGU on January 16, 2011, 05:13:42 PM
drumpi, te repito lo que te dije en el otro foro... ahora podes volver a compilar tu version gp2x, ya no usa mas openssl.
Sí, lo tengo pendiente, pero llevo unos días que no me cunde el tiempo. De todas maneras, mañana a ver qué sale, el martes o el miércoles a ver si le doy un nuevo tiento.
Kloppix: Entonces te hace lo mismo que a mi, se tira unos cuatro o cinco segundos compilando con la pantalla en negro y luego se sale. Lo que no he probado ha sido el DCB generado.
Sería interesante saber en qué parte del juego te falla, porque dices al mover el personaje, pero el personaje comienza moviéndose (cayendo), así que no sé si es por el movimiento de gráficos, por pulsar alguna tecla, o con algún fallo en mi código a la hora de cambiar de tile o de mover la cámara.
Quote from: Drumpi on January 17, 2011, 12:27:40 AM
Quote from: SplinterGU on January 16, 2011, 05:13:42 PM
drumpi, te repito lo que te dije en el otro foro... ahora podes volver a compilar tu version gp2x, ya no usa mas openssl.
Sí, lo tengo pendiente, pero llevo unos días que no me cunde el tiempo. De todas maneras, mañana a ver qué sale, el martes o el miércoles a ver si le doy un nuevo tiento.
Kloppix: Entonces te hace lo mismo que a mi, se tira unos cuatro o cinco segundos compilando con la pantalla en negro y luego se sale. Lo que no he probado ha sido el DCB generado.
Sería interesante saber en qué parte del juego te falla, porque dices al mover el personaje, pero el personaje comienza moviéndose (cayendo), así que no sé si es por el movimiento de gráficos, por pulsar alguna tecla, o con algún fallo en mi código a la hora de cambiar de tile o de mover la cámara.
fantastico
Quote from: Drumpi on January 17, 2011, 12:27:40 AM
Kloppix: Entonces te hace lo mismo que a mi, se tira unos cuatro o cinco segundos compilando con la pantalla en negro y luego se sale. Lo que no he probado ha sido el DCB generado.
Sería interesante saber en qué parte del juego te falla, porque dices al mover el personaje, pero el personaje comienza moviéndose (cayendo), así que no sé si es por el movimiento de gráficos, por pulsar alguna tecla, o con algún fallo en mi código a la hora de cambiar de tile o de mover la cámara.
La prueba que describí antes era con un juego salvado de Episode 2. Me acabo de dar cuenta que el programa no se cuelga cuando echo se mueve, sino cuando pasa de cierto punto muy cercano a él, por lo que daba esa impresión. En Episode 1 la pantalla ni terminó de cargar. Te lo voy a redactar mejor:
Cuando se ejecuta en un PC (con linux por supuesto ) el dcb creado en la gp2x, el juego se cuelga en.....
Episode 1: Cargando la pantalla. La imagen se genera horizontalmente hasta mas o menos la "N" de "ENERGY" y de ahí no pasa.
Episode 2: Al pasar de cierto punto. Funciona cambiar armas, saltar, disparar, mirar arriba...todo. El problema viene al caminar hacia la derecha y pasar una línea vertical imaginaria que parte más o menos desde la esquina derecha del cuadrado de la segunda arma (si alguien entendió sin screenshot me voy a sorprender mucho)
Finalmente volví a borrar el .dcb de la tarjeta SD y compilé pero esta vez directamente con la PC. En la computadora no dio problemas de ningún tipo, pero en la gp2x no funcionó. Para ésta última prueba modifiqué el script para que no compile sino que corra directamente el dcb, pero posiblemente metí la pata. Es script es así:
#!/bin/sh
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../bgd-runtime
PATH=$PATH:../bgd-runtime
export LD_LIBRARY_PATH
export PATH
echo 2 > /proc/cpu/alignment
bgdi echo.dcb
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
pues eso debería de ir.
Hoy lo hemos estado mirando, efectivamente el DCB generado en el test 10 sólo muestra en el primer nivel las primeras 7 columnas de pixels más o menos, sin embargo con DCBs anteriores (en Linux todo esto) todo iba bien.
En fin, hemos hecho algunas pruebas, pero no hemos conseguido nada nuevo, sólo encontrar algunos bugs. A ver si mañana pruebo con mis toolchains.
Y no hay manera de echar a andar la versión de librerías dinámicas, el sistema operativo de la GP2X, usa por co..nes los libs del sistema, y le da igual que el mismo papa ponga lo que quiera en el LD_LIBRARY_PATH porque él buscará siempre primero en el sistema y luego en los directorios que pusiste en esa variable. Asi que la única forma de usar la versión de librerías dinámicas sería tener un custom firmware con las librerias de gcc 4 y libc incrustadas en el sistema :D.
Bueno, tengo última versión monolítica, que me gustaría que probáseis cuanto antes a ver si arregla la ejecución del echo :D.
http://www.mediafire.com/?8zidcdjjgv7i5ze
Quote from: DCelso on January 18, 2011, 03:29:49 AM
Y no hay manera de echar a andar la versión de librerías dinámicas, el sistema operativo de la GP2X, usa por co..nes los libs del sistema, y le da igual que el mismo papa ponga lo que quiera en el LD_LIBRARY_PATH porque él buscará siempre primero en el sistema y luego en los directorios que pusiste en esa variable. Asi que la única forma de usar la versión de librerías dinámicas sería tener un custom firmware con las librerias de gcc 4 y libc incrustadas en el sistema :D.
Bueno, tengo última versión monolítica, que me gustaría que probáseis cuanto antes a ver si arregla la ejecución del echo :D.
http://www.mediafire.com/?8zidcdjjgv7i5ze
conoces la variable LD_PRELOAD? quizas sirva para solucionar el problema de que busca otras dlls.
leete este articulo http://jjmora.es/sabias-que-la-variable-ld_preload/
cuando dijiste "el sistema operativo de la GP2X, usa por co..nes los libs del sistema, y le da igual que el mismo papa ponga lo que quiera en el LD_LIBRARY_PATH porque él buscará siempre primero en el sistema y luego en los directorios que pusiste en esa variable." me di cuenta de que hablabas y me acorde de la LD_PRELOAD.
perdon por no haberlo entendido antes y haberte hecho trabajar tanto, disculpas.
siempre perdonado :D, aún así ni idea de cómo aplicar eso en la GP2X para que tire de las libs de gcc4 y libc2.6 en ve de las del sistema de gcc2 y libcloquesea. :D.
Quote from: DCelso on January 18, 2011, 03:29:49 AM
Y no hay manera de echar a andar la versión de librerías dinámicas, el sistema operativo de la GP2X, usa por co..nes los libs del sistema, y le da igual que el mismo papa ponga lo que quiera en el LD_LIBRARY_PATH porque él buscará siempre primero en el sistema y luego en los directorios que pusiste en esa variable. Asi que la única forma de usar la versión de librerías dinámicas sería tener un custom firmware con las librerias de gcc 4 y libc incrustadas en el sistema :D.
Bueno, tengo última versión monolítica, que me gustaría que probáseis cuanto antes a ver si arregla la ejecución del echo :D.
http://www.mediafire.com/?8zidcdjjgv7i5ze
Acabo de probar la versión nueva pero ocurre lo mismo. En la gp2x sólo compila y al probar en la PC el dcb generado, sólo carga una pequeña franja de la imagen al comenzar el juego. :(
Quote from: DCelso on January 18, 2011, 03:49:13 AM
siempre perdonado :D, aún así ni idea de cómo aplicar eso en la GP2X para que tire de las libs de gcc4 y libc2.6 en ve de las del sistema de gcc2 y libcloquesea. :D.
es muy simple, asi como definis la LD_LIBRARY_PATH, definis una LD_PRELOAD=path_lo_que_sea/mylibc.so y con eso el sistema carga primero tu libc antes de cargar la libc del sistema operativo, lo que significa esto es que los simbolos (funciones) de tu libc tendran precedencia sobre las del sistema.
lo unico que tenes que tener en cuenta es que al terminar el script restaure el viejo valor de esta variable, que seguramente sera vacio.
tal que así?
#!/bin/sh
LD_LIBRARY_PATH_BAK=$LD_LIBRARY_PATH
PATH_BAK=$PATH
LD_PRELOAD_BAK=$LD_PRELOAD
LD_PRELOAD=../bgd-runtime:$LD_PRELOAD
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
LD_PRELOAD=$LD_PRELOAD_BAK
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
Adjunto test 16 con este proceso.
http://www.mediafire.com/?tqdd79v54qw9980
Quote from: DCelso on January 18, 2011, 03:47:17 PM
tal que así?
#!/bin/sh
LD_LIBRARY_PATH_BAK=$LD_LIBRARY_PATH
PATH_BAK=$PATH
LD_PRELOAD_BAK=$LD_PRELOAD
LD_PRELOAD=../bgd-runtime:$LD_PRELOAD
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
LD_PRELOAD=$LD_PRELOAD_BAK
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
Adjunto test 16 con este proceso.
http://www.mediafire.com/?tqdd79v54qw9980
DCelso, además de la 16 volví a probar las versiones 10 y 15.
Con la v10 los resultados fueron los mismos, pero con la v15 el dcb generado aunque no funcionó el la gp2x, lo hizo en la computadora perfectamente. No se por que en la mañana no lo hizo. Por cierto, traté de correr directamente sin compilar dicho dcb en la gp2x y no funcionó
Con la v16 ni siquiera compiló. Ni con el script nuevo, ni con el de siempre.
Quote from: DCelso on January 18, 2011, 03:47:17 PM
tal que así?
#!/bin/sh
LD_LIBRARY_PATH_BAK=$LD_LIBRARY_PATH
PATH_BAK=$PATH
LD_PRELOAD_BAK=$LD_PRELOAD
LD_PRELOAD=../bgd-runtime:$LD_PRELOAD
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
LD_PRELOAD=$LD_PRELOAD_BAK
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
Adjunto test 16 con este proceso.
http://www.mediafire.com/?tqdd79v54qw9980
nop, no es una ruta, es el pathname completo de la lib... path+nombre de lib.
puse
Quote
LD_PRELOAD=path_lo_que_sea/mylibc.so
Ottia, pues eso podría ser el final de las preocupaciones por usar la toolchain oficial o la del open2x, por lo que te comentaba de la libc.so, DCelso. Sería buscar las dependencias de la libc e ir incluyéndolas en esa variable (espero que no haya que cargar todo el sistema, o que no haya incompatibilidad por las versiones del compilador del SO y de estas librerías).
De todos modos, a lo que venía. Iba a pediros ayuda para la compilación, pero mientras terminaba de mirar los mensajes anteriores se me ha venido la inspiración y ya no hace falta (es curioso, las toolchains Open2X no me piden nada, pero las oficiales me exigen que compile la libdes de la carpeta 3rdparty antes que el core ???).
O sea, que sí, que me han compilado los fuentes de la r222 en ambas toolchains (que ya es mucho), pero aun no he realizado pruebas.
Así que, me toca probar las de XCelso y las mías :D A poco que funcionen como las anteriores ya será un logro, y si la LD_PRELOAD funciona como creo, podría usarse las del OPEN2X en el oficial e ir más rápido. XCelso ¿cual era el comando que te decía las dependencias de una .so?
También tengo que ver si puedo coger las librerías SDL aceleradas y sustituirlas en la toolchain oficial y hacer que vaya más rápido. Y tengo que pensar en crear un módulo para hacer overclock y acelerar la RAM de la GP2X (sería buena idea algo similar en WIZ, basada en el pollux_set, sé que, Splinter, no eres muy amigo de las librerías exclusivas para según qué plataformas, pero sería interesante poder hacer overclock o underclock a las negritas).
drumpi, en principio proba con solo poner la libc.so, y referenciarla en el LD_PRELOAD.
Has entendido bien, el LD_PRELOAD permite tener una libreria que sobreescriba a la libreria del sistema (libc.so), con esto, las funciones que tengas definidas en tu lib cargada previamente por LD_PRELOAD, reemplazaran a las que estan en la libc original.
el comando es ldd, pero tenes que usar el del toolchains
otra cosa, yo no soy enemigo de las dlls exclusivas, solo que no pueden ser parte de un port oficial si no hay compatibilidad en las otras plataformas o si no tienen una forma de indicar que no estan disponibles para tal o cual plataforma.
#!/bin/sh
LD_LIBRARY_PATH_BAK=$LD_LIBRARY_PATH
PATH_BAK=$PATH
LD_PRELOAD_BAK=$LD_PRELOAD
LD_PRELOAD=../bgd-runtime/libc.so.6
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
LD_PRELOAD=$LD_PRELOAD_BAK
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
Así?, Drumpi prueba el último test con este script.
A ti no te hace falta el LD_PRELOAD, a ti te coje las librerías de dentro del ejecutable. A mi sí, porque no me carga la libc... y si la pongo en la misma carpeta, no me carga otra (no me acuerdo cual) aunque la ponga al lado (lo que te comentaba, que me la busca en el sistema porque... ¿está compilada así? ni idea).
Mañana lo miro, que ya es hora de cenar. Ahora tengo que probar 4 versiones ^^U
Drumpi, mi test 16, es ese que probamos en mi casa que daba problemas de librerías, uno que compilé de forma dinámica. Lo que he hecho de más es insertar el juego nim como test e intentar hacer lo que dice Splinter para sobrescribir la librería del sistema libc.
Pues comento:
El test15 sigue igual, hace el amago de arrancar pero se sale:
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 @ 0x417208 (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 0x40035800, 5085184
SDL_GP2X: Screen bucket 0x4167ec
SDL_GP2X: First free bucket 0x417208 (size = 5085184)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x4174e0 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5084928 bytes @ 0x4174f8
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x40035800
SDL_SYS_JoystickInit
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=80000000
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x417208 (size 256)
SDL_GP2X: Freeing bucket 0x4174f8 (size 5084928)
SDL_GP2X: InitHWSurfaces 0x40035800, 5085184
SDL_GP2X: Screen bucket 0x4167ec
SDL_GP2X: First free bucket 0x4174f8 (size = 5085184)
SDL_GP2X: Freeing cursor 0x4174e0
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x40035800 from bucket 0x417208
SDL_GP2X: merging with next bucket (0x4174f8) making 5085440 bytes
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x417208 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
Y el segmentation fault.
El test 16 es más raro: a mano (con los comandos por telnet) me da error al compilar y el GBDI se queja de versión del DCB incompatible.
Así que fui al método tradicional de ejecutar el .gpe (en serio, no sé qué pasa en mi PC que nunca sé cuando está usando el firm oficial y cuando el open2x). El mismo error en BGDC y BGDI:
bgdc: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
Y que conste que sí existe.
Probé a quitar la línea LD_PRELOAD (que por cierto, está mal escrita, pues referencia a una carpeta, no a un fichero) y obtuve dos errores distintos:
bgdc: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
bgdi: error while loading shared libraries: libbgdrtm.so: cannot open shared object file: No such file or directory
Pero lo dicho, no haría demasiado caso a estas pruebas por el tema del firm.
Quote from: Drumpi on January 19, 2011, 11:38:12 PM
Pues comento:
El test15 sigue igual, hace el amago de arrancar pero se sale:
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 @ 0x417208 (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 0x40035800, 5085184
SDL_GP2X: Screen bucket 0x4167ec
SDL_GP2X: First free bucket 0x417208 (size = 5085184)
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x4174e0 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5084928 bytes @ 0x4174f8
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x40035800
SDL_SYS_JoystickInit
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=80000000
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x417208 (size 256)
SDL_GP2X: Freeing bucket 0x4174f8 (size 5084928)
SDL_GP2X: InitHWSurfaces 0x40035800, 5085184
SDL_GP2X: Screen bucket 0x4167ec
SDL_GP2X: First free bucket 0x4174f8 (size = 5085184)
SDL_GP2X: Freeing cursor 0x4174e0
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x40035800 from bucket 0x417208
SDL_GP2X: merging with next bucket (0x4174f8) making 5085440 bytes
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x417208 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
Y el segmentation fault.
El test 16 es más raro: a mano (con los comandos por telnet) me da error al compilar y el GBDI se queja de versión del DCB incompatible.
Así que fui al método tradicional de ejecutar el .gpe (en serio, no sé qué pasa en mi PC que nunca sé cuando está usando el firm oficial y cuando el open2x). El mismo error en BGDC y BGDI:
bgdc: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
Y que conste que sí existe.
Probé a quitar la línea LD_PRELOAD (que por cierto, está mal escrita, pues referencia a una carpeta, no a un fichero) y obtuve dos errores distintos:
bgdc: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
bgdi: error while loading shared libraries: libbgdrtm.so: cannot open shared object file: No such file or directory
Pero lo dicho, no haría demasiado caso a estas pruebas por el tema del firm.
estas pruebas las hiciste con la version dinamica?
el preload debe referenciar al archivo libc.so especial, y el ld_library_path debe seguir estando.
Sí, esta última versión es dinámica, y sí, he entendido el concepto de LD_PRELOAD: es una variable que indica que debe cargarse esas librerías antes de ejecutar, de forma que, cuando el programa necesite la del sistema, vea que ya está "cargada", aunque no sea la del sistema. Digamos que se le miente.
por que hay 2 hilos hablando de lo mismo?
Quote from: SplinterGU on January 20, 2011, 10:48:26 PM
por que hay 2 hilos hablando de lo mismo?
Quote from: Drumpi on January 18, 2011, 08:07:31 PM
Bueno, para no apropiarme del hilo de XCelso, sigo con mi versión por aquí.
Ni mucho menos trato de hacerle la competencia, simplemente sigo lo que empecé hace tiempo por mi línea (llena de fallos, errores, incertidumbre...).
Pues eso, que son dos versiones distintas, con dos métodos de trabajo totalmente distintos y con un nivel de conocimientos radicalmente distintos ;D
XCelso sabe del tema, yo me muevo por intuición. Él está más cerca que yo de sacar una versión estable y rápida, yo tengo una muy buena versión con limitaciones de soft.
probad esto, pliss:
test17
compilado con la última versión de svn, que engancha con libdes.
no es monolítica.
modificado el script para que enganche con todas las libs de gcc4 que pide bgd,
Si esto no funciona, que dios nos coja confesaos :D.
http://www.mediafire.com/?e3a3og1u2gq3vmj
no entiendo... como que no es monolitica?
Por la misma razón por la que Bennu dividió Fenix en módulos :D
Hombre, yo se lo dije a XCelso, que una versión en módulos es mejor, porque así se le puede añadir módulos no oficiales y demás. Pero vamos, es mi opinión. Sus razones no las conozco ^^U
Quote from: DCelso on January 21, 2011, 03:03:59 AM
probad esto, pliss:
test17
compilado con la última versión de svn, que engancha con libdes.
no es monolítica.
modificado el script para que enganche con todas las libs de gcc4 que pide bgd,
Si esto no funciona, que dios nos coja confesaos :D.
http://www.mediafire.com/?e3a3og1u2gq3vmj
En lo que ejecuté el script (bgd-nim.gpe) la consola me devolvió al menú. Lo volví a ejecutar con un emulador de terminal para ver la salida y me encontré con esto:
basename: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libc.so.6)
basename: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libdl.so.2)
basename: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libpthread.so.0)
sync: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libc.so.6)
sync: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libdl.so.2)
sync: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ../bgd-runtime/libpthread.so.0)
Por curiosidad traté de ejecutar el .dcb diréctamente. No funcionó en la gp2x aunque si en la PC.
es dificil resolver al asunto asi, y seguro es una tremenda pavada.
La ultima no funciona, se sale automaticamente, aunque es raro, porque en 2 juegos se quedo la pantalla en negro, no salia ni avanzaba...
Tu ejemplo tambien se sale al menu, y no ha generado ningun log, he mirado tu gpe y si los ponias, con lo cual me imagino que el bgdc ni funciona...
Nuevo test. bennugp2xtest17
http://www.mediafire.com/?dscweumxabzxnk8
Una vez mas nos dejas a ciegas, como no digas lo que intentas cambiar en cada una, poco va servir las pocas ganas que me sobran para hacer pruebas xDDD
Lo veo todo igual, el deadly eye funciona igual, o eso parece, los videos flc siguen sin funcionar (se sale al menu)...
pues son tests, no estoy mejorando nada, como comenté en el port de psp, simplemente recompilo, quito warnings, cambio cosillas no importantes, etc, pero vamos en este caso el port debería ser idéntico al de wiz o caanoo o linux, solo que monolítico (no tuve que castrar nada de nada), osea que eso de que no funcionen los flc es extrañísimo. ¿Te van en wiz o caanoo?
Pues claro que me va en Wiz y Caanoo, pero creo que el tema del flc puede ser tb por falta de memoria, de todos modos mis juegos antiguos ya no van con tu runtime, seguramente sea porque ya no son compatibles con los ultimos bennu, tampoco me he puesto a recompilar, sólo he probado con las releases que tengo en mi pagina.
Yo lo siento, pero es que estoy hasta arriba de trabajo: me he propuesto aprender java en menos de un mes, y tengo que hacer 52 temas, y voy a casi dos por día... y luego me espera ASP.NET.
Mañana y pasado voy a estar ocupado, pero como siempre, intentaré hacer el esfuerzo, aunque sólo sirva a medias.
Sigues con esto DCElso ? Que era lo que estaba pendiente en el port ? La velocidad ?
Me han pedido portar el Skull a la Gp2x, tendré que ver como va y que falta.
pues no sigo con esto, lo tengo parado, aunque como lo llevo a la par del port de PSP no se si tengo subida la última versión recompilada de mi código de bennu para gp2x.
En cuanto pueda te recompilo lo último que tengo, pruebas tu .dcb de skull en la GP2X y me vas diciendo errores que veas para ir corrigiéndolos.
Por cierto, SplinterGU. Tengo dudas en una cosa, yo actualmente estoy he puesto ifs e ifdefs para GP2X en los mismos sitios que haces para GP2X_WIZ, ya que, al parecer a Drumpi le va bien la recompilación de bennu en el skd e GP2X usando los makefiles de bennu para WIZ, me puedes confirmar tu o alguno, por ejemplo si ¿la forma de usar los temporizadores (que tiene interna el código de benhu)en wiz es compatible con gp2x? lo digo para eliminar el condicional en gp2x y usar los sdl_timers o dejarlo como lo hace ahora para wiz.
yo no creo que sea compatibles.
El os_id que identifica la plataforma esta funcionando bien ?
Recuerda que ya venia definido de Fenix para la Gp2x, me gustaria saber si hay separacion para la F200 (deberia existir porque esta tiene touchscreen, necesario para Skull).
El port de Drumpi fallaba en esto.
ese os_id se setea a mano por codigo, no hay un codigo magico que lo detecte y asigne, si el port no lo tiene definido, entonces no funcionara.
No me digas que es al compilar que se asigna !? Y yo pensando que lo iba ya aprovechar para leer el id del procesador ;D
Entonces lo tenemos mal para separar la version de Gp2x de Gp2x F200, ya que es el mismo procesador...
Alguna sugerencia ? Detectando el mouse talvez ?
me entendiste todo al reves o no te explicaste bien...
no se detecta el cpu, alguien en el codigo C pone... un define que indica que la version compilada es tal o cual, y en base a ese define se setea el OS_ID.
ok, splinter, entonces me salto lo que haces en los timers referente a wiz y caanoo para gp2x.
En cuanto a lo del touch screen, pues no se, ¿no se mapea automáticamente con el mouse?
Siento no haberme puesto con esto, en serio, pero java me tiene abducido (hace ya un mes que no toco Bennu, con eso lo digo todo).
XCelso, puedes usar, en principio, todo lo que hace WIZ, salvo los timers, ya dije que mi port hace uso de los timers de WIZ, y hasta que splinter no le metió mano a "personalizarlos" para WIZ, iba de miedo. Métele los timers tal y como iban en PC.
Free: no existe OS_ID para GP2X, nunca ha existido, y de existir sería el mismo para F100 y F200 porque SON LA MISMA CONSOLA. Sólo cambia, a nivel de usuario, que F200 tiene pantalla táctil, que se mapea, según SDL, como un ratón y su clic izquierdo, y F100 tiene un joy de 9 botones que sí puede tener pulsados 2 a la vez (F200 tiene 8, pero los de las diagonales sólo se activan pulsando dos botones a la vez, pues son 4 botones físicos; F100 si tiene 8 botones físicos).
La prueba la tienes en que Fenix es el mismo para ambas consolas y funcionan exactamente igual.
ahora la culpa la tengo yo... que facil, no? no sera la culpa de quien no hizo las cosas bien y uso un setting de wiz o caanoo, donde no deberia usarlo?
:D :D :D No lo sé, alguien compiló una r143 que iba bien de velocidad, pero el port de la r222 va acelerado usando el mismo método, así que... ;D
[modo cachondeo off]
Nah, la solución es fácil, pero hay que ponerse ^^U Parece que estoy vago últimamente, pero es lo que tiene cuando presiones externas te obligan a auto-esclavizarte. Mañana, como penitencia, 4 horas de programación en Bennu :D :D :D
Han desaparecido la mayoria de los ficheros mediafire así como DCElso :(
Yo debería tener aun unos cuantos por ahí, pero no sé si DCelso sabrá cómo compiló cada una de las versiones.
También es verdad que no aparece por aquí el susodicho, debe estar de curro hasta el techo, o peor, de vacaciones :D
vale, voy a dar porcu, donde se pone la carpeta de la r222 para poder probarlo en la f100?????
Te tengo que cojer por las orejas xD
No has mirao la distro para Gp2x de tu Panta ?
nop, no se ni siquiera lo que es una distro...
weno, recarguemos a ver como furula, que lo que quiero hacer andar es el echo
pero vamos que me vi comprar una chanoo tamien, je je
<->
edito:
pos no se vé jefe, lo acabo de probar con mi v3.0.0 original de fabrica y no furula
la f-100 ?
Pon la distro (distribucioón de tu juego) a ver
aqui tienes, solo te mando el bdgd rutine
Para que quiero yo el runtime xDD
bueno, pues aqui tienes la otra carpeta...
total si me la has enviado te la reenvio a ver su cuando me la ree reenvies venga bien, ja jaj aj
menos mal que no es una cita de cassette, sino de grabar tantas veces perderia calidad, je je
A ver, eso poco ayuda, porque realmente no puedo probar a simular tu error, me tienes que enviar todo en un rar tal como lo copias a tu consola para que no te funcione y de paso lo copio tal cual a la mia y veo si tira.
Mi distro para Gp2x te funciona en la tuya o no ?
EDIT: Ten en cuanta que mi distro es para el firmware oficial no para el opengp2x ese...
tu distro oficial descomprimido (que es lo que te he puesto en estos dos adjuntos) no me funciona en mi gp2x f100 con el firmware oficial v3.0.0
pasame o enlazame a otro juego distinto por si no funciona en la mia
Que Gp22x tienes, la F-200 ?
Has probao el tixchos ?
En mi pagina tienes las distros.
EDIT: perdon, veo que tienes la F-100, la negra sin multitouch, a ver si arranca el chichos por lo menos porque no vas a poder jugar.
Acabo de probar en las mias el panta y el txichos:
F-200 firmware ver. 4.0: Funcionan los 2
F-100 firmware ver. 1.2.1: Funcionan los 2, jolin, pero la musica no suena (solo los efectos).
vale, probaré con el txishos a ver si por lo menos arranca...
por si acaso explicame como los tengo que poner en las carpetas, por si acaso hay que poner una ruta o algo asi...
<->
vale, me ha dao por esperar y al final arranca, pero no furula en progresive mode ni en modo historia, se me cuelga y pasa a la pantalla inicial...
hay que esperar una eternidad, asi que pasaré al firmware 2.6.1 o como se llame...
El problema es de las SDL, pero por lo menos esta version solo es lenta al principio, con lo cual Drumpi ha hecho un buen trabajo ;)
Por otra parte, es un calvario saber en que firmwares funciona.
A ver, no os lieis: hay sólo dos versiones, y la que hay que usar es la que denomino "oficial", ya que la "open2X" sólo funciona a los que usan el firm alternativo. La oficial vale para la F100 y F200 con cualquier firm 2.x, 3.x y 4.x.
Los que lo hayais probado con Echo, SBTime o King of Fighters: FoC, os aviso que tarda bastante en compilar (¿30 segundos?) por la cantidad de código que llevan, pero eso lo haceis una vez, luego os creais otro .GPE y quitais la línea del BGDC, usais sólo el BGDI y os arrancará en 3 segundos.
Aseguraos de usar la última versión que está en.. en...
http://forum.bennugd.org/index.php?topic=2383.0
Que aun están en fase de test (si funcionan, compilaré la última versión, prefiero tener una funcional que varias de su padre y su madre). Yo, de momento, no he tenido pegas, y un rendimiento aceptable (teniendo en cuenta las limitaciones de la máquina).
Si hubiera alguna forma de compilarlas usando las librerías optimizadas de open2x (como las SDL) lo haría, el aumento del rendimiento se nota (Echo va al 80% respecto a WIZ en open2X). Al menos es más rápido que el port de Fenix.
Quote from: Drumpi on August 04, 2011, 06:15:43 PMos aviso que tarda bastante en compilar (¿30 segundos?) por la cantidad de código que llevan, pero eso lo haceis una vez, luego os creais otro .GPE y quitais la línea del BGDC, usais sólo el BGDI y os arrancará en 3 segundos.
yo ya me he rayao con eso, a ver que es lo que saco en claro, je jeje
A ver, Futu: cuando haces un juego, primero lo compilas con BGDC, y luego lo ejecutas con BGDI ¿no?
Pues el GPE lo que hace es llamar a ambos: primero lo compila y luego lo ejecuta. Pero si ya lo tienes compilado, ya has hecho el DCB ¿para qué volverlo a compilar? usas el BGDI directamente y listo, no necesitas llamar a BGDC y crear el DCB nuevamente (salvo que cambies el runtime).
Drumpi, te lo repito de nuevo, aunque compilado y solo ejecutado, en el port es algo lento al entrar, pero despues ya no. Tu port anterior era lento al cargar y tambien era mas lento en su ejecucion.
Ah, vale, pero si hay alguna mejora de velocidad, eso se lo debeis a Splinter, yo sólo me he remitido a recompilar código, cambiando el target (que ya era hora).
El día que sepa cómo meterle las librerías de Open2X al firm oficial, lo vais a flipar (es una de las razones por las que aun no he instalado la 2.1.2, que me está haciendo falta para el wifi y demás).