¿Quien tiene una PSP con el homebrew activado?
http://www.mediafire.com/?dd8h8r4wjaf87aa (http://www.mediafire.com/?dd8h8r4wjaf87aa)
Yo, como siempre lo tengo todo ;D
Ahora te cuento, eres una maquina, que toolkit has utilizado ?
Funciona!!!!!!!!!!!
Esta completo ?
Voy a probar con otro dcb...
Karma, estas que ardes xDDDD
Falla, me imagino por la resolución, mas detalles de todo el proceso porfa ;D
Esto sale en el log:
Unsupported module: mod_video.so
¿Es esta versión una completa?. ¿Qué módulos has metido?.
Daniel (el que está intentando hacer el port a partir de mi versión para Wii) está teniendo muchos problemas de memoria al inicializar los módulos gráficos.
Le pido perdon a josebita, porque es la primera vez que pruebo una version de Bennu en PSP :D
Quote from: FreeYourMind on January 12, 2011, 12:31:27 AM
Le pido perdon a josebita, porque es la primera vez que pruebo una version de Bennu en PSP :D
:)
No hace falta, si funciona bien, mejor para todos. Aún así, me interesa saber si el port es completo por avisar a Daniel que lleva mucho tiempo intentando debuggear el problema de memoria que está teniendo y qué está haciendo DCelso para evitarlo. El módulo md_say ya lo tiene funcionando hace tiempo.
Por el tamaño del paquete y el error que da con el mod_video, parece que no se están compilando los módulos que a Daniel le dan problemas...
También te agradecería, DCelso, detalles sobre cómo lo has hecho: SDK, versión de SDL....
XCelso está que se sale, ha cogido carrerilla y no veas :D :D :D
Sólo por eso, karma (y el día que funcione la versión de GP2X sin problemas, week karma attack!! ;D)
aro, ta to incompleta esa versio :D, si te das cuenta solo compilé los módulos que necesitaba mi juego :D.
Enga, vaaa, os pongo la versión completa:
http://www.mediafire.com/?tun21xrur8x9yl8
En cuanto a qué hice, pues nada, bajéla versión del svn del pspkit, la instalé con los scrips que había (que por cierto tienen más de un error que he tenido que ir corrigiendo) luego con mi makefile monolítico de gp2x creé uno para psp y casi todo ha ido de perlas. He tenido que hacer unos cuantos retoque al código oficial de Splinter, como insertar los callbacks de psp para que puedas salir con HOME, y poco más, he eliminado (mas bien esquivando con ifndef TARGET_PSP) cosas que no se pueden hacer en psp como los dir_open,dir_read,etc, execvp, etc, luego he tenido que enganchar con la versión openssl del pspkit que es una mas antigüilla que la que usa splinter pero que va sin tocar nada. y poco más, bueno, millones de pruebas fallidas decepcionantes (tiré la toalla un par de asaltos) debido a que con la psp es un kaos el depurar una aplicación.
Entonces, ¿funcionan las rutinas gráficas?. Es lo que le daban problemas a Daniel.
¿Podrías poner el enlace a la web del SDK? Es que me da la impresión que no es el mismo que está usando él, o al menos la misma versión porque todo lo que comentas lo ha hecho él y le va a dar un poco por saco si todo lo que ha estado teniendo era un bug del SDK, porque de verdad que el tío le ha dado vueltas...
umn, mejor que eso, que tal un "history"?
mkdir ~/tmp/pspjim_src
cd ~/tmp/pspjim_src
svn co svn://psp.jim.sh/svn/psp/trunk .
sudo apt-get install build-essential autoconf automake bison flex \
libncurses5-dev libreadline-dev libusb-dev texinfo libgmp3-dev \
libmpfr-dev
export PSPDEV="/SDKs/pspdev"
export PSPSDK="$PSPDEV/psp/sdk"
export PATH="$PATH:$PSPDEV/bin:$PSPSDK/bin"
mkdir $PSPDEV
mkdir ~/tmp/pspjim_src/psptoolchain/build
cd ~/tmp/pspjim_src/psptoolchain/build
ln -s ../../pspsdk pspsdk
ln -s ../../psplinkusb psplinkusb
cd ..
./toolchain.sh
cd ~/tmp/pspjim_src/psplibraries
mkdir build
cd build
ln -s ../../bzip2/ .
ln -s ../../SDL_gfx/ .
ln -s ../../pspirkeyb/ .
ln -s ../../jpeg/ .
ln -s ../../pspgl/ .
ln -s ../../SDL_mixer/ .
ln -s ../../libmad/ .
ln -s ../../libvorbis/ .
ln -s ../../libogg/ .
ln -s ../../zlib/ .
ln -s ../../lua/ .
ln -s ../../freetype/ .
ln -s ../../libpng/ .
ln -s ../../zziplib/ .
ln -s ../../SDL_ttf/ .
ln -s ../../libTremor/ .
ln -s ../../libbulletml/ .
ln -s ../../SDL/ .
ln -s ../../SDL_image/ .
ln -s ../../libpspvram/ .
ln -s ../../sqlite/ .
ln -s ../../libmikmod/ .
./psplibraries/libraries-sudo.sh
cd ~/tmp/pspjim_src/openssl
gunzip < openssl-0.9.7j.tar.gz | tar xv
cd openssl-0.9.7j
patch -p1 < ../openssl-0.9.7j.patch
./Configure psp --prefix=$(psp-config --psp-prefix) threads zlib no-shared no-asm
make
make install
Gracias, con eso que dices yo diría que lo que le pasaba a daniel era que tenía un bug en su glibc... Qué putadón
Quote from: DCelso on January 12, 2011, 01:44:49 AM
aro, ta to incompleta esa versio :D, si te das cuenta solo compilé los módulos que necesitaba mi juego :D.
Enga, vaaa, os pongo la versión completa:
http://www.mediafire.com/?tun21xrur8x9yl8
En cuanto a qué hice, pues nada, bajéla versión del svn del pspkit, la instalé con los scrips que había (que por cierto tienen más de un error que he tenido que ir corrigiendo) luego con mi makefile monolítico de gp2x creé uno para psp y casi todo ha ido de perlas. He tenido que hacer unos cuantos retoque al código oficial de Splinter, como insertar los callbacks de psp para que puedas salir con HOME, y poco más, he eliminado (mas bien esquivando con ifndef TARGET_PSP) cosas que no se pueden hacer en psp como los dir_open,dir_read,etc, execvp, etc, luego he tenido que enganchar con la versión openssl del pspkit que es una mas antigüilla que la que usa splinter pero que va sin tocar nada. y poco más, bueno, millones de pruebas fallidas decepcionantes (tiré la toalla un par de asaltos) debido a que con la psp es un kaos el depurar una aplicación.
fantastico DCelso, estas hecho un maquina, muchas gracias.
con respecto a la openssl, fijate el codigo nuevo y la libdes incluida en el svn, esa version te sera mas simple para hacer los ports, ademas de consumir menos memoria.
¡KARMA!
(Vou falar em portugues do Brasil, se voces nao entenderem, eu peco para alguem traduzir para espanhol).
Bom saber que alguem conseguiu fazer um port funcional para o PSP. Estou no trabalho agora mas assim que chegar em casa eu vou olhar o port. Gostaria de ver como voce conseguiu vencer os problemas que eu tive. Uma coisa que notei é que voce usa o SDK direto do SVN e o compila manualmente. Como eu programo no Windows, eu uso o pacote disponibilizado para ele o que, talvez, seja um problema já que a sua pode ter algumas correcoes e bugfixes.
Tambem estou interessado em ver o seu patch monolithic. O Josebita tambem desenvolveu um e eu o usei para o port do PSP por que usar dynamic linking no PSP parece causar muitos problemas que eu nao fui capaz de resolver quando comecei o port.
Obrigado e até mais.
Obrigado, eu tambem falo portugues, mas o original ;D.
Quote from: DCelso on January 12, 2011, 01:44:49 AM
aro, ta to incompleta esa versio :D, si te das cuenta solo compilé los módulos que necesitaba mi juego :D.
Enga, vaaa, os pongo la versión completa:
http://www.mediafire.com/?tun21xrur8x9yl8
En cuanto a qué hice, pues nada, bajéla versión del svn del pspkit, la instalé con los scrips que había (que por cierto tienen más de un error que he tenido que ir corrigiendo) luego con mi makefile monolítico de gp2x creé uno para psp y casi todo ha ido de perlas. He tenido que hacer unos cuantos retoque al código oficial de Splinter, como insertar los callbacks de psp para que puedas salir con HOME, y poco más, he eliminado (mas bien esquivando con ifndef TARGET_PSP) cosas que no se pueden hacer en psp como los dir_open,dir_read,etc, execvp, etc, luego he tenido que enganchar con la versión openssl del pspkit que es una mas antigüilla que la que usa splinter pero que va sin tocar nada. y poco más, bueno, millones de pruebas fallidas decepcionantes (tiré la toalla un par de asaltos) debido a que con la psp es un kaos el depurar una aplicación.
Pero entonces ya llevas tiempo con esto ?
Todo en secreto heheheheh, a ver si al final nos lo explicas y pones todo a los newies para que podamos compilar tambien.
Ele fez o que eu tentei fazer mas com mais competencia do que eu. Debugar uma aplicacao no PSP é realmente dificil pela falta de documentacao e debuggers apropriados. Eu tenho usado o psp-link que é bastante rudimentar.
Nesse caso, eu tenho que ir compilando o codigo e vendo onde estao os erros manualmente e implementando pequenos fixes. As vezes, um ifdef resolve. Outras nao. E como DCelso já disse, o PSP nao tem muitas das rotinas que o BennuGD usa (eg: exec e suas variantes).
alguien que traduzca please.
Esto es lo que escribió antes.
(Hablo portugués en Brasil, que no entienden, te ruego que alguien le traduzca para el español).
Es bueno saber que alguien podría hacer un puerto funcional para la PSP. Estoy en el trabajo ahora, pero tan pronto como llegue a casa voy a mirar en el puerto. Me gustaría ver cómo se las arregló para superar los problemas que tenía. Una cosa que noté es que utilice el SDK directamente desde el SVN y compilarlo manualmente. ¿Cómo se programa en Windows, yo uso el paquete que se le asigna que tal vez es un problema ya que su puede tener algunas correcciones y correcciones de errores.
También estoy interesado en ver el parche monolítico. El Josebita también desarrolló una y yo el puerto para la PSP que utilicen la vinculación dinámica en la PSP parece causar muchos problemas que no he sido capaz de resolver cuando empecé el puerto.
Gracias y mucho más.
Quote from: danielt3 on January 12, 2011, 01:01:54 PM
Ele fez o que eu tentei fazer mas com mais competencia do que eu. Debugar uma aplicacao no PSP é realmente dificil pela falta de documentacao e debuggers apropriados. Eu tenho usado o psp-link que é bastante rudimentar.
Nesse caso, eu tenho que ir compilando o codigo e vendo onde estao os erros manualmente e implementando pequenos fixes. As vezes, um ifdef resolve. Outras nao. E como DCelso já disse, o PSP nao tem muitas das rotinas que o BennuGD usa (eg: exec e suas variantes).
Él hizo lo que traté de hacer, pero con más posibilidades que yo. Depurar una aplicación en la PSP es muy difícil por la falta de la debida documentación y depuradores. He utilizado la PSP-link que es muy rudimentario.
En este caso, tengo que ir a compilar el código y ver dónde están los errores y manual de aplicación de pequeñas correcciones. A veces, un ifdef resuelve. Otros no lo hacen. Y DCelso como he dicho, la PSP no tiene muchas de las rutinas que utiliza BennuGD (por ejemplo: exec y sus variantes).
////////////////7
Traducción con el imtranlator. Espero que alguien me diga que es correcta XD. Lo de Homebrew activado no se que es, podría probar yo?
Yo no veo lo de homebrew activado en su texto...
Es lo mismo que en español, significa tener la psp modificada soportando homebrew...
Por cierto DCElso, donde sacaste el src del kit de psp ?, en el sourceforge del proyecto no hay ningun fichero ni en el CVS...
Yo lo probaría, pero no se cómo se activa el homebrew xD
WOW! :O
Aunque me parece delictivo que lo hicieses tan a escondidas xD
Una pregunta más, ¿entonces tenemos un port extra o se integrará con el BennuGD monolítico?
Yo tengo pensado integrar los cambios en mi rama monolítica, porque parece que es más limpia que la mía y usarlo como base para mi port a Wii. No me cuesta nada integrar los cambios para PSP también.
Pero eso sí, con tiempo, que no tengo ahora y además querría hacer pruebas en la Wii y en iOS, y que contarais qué tal va en la PSP.
Quote from: DCelso on January 12, 2011, 12:01:56 AM
¿Quien tiene una PSP con el homebrew activado?
http://www.mediafire.com/?dd8h8r4wjaf87aa
Era ahí ;D
pues, no se, yo le pasaré a Splinter el .patch pronto y que decida él, estaría guapo sí, porque serviría para un port oficial de psp, wii y gp2x del tirón.
Por lo que he estado viendo, quizás en psp haya posibilidad de hacerlo dinámico, tengo que investigar un poco más, pero desde un .pbp (que es la entrada a ejecución de un programa desde homebrew) se pueden cargar .prx, pero no con el típico libdl sino con unas funciones propias to complejas, pero creo que sirve para ejecutar aplicaciones nada mas, no para cargar funciones, no se, estoy pez en ese sentido.
Quote from: PiXeL on January 12, 2011, 02:45:34 PM
WOW! :O
Aunque me parece delictivo que lo hicieses tan a escondidas xD
Una pregunta más, ¿entonces tenemos un port extra o se integrará con el BennuGD monolítico?
:D, a escondidas dice, pues no tenía que haberos pillado de sorpresas ya lo avisé en el post de Bennu GP2X que estaba cerca, no leeis atentamente los posts eh. :D.
hehehhe.
Una duda, que resolucion tenia PSP ? Poniendo una menor, no habria problema para probar los viejos compilados ?
Otra cosa, como se compilaria en PSP y como se haria el script de iniciar el juego, ya que este no existe, para cambiar por ejemplo la thumb y texto del menu de PSP ?
Quote from: laghengar on January 12, 2011, 01:49:01 PM
Esto es lo que escribió antes.
(Hablo portugués en Brasil, que no entienden, te ruego que alguien le traduzca para el español).
Es bueno saber que alguien podría hacer un puerto funcional para la PSP. Estoy en el trabajo ahora, pero tan pronto como llegue a casa voy a mirar en el puerto. Me gustaría ver cómo se las arregló para superar los problemas que tenía. Una cosa que noté es que utilice el SDK directamente desde el SVN y compilarlo manualmente. ¿Cómo se programa en Windows, yo uso el paquete que se le asigna que tal vez es un problema ya que su puede tener algunas correcciones y correcciones de errores.
También estoy interesado en ver el parche monolítico. El Josebita también desarrolló una y yo el puerto para la PSP que utilicen la vinculación dinámica en la PSP parece causar muchos problemas que no he sido capaz de resolver cuando empecé el puerto.
Gracias y mucho más.
Quote from: danielt3 on January 12, 2011, 01:01:54 PM
Ele fez o que eu tentei fazer mas com mais competencia do que eu. Debugar uma aplicacao no PSP é realmente dificil pela falta de documentacao e debuggers apropriados. Eu tenho usado o psp-link que é bastante rudimentar.
Nesse caso, eu tenho que ir compilando o codigo e vendo onde estao os erros manualmente e implementando pequenos fixes. As vezes, um ifdef resolve. Outras nao. E como DCelso já disse, o PSP nao tem muitas das rotinas que o BennuGD usa (eg: exec e suas variantes).
Él hizo lo que traté de hacer, pero con más posibilidades que yo. Depurar una aplicación en la PSP es muy difícil por la falta de la debida documentación y depuradores. He utilizado la PSP-link que es muy rudimentario.
En este caso, tengo que ir a compilar el código y ver dónde están los errores y manual de aplicación de pequeñas correcciones. A veces, un ifdef resuelve. Otros no lo hacen. Y DCelso como he dicho, la PSP no tiene muchas de las rutinas que utiliza BennuGD (por ejemplo: exec y sus variantes).
////////////////7
Traducción con el imtranlator. Espero que alguien me diga que es correcta XD. Lo de Homebrew activado no se que es, podría probar yo?
uff ni por asomo se parece a lo que dijo, hay que interpretar mucho, pero se entiende mejor el portugués que esto eh.
en resumidas cuentas dice que le gustaría saber qué hice para compilar y que él le dedicó bastante tiempo y no solventaba un error y cree que es porque yo usé la última versión del pspkit de svn (que hay que compilarla) y él usó una versión ya compilada (creo que se referirá a devkitpsp, que está to desactualizada porque de pspkit no encontré ningunos binarios a descargar). La verdad es que yo uso linux y me facilitó mucho la vida, él al usar windows vete a saber que limitaciones se encontró porque depende de si usó cygwin o msys o cualquier otro paquete de herramientas gcc para windows.
En cuanto a que no están subidos a SVN el que?, si está todo en SVN, quizas no estés usando el último pspkit, busca mejor, es uno de un tal pspjimPSP, y en él estan los scripts de compilación de herramientas cruzadas para psp y de compilación de librerías, leete el "history" que puse anteriormente para ver los directorios y nombres donde se encuentran los scripts.
Lo de cambiar la imagen y el texto del psp, tengo que crear un script que a partir del .elf de bgdi, la imagen y el texto genere el .pbp que necesitan los homebrew para ejecutarse en psp, pero creo que hay una herramienta para abrir el .pbp y cambiarlos a mano, por si quieres ir tirando mientras tanto. En cuanto al juego, debe de ir con el nombre game.dcb, es una limitación que puse a posta ya que psp no permite la entrada de parámetros típica de forma fácil, pero tengo ya pensado quitarla también porque el código de splinter soporta algo que no recordaba y que viene de perlas que es ponerle al dcb el mismo nombre que al ejecutable, así que se tendrían que llamar eboot.dcb para no romper la filosofía de bennu ni insertar código innecesario a los fuentes originales.
resolución pues es 480 x 272
mierda, el echo de drumpi no va en la psp, carga las imágenes de gph y bennu pero luego se apaga la consola, un montón de raro, pero no deja ni log ni nada, ya no se si será de que el que he usado está preparado para gp2x y he tenido que tocar al desconocimiento una línea para que compile con el último bgdi :D.
links please
:|
PiX Bros sin ningún cambio tira semiperfecto!
Aunque... el rojo es azul y el azul es rojo xD
Quote from: DCelso on January 12, 2011, 01:55:30 AM
umn, mejor que eso, que tal un "history"?
mkdir ~/tmp/pspjim_src
cd ~/tmp/pspjim_src
svn co svn://psp.jim.sh/svn/psp/trunk .
sudo apt-get install build-essential autoconf automake bison flex \
libncurses5-dev libreadline-dev libusb-dev texinfo libgmp3-dev \
libmpfr-dev
export PSPDEV="/SDKs/pspdev"
export PSPSDK="$PSPDEV/psp/sdk"
export PATH="$PATH:$PSPDEV/bin:$PSPSDK/bin"
mkdir $PSPDEV
mkdir ~/tmp/pspjim_src/psptoolchain/build
cd ~/tmp/pspjim_src/psptoolchain/build
ln -s ../../pspsdk pspsdk
ln -s ../../psplinkusb psplinkusb
cd ..
./toolchain.sh
cd ~/tmp/pspjim_src/psplibraries
mkdir build
cd build
ln -s ../../bzip2/ .
ln -s ../../SDL_gfx/ .
ln -s ../../pspirkeyb/ .
ln -s ../../jpeg/ .
ln -s ../../pspgl/ .
ln -s ../../SDL_mixer/ .
ln -s ../../libmad/ .
ln -s ../../libvorbis/ .
ln -s ../../libogg/ .
ln -s ../../zlib/ .
ln -s ../../lua/ .
ln -s ../../freetype/ .
ln -s ../../libpng/ .
ln -s ../../zziplib/ .
ln -s ../../SDL_ttf/ .
ln -s ../../libTremor/ .
ln -s ../../libbulletml/ .
ln -s ../../SDL/ .
ln -s ../../SDL_image/ .
ln -s ../../libpspvram/ .
ln -s ../../sqlite/ .
ln -s ../../libmikmod/ .
./psplibraries/libraries-sudo.sh
cd ~/tmp/pspjim_src/openssl
gunzip < openssl-0.9.7j.tar.gz | tar xv
cd openssl-0.9.7j
patch -p1 < ../openssl-0.9.7j.patch
./Configure psp --prefix=$(psp-config --psp-prefix) threads zlib no-shared no-asm
make
make install
Muchas gracias por la info. daniel está usando minpspw-pspsdk, sí. Sólo una nota: no me funciona el comando de hacer el checkout del svn, si a alguien más le falla, que use el siguiente:
[code language="bash"]svn checkout http://psp.jim.sh/svn/psp/trunk/[/code]
En cuanto a lo de Pixel... endianess!!!!! (casi seguro)
PD:
Lo del endianess, me refiero que se resuelve en gran medida añadiendo un "-D__MIPS__ -D__MISPEB__" a los cflags, la arquitectura de la PSP parece bigendian. Habría que mirarlo bien, porque no tengo nada claro si la PSP es big o little endian.
josebas dime un flag o macro para probar y recompilo y que pixel pruebe a ver si es eso, otra cosa no se me ocurre :D, pero en teoría eso se podría arreglar usando sdl_image que también está portado en psp (y en teoría debería de hacer transparente con respecto a eso la carga de imágenes)
Esto... no penséis que lo mío es un bug ni nada, eh?
Quiero decir, no he probado en varios modos gráficos, y encima funciona sobre una resolución virtual diferente...
Y a saber con qué versión de Bennu viejuna he compilado xD
ah, po fale, a lo mejor es eso :D.
Splinter, para qué valen los archivos te9_tf9_hybrid_driver.c y varspace_file.c ?, compilo sin ellos porque en psp y gp2x no compilan, les faltan headers, pero aparentemente todo va bien. En linux he probado a quitarlos y pasa lo mismo funciona el bennu aparentemente igual que sin ellos.
Pregunta! como se definirian las teclas para la PSP?
facil, tengo un .prg con unas macros que se podría usar para cualquier juego
#define PSP_TRIANGLE_BUTTON 0
#define PSP_CIRCLE_BUTTON 1
#define PSP_X_BUTTON 2
#define PSP_SQUARE_BUTTON 3
#define PSP_L_BUTTON 4
#define PSP_R_BUTTON 5
#define PSP_DOWN_BUTTON 6
#define PSP_LEFT_BUTTON 7
#define PSP_UP_BUTTON 8
#define PSP_RIGTH_BUTTON 9
#define PSP_SELECT_BUTTON 10
#define PSP_START_BUTTON 11
#define PSP_LEFT_RIGTH_AXIS 0
#define PSP_UP_DOWN_AXIS 1
luego es usar joy_button(0,PSP_LOQUESEA_BUTTON);
Entonces incluyendo esas lineas y modificando las teclas deberia de funcionar correctamente no?
Gracias!
Sus dejo la versión en formato .elf y las herramientas y script necesario para crear el .pbp con el texto,icono, imagen y sonido que querais.
(las herramientas son para linux)
http://www.mediafire.com/?g9y2n82jdmnobyd
Quote from: DCelso on January 12, 2011, 09:16:47 PM
Splinter, para qué valen los archivos te9_tf9_hybrid_driver.c y varspace_file.c ?, compilo sin ellos porque en psp y gp2x no compilan, les faltan headers, pero aparentemente todo va bien. En linux he probado a quitarlos y pasa lo mismo funciona el bennu aparentemente igual que sin ellos.
ignoralo.
:D, eso hice
los problemas de colores me dan a mi tambien con el logo de bennu, sale el ave azul, cagoen. Hay que compilar el prg con otra máquina que tenga el mismo endianes que la psp para probarlo, y los dcbs de wii supongo que no valdrán por el ajuste monolítico que hizo josebas, pero si alguien puede probarlos para salir de dudas mejor que mejor.
El bgdc para psp se me resiste, es rarísimo lo que me pasa, el monolítico de linux va del carajo, y lo mismo pero compilado para psp da un pedazo error que te cagas de "error 8000xxxalgo no se pudo cargar el juego".
Quote from: yawin on January 12, 2011, 02:40:17 PM
Yo lo probaría, pero no se cómo se activa el homebrew xD
Eu escrevi alguns textos (em ingles) sobre isso.
http://code.google.com/p/bennugd-monolithic/wiki/PSPGettingStarted
Estou a disposicao de todos para explicar como habilitar homebrews no PSP.
Quote from: DCelso on January 12, 2011, 03:07:17 PM
En cuanto a que no están subidos a SVN el que?, si está todo en SVN, quizas no estés usando el último pspkit, busca mejor, es uno de un tal pspjimPSP, y en él estan los scripts de compilación de herramientas cruzadas para psp y de compilación de librerías, leete el "history" que puse anteriormente para ver los directorios y nombres donde se encuentran los scripts.
Lo de cambiar la imagen y el texto del psp, tengo que crear un script que a partir del .elf de bgdi, la imagen y el texto genere el .pbp que necesitan los homebrew para ejecutarse en psp, pero creo que hay una herramienta para abrir el .pbp y cambiarlos a mano, por si quieres ir tirando mientras tanto. En cuanto al juego, debe de ir con el nombre game.dcb, es una limitación que puse a posta ya que psp no permite la entrada de parámetros típica de forma fácil, pero tengo ya pensado quitarla también porque el código de splinter soporta algo que no recordaba y que viene de perlas que es ponerle al dcb el mismo nombre que al ejecutable, así que se tendrían que llamar eboot.dcb para no romper la filosofía de bennu ni insertar código innecesario a los fuentes originales.
resolución pues es 480 x 272
Voce pode usar o makefile do SDK do PSP para realizar a geracao do arquivo PBP automaticamente. Essa é a maneira recomendada de compilar programas para o PSP: usar o makefile incluido no SDK ou integra-lo ao seu proprio makefile. Olhe os exemplos que vem com o PSPSDK que voce vai ver como isso deve ser feito.
ups, yawin, creí que te había respondido, jajaj, no le debí dar a enviar bien.
Habilitar el homebrew es una forma bonita de decir piratear :D. Homebrew literalmente es "hecho en casa" y se usa como termino para los juegos caseros que hacemos por amor al arte :D. En el caso de la psp habilitar el homebrew consiste en cambiar el firmware de la psp por uno personalizado que habilita el cargar juegos desde la memorystick, lo que más usa la peña para ello es un programa llamado "el despertar del cementerio" que nació así como para resucitar psps en las que el firmware falló por algún motivo (normalmente por trastear de meter firmwares no oficiales :D) y ahora se usa para "pi...tear" descaradamente la psp y meterle un "custom firmware, ahora van por el 5.50"
El mayor problema que tiene es que hay que modificar un chip de la batería (a estas baterías modificadas las llaman pandora y se venden ya por muchos sitios así) y si tienes una psp pirateada puedes hacerlo con un programa homebrew en un click, pero si no tienes a mano una psp pirateada te toca abrir la batería y levantar una patilla, con el consiguiente riesgo de quedarte sin ella :D.
Quote from: danielt3 on January 12, 2011, 11:04:37 PM
Quote from: DCelso on January 12, 2011, 03:07:17 PM
En cuanto a que no están subidos a SVN el que?, si está todo en SVN, quizas no estés usando el último pspkit, busca mejor, es uno de un tal pspjimPSP, y en él estan los scripts de compilación de herramientas cruzadas para psp y de compilación de librerías, leete el "history" que puse anteriormente para ver los directorios y nombres donde se encuentran los scripts.
Lo de cambiar la imagen y el texto del psp, tengo que crear un script que a partir del .elf de bgdi, la imagen y el texto genere el .pbp que necesitan los homebrew para ejecutarse en psp, pero creo que hay una herramienta para abrir el .pbp y cambiarlos a mano, por si quieres ir tirando mientras tanto. En cuanto al juego, debe de ir con el nombre game.dcb, es una limitación que puse a posta ya que psp no permite la entrada de parámetros típica de forma fácil, pero tengo ya pensado quitarla también porque el código de splinter soporta algo que no recordaba y que viene de perlas que es ponerle al dcb el mismo nombre que al ejecutable, así que se tendrían que llamar eboot.dcb para no romper la filosofía de bennu ni insertar código innecesario a los fuentes originales.
resolución pues es 480 x 272
Voce pode usar o makefile do SDK do PSP para realizar a geracao do arquivo PBP automaticamente. Essa é a maneira recomendada de compilar programas para o PSP: usar o makefile incluido no SDK ou integra-lo ao seu proprio makefile. Olhe os exemplos que vem com o PSPSDK que voce vai ver como isso deve ser feito.
:D, tienes mucha razón, yo los creo así, pero esto lo puse para que los programadores de bennu no tengan que instalarse el sdk completo de c++ para psp para crearse un juego bennu para psp. Con este adjunto la forma de crear un juego bennu para psp sería, crear el .prg de tu juego, compilarlo para optener el .dcb, renombrarlo a game.dcb, crearse un icono para su juego, editar el script adjunto para configurarlo para que enganche con el icono y con el texto a mostrar en pantalla de la psp y finalmente ejecutar el script para así obtener un .pbp personalizado con la imagen de tu juego y el texto de tu juego, y así evitar usar el que he puesto yo por defecto para el bgdi.
Pruebas:
1 - Loadings 4,5 veces mas lentos.
2 - Sonido perfecto.
3 - Color erroneo en la mayoria de menus.
4 - Reproducción de flc's no funciona, o se salta, pero puede ser que falle el ajuste de color de 16 a 8 bits durante el juego.
5 - Si tienes un juego de 320x240 te lo pone a pantalla completa (480 x 272)
6 - Si seteas tu juego a 480 x 272 (lo compilas y pruebas en psp), este se pone a 320x240 (con las bandas negras correspondientes), ajustado a la izquierda.
He hecho videos, a ver si alguno puedo subir.
En ppio. los dcbs de la wii deberían valer si la máquina es bigendian, porque salvo por el tema del endianess son compatibles con la versión oficial.
http://www.youtube.com/watch?v=gwnLFOOA7oc
Quote from: DCelso on January 12, 2011, 11:15:18 PM
:D, tienes mucha razón, yo los creo así, pero esto lo puse para que los programadores de bennu no tengan que instalarse el sdk completo de c++ para psp para crearse un juego bennu para psp. Con este adjunto la forma de crear un juego bennu para psp sería, crear el .prg de tu juego, compilarlo para optener el .dcb, renombrarlo a game.dcb, crearse un icono para su juego, editar el script adjunto para configurarlo para que enganche con el icono y con el texto a mostrar en pantalla de la psp y finalmente ejecutar el script para así obtener un .pbp personalizado con la imagen de tu juego y el texto de tu juego, y así evitar usar el que he puesto yo por defecto para el bgdi.
Voce tambem tem muita razao em nao querer que instale o SDK completo para criar jogos. Eu vou tentar criar um script igual ao seu mas para windows e disponibilizar para todos.
Quote from: FreeYourMind on January 12, 2011, 11:58:30 PM
http://www.youtube.com/watch?v=gwnLFOOA7oc
OMG! casi lloro!! :'D
Sigo este hilo atento :D
Esa linterna enfocando directamente a la pantalla sin apenas dejar ver nada es todo un logro, gracias por el detalle ;D
Quote from: DCelso on January 12, 2011, 11:09:19 PM
ups, yawin, creí que te había respondido, jajaj, no le debí dar a enviar bien.
Habilitar el homebrew es una forma bonita de decir piratear :D. Homebrew literalmente es "hecho en casa" y se usa como termino para los juegos caseros que hacemos por amor al arte :D. En el caso de la psp habilitar el homebrew consiste en cambiar el firmware de la psp por uno personalizado que habilita el cargar juegos desde la memorystick, lo que más usa la peña para ello es un programa llamado "el despertar del cementerio" que nació así como para resucitar psps en las que el firmware falló por algún motivo (normalmente por trastear de meter firmwares no oficiales :D) y ahora se usa para "pi...tear" descaradamente la psp y meterle un "custom firmware, ahora van por el 5.50"
El mayor problema que tiene es que hay que modificar un chip de la batería (a estas baterías modificadas las llaman pandora y se venden ya por muchos sitios así) y si tienes una psp pirateada puedes hacerlo con un programa homebrew en un click, pero si no tienes a mano una psp pirateada te toca abrir la batería y levantar una patilla, con el consiguiente riesgo de quedarte sin ella :D.
Ya imaginaba que sería el eufemismo de "pi-atear", pero mi comentario iba dirijido a que no se piratearla jajajajaja
De todas formas, tengo entendido que no hace falta cambiarle ningun chip. Mi hermano pequeño tuvo la PSP pirateada un tiempo y sólo metió software. No se. Coloco esto en el final de mi lista de proyectos xD
Quote from: Windgate on January 13, 2011, 01:53:16 PM
Esa linterna enfocando directamente a la pantalla sin apenas dejar ver nada es todo un logro, gracias por el detalle ;D
sublime! karma++ por ello!
Malditos xDDDD
Hice mas videos, pero todavia no tenia permisos de enseñarlo xDD
Quote from: FreeYourMind on January 13, 2011, 08:59:25 PM
Malditos xDDDD
Hice mas videos, pero todavia no tenia permisos de enseñarlo xDD
xDDDD
permiso de quien
Buenas!
tengo un problemilla con joy_button,la cosa esque nunca he utilizado esas funciones,tengo incluida la mod joy y los defines que dejo dcelso
y me dice joy_button undefined procedure
[code language="bennu"]LOOP
IF(joy_button(0,PSP_X_BUTTON));EXIT("",1);END
FRAME;
END
END
[/code]
Alguien me ilumina? gracias!!
No se ve muy bien,pero a la espera de que alguien me ayude con la duda anterior,he hecho esta prueba :
http://www.youtube.com/watch?v=Ilna4cEVO6s
DCelso, pon el patch de los fuentes, porfi.
Como dijo jack el destripador, vayamos por partes.
Quote from: Goku jr on January 13, 2011, 10:03:09 PM
Buenas!
tengo un problemilla con joy_button,la cosa esque nunca he utilizado esas funciones,tengo incluida la mod joy y los defines que dejo dcelso
y me dice joy_button undefined procedure
[code language="bennu"]LOOP
IF(joy_button(0,PSP_X_BUTTON));EXIT("",1);END
FRAME;
END
END
[/code]
Alguien me ilumina? gracias!!
Sorry goku, es joy_getbutton (http://wiki.bennugd.org/index.php?title=Joy_getbutton) la función correcta.
De todas formas tengo montado otro script, para poder ejecutar los juegos tanto en psp como en pc, mapeando las keys, pero por algún motivo no me va en mi psp(creo que porque como la psp no tiene teclado casca por ahí, tal vez con un os_id se arregle, estoy en ello, pero mientra dejo aqui la info)
#define PSP_TRIANGLE_BUTTON 0
#define PSP_CIRCLE_BUTTON 1
#define PSP_X_BUTTON 2
#define PSP_SQUARE_BUTTON 3
#define PSP_L_BUTTON 4
#define PSP_R_BUTTON 5
#define PSP_DOWN_BUTTON 6
#define PSP_LEFT_BUTTON 7
#define PSP_UP_BUTTON 8
#define PSP_RIGHT_BUTTON 9
#define PSP_SELECT_BUTTON 10
#define PSP_START_BUTTON 11
#define PSP_LEFT_RIGHT_AXIS 0
#define PSP_UP_DOWN_AXIS 1
function key_joy(int id)
begin
if (joy_numjoysticks() >0 )
if (joy_getbutton(0,id))
return 1;
end
end
switch (id)
case PSP_TRIANGLE_BUTTON:
return key (_a);
end
case PSP_CIRCLE_BUTTON:
return key (_s);
end
case PSP_X_BUTTON:
return key (_d);
end
case PSP_SQUARE_BUTTON:
return key (_f);
end
case PSP_L_BUTTON:
return key (_z);
end
case PSP_R_BUTTON:
return key (_x);
end
case PSP_SELECT_BUTTON:
return key (_c);
end
case PSP_START_BUTTON:
return key (_v);
end
case PSP_UP_BUTTON:
return key (_up);
end
case PSP_DOWN_BUTTON:
return key (_down);
end
case PSP_LEFT_BUTTON:
return key (_left);
end
case PSP_RIGHT_BUTTON:
return key (_right);
end
end
return 0;
end
Así ahora solo tienes que llamar a key_joy en vez de a joy_getbutton y remapear las teclas si no te molan mucho.
Por otro lado,
Quote from: josebita on January 14, 2011, 10:05:53 AM
DCelso, pon el patch de los fuentes, porfi.
Estoy en ello, estoy dejándolos perita y he cambiado algunas cosillas, en cuanto lo tenga os lo paso a splinter y a ti.
Splinter, acerca del .patch, puedes abrirlo con cualquier editor de texto, y ver la info, básicamente viene la siguiente info:
nombre de fichero
unas cuantas líneas que son iguales en ambos ficheros comparados
+ nuevas lineas a insertar
- líneas a eliminar
otras cuantas líneas que son iguales en ambos ficheros comparados
Siguiente fichero
.,,
Es decir, hay un + delante de las nuevas lineas a insertar y un - delante de las líneas a eliminar.
Así que es facil de interpretar, de todas formas intentaré resumirte los cambios.
si prefieres, otra opción es pasarte los archivos modificados y tu compararlos con algún programa comparador de archivos que te guste.
Gracias Dcelso por el comentario del traductor. No tengo ni idea de Portugués y me pareció convincente ;D
Quote from: DCelso on January 14, 2011, 02:15:43 PM
Como dijo jack el destripador, vayamos por partes.
Quote from: Goku jr on January 13, 2011, 10:03:09 PM
Buenas!
tengo un problemilla con joy_button,la cosa esque nunca he utilizado esas funciones,tengo incluida la mod joy y los defines que dejo dcelso
y me dice joy_button undefined procedure
[code language="bennu"]LOOP
IF(joy_button(0,PSP_X_BUTTON));EXIT("",1);END
FRAME;
END
END
[/code]
Alguien me ilumina? gracias!!
Sorry goku, es joy_getbutton (http://wiki.bennugd.org/index.php?title=Joy_getbutton) la función correcta.
De todas formas tengo montado otro script, para poder ejecutar los juegos tanto en psp como en pc, mapeando las keys, pero por algún motivo no me va en mi psp(creo que porque como la psp no tiene teclado casca por ahí, tal vez con un os_id se arregle, estoy en ello, pero mientra dejo aqui la info)
#define PSP_TRIANGLE_BUTTON 0
#define PSP_CIRCLE_BUTTON 1
#define PSP_X_BUTTON 2
#define PSP_SQUARE_BUTTON 3
#define PSP_L_BUTTON 4
#define PSP_R_BUTTON 5
#define PSP_DOWN_BUTTON 6
#define PSP_LEFT_BUTTON 7
#define PSP_UP_BUTTON 8
#define PSP_RIGHT_BUTTON 9
#define PSP_SELECT_BUTTON 10
#define PSP_START_BUTTON 11
#define PSP_LEFT_RIGHT_AXIS 0
#define PSP_UP_DOWN_AXIS 1
function key_joy(int id)
begin
if (joy_numjoysticks() >0 )
if (joy_getbutton(0,id))
return 1;
end
end
switch (id)
case PSP_TRIANGLE_BUTTON:
return key (_a);
end
case PSP_CIRCLE_BUTTON:
return key (_s);
end
case PSP_X_BUTTON:
return key (_d);
end
case PSP_SQUARE_BUTTON:
return key (_f);
end
case PSP_L_BUTTON:
return key (_z);
end
case PSP_R_BUTTON:
return key (_x);
end
case PSP_SELECT_BUTTON:
return key (_c);
end
case PSP_START_BUTTON:
return key (_v);
end
case PSP_UP_BUTTON:
return key (_up);
end
case PSP_DOWN_BUTTON:
return key (_down);
end
case PSP_LEFT_BUTTON:
return key (_left);
end
case PSP_RIGHT_BUTTON:
return key (_right);
end
end
return 0;
end
Así ahora solo tienes que llamar a key_joy en vez de a joy_getbutton y remapear las teclas si no te molan mucho.
eso no te funciona, porque no estas mapeando el joys al teclado, sino que estas diciendo, si tal boton del joy esta pulsado entonces retorname si tal tecla esta pulsada.
lo que vos deberias hacer es algo diferente, directamente retorna la constante, o mejor te diria que actualices la jkeys.lib, que para eso la hice.
Quote from: DCelso on January 14, 2011, 02:19:19 PM
Por otro lado, Quote from: josebita on January 14, 2011, 10:05:53 AM
DCelso, pon el patch de los fuentes, porfi.
Estoy en ello, estoy dejándolos perita y he cambiado algunas cosillas, en cuanto lo tenga os lo paso a splinter y a ti.
Splinter, acerca del .patch, puedes abrirlo con cualquier editor de texto, y ver la info, básicamente viene la siguiente info:
nombre de fichero
unas cuantas líneas que son iguales en ambos ficheros comparados
+ nuevas lineas a insertar
- líneas a eliminar
otras cuantas líneas que son iguales en ambos ficheros comparados
Siguiente fichero
.,,
Es decir, hay un + delante de las nuevas lineas a insertar y un - delante de las líneas a eliminar.
Así que es facil de interpretar, de todas formas intentaré resumirte los cambios.
conozco el formato el patch, pero preferia una explicacion de los cambios, no importa, dejalo, ya lo vere...
Tarde, splinter :'(, ya te mandé la explicación en formato pdf. Espero que te guste y me des críticas constructivas :D.
Por otro lado no se como lees eso tu en mi código porque lo que yo veo es lo siguiente:
Si hay almenos un joystic, mira si está pulsado el boton con el identificador pasdo, retorna 1 y no sigas con el código de a continuación.
Sino, a traves del identificador de boton pasado devuelve el estado de la tecla asociada a dicho id.
devuelve 0. << cosa que nunca pasará a nos er que pases un id malo a la función.
case PSP_CIRCLE_BUTTON:
return key (_s);
end
aca dice, si esta pulsado PSP_CIRCLE_BUTTON, entonces retorna el retorno de la funcion key con parametro _s, segun has dicho, no hay keys en PSP, por ende, esta funcion retorna 0, ya que key(_s) nunca dara un valor de pulsado.
edit: ya veo, primero detectas el joy, si no esta el joy usas key...
eso es demasiado hardcode, a mi me parece que deberias usar la jkeys.lib, pero bueno... esta bien...
con respecto al codigo monolitico, ya te respondi por mail algunas sugerencias, por ahora no lo incluire como oficial, creo que se podria hacer aun con menos cambios...
tengo que ver la version de josebita, que dice que esta menos prolija que la tuya... yo tenia entendido que josebita no habia cambiado mucho del codigo... quizas entendi mal o me hice una idea equivocada.
demas esta decir que te has mandado un muy buen trabajo.
pues no debería
Lo que tu dices solo pasaría si no pulsases ningun botón, pues para eso está el return 1 que hay antes que termina la ejecución de la función si se produjo la pulsación de cualquier boton.
¿No crees?
if (joy_numjoysticks() >0 )
if (joy_getbutton(0,id))
return 1;
end
end
si, si... lo edite y lo puse como tachado, pero se ve que no salio el tachado...
Quote from: SplinterGU on January 14, 2011, 04:38:55 PM
[...]
tengo que ver la version de josebita, que dice que esta menos prolija que la tuya... yo tenia entendido que josebita no habia cambiado mucho del codigo... quizas entendi mal o me hice una idea equivocada.
demas esta decir que te has mandado un muy buen trabajo.
La verdad es que la mía tiene un problema respecto a la de DCelso: Hay que andar cambiando los módulos uno a uno, que es un lío. Voy a ver cómo lo ha hecho él sin modificarlos, porque la verdad es que me facilitaría mucho la vida.
Quitando la modificación de los módulos, mi código lo que hace es definir los símbolos de los módulos en un array grande en el fichero core/includes/monolithic_includes.h (por cierto, he cambiado la extensión de los módulos ficticios en mi versión por ".fakelib" para que sea evidente que no se está intentando una carga real en la versión monolítica). Si os fijais, ese fichero tiene dos partes: una en la que se definen los símbolos necesarios unicamente para bgdrtm y otra con las cosas que usan bgdrtm y bgdi (nombres de funciones exportados, variables, constantes...). Lo hago así para no tener que compilar todos los símbolos dentro del bgdc. Ambos arrays tienen los símbolos de los módulos en el mismo orden.
Además he separado el core/include/loadlib.h en dos partes: una la que carga librerías de verdad y la otra que devuelve los símbolos monolíticos. Para poder trabajar con los mismos tipos que la versión "normal" lo que hago es redefinir dlibhandle de lo que es a:
[code language="c"]typedef struct
{
int index;
} dlibhandle ;
[/code]Donde, obviamente, index es el índice del módulo dentro del array de monolithic_includes.h
De mi forma de hacerlo no me gusta nada el tema de andar teniendo que modificar los módulos, pero por lo demás -de memoria- creo que no tengo mayor queja.
josebita, el trabajo de anda modificando a mano, podes resolverlo con un script-precompilador y un define, el define para deshabilitar las variables de los modulos y el script que tome las variables y genere la struct que vos decis que llenas a mano.
eso seria lo que yo haria, no me gusta eso de tener que meter muchos cambios en los fuentes, menos hardcodear cosas como nombres de librerias y demas, en el interprete y compilador.
splinter, ya la hice mas liviana, ahora simulo completamente a loadlib. como debería ser, asi que solo hay que hacer un ifdef para seleccionar loadlib.h o sim_loadlib.h, en cuanto se requiere para ser monolítico o no.
Los demás cambios que te puse en el código como podrás observar son para soportar psp y gp2x así que no hay mas remedio que introducirlos.
Adjunto el nuevo patch para que me digais tu y josebita que os parece. (ya que soys los doctos en compilar bennu eh) :D
Quote from: DCelso on January 14, 2011, 06:55:42 PM
splinter, ya la hice mas liviana, ahora simulo completamente a loadlib. como debería ser, asi que solo hay que hacer un ifdef para seleccionar loadlib.h o sim_loadlib.h, en cuanto se requiere para ser monolítico o no.
Los demás cambios que te puse en el código como podrás observar son para soportar psp y gp2x así que no hay mas remedio que introducirlos.
Adjunto el nuevo patch para que me digais tu y josebita que os parece. (ya que soys los doctos en compilar bennu eh) :D
O arquivo tem senha (password)?
Gracias Dcelso!
En cuanto tengo un rato,lo pruebo que hoy es viernes! :D:D
sorry, el zip solo era para splinter y josebas, es un patch del código fuente c para generar codigo fuente c, no es útil para usuarios bennu.
Jejejeje!,me referia al codigo para manejar los botones de la PSP,
Saludos!
Olá a todos.
Acabei de lançar a segunda versão beta do meu port para o PSP. Nessa versão, é possível rodar vários dos exemplos que vem com o BennuGD mas ainda existem questões importantes a serem resolvidas e bugs para serem corrigidos.
http://code.google.com/p/bennugd-monolithic/
Notificação de bugs e testes com outros jogos são bem-vindos.
Ok, ya probaré a ver que tal, lo mejor es que reunas esfuerzos tu y DCElso.
osti, tu, sí que me pilló de imprevisto esto. Por cierto, segunda versión? nunca vi la primera :(.
Quando eu começei a frequentar o forum do BennuGD eu lia apenas o forum em inglês e foi lá que eu postei. Mas o primeiro foi apenas um "Hello world". Quase nada funcionava nele. Esse segundo já chega perto de algo mais útil.
using the monolithic system of josebita?
Venga, lo siguiente es esto!
http://www.elotrolado.net/hilo_primer-homebrew-software-quot-firmado-quot_1555943_s20
:D
Ejecutarlo sin que sean PSPs piratas!!! :D
En el juego del cohete va la última versión que he compilado para psp.
Splinter, he descubierto varias cosas curiosas.
Si pongo set_mode(480.272,32), a la psp se le va la pinza (y eso que es su resolucion nativa) y no refresca bien las cosas va todo como desfasado a la hora de dibujarse en la pantalla. En cambio si pongo set_mode(480.271,32), va todo a la perfeción.
También va a la perfección si pongo set_mode(480.272,32) pero además pongo scale_resolution=04800272. Rarísimo, porque escalo a lo mismo que el set mode y no se le va la pinza a la psp.
Otra cosa rara que he visto es que, si usas map_new, map_clear, RGB, ... etc, compilar con el PC y obtienes el dcb y lo ejecutas en la psp los colores funcionan correctamente, el rojo es rojo, el verde es verde , etc.
En cambio si usas load_png o load_pcx , creas el dcb con el PC, los colores van bien en el PC pero en cambio en la psp se ven todos invertidos, el rojo es azul, el azul es rojo, etc.
No entiendo como que uno va bien y otro no, ¿si fuera cosa de los endianeses no debería de ir mal en los dos ejemplos?
sera porque en vez de poner 640,480,32 estas poniendo 640.480,32?
no, porque los png los maneja una lib externa... ahora los pcx puede que no tengan el manejo de los endians... como sea, estos problemas son en la carga.
en cuanto al problema de la resolucion, no le veo sentido, si anda el escale, entonces el set_mode tiene que funcionar, porque en realidad es lo mismo.
libpng !?
Buenas!
Mirando en San Google la resolucion la PSP de de 420x272 ,quizas sea eso el problema
Quote from: Goku jr on January 21, 2011, 10:51:53 AM
Buenas!
Mirando en San Google la resolucion la PSP de de 420x272 ,quizas sea eso el problema
jeje...
Quote from: danielt3 on January 15, 2011, 09:17:13 PM
Olá a todos.
Acabei de lançar a segunda versão beta do meu port para o PSP. Nessa versão, é possível rodar vários dos exemplos que vem com o BennuGD mas ainda existem questões importantes a serem resolvidas e bugs para serem corrigidos.
http://code.google.com/p/bennugd-monolithic/
Notificação de bugs e testes com outros jogos são bem-vindos.
He probado tu version con los 5 tests que tenia para probar la version de DCElso.
No me funciona ninguno, ni siquiera los que me funcionaban en la otra version, como el Deadly Eye por ejemplo.
Se queda la pantalla en negro y al rato se pone totalmente negra la pantalla y tengo que salir a la fuerza ya que si salgo a veces en home este se queda bloqueado.
free, prueba tus tests y los juegos que quieras con esta versión.
http://www.mediafire.com/?4w7cmb47863bu6e
Quote from: Goku jr on January 21, 2011, 10:51:53 AM
Buenas!
Mirando en San Google la resolucion la PSP de de 420x272 ,quizas sea eso el problema
Pues tu san google se ha equivocado un poco esta vez.
http://es.wikipedia.org/wiki/PlayStation_Portable
Resultados de tu cohete:
Funciona como antes, pero apuesto que peor, o sea sólo me va el Deadly Eye, es lento al cargar, me parece mas lento que antes, y no estoy seguro, pero creo que al deadly antes no le fallaban los colores (habria que mirar el video que puse a ver).
El Art Shot se me tira media vida en el loading (pone el texto en pantalla) al punto que ni me apetece seguir esperando a ver si arranca, llevo esperando 3 minutos por fin suena la musica del logo flc, pero peta y se apaga la consola.
Sigue necesitando ajustes de resolución, que como ya te dijé antes, 320x240 te pone a fullscreen en psp.
Siguen sin funcionar los flc, vamos, me imagino que no estas intentando resolver estas cosillas xDDD
apuesto que también fallaban antes, a no ser que hubieras compilado el dcb con la wii u otro sistema que use el mismo endianes que la psp.
me da la impresión que sean de lo mismo los problemas, los dichosos endianes.
en cuanto a la resolución, será culpa de la SDL para psp que redimensiona siempre a su formato nativo, no se si habrá forma de cambiarlo, sería cuestión de investigar.
todo se resolvería si funcionara el bgdc de psp, pero no lo consigo hacer funcionar, al juntar todos los ".o" se vuelve corrupto el exe final y la psp dice que no puede cargar el juego.
No redimensiona siempre a su formato nativo, como ya te comente en anteriores posts, si pones la resolución de la psp en tu juego, este se pone a 320x240, ajustado a la izquierda xDD
Quote from: FreeYourMind on January 23, 2011, 11:23:32 PM
No redimensiona siempre a su formato nativo, como ya te comente en anteriores posts, si pones la resolución de la psp en tu juego, este se pone a 320x240, ajustado a la izquierda xDD
Se voces estao tendo problemas de cores no PSP saibam que ele tem um formato de paleta de cores diferente. Eu conversei com o pessoal do ScummVM e eles disseram que tem isso implementado no codigo-fonte deles. Nos arquivos psppixelformat.cpp e psppixelformat.h está implementado o formato do PSP.
http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/tags/release-1-2-1/backends/platform/psp/
Quote from: DCelso on January 23, 2011, 10:04:43 PM
Quote from: Goku jr on January 21, 2011, 10:51:53 AM
Buenas!
Mirando en San Google la resolucion la PSP de de 420x272 ,quizas sea eso el problema
Pues tu san google se ha equivocado un poco esta vez.
http://es.wikipedia.org/wiki/PlayStation_Portable
Eso me pasa por poner el primer resultado que me dio xDD
Obrigado Daniel, então isso explica porque acontece directamente, no entanto parece que so ocorre com o formato png.
Ese ficheiro vai ser util para o port de Bennu à PSP sem duvida xDD
pptls para psp y ultima versión de bgdi para psp.
http://www.mediafire.com/?yc76y5hhok3t156
Sigue todo igual, estaria bien que digas antes lo que cambias porque no tiene sentido buscar cosas que no sabes si han cambiado.
1 - Mismo comportamiento en resolución.
2 - Loadings aún más eternos que antes (el deadly eye ni salio del loading el tiempo que tuve ganas de esperar)
3 - Mismo color trucado.
4 - Videos flc siguen sin reproducirse.
5 - Ejecución mas lenta de todos los menus.
Quote from: DCelso on January 31, 2011, 05:43:14 PM
pptls para psp y ultima versión de bgdi para psp.
http://www.mediafire.com/?yc76y5hhok3t156
Eu nao sei se voce ja está compilando o mod_dir ou se está apenas escondendo-o com um #ifdef. Em todo caso, eu tenho uma versao das funcoes glob* que compilei a partir da dietlibc para o PSP no meu repositorio. Com isso, mod_dir passa a funcionar no PSP tambem.
http://code.google.com/p/bennugd-monolithic/source/browse/PSP?r=202
Os arquivo estao em /PSP/3rd_party/dietlibc-glob
Olá a todos.
Eu gostaria de anunciar que o meu port do BennuGD para o PSP está oficialmente descontinuado. O DCelso conseguiu fazer um port melhor do que o meu e isso é melhor para a comunidade BennuGD.
Eu ainda vou frequentar este forum para ver como estão as coisas e tentar contribuir como puder.
Obrigado a todos pela oportunidade.
Não se trata de que o port de DCElso sejá melhor que o seu, simplesmente conseguiu fazelo funcionar melhor actualmente, mas isso não implica que não precisemos de sua ajuda. Esperamos que siga ajudando a comunidade a tornar o port de Bennu para a PSP uma realidade.
O port não é de DCElso, nem seu, nem meu, mas sim de todos os que que fazemos parte da comunidade Bennu :D
Quote from: FreeYourMind on January 31, 2011, 08:25:18 PM
Sigue todo igual, estaria bien que digas antes lo que cambias porque no tiene sentido buscar cosas que no sabes si han cambiado.
1 - Mismo comportamiento en resolución.
2 - Loadings aún más eternos que antes (el deadly eye ni salio del loading el tiempo que tuve ganas de esperar)
3 - Mismo color trucado.
4 - Videos flc siguen sin reproducirse.
5 - Ejecución mas lenta de todos los menus.
¿puedes pasarme el dcb para verlo?, en verdad te digo que no se ni por donde meterle mano a esos problemas, se supone que lo mio es un port a toda regla, solo tiene castradas las funciones "glob" con respecto a la versión de pc.
El que vaya lento, a mi me pasa con un monton de ports para psp, la psp es lenta cargando, lo del color, estoy en ello (creo que splinter también iba a meterle mano) , lo de los videos flc npi completamente porque si van en pc deberían de hacerlo en psp igualmente, y lo de ejecución más lenta pues tiene que ser culpa de los fps, cambia el setfps y ponlo más alto a ver que tal, yo lo cambié y rula puta madre.
Quote from: danielt3 on January 31, 2011, 09:20:59 PM
Olá a todos.
Eu gostaria de anunciar que o meu port do BennuGD para o PSP está oficialmente descontinuado. O DCelso conseguiu fazer um port melhor do que o meu e isso é melhor para a comunidade BennuGD.
Eu ainda vou frequentar este forum para ver como estão as coisas e tentar contribuir como puder.
Obrigado a todos pela oportunidade.
I am very sad to hear this, my port do not apport anything special, this is just a monolithic recompile of the official source code. I'm sure that your ideas are better than mines, it you want I can upload my changes to any site to you can continue over this growing the functionality.
And you're right I cropped "glob" functions with stubs methods, your contribution can improve the psp port.
Quote from: DCelso on January 31, 2011, 10:17:34 PM
¿puedes pasarme el dcb para verlo?, en verdad te digo que no se ni por donde meterle mano a esos problemas, se supone que lo mio es un port a toda regla, solo tiene castradas las funciones "glob" con respecto a la versión de pc.
El que vaya lento, a mi me pasa con un monton de ports para psp, la psp es lenta cargando, lo del color, estoy en ello (creo que splinter también iba a meterle mano) , lo de los videos flc npi completamente porque si van en pc deberían de hacerlo en psp igualmente, y lo de ejecución más lenta pues tiene que ser culpa de los fps, cambia el setfps y ponlo más alto a ver que tal, yo lo cambié y rula puta madre.
Pues bajate el deadly eye para caanoo de su hilo y ya lo tienes :)
O mi juego Art Shot para wiz de mi pagina para que veas lo del flc
En el repositorio monolítico tienes al menos 2 implementaciones algo distintas (pero compatibles) de la libglob que creo que deberías poder usar.
Quote from: FreeYourMind on January 31, 2011, 10:42:48 PM
Quote from: DCelso on January 31, 2011, 10:17:34 PM
¿puedes pasarme el dcb para verlo?, en verdad te digo que no se ni por donde meterle mano a esos problemas, se supone que lo mio es un port a toda regla, solo tiene castradas las funciones "glob" con respecto a la versión de pc.
El que vaya lento, a mi me pasa con un monton de ports para psp, la psp es lenta cargando, lo del color, estoy en ello (creo que splinter también iba a meterle mano) , lo de los videos flc npi completamente porque si van en pc deberían de hacerlo en psp igualmente, y lo de ejecución más lenta pues tiene que ser culpa de los fps, cambia el setfps y ponlo más alto a ver que tal, yo lo cambié y rula puta madre.
Pues bajate el deadly eye para caanoo de su hilo y ya lo tienes :)
O mi juego Art Shot para wiz de mi pagina para que veas lo del flc
Asias, voy a verlo, por ahora puedes ir probando este nuevo binario, que supuestamente debería de corregir los colores cuando cargas desde un png.
http://www.mediafire.com/?1767agxhhsv110l
Quote from: josebita on January 31, 2011, 10:56:39 PM
En el repositorio monolítico tienes al menos 2 implementaciones algo distintas (pero compatibles) de la libglob que creo que deberías poder usar.
asias a ti tambien, voy a ver que entiendo :D
Siguen igual...
cagoen, jope, el art shot no he podio bajarmelo se acabó el límite, a ver si mañana.
Por cierto he arreglao los colores de los load_png na mas, no los de los fpg,
He añadido la diet-glob que me habeis dicho, a ver si arreglo los colores de los fpg y subo nuevo pbp.
bueno, creo que he corregido la carga de fpgs y de camino insertado las funciones glob, a ver que tal anda este free.
http://www.mediafire.com/?nl8jq5za7b8mshr
Si que tarda en cargarse el deadly (¿que es lo que hace en este punto por dentro?),
Los colores ahora parecen ir bien, (pero las letras blancas salen ahora doradas),
En cuanto al menú, si que va lento, debe ser culpa del sdl_delay (en la funcion wait frame se usa esto para windows,linux y psp)
Lo de ensancharse, tambien debe ser cupla de la sdl, para cambiarlo habría que tocar las sdl para psp (miraré a ver qué puedo hacer).
Luego al empezar a jugar, se cuelga en el tutorial ¿que hace el código al llegar a aqui? ¿Abre algun tipo de recurso distinto que antes no haya hecho antes (por si es este el que hace que falle)?
Quote from: DCelso on February 01, 2011, 01:51:18 AM
Si que tarda en cargarse el deadly (¿que es lo que hace en este punto por dentro?),
Los colores ahora parecen ir bien, (pero las letras blancas salen ahora doradas),
En cuanto al menú, si que va lento, debe ser culpa del sdl_delay (en la funcion wait frame se usa esto para windows,linux y psp)
Lo de ensancharse, tambien debe ser cupla de la sdl, para cambiarlo habría que tocar las sdl para psp (miraré a ver qué puedo hacer).
Luego al empezar a jugar, se cuelga en el tutorial ¿que hace el código al llegar a aqui? ¿Abre algun tipo de recurso distinto que antes no haya hecho antes (por si es este el que hace que falle)?
La pantalla de loading lanza el proceso que se encarga de cargar los recursos: fuentes, gráficos ingame, los sonidos tanto de menu como ingame y crea un par de paletas (lo se, no debería hacer esto al inicio, pero así lo tenía desde el año de la pera... y al final decidí dejarlo asi ya que si peta por memoria, que pete de una vez y no luego de darle a jugar). Este proceso se mantiene en pantalla durante mínimo 1.5 segundos o durante lo que dure la carga de recursos.
Si con lo del menu se refieren al menu del deadly, pues es bastante lento, lo hice con mucha sobrecarga al exists(), es la parte del código que menos me gusta como quedó. Está tan mal hecho que cuantos más submenus tengan abiertos, puede llegar a usar más cpu que ingame ^^U
Los colores siguen mal, pero se han cambiado, o sea, se acercan mas a los originales, por ejemplo en mis pruebas en los 2 primeros png's se nota bien, pero en el tercero podria pasar desapercibido, sólo se nota en las partes supuestas transparentes que quedan amarillas. Los azules parece que se ven bien, entre otros colores ya corregidos.
Resumiendo me parece que el negro es amarillo, pero te acercas, posiblemente te hayas olvidado de cambiar alguna parte.
Mas cosas sobre el port:
- Sigue activado el screensaver de PSP que oscurece la pantalla pasado cierto tiempo, habria que controlar esto ya que se esta ejecutando el juego.
- Hay algo mal en el refresco, por ejemplo al matar procesos que pintan imagenes, estas parece que siguen pintadas y ya sólo desaparecen al pintar mas imagenes encima.
- Donde se pone el codigo que ejecuta algo en la pantalla con musica y todo, cuando selecionamos el icono del juego en la lista de psp ?
Quote from: FreeYourMind on February 01, 2011, 08:49:45 AM
Los colores siguen mal, pero se han cambiado, o sea, se acercan mas a los originales, por ejemplo en mis pruebas en los 2 primeros png's se nota bien, pero en el tercero podria pasar desapercibido, sólo se nota en las partes supuestas transparentes que quedan amarillas. Los azules parece que se ven bien, entre otros colores ya corregidos.
Resumiendo me parece que el negro es amarillo, pero te acercas, posiblemente te hayas olvidado de cambiar alguna parte.
puedes parasme los tres pngs esos?, para ver colores y demás.
Quote from: FreeYourMind on February 01, 2011, 08:57:47 AM
Mas cosas sobre el port:
- Sigue activado el screensaver de PSP que oscurece la pantalla pasado cierto tiempo, habria que controlar esto ya que se esta ejecutando el juego.
- Hay algo mal en el refresco, por ejemplo al matar procesos que pintan imagenes, estas parece que siguen pintadas y ya sólo desaparecen al pintar mas imagenes encima.
- Donde se pone el codigo que ejecuta algo en la pantalla con musica y todo, cuando selecionamos el icono del juego en la lista de psp ?
lo del screensaver lo buscaré, pero en teoría a mi no me salta, eso lo debería controlar el sistema.
Lo del refresco, a mi me pasa con la resolución original de la psp, pero si pones un pixel menos en el ancho no me pasa, parece tb cosa de SDL (parece estar muy verde este proyectito para psp :()
En cuanto a la música e iconos para el menú de juegos de la psp, bueno van dentro del .pbp, en psp scene beta hay herramientas para insertar y extraer estos recursos. De todas formas yo puse por aquí un zip con las herramientas necesarias y el script necesario para que a partir del binario .elf generado pudieras crear el .pbp con los recursos que quisieras.
Nueva versión de bgdi para psp.
He corregido um problema con la funcion get current dir, resulta que la forma de invocar getcwd de bennu no funcionaba bien en la psp.
Le he añadido de camino un sistema para no tener que nombrar los .dcb como EBOOT.dcb, ahora da igual el nombre que tenga que el bgdi de la psp lo buscará en el directorio donde se encuentre el EBOOT.pbp.
He insertado tres juegos de ejemplo, el priedra, papel, tijeras, lagarto, spock, el WIZ de apagame de PRG, y el demo-fire de Freeyourmind.
Ambos rulan bien, el demo-fire va un taco de lento y no van las teclas (simplemente lo compilé tal cual lo dejó free en el post de demos y lo probé en psp por si alguna función no iba en psp como pasó con getcwd) Para solventar los problemas de de lentitud hice una prueba de poner set_fps(loquesea, 3) en el juego ejemplo llamado WIZ y se arreglan perfectamente, así que el problema solo está en 0 frameskips.
Necesitaría encontrar más ejemplos sencillotes de tests de uso de funciones bennu para ir comprobando qué funciones van bien en psp y qué funciones no van para ir corrigiéndolas. Así que hago una invocación desde aquí a todo aquel que tenga tests facilotes (de uno o dos .prs controlables, que ya más de dos sería dificil de trastear) para ir pasando a la psp. Gracias de antemano.
Probé deathly eye y echo y siguen sin ir, al entrar a jugar se cuelgan, así que fijo que hay alguna otra función que no va bien en psp que habrá que detectar, en el caso de deathly eye no tengo el codigo fuente así que no podré hacerle pruebas para detectarla, en el caso de echo, uff está complejo el código, veré a ver como puedo ir aislando cosillas para detectar la función que no va en psp.
http://www.mediafire.com/?3rrublqwmnuex1o
Se me olvidaba decir que también van adjuntos los scrips de generación del EBOOT.pbp de los ejemplos para mostrar como crear tu propio EBOOT.pbp con imágen, texto y sonido en la selección de juegos (las herramientas necesarias adjuntas son solo para linux).
De momento te llevas otro karma por el esfuerzo.
Sobre mis pruebas y png's, mañana me pongo con ello que esta semana entre cambio de curro no he tenido tiempo.
Sobre los botones de la psp, lo mejor era que mapearas de una vez los botones de PSP de modo que sepamos que botones usar, y así dejar de una vez los problemas con los controles (a lo mejor Splinter te hecha una mano con la libjoy).
Que pongas ejemplos me parece bien, pero al final sólo sirven para crear falsas expectativas, ya que cosas con pocas funcionalidades ya pueden funcionar pero lo que nos interesa es que todo funcione.
De todos modos lo que mas me preocupa es la velocidad, ya daria prioridad a esto, todo va muy muy lento, en las cargas y demás.
Quote from: FreeYourMind on February 03, 2011, 06:32:15 PM
De momento te llevas otro karma por el esfuerzo.
Asias :D.
Quote from: FreeYourMind on February 03, 2011, 06:32:15 PM
Sobre mis pruebas y png's, mañana me pongo con ello que esta semana entre cambio de curro no he tenido tiempo.
Ok, perfes
Quote from: FreeYourMind on February 03, 2011, 06:32:15 PM
Sobre los botones de la psp, lo mejor era que mapearas de una vez los botones de PSP de modo que sepamos que botones usar, y así dejar de una vez los problemas con los controles (a lo mejor Splinter te hecha una mano con la libjoy).
Pues esto ya lo hice yo desde la primera demo que colgué. Es un fichero .inc en el que puse unos cuantos defines para ponerle nombre a todos los botones y de camino una función para usar get_joy_button y key a la vez mapeando a un teclado para poder probarlo tanto en pc como en psp.
#define PSP_TRIANGLE_BUTTON 0
#define PSP_CIRCLE_BUTTON 1
#define PSP_X_BUTTON 2
#define PSP_SQUARE_BUTTON 3
#define PSP_L_BUTTON 4
#define PSP_R_BUTTON 5
#define PSP_DOWN_BUTTON 6
#define PSP_LEFT_BUTTON 7
#define PSP_UP_BUTTON 8
#define PSP_RIGHT_BUTTON 9
#define PSP_SELECT_BUTTON 10
#define PSP_START_BUTTON 11
#define PSP_LEFT_RIGHT_AXIS 0
#define PSP_UP_DOWN_AXIS 1
function keyjoy(int keyid)
begin
if (key(keyid))
return 1;
end
if (NUMBER_JOY()>0)
if (keyid==_UP && get_joy_button(0,PSP_UP_BUTTON))
return 1;
end
if (keyid==_DOWN && get_joy_button(0,PSP_DOWN_BUTTON))
return 1;
end
if (keyid==_LEFT && get_joy_button(0,PSP_LEFT_BUTTON))
return 1;
end
if (keyid==_RIGHT && get_joy_button(0,PSP_RIGHT_BUTTON))
return 1;
end
if (keyid==_esc && get_joy_button(0,PSP_SELECT_BUTTON))
return 1;
end
if (keyid==_enter && get_joy_button(0,PSP_START_BUTTON))
return 1;
end
end
return 0;
end
Quote from: FreeYourMind on February 03, 2011, 06:32:15 PM
Que pongas ejemplos me parece bien, pero al final sólo sirven para crear falsas expectativas, ya que cosas con pocas funcionalidades ya pueden funcionar pero lo que nos interesa es que todo funcione.
Pues no pongo ejemplos que no hagan nada, son juegos completos y estoy en ello el problema de que no funcionen algunas funciones no es culpa del port sino de quien haya programado las toolchain para psp, tampoco es plan de reprogramarlas, tendremos que adaptarnos a ellas, (a no ser que sea más dificil la adaptacion que reprogramar algo ):D.
Quote from: FreeYourMind on February 03, 2011, 06:32:15 PM
De todos modos lo que mas me preocupa es la velocidad, ya daria prioridad a esto, todo va muy muy lento, en las cargas y demás.
Esto de la velocidad de carga es también culpa de la lectura de archivos de la psp desde la toolchain, he probado algunos juegos portados de SDL PC a SDL psp y les pasa lo mismo, tardan taco en cargar pero luego van bien, como no lo arreglen los que hicieron el porl de SDL psp la llevamos clara también.
En cuanto a lo de que el "set_fps(loquesea,0)" vaya tan lento en psp en vez de ir como en pc, para esto no tengo explicación, creo que sí tiene que ser culpa de bennu, tengo que analizar el código de esta función para intentar detectar el problema, pero bueno, se arregla con poner set_fps(loquesea,3). Un simple if en tu código prg lo arreglaría.
frameskip=0;
if (OS_ID==OS_PSP)
frameskip=3;
end
set_fps(25,frameskip);
Para lo del ensanchado de resoluciones distintas a la nativa de la psp,( también problema de SDL PSP) se puede arreglar también por código prg.
if (OS_ID==OS_PSP)
scale_resolution = 04800240;
end
Tenemos que pensar que ningún .prg que no esté pensado para correr en psp va a ser portado directamente a psp, tenemos que tocar algo de código .prg debido a las características técnicas de la psp, pero bueno esto es como siempre ha pasado para otros ports de nuevas plataformas de bennu.
Vale, este finde intentaré adaptar alguna demo a psp con tu port para ver si ya tira perfecto con lo que tengas ahora mismo ;)
Quote from: FreeYourMind on February 03, 2011, 11:16:11 PM
Vale, este finde intentaré adaptar alguna demo a psp con tu port para ver si ya tira perfecto con lo que tengas ahora mismo ;)
ah, guais, estoy intentando depurar echo, pero está to complejo, este Drumpi, no veas como complica las cosas, con signals y variables globales :D.
Jajaja ¿Echo complicado? :D
Bueno, sí, un poco sí que lo es, pero dentro del desastre está bastante bien organizado ^^U
Puedes empezar probando el motor de tiles v3 que andaba en un hilo por ahí, que es el que uso en Echo. Si eso funciona, puedes descartar los ficheros add_tile, tscroll y tmap (con extensión .h y .inc). Por lo general, las variables globales están en los .h y sólo las usan sus respectivos.inc, salvo que sean genéricos del juego.
SBTime es algo más sencillo, pero necesitas un ratón para hacerlo funcionar :D
Respecto a ficheros de test, en Bennu tengo muy pocos, la mayoría los hice en Fenix para ver cómo iban algunas funciones y hacer algunas conversiones, pero son un caos, no sé si te iban a servir (son programas cortos, para probar una función o dos, generalmente usando un fichero externo).
De paso, un nuevo karma al esfuerzo.
Callejón sin salida.
A ver si alguno tiene idea del por qué
type t_mapa
//datos del mapa
int version;
int filas;
int columnas;
int capas;
int tipo_dato;
int ancho_tile;
int alto_tile;
int desplaz_tile; //para scroll normal, desplazamiento vertical de cada capa
//para scroll isom�trico, altura hacia arriba
string fpg;
word tipo_mapa;
//contenido del mapa
byte pointer b_mapa;
word pointer w_mapa;
<b> int pointer i_mapa; </b>
int fpg_mapa;
//gestion de mapas (por si se almacenan los datos en lista enlazada)
int id;
t_mapa pointer sig;
byte null2;
end
process load_tmf (string tmf_carga, t_mapa pointer tmf_mapa)
private
id_tmf;
cont;
cont2;
byte dato;
word dato2;
int dato3;
string magic;
filas;
columnas;
capas;
tam_dato;
guardado_correcto;
<b> int *puntero_datos;</b>
int tamanio =3800;
begin
[tmf_mapa].tipo_mapa=1;
guardado_correcto=false;
if (file_exists(tmf_carga))
id_tmf=fopen(tmf_carga,o_read);
if (id_tmf==0) return 0; end;
//LECTURA CAMPO MAGIC
cont=0;
for (cont=0;cont<16;cont++)
fread(id_tmf,dato);
magic=magic+chr(dato);
end
if (magic=="TileMapFile "+chr(26)+chr(13)+"\n")
//LECTURA DE LA VERSION
fread(id_tmf,dato3);
[tmf_mapa].version=dato3;
//LECTURA DE FILAS, COLUMNAS Y CAPAS
fread(id_tmf,dato3);
columnas=dato3;
[tmf_mapa].columnas=dato3;
fread(id_tmf,dato3);
filas=dato3;
[tmf_mapa].filas=dato3;
fread(id_tmf,dato3);
capas=dato3;
[tmf_mapa].capas=dato3;
cont2=columnas*filas*capas;
//LECTURA DE TIPO DE DATO
fread(id_tmf,dato3);
tam_dato=dato3;
[tmf_mapa].tipo_dato=dato3;
//LECTURA DE ANIMACIONES (temporalmente disabled)
fread(id_tmf,dato3);
//ZONA DE DATOS
switch (tam_dato)
case 0:
print_debug("CASE O");
[tmf_mapa].b_mapa=alloc(cont2);
print_debug("ALLOC 0");
end
case 1:
print_debug("CASE 1");
[tmf_mapa].w_mapa=alloc(cont2*sizeof(word));
print_debug("ALLOC 1");
end
case 2:
print_debug("CASE 2");
<b> //[tmf_mapa].i_mapa=alloc(cont2*sizeof(int)); </b> <-- esto cuelga la PSP, pero en PC va
<b> puntero_datos=alloc(tamanio*sizeof(int));</b> <-- esto no cuelga la PSP
print_debug("Despues de ALLOC");
<b> (*tmf_mapa).i_mapa=puntero_datos; </b> <-- esto cuelga la PSP, pero en PC va
<b> //tmf_mapa.i_mapa=puntero_datos; </b> <-- esto cuelga la PSP, pero en PC va
<b> //[tmf_mapa].i_mapa=puntero_datos; </b> <-- esto cuelga la PSP, pero en PC va
end
end
print_debug("despues de ALLOC");
cont=1;
for (cont;cont<=cont2;cont++)
switch (tam_dato)
case 0:
fread(id_tmf,dato);
[tmf_mapa].b_mapa[cont-1]=dato;
end
case 1:
fread(id_tmf,dato2);
[tmf_mapa].w_mapa[cont-1]=dato2;
end
case 2:
fread(id_tmf,dato3);
[tmf_mapa].i_mapa[cont-1]=dato3;
end
end
end
print_debug("despues for CONT");
guardado_correcto=true;
end
print_debug("ANTES FCLOSE");
fclose(id_tmf);
end
print_debug("ANTES RETURN");
return (guardado_correcto);
frame;
end
Creía que fallaba la función alloc en psp, pero no es así, parece que falla la asignacion de un puntero con otro.
Me tiene todo escamao, ¿será problema de ámbito?
No he tenido tiempo de probarte nada.
y como la llamas?
pues la llamo así
.....
//VARIABLES DINAMICAS PARA CARGA DE NIVEL Y DUREZAS
//word pointer nivel;
//byte pointer durezas;
t_mapa nivel;
t_mapa durezas;
...
...
...
load_tmf("IFenixD.tmf",&nivel);
print_debug("**despues de tmf IFenixD");
load_tmf("IFenix2.tmf",&durezas);
print_debug("**despues de tmf IFenix2");
....
lo mosqueante es que funciona en el PC perfectamente y en la psp el mismo dcb la cuelga.
en pc va bien, y da los resultados esperados? o solo no se cuelga?
puede ser alguna de las cosas que le has puesto valores por default en el compilador, no se que tan diferente es la version psp de la oficial.
ya pensé eso, y probé la version monolítica de linux para ver si fallaba y nada, no falla,
también pensé en los parámetros y probé unos cuantos bgdis compilados con parámetros distintos, como -00, -02 -fno-strict-aliasing, -0S -fno-strict-aliasing, -03 -fno-strict-aliasing, y nada.
Una cosa que me escama es que tengo que compilar con -G1, o -G2, o -G3, si no pongo ninguno o pongo un g superior a 3 falla el linkado con el siguiente problema:
build_psp/src/strings.o: En la función `string_format':
strings.c:(.text+0x554): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
build_psp/src/sysprocs.o: En la función `get_var_info':
sysprocs.c:(.text+0x1444): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
sysprocs.c:(.text+0x15ec): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
sysprocs.c:(.text+0x1b44): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
sysprocs.c:(.text+0x1cf4): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
sysprocs.c:(.text+0x2194): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
sysprocs.c:(.text+0x23ec): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
sysprocs.c:(.text+0x2504): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
build_psp/src/dirs.o: En la función `dir_open':
dirs.c:(.text+0x354): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
build_psp/src/mod_debug.o: En la función `get_token':
mod_debug.c:(.text+0x4b8): reubicación truncada para ajustar: R_MIPS_GPREL16 contra `__ctype_ptr'
build_psp/src/regex.o: En la función `regex_compile':
regex.c:(.text+0xa48): se omitieron desbordamientos de reubicación adicionales de la salida
collect2: ld devolvió el estado de salida 1
make: *** [bgdi.elf] Error 1
los parámetros con los que compilo son:
-Wall -Os -fno-strict-aliasing -DTARGET_PSP -D__STATIC__ -DDISABLE_X11 -D__BGDRTM__ -DVERSION=\"1.0.0\" -D__LITE__=$(LITTLE_VERSION) \
-I$(BUILD_DIR)/src -DJOY_YES $(shell $(PSPBIN)/sdl-config --cflags) -DSTDC_HEADERS
y linko con:
-lz -lpng -lSDL_mixer -logg -lvorbis -lvorbisidec -lsmpeg -lstdc++ -L$(OSSL_INSTALL_DIR) -lcrypto -L/SDKs/pspdev/psp/lib -lSDLmain -lSDL -lm -lGL -lpspvfpu -L/SDKs/pspdev/psp/sdk/lib -lpspdebug -lpspgu -lpspctrl -lpspge -lpspdisplay -lpsphprm -lpspsdk -lpsprtc -lpspaudio -lc -lpspuser -lpsputility -lpspkernel -lpspnet_inet -lpspirkeyb -lpsppower
ni idea... que loco eso.
Es la primera vez que veo definir un puntero a enteros como
int *puntero
Pensé que la nomenclatura era:
int pointer puntero
No sé si es lo mismo o no.
es lo mismo.
jo, pues estamos buenos, ¿alguna idea de como probar o testear esto?
Me da a mi que si solvento esto ya irian todos los juegos en la psp.
Por otro lado, splinter,¿ como puedo corregir la lentitud de setfps(loquesea,0)? ¿qué funciones tengo que estudiarme?
He visto que hiciste cosas diferentes para wiz y caano referente a timers pero no se si está esto relaccionado con lo mismo.
no entiendo que queres corregir.
En WIZ/CAANOO se tocó algo de los FPS, pero eso provoca que vaya más rápido de lo normal (al menos, en GP2X). Si en PSP te va a distinta velocidad, cambialo para que con el OS_ID de PSP lo regule como si fuera un PC... y luego me dices cómo se hace para probarlo en mi port de GP2X ;D
Es por un tratamiento distinto en los tiempos en las consolas de GPH (¿chapuzas del firm oficial?)
um, pues algo de eso debe pasar en psp, pero justo lo contrario. Un .dcb en PC va mucho más rápido que en PSP usando el mismo fps, la única solucion que encontré fue ponerle frameskip 3, con eso ya va igual en los dos sistemas.
La cosa es que usa sdl_delay, como en el PC, osea que puede ser culpa de esa función o no, no se.
Quote from: Drumpi on February 08, 2011, 01:13:30 AM
En WIZ/CAANOO se tocó algo de los FPS, pero eso provoca que vaya más rápido de lo normal (al menos, en GP2X). Si en PSP te va a distinta velocidad, cambialo para que con el OS_ID de PSP lo regule como si fuera un PC... y luego me dices cómo se hace para probarlo en mi port de GP2X ;D
Es por un tratamiento distinto en los tiempos en las consolas de GPH (¿chapuzas del firm oficial?)
drumpi, como bien dijiste, el cambio es solo para wiz y caanoo, en todas las demas plataformas ese codigo no existe, incluso es diferente entre wiz y caanoo.
Quote from: DCelso on February 08, 2011, 01:18:03 AM
um, pues algo de eso debe pasar en psp, pero justo lo contrario. Un .dcb en PC va mucho más rápido que en PSP usando el mismo fps, la única solucion que encontré fue ponerle frameskip 3, con eso ya va igual en los dos sistemas.
La cosa es que usa sdl_delay, como en el PC, osea que puede ser culpa de esa función o no, no se.
y con fps(0,0) como va?
aca tenes 2 cosas...
1) que la psp no le de el cuero como en una PC, cosas mas que logica.
2) que suceda lo mismo que sucedia en wiz/caanoo con la SDL_delay, en realidad con los timers del sistema que tienen una granularidad mayor de lo necesaria.
pues como se arreglaría lo segundo? lo de la granulidad.
Quote from: DCelso on February 08, 2011, 01:18:03 AM
um, pues algo de eso debe pasar en psp, pero justo lo contrario. Un .dcb en PC va mucho más rápido que en PSP usando el mismo fps, la única solucion que encontré fue ponerle frameskip 3, con eso ya va igual en los dos sistemas.
La cosa es que usa sdl_delay, como en el PC, osea que puede ser culpa de esa función o no, no se.
A mi, eso, me suena más a falta de potendia que a otra cosa ¿qué programa estás probando?
Quote from: SplinterGU on February 08, 2011, 01:18:28 AM
drumpi, como bien dijiste, el cambio es solo para wiz y caanoo, en todas las demas plataformas ese codigo no existe, incluso es diferente entre wiz y caanoo.
Ya, pero como el port está hecho como si fuera una WIZ... no he tocado los flags de compilación, sólo las direcciones. Tengo que crear un nuevo OS_ID y añadirlo a tooodo el código, y va a ser un trabajo memorable sin conocerlo ^^U
Quote from: DCelso on February 08, 2011, 01:31:36 AM
pues como se arreglaría lo segundo? lo de la granulidad.
viendo como usar otro tipo de timers, pero primero tenes que confirmar que sea eso, proba con fps(0,0)...
Quote from: Drumpi on February 08, 2011, 01:32:52 AM
Quote from: DCelso on February 08, 2011, 01:18:03 AM
um, pues algo de eso debe pasar en psp, pero justo lo contrario. Un .dcb en PC va mucho más rápido que en PSP usando el mismo fps, la única solucion que encontré fue ponerle frameskip 3, con eso ya va igual en los dos sistemas.
La cosa es que usa sdl_delay, como en el PC, osea que puede ser culpa de esa función o no, no se.
A mi, eso, me suena más a falta de potendia que a otra cosa ¿qué programa estás probando?
Quote from: SplinterGU on February 08, 2011, 01:18:28 AM
drumpi, como bien dijiste, el cambio es solo para wiz y caanoo, en todas las demas plataformas ese codigo no existe, incluso es diferente entre wiz y caanoo.
Ya, pero como el port está hecho como si fuera una WIZ... no he tocado los flags de compilación, sólo las direcciones. Tengo que crear un nuevo OS_ID y añadirlo a tooodo el código, y va a ser un trabajo memorable sin conocerlo ^^U
lamento decirte, pero el codigo psp no puede estar hecho como wiz, si lo estuviera, posiblemente crashearia.
si te referis a la gp2x, yo diria que no lo hagas, ademas dicha version no es oficial, yo no pongo las manos en el juego por eso... pero como sea, se estaba hablando de la version psp, y no esta bueno dar pistas que despistas, mencionando que el problema de velocidad de la psp puede deberse al cambio para wiz/caanoo.
no se si me explico.
A ver, yo me refería a la GP2X, y no, no hice su propia versión con su OS_ID porque, como me indicaste en su día, estaba probando a ver si iba con el código de WIZ porque usa un HW y SW muy similar. Obviamente tengo que cambiar el OS_ID en la versión final.
También lo decía porque DCelso andaba probando también con el port a GP2X, y me parece, intuyo, que ha usado los mismos flags que yo, que son los de WIZ, por eso, me parece, que está usando los tiempos de WIZ para el port a PSP, y si hubo cambios para arreglar la velocidad en WIZ, puede estar afectando a ambos ports, al de PSP y al mío de GP2X. Sólo eso ;)
a ver, yo definí variables para PSP, para control de GP2X, ya existe en el código oficial, y la reutilizé para hacer que funcione igual que caanoo y/o wiz cuando creí que era necesario, en el código oficial hay unos cuantos ifdef target_gp2x_wiz y unos cuantos if defined target_gp2x_wiz || defined target_caanoo, así que añadí a estos ifs el target_gp2x.
Por consiguiente bennu compila exactamente igual para gp2x que para gp2x_wiz.
En cuanto a psp, pues no tira por esos ifs, así que lo referente a timers, hace lo mismo que para linux o windows.
Voy a probar lo de setfps(0,0) pero, ¿qué tiene que pasar para saber si van bien los timers o no?
Acias de antemano.
Eso tu, yo no he modificado nada del código de Bennu en mi port :D (así me va :P).
Si lo pones a set_fps(0,0) debería irte mucho más rápido que lo que te va ahora. Es para descartar que vaya lento por falta de potencia.
drumpi, es imposible que le vaya el codigo si usa las modificaciones de los timers que tiene la wiz o la caanoo.
le va a crashear a penas arrancar.
y evidentemente no los tiene.
Quote from: DCelso on February 09, 2011, 02:48:04 PM
a ver, yo definí variables para PSP, para control de GP2X, ya existe en el código oficial, y la reutilizé para hacer que funcione igual que caanoo y/o wiz cuando creí que era necesario, en el código oficial hay unos cuantos ifdef target_gp2x_wiz y unos cuantos if defined target_gp2x_wiz || defined target_caanoo, así que añadí a estos ifs el target_gp2x.
Por consiguiente bennu compila exactamente igual para gp2x que para gp2x_wiz.
En cuanto a psp, pues no tira por esos ifs, así que lo referente a timers, hace lo mismo que para linux o windows.
Voy a probar lo de setfps(0,0) pero, ¿qué tiene que pasar para saber si van bien los timers o no?
Acias de antemano.
simplemente correr mas rapido que con lo que vos decis le falta velocidad.
Pues yo he compilado con estas definiciones de variables:
Firm Open2X:
#!/bin/sh
## -- OPEN2X USER SETTINGS
## OPEN2X - This should point to the root of your tool-chain {i.e. folder above the BIN dir}
OPEN2X=/opt/open2x/gcc-4.1.1-glibc-2.3.6
## HOST and TARGET - These should be the canonical tool names of your tool.
## For the sake of this script HOST and TARGET should be the same.
## Defaults would be 'arm-open2x-linux' for a normal Open2x tool-chain.
HOST=arm-open2x-linux
TARGET=arm-open2x-linux
BUILD=`uname -m`
PKG_CONFIG_PATH=/opt/open2x/gcc-4.1.1-glibc-2.3.6/arm-open2x-linux/lib/pkgconfig
## -- END OPEN2X USER SETTINGS
export OPEN2X
export HOST
export TARGET
export PKG_CONFIG_PATH
PREFIX=$OPEN2X
export PREFIX
PATH=$PATH:$OPEN2X/bin
export PATH
#ln -s `whereis -b pkg-config | sed 's/pkg-config\: //g'` /opt/open2x/gcc-4.1.1-glibc-2.3.6/arm-open2x-linux/bin/pkg-config
# Do not edit below here
CC="${OPEN2X}/bin/${HOST}-gcc"
CXX="${OPEN2X}/bin/${HOST}-g++"
AR="${OPEN2X}/bin/${HOST}-ar"
STRIP="${OPEN2X}/bin/${HOST}-strip"
RANLIB="${OPEN2X}/bin/${HOST}-ranlib"
CFLAGS="-DTARGET_GP2X_WIZ -O2 -ffast-math -fomit-frame-pointer -mcpu=arm920t -DARM -D_ARM_ASSEM_ -I${OPEN2X}/include -I${OPEN2X}/include/libxml2 -I${OPEN2X}/include/SDL"
LDFLAGS="-L${OPEN2X}/lib"
PKG_CONFIG="${OPEN2X}/bin/pkg-config"
export CC
export CXX
export AR
export STRIP
export RANLIB
export CFLAGS
export LDFLAGS
export PKG_CONFIG
echo Current settings.
echo
echo Install root/Working dir = $OPEN2X
echo Tool locations = $OPEN2X/bin
echo Host/Target = $HOST / $TARGET
echo
echo CC = $CC
echo CXX = $CXX
echo AR = $AR
echo STRIP = $STRIP
echo RANLIB = $RANLIB
echo CFLAGS = $CFLAGS
echo LDFLAGS = $LDFLAGS
echo PKG_CONFIG = $PKG_CONFIG
#cd vendor/des-4.04b; make -f Makefile.openwiz clean all install; cd -
#cd core; ./configure --prefix=${PREFIX} --target=${TARGET} --host=${HOST} --build=${BUILD} --enable-shared ; make -f Makefile; cd -
echo ""
echo "Now do:"
echo "cd project"
echo './configure --prefix=${PREFIX} --target=${TARGET} --host=${HOST} --build=${BUILD} --enable-shared'
Firm oficial
#!/bin/sh
## -- OPEN2X USER SETTINGS
## OPEN2X - This should point to the root of your tool-chain {i.e. folder above the BIN dir}
OPEN2X=/opt/sdkoficial2
#OPEN2X=/opt/sdkoficial
## HOST and TARGET - These should be the canonical tool names of your tool.
## For the sake of this script HOST and TARGET should be the same.
## Defaults would be 'arm-open2x-linux' for a normal Open2x tool-chain.
HOST=arm-gp2x-linux
TARGET=arm-gp2x-linux
BUILD=`uname -m`
PKG_CONFIG_PATH=/opt/sdkoficial2/arm-gp2x-linux/lib/pkgconfig
#HOST=arm-linux
#TARGET=arm-linux
#BUILD=`uname -m`
#PKG_CONFIG_PATH=/opt/sdkoficial/arm-linux/lib/pkgconfig
## -- END OPEN2X USER SETTINGS
export OPEN2X
export HOST
export TARGET
export PKG_CONFIG_PATH
PREFIX=$OPEN2X
export PREFIX
PATH=$PATH:$OPEN2X/bin
export PATH
#ln -s `whereis -b pkg-config | sed 's/pkg-config\: //g'` /opt/openwiz/toolchain/arm-openwiz-linux-gnu/bin/pkg-config
# Do not edit below here
CC="${OPEN2X}/bin/${HOST}-gcc"
CXX="${OPEN2X}/bin/${HOST}-g++"
AR="${OPEN2X}/bin/${HOST}-ar"
STRIP="${OPEN2X}/bin/${HOST}-strip"
RANLIB="${OPEN2X}/bin/${HOST}-ranlib"
CFLAGS="-DTARGET_GP2X_WIZ -O2 -ffast-math -fomit-frame-pointer -mcpu=arm920t -DARM -D_ARM_ASSEM_ -I${OPEN2X}/include -I${OPEN2X}/include/libxml2 -I${OPEN2X}/include/SDL"
LDFLAGS="-L${OPEN2X}/lib"
PKG_CONFIG="${OPEN2X}/bin/pkg-config"
export CC
export CXX
export AR
export STRIP
export RANLIB
export CFLAGS
export LDFLAGS
export PKG_CONFIG
echo Current settings.
echo
echo Install root/Working dir = $OPEN2X
echo Tool locations = $OPEN2X/bin
echo Host/Target = $HOST / $TARGET
echo
echo CC = $CC
echo CXX = $CXX
echo AR = $AR
echo STRIP = $STRIP
echo RANLIB = $RANLIB
echo CFLAGS = $CFLAGS
echo LDFLAGS = $LDFLAGS
echo PKG_CONFIG = $PKG_CONFIG
#cd vendor/des-4.04b; make -f Makefile.openwiz clean all install; cd -
#cd core; ./configure --prefix=${PREFIX} --target=${TARGET} --host=${HOST} --build=${BUILD} --enable-shared ; make -f Makefile; cd -
echo ""
echo "Now do:"
echo "cd project"
echo './configure --prefix=${PREFIX} --target=${TARGET} --host=${HOST} --build=${BUILD} --enable-shared'
Aparte de eso no he cambiado ni una sóla línea de ningún código o fichero, y os digo, me funcionan ambos en mi negrita, pero eso, cuando puede, se acelera muchísimo, es la única consecuencia de usar los timers de WIZ (lo supongo, porque tengo en los CFLAGS la constante -DTARGET_GP2X_WIZ).
seguramente deberias ver cuales son los timers de gp2x, si encuentro info actualizo el codigo.
test de fps(0,0).
He probado el temp1.prg del scrolltileado de Drumpi adaptado para psp y solucionando el problema de bloqueo y el resultado es el siguiente:
en PC da unos 90 fps de media y en PSP da unos 35 fps de media.
El problema de bloqueo de la psp parece encontrarse al hacer alloc y guardar el contenido en un campo puntero a tipo int a un puntero de un type.
A ver si llego a un ejemplo básico que se centre en probar justo eso.
También a ver si pongo las modificaciones que hice para GP2X y que nos las valide Splinter.
Problema encontrado:
Esto va perfecto en la PSP:
program demo_compatible_tiled_scroll;
type t_mapa
<b>int tipo_mapa; </b>
int pointer i_mapa;
end
GLOBAL
_jkey_UP = 8;
_jkey_UPLEFT = 8;
_jkey_LEFT = 7;
_jkey_DOWNLEFT = 6;
_jkey_DOWN = 6;
_jkey_DOWNRIGHT = 6;
_jkey_RIGHT = 9;
_jkey_UPRIGHT = 9;
_JKEY_START = 11;
_jkey_SELECT = 10;
_jkey_L = 4;
_jkey_R = 5;
_jkey_A = 2;
_jkey_B = 1;
_jkey_X = 0;
_jkey_Y = 3;
_jkey_VOLUP = 12;
_jkey_VOLDOWN = 13;
t_mapa tmapa;
END
process load_tmf (string tmf_carga)
private
cont2=3800;
begin
tmapa.i_mapa=alloc(cont2*sizeof(int));
return 1;
end
private
string dir_mapa;
int error2;
begin
set_mode(480,240,16);
set_fps(0,0);
dir_mapa="IFenixD.tmf";
error2=load_tmf(dir_mapa);
end
Esto bloquea la PSP
program demo_compatible_tiled_scroll;
type t_mapa
<b>word tipo_mapa;</b>
int pointer i_mapa;
end
GLOBAL
_jkey_UP = 8;
_jkey_UPLEFT = 8;
_jkey_LEFT = 7;
_jkey_DOWNLEFT = 6;
_jkey_DOWN = 6;
_jkey_DOWNRIGHT = 6;
_jkey_RIGHT = 9;
_jkey_UPRIGHT = 9;
_JKEY_START = 11;
_jkey_SELECT = 10;
_jkey_L = 4;
_jkey_R = 5;
_jkey_A = 2;
_jkey_B = 1;
_jkey_X = 0;
_jkey_Y = 3;
_jkey_VOLUP = 12;
_jkey_VOLDOWN = 13;
t_mapa tmapa;
END
process load_tmf (string tmf_carga)
private
cont2=3800;
begin
tmapa.i_mapa=alloc(cont2*sizeof(int));
return 1;
end
private
string dir_mapa;
int error2;
begin
set_mode(480,240,16);
set_fps(0,0);
dir_mapa="IFenixD.tmf";
error2=load_tmf(dir_mapa);
end
Parece problema de alineación.
Ahora falta corregirlo :(, a ver si lo encuentro porque esto me imagino que va a ser chungo de encontrar, por el momento, para la psp, habrá que evitar el word en types o meter dups.
Voy a probar.
Efectivamente, esto no bloquea la psp.
program demo_compatible_tiled_scroll;
type t_mapa
<b>word tipo_mapa;</b>
<b>word dup1;</b>
int pointer i_mapa;
end
GLOBAL
_jkey_UP = 8;
_jkey_UPLEFT = 8;
_jkey_LEFT = 7;
_jkey_DOWNLEFT = 6;
_jkey_DOWN = 6;
_jkey_DOWNRIGHT = 6;
_jkey_RIGHT = 9;
_jkey_UPRIGHT = 9;
_JKEY_START = 11;
_jkey_SELECT = 10;
_jkey_L = 4;
_jkey_R = 5;
_jkey_A = 2;
_jkey_B = 1;
_jkey_X = 0;
_jkey_Y = 3;
_jkey_VOLUP = 12;
_jkey_VOLDOWN = 13;
t_mapa tmapa;
END
process load_tmf (string tmf_carga)
private
cont2=3800;
begin
tmapa.i_mapa=alloc(cont2*sizeof(int));
return 1;
end
private
string dir_mapa;
int error2;
begin
set_mode(480,240,16);
set_fps(0,0);
dir_mapa="IFenixD.tmf";
error2=load_tmf(dir_mapa);
end
tooma, alineé los types del echo y va en la psp, fallan colores, y teclas, pero era de suponer, seguiré trasteando :D.
pero no es la solucion...
psp, tiene linux?
busca en internet alineamientos, puede que tengas que setear algo como se hace en wiz/caanoo con el echo cpu algo...
con respecto a los fps, cuante te daba con la otra que le tenias que poner skip 3?
logicamente no es problema de timers, es problema de que no le da la potencia a la psp para ejecutar todo esto, quizas porque la SDL de psp no sea un buen port o tambien porque no estamos aprovechando nada de la acceleracion de video de la psp.
lamento no poder ayudar.
ya busqué, como no sea algún parámetro del compilador no hay nada, no viene con linux tampoco :(.
puede ser del compilador, aunque por la forma de accesar de las variables en cuestion no lo es... asi que tiene que ser como el procesador alinea los accesos.
por el momento te recomiendo no usar ningun tipo de datos que sean de diferente tamaño que un int (4 bytes), pero me temo que si hay algo interno que use algun dato de tamaño menor, tambien pueda reventar.
aro, lo suyo sería hacerlo transparente al usuario e intentar alinear los types en tiempo de compilación, desde el bgdc, o en tiempo de ejecución desde el bgdi de la PSP. Estoy buscando a ver como trata los types el sistema, pero ando un poco perdido por ahora. :D
También tengo pendiente poner los cambios que le puse al código para gpx2. y subir el echo de drumpi compilado para psp :D.
Quote from: DCelso on February 12, 2011, 09:17:39 AM
aro, lo suyo sería hacerlo transparente al usuario e intentar alinear los types en tiempo de compilación, desde el bgdc, o en tiempo de ejecución desde el bgdi de la PSP. Estoy buscando a ver como trata los types el sistema, pero ando un poco perdido por ahora. :D
También tengo pendiente poner los cambios que le puse al código para gpx2. y subir el echo de drumpi compilado para psp :D.
evidentemente tengo un problema para explicar las cosas... algunos procesadores (como ser el caso del wiz o caanoo, y me suena que tambien es el caso de la psp, por los sintomas) tienen un modo de operacion donde las direcciones de acceso se aliean automaticamente a direcciones multiplos de 32bits (o el tamaño de la palabra del procesador), y por ende, por mas que uno quiera acceder a una direccion fuera de esta caracteristica, el procesador ignorara dicha direccion y accedera a la direccion alineada... con lo cual, si el area reservada es mejor o no esta alineada (cosa logica si nosotros accedemos a un area RAW donide cada offset es una variable), entonces tendremos problemas porque se llenarian/leerian datos donde/desde no deben...
en wiz/caanoo hay una variable del kernel que se setea antes de lanzar el programa y entonces el kernel switchea el modo antes de cargar dicha aplicacion.
este alineamiento automatico se hace para ganar performance.
quizas esta explicacion te aclare un poco que pasa...
http://www.daniweb.com/forums/thread73230.html
evidentemente si no hay forma de cambiar ese "escalado" por defecto que hace el procesador, bennugd no puede ser 100% compatible... y quizas los problemas que tenes con colores extraños en video y demas, se deba a esto... y cuando esto este solucionado, quizas tus parches dejen de funcionar... no se, cualquier cosa puede pasar.
El tema de los colores ya ha sido explicado en este foro...
ok, gracias por la explicación, entonces desde gcc no se podría solventar la papeleta ¿no?
Buscaré info por el sdk de psp por si hay alguna función o algo para establecer ese parámetro a la cpu.
quizas, haciendo algo de esto en el código...,
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Variable-Attributes.html
pues no es problema de compilacion, por el contrario, el problema sucede porque los datos estan alineados a 1 byte...
en psp por lo que consegui investigar el direccionamiento se alinea a 16bits... parece ser un tema de los mips, asi que supongo que tambien puede ser el problema de los wav en dingux.
o quizas nada que ver...
Quote from: SplinterGU on February 11, 2011, 01:10:02 AM
pero no es la solucion...
psp, tiene linux?
busca en internet alineamientos, puede que tengas que setear algo como se hace en wiz/caanoo con el echo cpu algo...
con respecto a los fps, cuante te daba con la otra que le tenias que poner skip 3?
logicamente no es problema de timers, es problema de que no le da la potencia a la psp para ejecutar todo esto, quizas porque la SDL de psp no sea un buen port o tambien porque no estamos aprovechando nada de la acceleracion de video de la psp.
lamento no poder ayudar.
Splinter, tem razao. É de conhecimento geral que SDL no PSP nao tem bom desempenho. Nao sei dizer o por que. Talvez seja o caso de reescrever alguns modulos usando diretamente as funcoes do PSP e nao chamando SDL. Vou pesquisar sobre isso e depois posto aqui no forum.
Quote from: danielt3 on February 14, 2011, 03:55:25 PM
Quote from: SplinterGU on February 11, 2011, 01:10:02 AM
pero no es la solucion...
psp, tiene linux?
busca en internet alineamientos, puede que tengas que setear algo como se hace en wiz/caanoo con el echo cpu algo...
con respecto a los fps, cuante te daba con la otra que le tenias que poner skip 3?
logicamente no es problema de timers, es problema de que no le da la potencia a la psp para ejecutar todo esto, quizas porque la SDL de psp no sea un buen port o tambien porque no estamos aprovechando nada de la acceleracion de video de la psp.
lamento no poder ayudar.
Splinter, tem razao. É de conhecimento geral que SDL no PSP nao tem bom desempenho. Nao sei dizer o por que. Talvez seja o caso de reescrever alguns modulos usando diretamente as funcoes do PSP e nao chamando SDL. Vou pesquisar sobre isso e depois posto aqui no forum.
Puede que sea una buena idea. Por poner un ejemplo, la SDL para Wii no maneja del todo bien los joysticks (Wiimotes) así que después de exámenes voy a tener que mejorar el soporte yo mismo.
Quote from: josebita on February 14, 2011, 05:10:44 PM
Quote from: danielt3 on February 14, 2011, 03:55:25 PM
Quote from: SplinterGU on February 11, 2011, 01:10:02 AM
pero no es la solucion...
psp, tiene linux?
busca en internet alineamientos, puede que tengas que setear algo como se hace en wiz/caanoo con el echo cpu algo...
con respecto a los fps, cuante te daba con la otra que le tenias que poner skip 3?
logicamente no es problema de timers, es problema de que no le da la potencia a la psp para ejecutar todo esto, quizas porque la SDL de psp no sea un buen port o tambien porque no estamos aprovechando nada de la acceleracion de video de la psp.
lamento no poder ayudar.
Splinter, tem razao. É de conhecimento geral que SDL no PSP nao tem bom desempenho. Nao sei dizer o por que. Talvez seja o caso de reescrever alguns modulos usando diretamente as funcoes do PSP e nao chamando SDL. Vou pesquisar sobre isso e depois posto aqui no forum.
Puede que sea una buena idea. Por poner un ejemplo, la SDL para Wii no maneja del todo bien los joysticks (Wiimotes) así que después de exámenes voy a tener que mejorar el soporte yo mismo.
y si aportas esos cambios a la SDL oficial y de paso aprovechas para publicitar a bennugd ahi, quizas en la lista de lenguajes que usan SDL... seria grandioso.
Quote from: SplinterGU on February 14, 2011, 05:31:05 PM
Quote from: josebita on February 14, 2011, 05:10:44 PM
Quote from: danielt3 on February 14, 2011, 03:55:25 PM
Quote from: SplinterGU on February 11, 2011, 01:10:02 AM
pero no es la solucion...
psp, tiene linux?
busca en internet alineamientos, puede que tengas que setear algo como se hace en wiz/caanoo con el echo cpu algo...
con respecto a los fps, cuante te daba con la otra que le tenias que poner skip 3?
logicamente no es problema de timers, es problema de que no le da la potencia a la psp para ejecutar todo esto, quizas porque la SDL de psp no sea un buen port o tambien porque no estamos aprovechando nada de la acceleracion de video de la psp.
lamento no poder ayudar.
Splinter, tem razao. É de conhecimento geral que SDL no PSP nao tem bom desempenho. Nao sei dizer o por que. Talvez seja o caso de reescrever alguns modulos usando diretamente as funcoes do PSP e nao chamando SDL. Vou pesquisar sobre isso e depois posto aqui no forum.
Puede que sea una buena idea. Por poner un ejemplo, la SDL para Wii no maneja del todo bien los joysticks (Wiimotes) así que después de exámenes voy a tener que mejorar el soporte yo mismo.
y si aportas esos cambios a la SDL oficial y de paso aprovechas para publicitar a bennugd ahi, quizas en la lista de lenguajes que usan SDL... seria grandioso.
Pensaba parchear el port de SDL para Wii (que no es oficial) aquí (http://code.google.com/p/sdl-wii/). Puede que -si no es demasiado trabajo- intente portar SDL1.3 también, ahora que parece que el API es casi definitivo. En cualquier caso, les mandaré los parches y sí, subiré el bennu a la web de SDL.
bueno, como sea, mientras los cambios no queden solo en nuestro entorno es grandioso...
gracias joseba!
splinter, eso mismo iba a decir yo, será un magnífico aporte para wii, gracias josebas.
Splinter, tenías razón, algo interno está desalineado, o creo que es eso, jugando al echo en la psp se me ha colgado la psp en mitad del juego, al matar a unos cuantos enemigos, y he comprobado que todos los types y structs que usa estén alineados. Así que :'(. Investigaré más pero tiene mala pinta el poder portar al completo bennu a psp.
lo que tenes que investigar es trap alignment pero en mipsel, no se como se llamara ahi... pero si se que lo hace, y alinea los direccionamientos a 16bits...
la cuestion es como saltar eso... mira, aca te paso un articulo, pero de arm... para que entiendas la cosa...
http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment
lo que hay que hacer es buscar lo mismo en mipsel, pero paso me sirve para dingux... aunque en dingux quizas lo solvente con el mismo echo 2> /proc/cpu/alignment que uso en wiz y caanoo.
Quote from: SplinterGU on March 02, 2011, 03:39:46 PM
DCelso, por que no chequeas si no te esta pasando el problema que le pasa a josebita con la libz en wii, proba compilar sin soporte de comprimidos y poniendo todos los recursos sin comprimir.
perdon por no responder en ingles, se pierden algunas cosas en la traduccion y ultimamente esta costando un poco que nos entendamos por escribir en ingles.
PD: jejeje, al mismo tiempo escribimos justificandonos por poner las cosas en español... ;)
Y ¿como sería eso? ¿que pongo al compilar?
hay un thread que digo que hay que poner, pero es tan simple como poner en cflags -DNO_ZLIB o algo asi, si miras el codigo de common/files.c lo vas a ver simple
¿que le pasa a josebita en wii?
Yo creo que no es eso porque lo que me pasa a mi es que se me cuelga la psp con alguna música y con las structs no alineadas pero voy a probar.
Gracias splintergu, sí eso lo ví, son los cambios de las 230, voy a probar sin recursos comprimidos y con ese flags, pero
acabo de encontrar otro problema en el vigoroth, resulta que se me cuelga al cargar una música justo en esta línea.
int file_read( file * fp, void * buffer, int len )
{
assert( len != 0 );
...
Resulta que len es 0 y el assert este al salir bloquea la psp, cagoen.
por eso mismo, proba sin zlib y vemos que pasa.
ya he probado, mismos resultados, siguen colgándose los juegos, probé con vigoroth y con echo, necesitaría gente que probase tests de diversa índoloe para ir acotando cuales son las funciones o flujos que cuelgan la psp e ir al grano en el código, pero creo que tiene que ser algo interno de alineación, lo que pasa es que he buscado en todo el código c de bennu types y structs y no veo ninguno desalineado :D.
¿De todas formas por qué está ese assert? creí que los habías quitado todos, es decir, que hiciste que si no se encontrase algún recurso siguiera la ejecución sin éste, que antes en fenix si no encontraba alguno se terminaba la ejecucion.
probaste con compilacion son zlib y con los recursos descomprimidos?
nunca dije que quite ni quitaria los asserts, si dije que quitaria chequeos de errores que provocaran salida y el control fuera posible, pero esto es una situacion critica, y este funcion es generica, y no siempre hay control del usuario sobre los retornos de esta funcion.
la cosa es que nunca deberia llegar ahi un read con 0 de len a leer.
Nuevos tests con vigoroth.
Quité del código todas las funciones _song, load, play, unload, set volume, y voilá desaparecieron muchos cuelgues, pero aún así se seguía colgando el vigoroth al volver al menú y cambiar de juego.
No dispuesto a dejarlo por imposible eliminé del código todas las funciones _wav, load, unload, y play. Y ahora va perfecto el vigoroth pero sin ningún sonido :D.
la mixer me parece que tiene algunos problemas.
freeyourdmind, puedes probar tus juegos sin cargar sonidos en psp para ver si van más rápidos y si no se cuelgan?
Porque ahora sin sonidos el vigoroth va igual de rápido que en pc.
todo el problema de consumo y cuelgues en psp es por la mixer?
Pues parece ser que no, he probado a usar los wavs de vigoroth en un ejemplo de sdl_mixer para psp usando c a pelo y no se cuelga ni nada en la psp, así que supongo que es algo de integración de la sdl_mixer en el bgdi, tengo que estudiar más el código de bgdi por si es por ahí por donde anda algún fallo de alineamiento.
Me gustaria, pero no tengo los src por aqui, y tampoco es una tarea tan rapida la que pides ;D
De todas formas si ya has confirmado que es la mixer, pues estais como en Dingoo, y mas cerca :)
Quote from: DCelso on March 02, 2011, 07:58:46 PM
Pues parece ser que no, he probado a usar los wavs de vigoroth en un ejemplo de sdl_mixer para psp usando c a pelo y no se cuelga ni nada en la psp, así que supongo que es algo de integración de la sdl_mixer en el bgdi, tengo que estudiar más el código de bgdi por si es por ahí por donde anda algún fallo de alineamiento.
ok, pruebalo y me cuentas.
he creado una versión capada del bgdi que hace que los load_song y load_wav devuelvan siempre 0, y he probado varios juegos y aún no me han dado cuelgues.
Free, puedes probar tus dcbs con esta versión?
http://www.mediafire.com/?xdjd7w6hd19f7d9
Vale, en una hora.
SplinterGu, he encontrado estos parámetros del gcc
-fpack-struct=16
-freg-struct-return
No se exactamente para qué valen, parece que el primero alinea las estructuras de 16 en 16 bits y el segundo permite devolver estructura en funciones, si alguien lo puede confirmar...
Con esos parámetros parece que se cuelga menos el bgdi para psp, pero se sigue colgando. Esos parámetros no parece que alineen los campos de la estructura que es lo que necesitamos, creo. :(.
Estoy probando con el echo, he castrado el sonido, y parece que ahora se me cuelga el juego cuando pillo la arma y empiezo a disparar como un cosaco y va a salir la estrella de energía que se mueve, pero solo me pasa a veces. Creo que es algún chequeo interno de bennu que no siempre lee alguna estructura desalineada, y en cuanto la va a leer, pues cuelgue al canto.
¿Sugerencias? me encantaría encontrar un test .prg que se cuelgue siempre en el mismo sitio para poder encontrar al culpable, pero no veo nada, mis juegos ejemplo como nim y pptls van bien siempre, supongo que no usan la parte conflictiva de bgdi.
todo lo que yo explique tiempo atras no tiene que ver con alineacion de estructuras... se ve que no se entendio lo que explique.
no importa...
si eso lo tenes seteado en la compilacion, proba con -fpack-struct solo, sin = ni valor
splinterGu, porfa ¿puedes explicarme lo que explicaste tiempo atras? leí las trece páginas y no lo encuentro o no se a qué te refieres. Si es lo del zip, pues ahora mismo lo tengo desactivado, meto todo unzippeado para saltarme ese problema, si es lo de la música, pues también la tengo desactivada también para saltar ese problema, ahora el problema parece estar en el core de bennu o SDL porque no uso nada así raro.
Yo creo que es problema de alineamiento porque los primeros cuelgues de echo en psp los solucioné alineando los bytes de las estructuras definidas con type en código bennu del juego.
Gracias de antemano, voy a probar lo que dices de compilar sin número, pero eso creo que sería lo mismo que compilar sin ese flag ¿no?
Por otro lado, Drumpi, donde haces en el echo de poner el color de fondo azul? no lo encuentro y eso actualmente me falla en psp, me sale marrón :D.
Splinter, probados los siguientes flags
-fpack-struct
a secas, na genera un binario que cuelga la psp nada más ejecutarlo.
-fpack-struct=2
lo mismísimo
-fpack-struct=4
el binario va, pero sigue colgándose el echo al disparar a diestro y siniestro y eliminar un enemigo
-fpack-struct=8
lo mismo que en 4
-fpack-struct=16
lo mismo que en 4 tambien
mas arriba de 16 no deja compilar.
voy a explicar:
- el core, core, no tiene ninguna estructura que alinear
- las estructuras del lenguaje bennugd no se alienan, el compilador no tiene relacion con eso.
no, no es lo mismo que compilar sin el flag
lo que yo explique, es el acceso a la memoria que nada tiene que ver con las estructuras... en algunos procesadores y en algunos modos, el acceso a memoria esta alineado, no las estructuras, los accesos a memoria, por mas que vos digas dame el contenido de la direccion 1, te va a dar el contenido de la direccion 0, si decis el contenido de la 2, tambien te dara de la 0, si decis de la 4, te dara de la 4, si decis de la 5, retorna 4, y asi... esto segun a cuando alinea el procesador... evidentemente que si alineas los elementos en las estructuras te va a funcionar, por esta misma cosa, pero por eso mismo es muy probable que no sea por alineamiento de estructuras, ya que el alineamiento se refiere a como se compilan y como se compilan es como se usan... por lo que parece, el alineamiento de las estructs va bien... no se, la verdad que sin tener la maquina y sin poder hacer pruebas es complejo...
pero las 13 paginas que te leiste (si son las que te referencie yo) no hablaban alineamientos de estructuras.
lamentablemente no podre ayudar mucho, porque la verdad que no tengo en planes gastar dinero en comprar una psp; y no soy muy paciente ni bueno para explicar las cosas.
te pido disculpas por no poder ser de mas ayuda, me siento atado de manos.
proba en 1
ok, acias de todos modos, probaré con ese tb,
cagoen, mismo resultado que 2.
para mi no van por ahi los tiros.
ya te digo, por otro lado, estoy intentando aislar el problema del sonido y tengo este test
....
...
Begin
id_text_key=write_var(0,10,10,0,text_key);
write_var(0,40,40,0,id_song);
while (!keyjoy(_esc))
if(keyjoy(_a))
text_key="a";
while (keyjoy(_a)) frame;end
id_song=load_song( "Sound/BossCourage.xm" );
end
if(keyjoy(_s))
text_key="s";
while (keyjoy(_s)) frame;end
play_song(id_song,-1);
end
if(keyjoy(_z))
text_key="z";
while (keyjoy(_z)) frame;end
stop_song();
end
if(keyjoy(_x))
text_key="x";
while (keyjoy(_x)) frame;end
unload_song(id_song);
end
if(keyjoy(_q))
text_key="q";
while (keyjoy(_q)) frame;end
set_song_volume(50);
end
if(keyjoy(_w))
text_key="w";
while (keyjoy(_w)) frame;end
set_song_volume(100);
end
frame;
end
end
...
...
funciona tanto en pc como en psp, pero una cosa, no se puede hacer esta combinacion ni en pc ni en psp
a, s, x, s.
es decir: load_song,play_song, stop_song, play_song.
Perdonad mi desconocimiento, pero como es que no puedo volver a hacer play? casca que da gusto dice que no sabe qué tipo de archivo es (Can't play unknown music type), y resulta que lo estuvo tocando antes :D, (¿fallo de bennu?)
Tengo que hacer un unload otra vez el load y tocar el play para que vuelva a escucharse.
codigo bennugd..
/* --------------------------------------------------------------------------- */
/*
* FUNCTION : play_song
*
* Play a MOD/OGG
*
* PARAMS:
* mod pointer
* number of loops (-1 infinite loops)
*
* RETURN VALUE:
*
* -1 if there is any error
*
*/
static int play_song( int id, int loops )
{
if ( audio_initialized && id )
{
int result = Mix_PlayMusic(( Mix_Music * )id, loops );
if ( result == -1 ) fprintf( stderr, "%s", Mix_GetError() );
return result;
}
fprintf( stderr, "Play song called with invalid handle" );
return( -1 );
}
/* --------------------------------------------------------------------------- */
/*
* FUNCTION : stop_song
*
* Stop the play of a mod
*
* PARAMS:
*
* no params
*
* RETURN VALUE:
*
* -1 if there is any error
*
*/
static int stop_song( void )
{
if ( audio_initialized ) Mix_HaltMusic();
return ( 0 ) ;
}
/* ------------------ */
/* Sonido MOD y OGG */
/* ------------------ */
/* --------------------------------------------------------------------------- */
/*
* FUNCTION : load_song
*
* Load a MOD/OGG from a file
*
* PARAMS:
* file name
*
* RETURN VALUE:
*
* mod pointer
*
*/
static int load_song( const char * filename )
{
Mix_Music *music = NULL;
file *fp;
if ( !audio_initialized && sound_init() ) return ( 0 );
if ( !( fp = file_open( filename, "rb0" ) ) ) return ( 0 );
if ( !( music = Mix_LoadMUS_RW( SDL_RWFromBGDFP( fp ) ) ) )
{
file_close( fp );
fprintf( stderr, "Couldn't load %s: %s\n", filename, SDL_GetError() );
return( 0 );
}
return (( int )music );
}
* --------------------------------------------------------------------------- */
/*
* FUNCTION : unload_song
*
* Play a MOD
*
* PARAMS:
*
* mod id
*
* RETURN VALUE:
*
* -1 if there is any error
*
*/
static int unload_song( int id )
{
if ( audio_initialized && id )
{
if ( Mix_PlayingMusic() ) Mix_HaltMusic();
Mix_FreeMusic(( Mix_Music * )id );
}
return ( 0 ) ;
}
/* --------------------------------------------------------------------------- */
/*
* FUNCTION : modsound_unload_song
*
* Frees the resources from a MOD and unloads it
*
* PARAMS:
* mod id;
*
* RETURN VALUE:
*
* -1 if there is any error
* 0 if all goes ok
*
*/
static int modsound_unload_song( INSTANCE * my, int * params )
{
if ( params[0] == -1 ) return ( -1 );
return( unload_song( params[0] ) );
}
si ves o piensas que ahi hay aun bug, por favor, no dudes en comunicarmelo.
umn, lo veo perfecto :D, es más fue fallo mío, hacía el play después del unload en vez de después del stop. sooorrryy ;'(
bueno, mejor que sea un problema humano de testing... sino estamos en un grave problema.
XCelso, lo del color del fondo está en el fichero game.inc, lineas 270, 297, 308, 333 y 483, según el nivel que estés probando. Es la parte donde se ejecutan los niveles y todo eso.
Eso está pendiente de ser reescrito porque me parece poco claro y muy poco modular ^^U Espero que para la versión 1.2 esté lista.
SplinterGU, estoy adoptando el mismo test de sonido a c/SDL, ya me funciona en PC voy a compilarlo para psp a ver si falla también para descartar que sea cosa de como gestiona bennu la sdl mixer, ya que el test de sonido hecho en bennu va perfecto en PC y en cambio en PSP al darle al play suena la canción y aleatoriamente se bloquea al poco tiempo la psp y nunca es en el mismo segundo.
el problema es que no se entiende que bennugd no gestiona el sonido... perdon, pero es algo que explique cientos de veces a mucha gente... el modulo de sonido de bennugd solo es un wrapper a la mixer... solo se hacen algunos chequeos de punteros nulos y esas csoas, pero nada mas.
Sip, puede que alguna comprobación esté mal y no la veamos, como ha pasado alguna que otra vez. Iba a ser el siguiente paso que iba a realizar, si va en la psp el codigo c/SDL tal cual lo tengo, intentar hacer que el código bennu, concretamente tu wrapper haga exactamente lo mismo (con mismas comprobaciones) que mi código a ver si sigue cascando.
O bien puede que sea de la gestión de hilos, semáforos o mutex, por eso es por lo que quiero hacer ejemplos que siempre se bloqueen en el mismo sitio porque siendo aleatorios es casi imposible detectar el problema :D.
bennugd no tiene hilos, semaforos o mutex...
un simple ejemplo no sirve si no esta en un loop, como decis vos, pasa despues de un tiempo.
como sea, yo no veo ningun error, si vos lo ves, maravilloso.
suerte con eso, avisame.
Pues entonces de la gestión de prioridades de los procesos y la parada de frames, porque es la única parte pseudoaleatoria que se me ocurre que dé problemas aleatoriamente. Quizas mientras está sonando la música (que por narizes sdl tiene que pasarla a un hilo o similar para dejar ejecutar código del programa mientras suena) se haga una comprobación usando un puntero o algo que acceda a un dato desalineado y haga cascar a la psp.
Parece que la psp tiene la limitación de que solo puede acceder a posiciones múltiplo de 16 bits por lo tanto, no dejándote acceder a los segundos 8 bits de una palabra de manera independiente.
Estoy indagando de si se puede crear un parche o algo al firmware para que lo permita aunque haga el acceso más lento, para así probar definitivamente que es eso, pero no encuentro información al respecto, habría que hablar con algún experto de homebrew para psp pero no localizo a ningún friki español que me pueda ayudar :D.
bueno, a ver, si accede o no a posiciones de 16bits se prueba facil con un programa simple...
private
int a = 12345678h;
byte * p;
begin
p = &a;
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
end
cada valor deberia ser diferente
XCelso, deberías hablar con Misato de GP32Spain. Seguramente haya más de un programador de PSP por allí, pero ella es la que siempre salta cuando se habla de ese tema.
Por otro lado ¿alguien me podría explicar, de forma extremadamente resumida, cómo se accede al buffer de sonido? para hacerme una idea de cómo trabaja internamente SDL o cualquier librería de sonido (sobre todo, la parte en la que da igual la plataforma en la que se trabaje). Es para ir mirando cuan difícil sería desarrollar una librería de sonido alternativa a SDL_Mixer.
Quote from: SplinterGU on March 05, 2011, 08:00:32 PM
bueno, a ver, si accede o no a posiciones de 16bits se prueba facil con un programa simple...
private
int a = 12345678h;
byte * p;
begin
p = &a;
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
end
cada valor deberia ser diferente
:o, muchas gracias, lo probaré en breve.
Por otro lado, programa c/SDL pseudo análogo al de bennu con recursos iguales no cuelga la psp, aunque sí hace que cuando el .xm tiene mucha caña se enlentezca el sonido.
#include <stdio.h>
#include <SDL/SDL.h>
#include <SDL/SDL_image.h>
#include <SDL/SDL_ttf.h>
#include <SDL/SDL_mixer.h>
#define PSP_TRIANGLE_BUTTON 0
#define PSP_CIRCLE_BUTTON 1
#define PSP_X_BUTTON 2
#define PSP_SQUARE_BUTTON 3
#define PSP_L_BUTTON 4
#define PSP_R_BUTTON 5
#define PSP_DOWN_BUTTON 6
#define PSP_LEFT_BUTTON 7
#define PSP_UP_BUTTON 8
#define PSP_RIGHT_BUTTON 9
#define PSP_SELECT_BUTTON 10
#define PSP_START_BUTTON 11
#define PSP_LEFT_RIGHT_AXIS 0
#define PSP_UP_DOWN_AXIS 1
#if defined(TARGET_PSP)
#include "callbacks_psp.h"
PSP_MODULE_INFO("mixerExample", PSP_MODULE_USER, 1, 0); // user mode
#endif
int main(int argc, char *argv[]) {
int quit = 0;
SDL_Event event;
SDL_Surface* hello = NULL;
SDL_Surface* message = NULL;
SDL_Surface* message_up = NULL;
SDL_Surface* message_down = NULL;
SDL_Surface* message_a, *message_s, *message_z, *message_x;
SDL_Surface* screen = NULL;
TTF_Font *font = NULL;
SDL_Color textColor = { 0, 255, 0 };
SDL_Rect offset;
int have_joy = 0;
SDL_Joystick *stick;
Uint8 *keystates;
Mix_Music *music = NULL;
#ifdef TARGET_PSP
PSP_HEAP_SIZE_MAX ();
pspDebugScreenInit();
SetupCallbacks();
#endif
//Start SDL
SDL_Init(SDL_INIT_EVERYTHING);
TTF_Init();
Mix_OpenAudio(22050, MIX_DEFAULT_FORMAT, 2, 4096);
//Check if there's any joysticks
if (SDL_NumJoysticks() > 0) {
have_joy = 1;
stick = SDL_JoystickOpen(0);
}
//Set the window caption
SDL_WM_SetCaption("Hello World", NULL);
//Set up screen
screen = SDL_SetVideoMode(480, 240, 32, SDL_SWSURFACE);
//Load image
//hello = SDL_LoadBMP( "hello.bmp" );
hello = IMG_Load("hello.jpg");
font = TTF_OpenFont("lazy.ttf", 28);
message_up = TTF_RenderText_Solid(font, "up", textColor);
message_down = TTF_RenderText_Solid(font, "down", textColor);
message_a = TTF_RenderText_Solid(font, "a", textColor);
message_s = TTF_RenderText_Solid(font, "s", textColor);
message_z = TTF_RenderText_Solid(font, "z", textColor);
message_x = TTF_RenderText_Solid(font, "x", textColor);
//While the user hasn't quit
offset.x = 0;
offset.y = 150;
while (quit == 0) {
keystates = SDL_GetKeyState(NULL);
if (keystates[SDLK_UP]) {
offset.y--;
}
if (keystates[SDLK_DOWN]) {
offset.y++;
}
while (SDL_PollEvent(&event)) {
if (event.type == SDL_JOYBUTTONDOWN) {
switch (event.jbutton.button) {
case PSP_SQUARE_BUTTON:
message = message_a;
music = Mix_LoadMUS("BossCourage.xm");
break;
case PSP_TRIANGLE_BUTTON:
message = message_s;
if (Mix_PlayingMusic() == 0) {
//Play the music
if (Mix_PlayMusic(music, -1) == -1) {
return 1;
}
}
break;
case PSP_X_BUTTON:
message = message_z;
Mix_HaltMusic();
break;
case PSP_L_BUTTON:
message = message_z;
Mix_VolumeMusic(50);
break;
case PSP_R_BUTTON:
message = message_z;
Mix_VolumeMusic(100);
break;
case PSP_CIRCLE_BUTTON:
message = message_x;
//Free the music
Mix_FreeMusic(music);
break;
case PSP_SELECT_BUTTON: {
SDL_Event quit;
quit.type = SDL_QUIT;
SDL_PushEvent(&quit);
break;
}
}
}
//If a axis was changed
if (event.type == SDL_JOYAXISMOTION) {
//If joystick 0 has moved
if (event.jaxis.which == 0) {
//If the X axis changed
if (event.jaxis.axis == 0) {
//If the X axis is neutral
if ((event.jaxis.value > -8000) && (event.jaxis.value
< 8000)) {
}
//If not
else {
//Adjust the velocity
if (event.jaxis.value < 0) {
offset.x--;
} else {
offset.x++;
}
}
}
//If the Y axis changed
else if (event.jaxis.axis == 1) {
//If the Y axis is neutral
if ((event.jaxis.value > -8000) && (event.jaxis.value
< 8000)) {
}
//If not
else {
//Adjust the velocity
if (event.jaxis.value < 0) {
offset.y--;
} else {
offset.y++;
}
}
}
}
}
if (event.type == SDL_KEYDOWN) {
//Set the proper message surface
switch (event.key.keysym.sym) {
case SDLK_UP:
message = message_up;
break;
case SDLK_DOWN:
message = message_down;
break;
case SDLK_ESCAPE: {
SDL_Event quit;
quit.type = SDL_QUIT;
SDL_PushEvent(&quit);
}
break;
case SDLK_a:
message = message_a;
music = Mix_LoadMUS("BossCourage.xm");
break;
case SDLK_s:
message = message_s;
if (Mix_PlayingMusic() == 0) {
//Play the music
if (Mix_PlayMusic(music, -1) == -1) {
return 1;
}
}
break;
case SDLK_z:
message = message_z;
Mix_HaltMusic();
break;
case SDLK_q:
message = message_z;
Mix_VolumeMusic(50);
break;
case SDLK_w:
message = message_z;
Mix_VolumeMusic(100);
break;
case SDLK_x:
message = message_x;
//Free the music
Mix_FreeMusic(music);
break;
default:
break;
}
}
if (event.type == SDL_QUIT) { //Quit the program
quit = 1;
}
}
//Apply image to screen
SDL_BlitSurface(hello, NULL, screen, NULL);
SDL_BlitSurface(message, NULL, screen, &offset);
//Update Screen
SDL_Flip(screen);
}
//Free the loaded image
SDL_FreeSurface(hello);
SDL_FreeSurface(message_up);
SDL_FreeSurface(message_down);
//Close the font that was used
TTF_CloseFont(font);
//Free the music
//Mix_FreeMusic(music);
//Quit SDL_mixer
Mix_CloseAudio();
//Quit SDL_ttf
TTF_Quit();
//Close the joystick
SDL_JoystickClose(stick);
//Quit SDL
SDL_Quit();
#ifdef TARGET_PSP
sceKernelExitGame();
#endif
return 0;
}
Nota, he usado eventos para las teclas y joystick para usar el estado keydown, cosa que bennu no hace, así que reprogramaré esto usando el sdl getjoybutton que usa bennu no vaya a ser esto el problema y me lo salte :D, así intentarlo hacer lo más fiel posible a lo que hace bennu.
debo comentar que el modulo de sonido hace uso de la zlib...
nuevamente, y por enesima vez, por favor, elimina el uso de la zlib y usa recursos no comprimidos y vuelve a probar.
Splinter eso hago, no uso nada comprimido y activé en la compilacion lo que me dijiste del nozlib.
Por otro lado, me vais a matar sí o sí. resulta que ese ejemplito va perfecto en la psp. ;'(
import "mod_say"
import "mod_joy"
import "mod_key"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(480,240,32);
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
end
Pero curiosamente al hacerle el bucle loop bloquea a la psp después de mostrar la info
import "mod_say"
import "mod_joy"
import "mod_key"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(480,240,32);
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
while(!(get_joy_button(0,0) OR key(_esc)) )
frame;
end
end
Voy a quitar modkey por si es eso, ya que la psp no tiene, y acto seguido quitaré los says a ver si el bucle por sí solo casca.
juas, me mondo y me parto,
este muestra la info y cuelga la psp.
import "mod_say"
import "mod_joy"
import "mod_video"
#define PSP_TRIANGLE_BUTTON 0
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(480,240,32);
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
while(!get_joy_button(0,PSP_TRIANGLE_BUTTON) )
frame;
end
end
este no cuelga la psp y va bien ( osea no muestra nada, queda en bucle y puedes salirte con el bótón triángulo)
import "mod_joy"
import "mod_video"
#define PSP_TRIANGLE_BUTTON 0
begin
set_mode(480,240,32);
while(!get_joy_button(0,PSP_TRIANGLE_BUTTON) )
frame;
end
end
Osea la combinación de mostrar datos desalineados con el bucle cuelga la psp.
Voy a no mostrar datos desalineados a ver si no la cuelga.
Pa mear y no echar gota.
esto muestra los dos datos y cuelga la psp a veces sí a veces no.
import "mod_say"
import "mod_joy"
import "mod_video"
#define PSP_TRIANGLE_BUTTON 0
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(480,240,32);
say(p[0]);
say(p[2]);
while(!get_joy_button(0,PSP_TRIANGLE_BUTTON) )
frame;
end
end
Y esto y para incredulidad mia, hace lo mismo, a veces se cuelga a veces no.
import "mod_say"
import "mod_joy"
import "mod_video"
#define PSP_TRIANGLE_BUTTON 0
begin
set_mode(480,240,32);
while(!get_joy_button(0,PSP_TRIANGLE_BUTTON) )
frame;
end
end
realmente no le veo sentido, y con un while(1)?
a veces si a veces no
import "mod_video"
begin
set_mode(200,200,16);
while (1)
frame;
end
end
Está claro que o bien me he cargao la psp :D, o bien algo estoy haciendo mal, porque esto ni es normal ni tiene sentido.
Usando loop en vez de while lo mismo. (¿cómo implementa los bucles benno?)
Pero si quito el loop va perfecto, he ejecutado este código más de 10 veces esperando a que se me colgase y no se cuelga, todo perfecto las más de diez veces.
import "mod_say"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(320,480,32);
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
frame;
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
frame;
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
frame;
end
Voy a ponerle un puñao más a ver que pasa.
Voy a ponerle ahora un for hasta mil. hecho, perfecto también
import "mod_say"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(320,480,32);
for (x=0;x<100;x++)
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
frame;
end
end
y si le pongo un for infinito, a ver... hecho, va de lujo también
import "mod_say"
import "mod_video"
import "mod_joy"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(320,480,32);
for (x=0;x<100;)
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
if (get_joy_button(0,0))
break;
end
frame;
end
end
Voy a simular el while primero con un for para ver que pasa ... Ostras tu, esto casca a veces
import "mod_say"
import "mod_joy"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(320,280,16);
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
while(!get_joy_button(0,0) )
frame;
end
end
Esto no casca nunca
import "mod_say"
import "mod_joy"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(320,280,16);
while(!get_joy_button(0,0) )
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
frame;
end
end
¿Las aletoriedades de casque se produce cuando se deja el bucle solo con la sentencia frame?, voy a probar a hacer una asignación tonta en el bucle.
jajaja, el for es un while sin incrementos, ni inicializacion, y un loop es un while sin condicion, como un goto...
me parece que esto va por otro lado, modulos que se cargan (cierto que aca se carga todo, entonces que se inicializan).
que valores muestran los says?
no me comentaste eso.
Los mismos que en pc.
120
86
52
18
Ya veo que estoy haciendo pruebas estúpidas :D, algo es algo, por ahora veo que el while tampoco casca si hace los says dentro, solo casca si lo dejo solo con la sentencia frame.
para nada es una prueba estupida, esto confirma que el acceso a las direcciones no esta alineado a 16bits... entonces el problema no viene por ahi, no por lo menos en psp.
tenes alguna forma de ver el consumo de memoria? a ver si no hay un memory leak por ahi?
podes deshabilitar la inicializacion del modulo de eventos de la SDL? solo dejar lo basico, el video.
Umm, pues no se a qué te referes, ¿a quitar mod_joy?, ya lo hice y pasaba lo mismo,
Bueno he dejado un say("") antes del frame en el bucle y también casca aleatoriamente la aplicación, nose, ¿puede que sea problema de pintar varios frames negros enteros de seguido?, voy a probar a poner un puñao de frames del tirón justo despues de mostrar los datos, a ver si finaliza bién o se cuelga en el proceso.
esto es un poco frustrante, no encuentro la salida, voy a tener que dejarlo hasta que se me pase el cabreo :D, pero antes voy a probar lo de muchos frames de seguido :D.
callbacks de inicializacion
¿pero dices de modificar algun fichero c de bennu para ello?
Dos pruebas mas
Esta funciona perfectamente, la ejecuté unas 10 veces
import "mod_say"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(320,280,16);
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
frame;
frame;
frame;
frame;
frame;
end
Esta cuelga la psp
import "mod_say"
import "mod_video"
private
int a = 12345678h;
byte * p;
begin
p = &a;
set_mode(320,280,16);
say(p[0]);
say(p[1]);
say(p[2]);
say(p[3]);
frame;
frame;
frame;
frame;
frame;
frame;
frame;
frame;
frame;
frame;
end
la ejecuté 5 veces, de las cuales 4 colgaron la psp y una no.
Dcelso, los load_wav te funcionan? a mi en dingux, revienta al hacer load_wav.
pues a mi sí que me van, depende del wav (al igual que el song) revienta la psp o no, pero el problema es que es aleatoriamente, si fuera siempre en el mismo sitio podría pensar que es algun dato fuera de rango pero como es aleatoriamente tiene que ser algo de gestion de prioridades que varíe dependiendo de la ejecución.
De todas formas el load_wav me funciona siempre bien en todos los wavs, es al hacer play_wav cuando me revienta. Así que dudo que sea el mismo problema.
Yo ya dudo de todo lo que le hice a la psp, quizás sea la gestión monolítica que le hice lo que hace que reviente aleatoriamente, como uso punteros a tutiplen y encima en vectores estáticos fijo que la lio sin querer en algún momento, así que estaba esperando tu versión monolítica que seguro que es más estable para ver si es problema de esto o no :D. La cosa es que en linux la versión monolítica mía va perfect, pero claro son infinitos más recuros de los que dispongo que en la psp :D.
olvidate de las prioridades, no tiene absolutamente nada que ver... las prioridades en bennugd son solamente el orden dentro de una lista...
si te crashea con un simple while frame, me parece que las prioridades no tienen nada que ver.
para mi tiene que ver con los LOC_*, PUB_*, etc... que en la version monolitica no deberian usarse como se usa en la version modular.
no se.
pues tienes que estar muy muy cerca de la tecla, mira mis dos úlitimos tests
este se bloquea en al mostrar frame8, a veces si, a veces no.
import "mod_say"
import "mod_video"
private
int a = 12345678h;
begin
set_mode(320,280,16);
x=1;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
end
Y simplemnte quitando la sección private, ya no se crashea nunca, almenos lo ejecuté 11 veces sin colgarse.
import "mod_say"
import "mod_video"
begin
set_mode(320,280,16);
x=1;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
end
te recomiendo analices el codigo en la parte de las prioridades, asi entenderas que lo que dices no tiene nada que ver.
ok, asias por la recomendación, eso haré.
Siguiente test sin problemas en psp.
import "mod_say"
import "mod_video"
local
int a = 12345678h;
begin
set_mode(320,280,16);
x=1;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
frame;
say("frame"+x++);
end
Osea con local no pasa, parece problema de la private, voy a ver public, que se parece más a private :D. Realizado,
ups, no puedo poner public si no es dentro de un proceso, en cambio private sí, voy a crear el proceso main. Realizado
tambíen la jiere la variable public, es decir, private y public hacen cosas raras en psp.
DCelso, no hagas mas pruebas... o sea, no tiene sentido tirar pruebas a diestra y siniestra si con un while frame solo se cae.
vas a tener que hacer esa prueba con while frame, y meter log en varios lugares del codigo, hasta encontrar donde cae.
log = printf + fflush.
ok, me parece muy correcto :D. pero tb me parece que mi prueba del simple frame tenía la variable private puesta, voy a ver si un simple while frame no casca.
lo que digo es que no tiene nada que ver las variables, porque una prueba sin variables ya demostraste que cae... entonces para que seguir probando con ejemplos mas complejos si ya tenes el ejemplo mas simple que podrias probar? ya tenes el ejemplo, empeza a debuguear a ver donde casca... y luego se ve si tiene o no sentido que casque ahi o es por algun pise de memoria o lo que sea.
incluso puede ser algun mecanismo de signal que lleva psp, y no te estas enterando.
lo que digo, es que evidentemente te va a cascar en cualquier cosa compleja que hagas si ya un simple while casca.
puede tambien ser que se estan escuchando demas eventos de SDL de los que se limpian y en algun momento la queue se llena y casca.
la verdad que no se, es dificil sin la maquina, hay un monton de cosas que yo puedo testear y darme cuenta gracias a mi experiencia... pero es dificil hacerlo a traves de otros... mas cuando se desconoce internamente lo que se esta analizando.
jajaja, pues muucha razón que tienes. pues el ejemplo más simple es el siguiente:
Process main()
begin
set_mode(320,280,16);
say(x++);
while (1)
frame;
end
end
este casca de lo lindo, pero en cambio poniendo el say dentro del while no casca
Process main()
begin
set_mode(320,280,16);
while (1)
say(x++);
frame;
end
end
Voy a quitar el set mode y el say y ejecutarlo sin ningún módulo, si casca eso, pues debugear frame pa ver donde se casca exactamente. Tiene justísimo lo que tu dices, un acceso a memoria indebido en algún momento, algo no inicializado o desinicializado.
Lo raro es que la versión monolítica en PC vaya bien, porque si no lo fuera sería culpa de ella, cachis.
Y otra cosa rara es que juegos complejos vayan bien, como el vigoroth sin sonido, el tetris, o mi piedra-papel-tijera-lagarto-spock, o el wiz de prg que tiene sonido y todo y no casca.
creo que ya se por donde empezar a depurar.
import "mod_joy"
Process main()
begin
loop
if (get_joy_button(0,0))
break;
end
frame;
end
end
Este código no casca ni pa atrás.
Este otro sí
import "mod_joy"
import "mod_video"
Process main()
begin
set_mode(320,480,16);
loop
if (get_joy_button(0,0))
break;
end
frame;
end
end
Así es lo mínimo que he encotrado que casque, puedo depurar los procesos de inicialización de mod_video y las funciones set_mode y frame
¿como lo ves?
nota, el get_joy lo puedo quitar, pero está para que si va bien poder salir del juego rápidamente :D
ostras tu, en fenix para psp, van bien los bucles, no casa ningún ejemplo de aquí, en cambio el del sonido sí que casca igual.
no pienses en el loop, busca el error debugueando... quita el joy y no uses ninguna variable...
primero mira donde casca (a nivel C) y luego da otro paso...
ok, asias, eso haré
jo, no me va el psplinkusb, consigo conectar con la psp desde mi pc, pero a la hora de ejcutar cualquier .elf me dice que es un .elf no válido, cago en la madre del topo.
jajaja, esa de la madre del topo nunca la escuche.
Splinter, solucioné el problema de los colores en las funciones de pintado manual cambiando bitmap_create_format por esto
PIXEL_FORMAT * bitmap_create_format( int bpp )
{
PIXEL_FORMAT *format;
/* Allocate an empty pixel format structure */
format = malloc( sizeof( *format ) );
if ( !format ) return( NULL );
/* Set up the format */
format->palette = NULL;
format->depth = bpp;
format->depthb = ( bpp + 7 ) / 8;
if ( bpp == 32 )
{
format->Aloss = 0;
format->Rloss = 0;
format->Gloss = 0;
format->Bloss = 0;
#ifdef TARGET_PSP
format->Ashift = 0x18;
format->Rshift = 0x00;
format->Gshift = 0x08;
format->Bshift = 0x10;
format->Amask = 0xFF000000;
format->Rmask = 0x000000FF;
format->Gmask = 0x0000FF00;
format->Bmask = 0x00FF0000;
#else
format->Ashift = 0x18;
format->Rshift = 0x10;
format->Gshift = 0x08;
format->Bshift = 0x00;
format->Amask = 0xFF000000;
format->Rmask = 0x00FF0000;
format->Gmask = 0x0000FF00;
format->Bmask = 0x000000FF;
#endif
}
else if ( bpp > 8 )
{
/* R-G-B */
if ( bpp > 24 ) bpp = 24;
format->Aloss = 8;
format->Rloss = 8 - ( bpp / 3 );
format->Gloss = 8 - ( bpp / 3 ) - ( bpp % 3 );
format->Bloss = 8 - ( bpp / 3 );
format->Ashift = 0;
format->Gshift = ( bpp / 3 );
format->Amask = 0;
format->Gmask = (( 0xFF >> format->Gloss ) << format->Gshift );
#ifdef TARGET_PSP
format->Rshift = 0;
format->Bshift = (( bpp / 3 ) + ( bpp % 3 ) ) + ( bpp / 3 );
#else
format->Rshift = (( bpp / 3 ) + ( bpp % 3 ) ) + ( bpp / 3 );
format->Bshift = 0;
#endif
format->Rmask = (( 0xFF >> format->Rloss ) << format->Rshift );
format->Bmask = (( 0xFF >> format->Bloss ) << format->Bshift) ;
}
else
{
format->Rloss = 8;
format->Gloss = 8;
format->Bloss = 8;
format->Aloss = 8;
format->Rshift = 0;
format->Gshift = 0;
format->Bshift = 0;
format->Ashift = 0;
format->Rmask = 0;
format->Gmask = 0;
format->Bmask = 0;
format->Amask = 0;
}
return( format );
}
¿Como lo ves?
Me tuve que crear una aplicacioncilla en SDL para ver los valores de mask y shift que usaba SDL tanto en pc como en psp para comprobar las diferencias
//Set up screen
screen = SDL_SetVideoMode(480, 240, 16, SDL_SWSURFACE);
hello = SDL_GetVideoSurface();
printf("**********16************************\n");
printf("hello->format->Amask:%08x\n", hello->format->Amask);
printf("hello->format->Rmask:%08x\n", hello->format->Rmask);
printf("hello->format->Gmask:%08x\n", hello->format->Gmask);
printf("hello->format->Bmask:%08x\n", hello->format->Bmask);
printf("hello->format->Ashift:%02x\n", hello->format->Ashift);
printf("hello->format->Rshift:%02x\n", hello->format->Rshift);
printf("hello->format->Gshift:%02x\n", hello->format->Gshift);
printf("hello->format->Bshift:%02x\n", hello->format->Bshift);
printf("hello->format->Aloss:%02x\n", hello->format->Aloss);
printf("hello->format->Rloss:%02x\n", hello->format->Rloss);
printf("hello->format->Gloss:%02x\n", hello->format->Gloss);
printf("hello->format->Bloss:%02x\n", hello->format->Bloss);
printf("**********16************************\n");
while ((SDL_JoystickGetButton(stick, PSP_CIRCLE_BUTTON) == 0
&& SDL_GetKeyState(0)[SDLK_ESCAPE] == 0)) {
SDL_PollEvent(&event);
}
printf("**********32************************\n");
screen = SDL_SetVideoMode(480, 240, 32, SDL_SWSURFACE);
hello = SDL_DisplayFormatAlpha(SDL_GetVideoSurface());
printf("hello->format->Amask:%08x\n", hello->format->Amask);
printf("hello->format->Rmask:%08x\n", hello->format->Rmask);
printf("hello->format->Gmask:%08x\n", hello->format->Gmask);
printf("hello->format->Bmask:%08x\n", hello->format->Bmask);
printf("hello->format->Ashift:%02x\n", hello->format->Ashift);
printf("hello->format->Rshift:%02x\n", hello->format->Rshift);
printf("hello->format->Gshift:%02x\n", hello->format->Gshift);
printf("hello->format->Bshift:%02x\n", hello->format->Bshift);
printf("hello->format->Aloss:%02x\n", hello->format->Aloss);
printf("hello->format->Rloss:%02x\n", hello->format->Rloss);
printf("hello->format->Gloss:%02x\n", hello->format->Gloss);
printf("hello->format->Bloss:%02x\n", hello->format->Bloss);
while ((SDL_JoystickGetButton(stick, PSP_CIRCLE_BUTTON) == 0
&& SDL_GetKeyState(0)[SDLK_ESCAPE] == 0)) {
SDL_PollEvent(&event);
}
También tuve que modificar otra funcións que hace uso de máscaras "hardcode"
static void init_conversion_tables()
{
uint8_t r, g, b ;
int n ;
/* Alloc space for the lookup tables */
convert565ToScreen = ( uint16_t * ) malloc( sizeof( uint16_t ) * 65536 );
if ( !convert565ToScreen ) return ;
convertScreenTo565 = ( uint16_t * ) malloc( sizeof( uint16_t ) * 65536 );
if ( !convertScreenTo565 ) // No memory
{
free( convert565ToScreen );
return ;
}
/* Special case if screen already in 565 format */
#ifdef TARGET_PSP
if ( sys_pixel_format->Rmask == 0x001F &&
sys_pixel_format->Gmask == 0x07E0 &&
sys_pixel_format->Bmask == 0xF800 )
#else
if ( sys_pixel_format->Rmask == 0xF800 &&
sys_pixel_format->Gmask == 0x07E0 &&
sys_pixel_format->Bmask == 0x001F )
#endif
{
for ( n = 0; n < 65536; n++ )
{
convert565ToScreen[ n ] = n;
convertScreenTo565[ n ] = n;
}
return ;
}
/* Create a fast lookup array */
for ( n = 0; n < 65536; n++ )
{
/* Calculate conversion from 565 to screen format */
#ifdef TARGET_PSP
b = (( n >> 8 ) & 0xF8 ) >> sys_pixel_format->Bloss ;
g = (( n >> 3 ) & 0xFC ) >> sys_pixel_format->Gloss ;
r = (( n << 3 ) & 0xF8 ) >> sys_pixel_format->Rloss ;
#else
r = (( n >> 8 ) & 0xF8 ) >> sys_pixel_format->Rloss ;
g = (( n >> 3 ) & 0xFC ) >> sys_pixel_format->Gloss ;
b = (( n << 3 ) & 0xF8 ) >> sys_pixel_format->Bloss ;
#endif
convert565ToScreen[ n ] = ( r << sys_pixel_format->Rshift ) | ( g << sys_pixel_format->Gshift ) | ( b << sys_pixel_format->Bshift ) ;
/* Calculate conversion from 565 to screen format */
r = ((( n & sys_pixel_format->Rmask ) >> sys_pixel_format->Rshift ) << sys_pixel_format->Rloss );
g = ((( n & sys_pixel_format->Gmask ) >> sys_pixel_format->Gshift ) << sys_pixel_format->Gloss );
b = ((( n & sys_pixel_format->Bmask ) >> sys_pixel_format->Bshift ) << sys_pixel_format->Bloss );
#ifdef TARGET_PSP
convertScreenTo565[ n ] = (( b & 0xF8 ) << 8 ) | (( g & 0xFC ) << 3 ) | (( r & 0xF8 ) >> 3 ) ;
#else
convertScreenTo565[ n ] = (( r & 0xF8 ) << 8 ) | (( g & 0xFC ) << 3 ) | (( b & 0xF8 ) >> 3 ) ;
#endif
}
conversion_tables_ok = 1;
}
Esto no soluciona el cambio de colores al leer los ficheros png, fpt o fnt, ya que en la lectura se usa el create format para crear el formato y luego se le asignan los bytes de color manualmente sin usar los valores de masc, shift, loss que nos dió create format, por tanto tuve que meter unos cuantos ifs en las funciones de lectura para que cuando sea psp girara los valores R y B.
Como es evidente, esto no arregla los cuelgues aleatorios que se me producen en psp, pero bueno, como encontré esto fácil de solventar pensé a ver si de casualidad se arreglan los cuelgues pero na de na, siguen estando :D.
A ver si consigo poder mostrar trazas de stdout y stdin de la psp en el pc y hago las trazas al código del while y un frame :D.
hay un tema de byteorder por lo visto... pero solo para el video...
bueno, hay otras funciones, todo el blitter que hace rotaciones y mascaras de forma manual, si no me equivoco, hay que revisarlo...
pero bueno, esto tiene solucion, lo voy a emparchar en el codigo de forma prolija y revisar todo... igual el cambio no va a ser muy diferente de lo que vos hiciste.
karma y gracias por el trabajo y la info.
ya creo que no soluiciona los cuelgues.
splinter, para mí que esto de invertir los shift y los mask en PSP solo para el video es fallo del port de SDL, ya que hay un código de SDL para PC por ahí que usa SDL_BYTE_ORDER para usar unos shift o mask dependiendo de éste, pero claro está que como tanto el PC como PSP son little endian pues no sirve porque entran ambos por la misma condición y no invierte las máscaras, para mí que quien programó SDL para psp la fastidió sin querer en ese sentido, fijo que se pensaba que psp era bigendian y lo programó mal sin querer :D.
Si te pones a hacer el cambio en el port oficial sería bueno que usaras SDL_BYTE_ORDER y/o TARGET_PSP para invertir las máscaras también así de paso solventas el problema para los ports de mac y wii :D.
no creo que sea un bug de SDL, si los ejemplos de ellos lo usan.
no, no puedo usar SDL_BYTE_ORDER, porque significa ponerle dependencia a todo bennugd de SDL y eso es retorceder... por otro lado, bennugd usa las mismas condiciones que usa SDL para determinar el byteorder, obviamente no tiene invertido el byteorder, si asi fuera no funcionaria nada.
yo creo que no es un bug, sino que es cuestion de la grafica de estas plataformas, o no se, no tengo ninguna de las plataformas mencionadas para probar.
ok, entiendo, y otra forma de detectar el byteorder independiente de sdl? como por ejemplo
| const int __endian_detect = 1;
|
| inline bool __little_endian() { return *(char *)&__endian_detect == 1;}
ya se esta haciendo independiente de SDL...
Compilados los últimos fuentes de SVN con mismos resultados, se cuelgan aleatoriamente los juegos.
La versión bgdi sin sonido funciona mil veces mejor, vamos no se cuelga tanto, casi ni se cuelga, pero aún asi a veces se cuelga :D.
No puedo hacer mejores tests para detectar el posible fallo hasta que no consiga echar a andar el ejecutar juegos en la psp y ver los resultados de las salidas stdout y stderr en el pc. Usbhost en cuestión no me funciona en mi psp, cagoento.
Me gustaría que me dijerais juegos simplones en código para probar en la psp a ver si sirven para detectar las funciones que fallan.
free, toma la versión última que tengo para que pruebes si quieres el hardcorefight antes de subirlo si quieres.
http://www.mediafire.com/?94nue2ohk44q4n1
Te advierto que es la mas estable que tengo, capa a posta el sonido, pero de forma transparente, no tienes que tocar nada en los .prg.
También le es indiferente el nombre del .dcb que le pongas, busca en el directorio del eboot.pbp cualquier *.dcb y abre el primero :), con tiempo incluso se podría hacer un menú de seleccion :D.
Si da errores lo muestra en la pantalla, (y los say tambien salen en pantalla. creo :D ) (Se queda bloqueado a posta para poder leerlo pero te puedes escapar con la tecla select o home)
Tiene solucionado el tema de colores tanto en imagenes pintadas desde bennu como recursos cargados .png, .fpg o fnt. (Si ves algun color cambiado en algun recurso, dimelo y pásame el recurso en cuestion y lo corrijo en un plisplas).
No tiene ningun mod capado pero tampoco tiene ningun mod no oficial, asi que si necesitas alguno en cuestión para el juego dimelo y lo inserto tb.
Ok thanks. Lo probaré hoy de forma rapida, de la velocidad dependerá mi decision de perder o no tiempo con este port, quedas ya avisado (que encima para mi jugar sin sonido no me va, pero a otros seguro que si...)
;D
Quote from: DCelso on April 13, 2011, 09:17:31 PM
;D
>:( >:( >:( >:(
Como puedes ser tan caradura!!!
Me has hecho perder 10 minutos sacando la psp, para ver colores erroneos, 5 minutos para que se saltara el logo inicial, mas lento que un caracol de 400 kilos.... puffff, olvidate tio, el tema psp esta aún muy verde, y te has esforzado muchissimo ya.
Venga suerte con el port y por favor no nos vuelgas a engañar ;D
Tan verde no está, no? Yo jugué a PiX Bros en su día bastante fluído :|
Quote from: FreeYourMind on April 13, 2011, 09:22:21 PM
Quote from: DCelso on April 13, 2011, 09:17:31 PM
;D
>:( >:( >:( >:(
Como puedes ser tan caradura!!!
Me has hecho perder 10 minutos sacando la psp, para ver colores erroneos, 5 minutos para que se saltara el logo inicial, mas lento que un caracol de 400 kilos.... puffff, olvidate tio, el tema psp esta aún muy verde, y te has esforzado muchissimo ya.
Venga suerte con el port y por favor no nos vuelgas a engañar ;D
???, no me lo puedo de creer, ¿en serio te va tan mal? a mi me va lenta la carga pero no es para tanto, luego va bien, he probado el echo, vigoroth, tetris, algunos ejemplos y todos van a la misma velocidad de juego que en pc.
Dime juegos que pruebas y firmware de tu psp.
Pasame los graficos que ves del reves los colores para ver qué formato tiene y por qué no funciona bien mi código de cambio de colores.
¿Has probado la versión fenix a ver que tal va? para ver si te va igual de lento.
http://www.mediafire.com/?9k54gun39y8jv1l
Pero no has probado el juego ? Es el logo EGS al principio y las letras de la intro ya que despues se ha ido abajo.
Lo pruebo en una psp tocha, con el 1.5 creo.
La de fenix no tengo aqui ningun ejemplo, tampoco tengo tiempo, tendré que dejar mis pruebas para despúes de semana santa ;D
Quote from: FreeYourMind on April 13, 2011, 11:11:55 PM
Pero no has probado el juego ? Es el logo EGS al principio y las letras de la intro ya que despues se ha ido abajo.
Lo pruebo en una psp tocha, con el 1.5 creo.
La de fenix no tengo aqui ningun ejemplo, tampoco tengo tiempo, tendré que dejar mis pruebas para despúes de semana santa ;D
¿La 1.5? pues tiene que ser eso, yo uso la 5.50 Prometheus (4 versiones por encima) que se consigue usando el despertar del cementerio que instala la 5.0 e instalando a posteriori la 5.50 GEN-D3 y parcheando a prometheus. Es lo último en firmware estable ante hardware reset, luego está la 6.20 TN que ante un hardware reset se pierde y tienes que estar volviendo a instarlar el CF (vamos una kaka) y no he visto método fiable de hacerla estable como la 5.50 prometheus así que no actualizo.
Pixel ¿que firmware tiene tu psp?
Lo de los colores, lo verificaré no me di cuenta de que estuvieran al revés cuando lo ejecuté :'(.
5.50 GEN-D3
A ver si firmas Bennu con la key esa de Sony y lo pruebo en otra psp mas reciente xD
ok
bgdi al firmarlo se corrompe, el pbp optenido no se puede ejecutar en mi psp.
He probado otros ejemplos C y no les pasa, el firmado funciona bien en mi psp.
Curiosisimo.
Como lo firmas en el proyecto, donde pones la firma, enseñanos joer xD
Sasto, usando prxEncrypt, en linux es descomprimir el zip que hay en scennebeta psp en el directorio del sdk y meter en el makefile
BUILD_PRX = 1
ENCRYPT = 1
Más fácil imposible :D.
Básicamente mete dos nuevos ejecutables, prx_encrypt y fix-relocations y los usa en las reglas genéricas build.mak para que al compilar se utilicen dichas herramientas para encriptar el prx y empaquetarlo en el .pbp final.
En windows supongo que es igual :D.
Estoy haciendo más tests de firmado, resulta que parece ser que los ejemplos que usan SDL no se pueden firmar, he probado dos tests y el resultado es un .pbp corrupto. A ver si encuentro al causante para poder firmarte algo :D.
Downloads please, no tienes tus compilaciones y makefiles para download ? ;D
Quote from: FreeYourMind on April 14, 2011, 09:51:43 PM
Downloads please, no tienes tus compilaciones y makefiles para download ? ;D
Compiles y makefiles de bgdi?
Del port de psp con el respectivo SDK y la firma, hombre, para que yo intente compilar tambien, tal como hicimos antes para Caanoo amigo mio ;D
:o ¿eso fue conmigo? I dont remember.
A ver qué puedo hacer, pero creo que ocupa el ciento y la madre el sdk.
Hola Free, ¿puedes probarme esto en algunas de tus psps?
http://www.filejungle.com/f/rjKjXa/Tetris.7z
y este paquete con la versión de linux y psp tambien me vendría de perlas que la probaseis.
http://www.filejungle.com/f/brvMNV/bgd_mono.7z
Mierda. Ha muerto la bateria de mi psp. No puedo probar nada. Quien tiene psp pa probar la nueva version? Cambié mi version monolitica por la de splinter para comprobar si los cuelgues de la psp eran debidos a mi version. Y de camino sincronicé con la rama última de bennu. En el anterior zip va lo necesario para crear el .dcb desde linux o desde psp y probarlo tambien desde linux y psp. En teoria con la version monolitica oficial se pueden crear dcbs compatibles con esta versiin de psp. Pero como digo no puedo probar nada. :'(
Voy a poner a cargar la psp a ver si lo puedo probar xD
PD: FileJungle es una puta mierda .. no he conseguido ni descargarme el archivo xDDD
http://www.mirrorcreator.com/files/BOEUP12J/Tetris.7z_links
http://www.crocko.com/2B13253F203148278BF304C01DC29E02/Tetris.7z (http://www.crocko.com/2B13253F203148278BF304C01DC29E02/Tetris.7z)
http://www.crocko.com/4DAFF5EE8B62439DB3D872295EAA43C5/bgd_mono.7z (http://www.crocko.com/4DAFF5EE8B62439DB3D872295EAA43C5/bgd_mono.7z)
http://www.mirrorcreator.com/files/AOUCZKSX/bgd_mono.tar.gz_links (http://www.mirrorcreator.com/files/AOUCZKSX/bgd_mono.tar.gz_links)
DCelso .... una palabra DROPBOX xDDDDDDDDD joer vaya tela ... he conseguido bajar uno xD
Jejej es que era pa no registrarme. Cual te fue?
Yo también quiero probarlo, pero no he conseguido descargar nada de ahí :\
Prueba a subirlo aquí como proyecto:
Subir proyectos a la web (BETA 2.0!) (http://projects.bennugd.org/cpanel/login.php)
Públicamente no aparecerá la descarga, pero puedes hacer un pequeño hack y copiar el enlace del gestor del proyecto
He conseguido descargar el bgd_mono.7z ... he probado lo de linux y funciona en mi Ubuntu 12.04 64bits aparentemente bien xD. no lo he probado a fondo. Ahora quiero probar el de PSP pero voy a tener q hacer un prg al gusto de la psp xD a ver si encuentro mis notas de cuando hice pruebas xD. ¿el dcb tiene q llamarse main.dcb obligatoriamente no?
Vale .. he conseguido hacer q funcione en la psp xD perfect :P he tenido q hacer un programa exclusivo ... voy a ver si consigo portar mi 4 dias cubierto de mierda :P
Ok, he conseguido q funcione el jueguecillo en la consola ... con la version anterior q tenia del bgdi para psp los colores salian jodidos .. pero en esta version estan perfectos. He hecho q el juego este a 320x240 q es la unica resolucion q recuerdo q iba bien en la consola xD no me acuerdo cuales eran las otras resoluciones mayores .. creo recordar q con un scale_resolution se podian hacer cosas. Lo que si no me acuerdo aunque creo q lo tengo por ahí era el tema de los botones ... no me acuerdo como iba ..a ver si lo encuentro.
Olee. Cuentame. Como has generado el dcb?. Lo de las teclas es un joy . Se usa con mod joy. Lo del main.dcb ya da igual. Puede ser cualquiera siempre k termine en .dcb.
Necesito saber tambien si van los dcbs generados con los binarios oficiales dinamicos. Que supongo que no porque con mi version monolitica no iban. Tambien necesito saber si te tarda mucho en cargar.
Y version de firmware de tu psp y modelo. 1000. 2000. 3000 o Go.
Ah. Intenta bajarte el tetris. Dime de que pagina te funciono la descarga
Jop. Yo quiero probarrr. Cagoen. A nadie le sobra una bateria? :-). Brikeé la psp con las tonterias y to. :'(
Voy a probar a compilar el dcb con la consola. De momento lo he hecho en linux con la version oficial, no con la tuya. Ya encontré mis "apuntes" para psp, los tenia escondidos en una carpeta de Ubuntu One xD. La pagina que me funciono la descarga es la de crocko.com, aunq costó trabajito xD.
En cuanto al firmware .. no me acuerdo hace mil años q la piratee .. pero en informacion de sistema, software de sistema (q me imagino sera eso el firmware xDDD) aparece 5.50 GEN-D2... y la consola no se cual es xDDDD ... en el codigo de barras que tiene abajo lo ultimo que aparece es PSP1004 xDD asi q supongo q sera el modelo 1000 xDDD
Pues eso q con mis apuntes consegui mapear los botones .. me falta hacer la prueba del joy. Tarda como 6 o 8 segundos en arrancar el juego.
Voy a ver si consigo bajar el tetris.
https://www.dropbox.com/s/vqe3g7ukaq2ms5d/Tetris.7z
https://www.dropbox.com/s/c9a66z89kz9aoqx/bgd_mono.tar.gz
Quote from: KeoH on August 05, 2012, 10:18:20 PM
Voy a probar a compilar el dcb con la consola. De momento lo he hecho en linux con la version oficial, no con la tuya. Ya encontré mis "apuntes" para psp, los tenia escondidos en una carpeta de Ubuntu One xD. La pagina que me funciono la descarga es la de crocko.com, aunq costó trabajito xD.
En cuanto al firmware .. no me acuerdo hace mil años q la piratee .. pero en informacion de sistema, software de sistema (q me imagino sera eso el firmware xDDD) aparece 5.50 GEN-D2... y la consola no se cual es xDDDD ... en el codigo de barras que tiene abajo lo ultimo que aparece es PSP1004 xDD asi q supongo q sera el modelo 1000 xDDD
Pues eso q con mis apuntes consegui mapear los botones .. me falta hacer la prueba del joy. Tarda como 6 o 8 segundos en arrancar el juego.
Voy a ver si consigo bajar el tetris.
Umn, interesante, eso de que funcione el dcb creado con la oficial, facilita mucho las cosas :D.
Lo del joistic, tirado. importas mod_joy y defines las siguientes constantes
//PSP Controls
#define PSP_TRIANGLE_BUTTON 0
#define PSP_CIRCLE_BUTTON 1
#define PSP_X_BUTTON 2
#define PSP_SQUARE_BUTTON 3
#define PSP_L_BUTTON 4
#define PSP_R_BUTTON 5
#define PSP_DOWN_BUTTON 6
#define PSP_LEFT_BUTTON 7
#define PSP_UP_BUTTON 8
#define PSP_RIGHT_BUTTON 9
#define PSP_SELECT_BUTTON 10
#define PSP_START_BUTTON 11
//Joystick?
#define PSP_LEFT_RIGHT_AXIS 0
#define PSP_UP_DOWN_AXIS 1
luego ya puedes usar
if(get_joy_button( PSP_UP_BUTTON))
.....
end
[end]
Un truco para poder rular el mismo juego en psp y windows o linux (o cualquier por con soporte de teclado.. :D) es el siguiente:
Defines unas variables para las teclas en caso de psp;
[code]
//PSP Key layout
int __A = PSP_X_BUTTON;
int __B = PSP_SQUARE_BUTTON;
int __SELECT = PSP_SELECT_BUTTON;
int __R = PSP_R_BUTTON;
int __L = PSP_L_BUTTON;
int __START = PSP_START_BUTTON;
int __UP = PSP_UP_BUTTON;
int __DOWN = PSP_DOWN_BUTTON;
int __LEFT = PSP_LEFT_BUTTON;
int __RIGHT = PSP_RIGHT_BUTTON;
metes al principio de tu main un if, para saber si estás en pc y así cambiarlas a teclas.
if(OS_ID == OS_WIN32 || OS_ID == OS_LINUX)
//Adapt controls to a keyboard
__A = _control;
__B = _alt;
__SELECT = _esc;
__R = _r;
__L = _l;
__START = _enter;
__UP = _up;
__DOWN = _down;
__LEFT = _left;
__RIGHT = _right;
end
y finalmente creas una función que compruebe si es el joystic o la tecla pulsada dependiendo del sistema en que esté rulando el juego.
function checkButton(int buttonID)
begin
if(OS_ID == OS_PSP)
return get_joy_button(buttonID);
else
return key(buttonID);
end
end
y a partir de ahí usar checkButton para saber si hay una tecla pulsada
if(checkButton(__A))
......
end
[end]
Quote from: KeoH on August 05, 2012, 10:18:20 PM
---
En cuanto al firmware .. no me acuerdo hace mil años q la piratee .. pero en informacion de sistema, software de sistema (q me imagino sera eso el firmware xDDD) aparece 5.50 GEN-D2... y la consola no se cual es xDDDD ... en el codigo de barras que tiene abajo lo ultimo que aparece es PSP1004 xDD asi q supongo q sera el modelo 1000 xDDD
---
ah todo lo que dices es correcto y todo igual que la mia que me cascó, que curioso :D.
Si, así es como tengo las teclas definidas, creo q lo copié de un codigo que dejaste por ahí. Pero cuando declaras las variables __A y __B ... se te han olvidado declarar otras __C y __D para los botones de circulo y triangulo que he añadido, y lo mismo para usar otras teclas en win/linux equivalentes.
El tetris me funciona perfectamente, aunq tarda mas en cargar. y veo mucha pantalla desaprovechada xDDD.
Has hecho pruebas sobre las resoluciones maximas q soporta la psp? 480x272 tengo yo en mis pruebas. Voy a ver si la puedo duplicar sin que se queje la consola xD
sí, físicamente esa es la resolución real de la psp (480 x 272 pixels), si pones otra distinta, creo que las SDL de psp te la deforma para mostrarla en 480x272, así que da igual la que pongas, si es una resolución más grande, verás todo mas chico en la psp y si es una resolución mas chica, verás todo más grande en la psp.
kkdvk que no pueda probar. jop.
Por cierto, antes el tetris se colgaba al darle mucha caña, eso de salir, empezar, salir, empezar, mover como un loco, etc, mira a ver si ahora no se cuelga. Pero por lo que dices, parece que al fín tenemos una versión estable para psp (lenta al cargar, pero estable :D, tengo que dedicarle algún tiempo a ver por qué es tan lenta la carga es como si reintentase iniciar un recurso n veces y al ver que no puede sigue, ejemplos de SDL normales sin bennu cargan volados).
DCelso, ya estas usando la rama oficial?
con pasar a la rama oficial se solucionaron los problemas de color?
me podrias hacer un resumen de pocas lineas del status? gracias y disculpa que moleste.
buenas y malas noticias.
ya tengo la psp disponible para pruebas, pero he hecho pruebas con los nuevos binarios usando tu formato de monolítico y da los mismísimos resultados que con la mia, los juegos se paran y bloquean la psp aleatoriamente (aparentemente claro). Asi que mi versión monolítica tampoco era tan mala, va igual.
He probado con custom firmware 5.00m30-4 y 5.00m30-6 con mismos resultados, probaré con el último custom firmware para corroborar que no es culpa de fallos de los custom firmware.
Estoy intentando firmar los binarios, para poder probar en firmwares oficiales, pero sigo creyendo que es algo de alineamiento de datos (como ya pensaba hace un año)
Lo de los colores es porque la psp trabaja al reves que el pc los endianeses, así que algunos formatos de archivos de imagen no se cargaban bien, había que invertir los R-B al leerlos y guardarlos en los map de bennu.
Cuando tenga noticias nuevas, las pegaré, pero vamos por ahora lo veo igual que hace un año. :'(
gracias por el resumen.
quiero decir que nunca pense que tu version era mala.
con respecto a los cuelgues de psp y demas, seria bueno probaras ejemplos sin video, o sea, ejecucion, loops con frames, procesos y demas, sin graficos, etc... a ver si es cosa de sonido o sdl.
la idea es acotar un poco los errores.
Exacto. En ello estoy.
cuando dije sin video, tambien me referia sin teclado, sin sonido y demas... solo probar el motor del "interprete"...
suguiero hacer pruebas (en ejemplos separados y luego combinandolos) con int, short, byte... punteros, etc.... y ver como se comportan en cada caso... la version que pruebes no debe tener compilado modulos de video, sonido, teclado, joys, etc.... simplemente maquina virtual y modulo say... con eso creo que seria suficiente...
imagino que ya lo tenias claro, pero nunca esta demas remarcar para no dejar dudas.
gracias por el esfuerzo que le pones... karma para ti!
eso hice con mi versión monolítica, solo con mod say tampoco iba en algunos bucles, tengo que buscar los ejemplos que tenía hace un año y probarlos con tu versión, pero todo eso lleva tiempo. a ver si saco huequitos poco a poco.
Splinter, te adjunto un .patch sobre la última versión de svn, para que veas los cambios que hice al código, son muy pocos ya con la nueva versión monolítica :D.
Sabes mirar un .patch ¿no?
En resumen los cambios se reducen a los swap
en las imagenes con colores invertidos, en incluir algunas cabeceras que me pedía el compilador y en saltar las partes que no funcionan en psp del código oficial.
Si tienes un hueco échale un vistazo a ver si estoy cometiendo alguna locura que produzca estos errores. :D
se como leer un patch...
lo revisare y te comentare...
gracias.
Splinter, lo viste?
Por cierto me he metido en camisa de 11 varas, vi que había una versión más reciente del pspdev, e intentando instalarlo en linux/debian, me he encontrado con un millar de fallos para linux/bash en los scripts de compilación, llevo tres dias arreglando fallos y no consigo instalar por completo el entorno de desarrollo de psp, cagoen, pero bueno, espero que alguno de los cambios que hayan hecho en este último año hayan arreglado mas de un problema :D.
Mientras estoy probando con el bgdi que generé con el antiguo entorno y no encuentro un patrón fiable que cuelgue a la psp. parece como algún fallo de no liberación de recursos que haga que la psp se cuelgue cuando llena su memoria o se hace un acceso indebido, y de ahí que siempre se cuelgue en lados distintos. No se no se está fea la cosa.
vi el parche, si... es para PSP, como bien has dicho y se carga todo el codigo no PSP...
por otro lado, me parece que no es tan necesario que hagas esos parches, segun habia visto, se puede setear el modo de color RGB, BRG, etc, en SDL... no recuerdo donde lo vi... pero recuerdo (o soñe) que se podia hacer... lamentablemente no tengo hardware ni tiempo para hacer pruebas... y por ende menos entusiasmo en hacerlo.
lo de lo liberacion de recursos, a menos que tengas una pista certera de eso, te diria que no hay fugas en ese sentido... claro esta que si tu cargas mapas, sonidos u otros recursos dentro de un proceso y nunca los liberas, seguro que ahi tendras fugas, pero el motor todo lo que reserva, lo libera cuando ya no lo usa.
DCelso, vi el parche, y no se porque dije que se carga todo el codigo PSP (bueno, en algun que otro caso si...), quiero preguntarte algunas cosas que veo...
por que esto? que bugs encontraste que hiciste esto?
Index: core/bgdc/src/c_code.c
===================================================================
--- core/bgdc/src/c_code.c (revision 277)
+++ core/bgdc/src/c_code.c (working copy)
@@ -1718,6 +1718,7 @@
return res ;
}
compile_error( MSG_NUMBER_REQUIRED ) ;
+ res.type.chunk[0].type=0;
return res ;
}
else if ( token.code == identifier_bnot ) /* "BNOT" or "~" */
@@ -1741,6 +1742,7 @@
return res ;
}
compile_error( MSG_NUMBER_REQUIRED ) ;
+ res.type.chunk[0].type=0;
return res ;
}
y esto?
Index: core/bgdrtm/src/sysprocs.c
===================================================================
--- core/bgdrtm/src/sysprocs.c (revision 286)
+++ core/bgdrtm/src/sysprocs.c (working copy)
@@ -231,6 +231,10 @@
unsigned int n ;
DCB_VAR rvar ;
void * rdata = NULL ;
+
+ rvar.Type.BaseType[0]=0;
+ rvar.Type.Members=0;
+ rvar.Type.Count[0]=0;
token_ptr = varfixup->var ;
y este otro?
static int moddir_cd( INSTANCE * my, int * params )
{
+#ifndef TARGET_PSP
char * d = dir_current() ;
int r = string_new( d ) ;
string_use( r ) ;
if ( d ) free( d ) ;
return r ;
+#else
+ char current_dir[PATH_MAX];
+ getcwd(current_dir,PATH_MAX);
+ int r = string_new( current_dir ) ;
+ string_use( r ) ;
+ return r ;
+#endif
}
despues veo que cuando cargas los fpg haces un swap (cosa que deberia hacerse automaticamente con en la fileread... si no lo hace me da la impresion que el codigo de deteccion de byteorder no esta soportando PSP, quizas ese sea la madre de los problemas)... y luego cuando usas el fpg volves a hacer otro swap de bytes... lo mire muy por arriba, pero me parece que algo raro hay.
Los dos primeros trozos de codigo son de asignaciones a cero. El compilador de c de psp se quejaba de que no estaban iniciados y que podrian ser usados sin estarlo. Entonces los puse a cero para evitar ser usados con datos espureos. Crei que podrian venir por ahi los cuelgues. Pero nada nal principio parecia arreglarlo parecia mas estable pero se seguia colgando. Asi que quizas seqn innecesarias esas asignqciones a cero pero tampoco estan de mas.
Luego el parche tercero era porque usas asignacion dinamica para el string y crei que por qhi tqmvien podria haber problemas de direccionqmiento y o memoria asi que lo puse en cadenq estatica por si.arreglaba algo.
Pero tampoco arreglo nada. Asi que tqmpoco es unbparche. Necesario.
Lo de lo del swap automatico. Que me dices Eso pinta muy bien. Casi fijo que es el problema de los cuwlgues
en todo caso, inicialos al inicio... el compilador da warnings en esos, pero por las condiciones que estan antes, deberian estar seteados para los casos donde se necesitan... el problema es que si los seteas antes del return, podes estar pisando (seguro lo esta haciendo) algun seteo de estos en un if que si corresponde...
despues de cambiar esto, tendrias que recompilar tus dcb, ya que esto afecta a los dcb (casos de fuentes bgdc).
PD: ahora que miro el parche, si va tras un compile_error, entonces olvidarse de todo eso, el compile_error aborta la ejecucion de la aplicacion.
Por cierto, OS_PSP es 1001 según ese parche, ¿no?
Lo he añadido al wiki, que faltaba.
Hay posibilidad de actualizar el interprete o el proyecto esta abandonado?
Hace tiempo baje una demo de un tetris.
Funcionar funciona bien tal como esta si uso los archivos que trae, pero si compilo el prg, deja de funcionar y la psp se bloquea.
Por cierto. Gracias a todos aquellos que siguen trabajando en actualizaciones y mejoras en el lenguaje despues de tanto tiempo.
Eu posso tentar recompilar o port para PSP e verificar se está funcionando. Poderia enviar o demo do tetris para testar?
Quote from: Abash on March 14, 2017, 12:27:56 PM
Hay posibilidad de actualizar el interprete o el proyecto esta abandonado?
Hace tiempo baje una demo de un tetris.
Funcionar funciona bien tal como esta si uso los archivos que trae, pero si compilo el prg, deja de funcionar y la psp se bloquea.
Por cierto. Gracias a todos aquellos que siguen trabajando en actualizaciones y mejoras en el lenguaje despues de tanto tiempo.
El port de PSP tiene algunos errores conocidos, problemas de color, lo llebaba DCElso pero esta descontinuado, lo ideal seria poder portar la ultima version.
Otro problema que tenia el port era los tiempos de ejecución y carga eran muy lentos.
Daniel te dejo el juego como adjunto. Te lo subo desde el telefono movil y no se si me lo subira bien.
El EBOOT no es el original que venia con el juego. Es otro que no se de donde lo saque.
Ni el original ni otros 3 que e intentado usar me funcionaban.
La PSP quedaba bloqueada.
En la PSP Slim que tengo funciona. Tarda un poco en cargar el juego.
Quote from: Abash on March 14, 2017, 04:49:30 PMDaniel te dejo el juego como adjunto. Te lo subo desde el telefono movil y no se si me lo subira bien.
El EBOOT no es el original que venia con el juego. Es otro que no se de donde lo saque.
Ni el original ni otros 3 que e intentado usar me funcionaban.
La PSP quedaba bloqueada.
En la PSP Slim que tengo funciona. Tarda un poco en cargar el juego.
No hay manera de cargarlo en la consola real :( ,
que CFW estas usando? yo uso el ultimo CFW 6.61 PRO-C2, en una PSP 3000
Realmente hay que llamarlo "game.dcb" ?? no es "EBOOT.dcb"???