BennuGD Android

[josebita]

Vale, he desactivado el soporte para SMPEG temporalmente hasta que vea qué puede estar pasando y he hecho una compilación entera limpia en Windows con el NDK 8e.

Eso sí: he probado a compilar con el NDK 9 (que ha salido hoy) y da algunos problemas, así que no actualices el NDK.

PD: Parece que Google me ha bloqueado el acceso a Google Code. No entiendo muy bien por qué pero mientras se resuelve puedes obtener una copia del último código aquí:
https://www.dropbox.com/s/7vm0j7bsxbq7rns/bennugd_src_20130726.7z

[FreeYourMind]

Muchas gracias josebita, por fin he podido compilarlo :) Lo he probado y funciona, asi que esta funcional.

Tengo una duda y a lo mejor es porque hay que controlarlo por codigo, la pregunta tambien la puede responder Javis y Pixel:

Noto que si le doy al menu mi juego sigue sonando su musica o sea su ejecución no se para y si vuelvo la pantalla esta se queda negra pero el juego rulando, sólo al volver y salir un par de veces se pone bien, este problema con lo del salir al menu lo llevo relatando hace tiempo, que me ocurria en la tablet y en varias consolas android de modo similar.

Veo que en los juegos de pixel y en el monkey esto no ocurre, asi que la pregunta es, estais parando vosotros la ejecución del juego al darle al menu ?

De paso voy a probar esta version en las consolas con el joy test a ver si por fin me detecta ya los joysticks de las consolas.

Muchas gracias a todos

[FreeYourMind]

Ya tengo un resumen:

- Ahora funciona bien en todos mis cacharros android, incluida la Droid 360, que antes con versiones anteriores se congelaba y salia del juego.

- Los joys siguen sin detectar nada, he probado el test android que tienes con fondo rojo.
La diferencia es que con anterior version este test petaba, daba despues mensaje de error al presionar algun joy button o cruzeta, y ahora tambien peta pasado unos segundos despues de presionar algun joy button, pero no sale mensaje de error y sale del juego.

[panreyes]

focus_status :)

Code Select Expand



if(os_id==1003 and !focus_status) //en android, si estamos en 2º plano, nos vamos al aire
let_me_alone();
fade_music_off(500);
while(is_playing_song()) frame; end
salir_android();
end



Luego, en la función salir_android, hacemos un guardado rápido de la partida para que cuando se vuelva a abrir el juego, se empiece desde el punto más cercano.
Pruébalo en PiX Pang en Android. Si cierras el juego rápido y luego vuelves, apareces en el nivel que estabas.

[FreeYourMind]

gracias! afinal habia control de salida :)

[josebita]

Nuevo post con info sobre algunas de las últimas novedades:
http://bennugd-mobile.blogspot.com/2013/10/mvr-gpu-scaling-in-app-purchases.html

[warrior_rockk]

¿Se pudo solucionar el tema de las GPU Adreno?

[emov2k4]

¿Se pudo solucionar el tema de las GPU Adreno?

Tengo entendido que hace tiempo !!

Nuevo post con info sobre algunas de las últimas novedades:
http://bennugd-mobile.blogspot.com/2013/10/mvr-gpu-scaling-in-app-purchases.html

Excelente noticia !

[josebita]

Yo diría que hace tiempo, sí. Creo que fue pixel quien encontró el problema.
¿Se pudo solucionar el tema de las GPU Adreno?

[MythomizeR]

¡Hola compañeros!

Una pregunta, ¿Existen en BennuGD Android ciertos problemas con el soporte para colores a 32 bits?

Lo digo porque, por más que lo intento, solo me funciona el set_mode con 16 bits, y es que cuando lo pongo a 32 bits se ven mal los colores de los gráficos, o directamente, no se ve nada.

Solo me funciona a 32 bits el ejemplo que trajo la primera release, la del círculo que rebota por la pantalla y que usa la api de Android 2.3.3... es muy raro.

¿Es que hay alguna limitación o razón técnica (formato en el que deben de ir los gráficos, etc.) por lo que no me funciona y que tenga que saber?

Aunque no creo que haya problema por mis máquinas, decir que mis pruebas las hago sobre una tableta con GPU Mali-400 (SoC Allwinner A10) con pantalla de 800x480 pixels, y en un móvil que ahora no sé exactamente su GPU pero que tiene mejor SoC que la tableta (pantalla de 480x854 pixels), y sin embargo, como digo, en ambos tengo el problema con los 32 bits.

Gracias, un saludo!  :)

[josebita]

¿Puedes mandarme por mail el APK que estás usando?. ¿Qué versión de BennuGD para Android estás usando?.
Me gustaría revisarlo, pero a primera vista puede ser por alguna incompatibilidad con la GPU, sí.

Un saludo

[MythomizeR]

¿Puedes mandarme por mail el APK que estás usando?. ¿Qué versión de BennuGD para Android estás usando?.
Me gustaría revisarlo, pero a primera vista puede ser por alguna incompatibilidad con la GPU, sí.

Un saludo

Hola Joseba, te explico:

- Esta tarde he comprobado que el LogCat cuando compilo y envio a mi tableta suelta esto:

12-22 20:23:08.240: V/SDL(5472): onResume()
12-22 20:23:08.300: V/SDL(5472): surfaceCreated()
12-22 20:23:08.300: V/SDL(5472): surfaceChanged()
12-22 20:23:08.300: V/SDL(5472): pixel format RGB_565
12-22 20:23:08.300: V/SDL(5472): Window size:800x444
12-22 20:23:08.320: V/SDL(5472): Language: es

por lo que ya veo que mi programa no estaba funcionando realmente a 32 bits (aún habiéndolo indicándo en el set_mode) como yo me pensaba, sino a 16 bits, ¿verdad?

En cualquier caso, como digo, en la versión de BennuGD Android que tienes colgada (API 2.3.3), sí que se muestran correctamente los colores de los gráficos haciendo "set_mode (800,480,32)" (aunque la tableta realmente funcione a 16 bits por lo que se ve en el log que te he puesto).

- La versión de BennuGD Android que empleo y con la que tengo los problemas con los colores en modo 32 bits es la contenida en la carpeta "libs" (archivos con fecha 10/12/2013) que cogí de la última actualización de la plantilla de Pixel:

libs\armeabi:

22/12/2013  20:12    <DIR>          .
22/12/2013  20:12    <DIR>          ..
10/12/2013  22:53           822.476 libbgdrtm.so
10/12/2013  22:53            13.448 libmain.so
10/12/2013  22:53           162.768 libmikmod.so
31/10/2013  20:25           136.312 libpng.so
10/12/2013  22:53           527.444 libSDL2.so
10/12/2013  22:53           349.776 libSDL2_mixer.so
               6 archivos      2.012.224 bytes
               2 dirs  45.823.815.680 bytes libres

(la carpeta "libs" trae además otras 2 carpetas "armeabi-v7a" y "x86" además del ouya-sdk.jar, supongo para otras arquitecturas)

- El .apk lo tienes aquí, como digo, a mi se me ven los colores cambiados de la pelota (y de lo que cargue con "set_mode 32 bits"):
https://mega.co.nz/#!rUMWEJAJ!eOC3TQBctAnVMPlyJaKoRFGj2-o_9Zcy6bV-O0hlmU4

[josebita]

Splinter, estoy trabajando en añadir soporte para SDL_Render como librería de renderizado.
De momento parece que lo básico empieza a funcionar, como se puede ver aquí.
Básicamente, lo que he hecho es añadir un puntero a una SDL_Texture a cada GRAPH además del puntero a los píxeles. Lo hago además y no "en lugar de" porque el API de SDL_Render no soporta leer el contenido de las texturas y la propia documentación de SDL dice que si se quiere tener acceso a los bitmaps se debe guardar una copia en RAM.

Básicamente la forma de trabajo es que en gr_blit y gr_rotated_blit tengo un bloque if que distingue si estamos pintando a pantalla o a otro GRAPH. Si estamos pintando a un GRAPH se usan las rutinas de toda la vida (software) y al final se actualiza la texture pero si estamos pintando a la pantalla se usan las rutinas de SDL_Render.

He visto que el valor de la variable local "alpha" se pasa enmascarada (masked?) como parámetro a éstas funciones, pero no me ha quedado claro cómo obtener el valor de 0 a 255. ¿Te viene rápido a la memoria cómo funciona o me estudio el código?