BennuGD Android

[SplinterGU]

joseba, con respecto al SDL1.3, tiene mejor rendimiento que el 1.2? probaste con acceleracion opengl (sobre SDL1.3)?

ya es hora de empezar a meter SDL1.3 en la rama oficial... y tengo intenciones de que los graphs sean surfaces SDL...

quizas ya esto podria ser una version 2.x de los modulos.

ahora solo estoy en fase de ganas... espero pronto sea fase de construccion.

[josebita]

Creo que la aceleración OpenGL (aceleración por hardware, en general) ya se hace automáticamente si la plataforma lo soporta. Aún así eso no aporta ganancia de rendimiento porque lo único que hace es acelerar el blit "surface"->pantalla (donde surface es la SDL_Surface definida en libgrbase) y lo que es realmente lento es todo el redibujado procesos->"surface".

Lo que sí que aceleraría MUCHO sería lo que dices: hacer todos los graphs texturas (no surfaces) de SDL1.3 o surfaces por hardware de SDL1.2. Porque ahí SDL se encargaría de hacerlo por hardware en la plataforma mediante el sistema nativo: OpenGL, OpenGL ES, DirectX... o si todo falla, por software. Creo que es el camino a seguir porque es la forma más sencilla de conseguir aceleración por hardware casi "gratis". Había pensado en intentarlo yo pero la verdad es que no me veo capaz de hacerlo sin tener mi rama rota durante bastante tiempo.
El único "problema" es que habría que parchear SDL para que soportara rotación de texturas porque no lo soporta. No creo que sean más que un par de líneas en cada sistema de rendering acelerado, se podría copiar lo que tenemos ahora para la rotación por software y podría mandar los parches a la lista de SDL. Con la ventaja de que si la plataforma soporta aceleración por hardware entiendo que la rotación se podría hacer fácilmente con antialias.

En todo caso, lo que sí considero que sería muy importante sería independizar Bennu del sistema de renderizado: me da la impresión -corrígeme si me equivoco- de que ahora mismo el sistema de renderizado está "mezclado" dentro del código. de unos cuantos módulos. Sería interesante buscar el mínimo de funciones necesarias de forma que si se implementan esas funciones para un sistema nuevo el renderer funcione en ese sistema nuevo.
Como lo que hace SDL aquí, vamos.

[SplinterGU]

segun tengo entendido (por lo poco que lei, pero puede que me equivoque...) el modo opengl no viene automatico... y el modo opengl, hace que las surfaces sean texturas transparentemente, en eso se basa la acceleracion... yo no encontre ninguna referencia de como hacer rotaciones, pero me parece que SDL 1.3 esta mejor diseñado y permite agregar funcionalidades mas facil... (pero puede que me equivoque tambien)... recien empiezo a ver el tema...

con respecto al render esta bastante separado, el problema es que la mayoria de las funciones estan pensadas en que el area de datos del grafico esta siempre en memoria accesible directamente, y en opengl, sabemos que las texturas estan en la tarjeta y para modificar datos de la misma hay que descargar la textura de la placa de video,  modificarla y volverla a subir o tener siempre la textura en memoria ademas de tenerla en la memoria de la tarjeta y al aplicarle cambios subirla... evitando la descarga de esta de la memoria de video.

[josebita]

La conversión SDL_Surface<->SDL_Texture no es automática. En SDL 1.2 las SDL_Surface tenían un campo que indicaba si estaban aceleradas por hardware o no. Ahora se han separado las dos cosas y puedes tener SDL_Surfaces y SDL_Textures tanto cuando estás renderizando por software como por hardware, aunque sea un poco tonto en ppio. usar SDL_Textures cuando estás renderizando por software.

En SDL 1.3 el tema del renderizado por hardware o por software va un poco así:
Lo que vendría a ser SDL_SetVideoMode se ha dividido en varias funciones porque ahora se soporta que una aplicación dibuje más de una ventana a la vez. El equivalente ahora es:

• SDL_CreateWindow(): Te crea una ventana con las dimensiones y los FLAGS que desees. La función unicamente se habla con el gestor de ventanas, no sabe nada de dibujado.
• SDL_CreateRenderer(): Crea un SDL_Renderer que puede ser software o acelerado por hardware (OpenGL, OpenGL ES, DirectX.. "acelerado por software" puede significar cosas distintas según la plataforma). Este paso es opcional y si no se hace, por lo que he leído en las listas de SDL, trata de utilizar primero los modos acelerados por hardware. Si no se hace a mano, es SDL el que lo hace, claro.

Ahora las SDL_Surface y las SDL_Texture son cosas completamente independientes y la diferencia es que con las SDL_Texture no tienes acceso directo al bitmap porque están almacenadas en la RAM de la tarjeta gráfica. Tampoco se puede hacer blit de unas texturas a otras directamente. Aún así, se puede crear una SDL_Texture a partir de una SDL_Surface y las SDL_Surfaces siempre se van a blittear por software.

Así que si quieres velocidad lo que hay que tender a usar es SDL_Textures, siempre que la plataforma admita aceleración hardware porque sólo la combinación SDL_Texture+SDL_Renderer acelerado te da aceleración real.

[josebita]

[Enviado al hilo de android y al de iOS, porque aplica a los dos]
Acabo de hacer un commit relativamente grande e importante a mi rama, los cambios fundamentales son:

• ¡Finalmente me he librado de la capa de compatibilidad SDL1.2<->SDL1.3 en dispositivos!. Aún la uso en la libkey/mod_key, pero esa no la estoy compilando para dispositivos.
• La orientación del dispositivo se establece automáticamente ahora en iOS: si el ancho es mayor que el alto, se asume que quieres estar en modo apaisado y el dispositivo se configura de esa manera.
• Parece que la imagen ya no se congela cuando pasan eventos de pantalla. Antes Bennu hacía automaticamente una chapucilla para forzar a refrescar la pantalla, pero parece que ya no hace falta :)

Aún hay bugs y tengo que probarlo pero parece que la cosa avanza :)

[josebita]

Publico una versión actualizada del APK para android con el último código de hoy. Aún tiene muchos bugs, pero bennu ya pone el modo de pantalla a pantalla completa en el teléfono. Bugs conocidos:
* Se sigue sin poder hacer set_mode(). Parece un bug en SDL que luego reportaré. Aún así, Bennu se inicia en modo pantalla completa directamente y lo que hay que hacer es averiguar a qué resolución estamos y adaptar el funcionamiento del juego en tiempo de ejecución.
* El main.dcb debe estar en la carpeta "data" de la SD de forma que esté en /mnt/sdcard/data/main.dcb.
* El tema del sonido está como antes: al salir de la aplicación no se pausa el sonido, pero es que además si estais reproduciendo un fichero de música y llega al final de la canción, casca.

APK + programa de ejemplo que muestra cómo averiguar la resolución (y la imprime por adb).
http://www.megaupload.com/?d=8L12GETJ
http://www.megaupload.com/?d=GGYPT0PU

[Edito] El cuelgue de la música se solucionó hace tiempo en SDL_mixer pero yo no había actualizado el código.

[JaViS]

Lo probamos en un Samsung Galaxy Ace y funciona bien.

No escuchamos ningun sonido, cuando se supone que deberia reproducirse?

Es curioso que cuando tocas la pantalla con dos dedos no responde de la misma forma que en IOS, que me soluciona un par de dolores de cabeza ^_^

Una lastima lo del set_mode, no voy a poder probar el juego que estamos haciendo todavia porque jugamos con diferentes resoluciones :)

Excelente trabajo!! :D me muero de ganas por probar lo que estamos haciendo. gracias!

[josebita]

Acabo de subir un apk nuevo que soluciona el tema de la reproducción de música. Creo que en el programa de ejemplo no debe sonar nada (hay una variable global sound que controla si se reproduce el ogg o no).
Aún así, no podrás setear la resolución a mano: en la mayor parte de los móviles la resolución es única y sólo se puede establecer esa, por eso debes mirar cuál es e intentar adaptar el funcionamiento del juego. Es probable que ése sea el comportamiento definitivo...

El nuevo apk que debería solucionar lo del crash al finalizar la reproducción de la música:
http://www.megaupload.com/?d=HTCLNVN4

El mismo programa de ejemplo que antes:
http://www.megaupload.com/?d=8L12GETJ

[JaViS]

Bueno, entiendo tu punto, pero para eso esta scale_resolution, no?

es decir, en IOS siempre anda a la resolucion que debe ser, pero nosotros por una cuestion de rendimiento y tambien relacionada con el estilo grafico, cambiamos de resolucion de la nativa a la mitad de resolucion de la nativa entre menues y el juego en si.

gracias a scale_resolution se puede decir que anda a la resolucion del dispositivo.

edit:

si soportara set_mode y scale_resolution seria mejor todavia para android, en donde encontramos muchos dispositivos con diferentes pantallas.

[josebita]

Hombre, la idea es que se pueda hacer al menos un set_mode a mano para que funcione el scale_resolution pero piensa que el scale_resolution no va a servir (porque va a escalar la imagen con muy poca calidad) en caso de tener una pantalla mucho más grande que aquella para la que está pensado el juego. Vamos, que habrá que ver qué tal escalan los juegos hechos para móviles cuando se usan en tabletas.

De todas formas, he visto que SDL1.3 tiene rutinas de escalado automático que se hacen por hardware (y que pueden suavizar el escalado mediante opengl) así que igual intento hacer que el scale_resolution en SDL 1.3 se haga por hardware, que además así seguro que aumenta el rendimiento...

[JaViS]

El tema de la calidad de la imagen no es una preocupacion, veras, estoy haciendo juegos en pixelart con un acabado "retro", y hacer sprites en baja resolucion me ayuda mucho. El escalado de scale_resolution funciona perfecto para este caso.

Supongo que, ademas de la performance, tambien pasa por una cuestion de posibilidades. Imagino que, como yo, habrán otros que encontrarán la ventaja de jugar con diferentes resoluciones durante el gameplay.

[sereno]

Hola, lo primero agradeceros y daros ánimos a todos los que hacéis posible bennugd y por el port a Android.
He probado el ejemplo que has puesto y funciona con sonido y todo en un ZTE blade, también cambia la pantalla al inclinarla pero después ya no detecta que tocas la pantalla (no se si es un bug)
Lo dicho gracias  :)

[josebita]

Hola, lo primero agradeceros y daros ánimos a todos los que hacéis posible bennugd y por el port a Android.
He probado el ejemplo que has puesto y funciona con sonido y todo en un ZTE blade, también cambia la pantalla al inclinarla pero después ya no detecta que tocas la pantalla (no se si es un bug)
Lo dicho gracias  :)

Bienvenido, lo primero :)
Sí, lo de la rotación es un bug que habrá que arreglar.
Por lo que comentais parece que el código funciona en varios modelos distintos de android, ¿me podríais poner la versión de android que estais usando, sólo por ir haciéndome una idea?.

Yo uso 2.2 en mi móvil (LG Optimus Black) y 2.3.3 en el emulador.

[sereno]

En el ZTE Blade tengo la 2.2 que venía de serie

[josebita]

Splinter, para poder leer directamente recursos que estén incluídos en la aplicación (en el apk) en android voy a necesitar leerlos usando el interfaz SDL_RWops de SDL, ¿cómo lo harías tú para que compatibilizar esto con el código Bennu actual?. ¿Quizás añadiendo otra entrada a file->type que sea F_SDLFILE?.

En el ZTE Blade tengo la 2.2 que venía de serie

Gracias.