BennuGD Android

[Drumpi]

En este momento quiero un aparato con Android! :O

No eres el único :D :D :D

Si aún sigues despierto, mándamelo al mail, que tengo ganas de probar el PiX Frogger en el móvil! :D

¡¡SACRILEGIO!! ¡¡EL QUE HAY QUE PORTAR ES EL PIX-PANG!! Mantengamos las tradiciones ancestrales (que si no, friyurmaind te quita el record del juego con más ports ;D).

[josebita]

Venga, que ayer no lo puse. El módulo tiene dos funciones:

Code Select Expand

INT MULTI_NUMPOINTERS()Devuelve el número de punteros activos y

Code Select Expand

FLOAT MULTI_INFO(int pointer, string info)Devuelve la información asociada a info para el puntero pointer.
Los valores aceptados de info ahora mismo son:

Code Select Expand

"X": El tanto por 1 en x del punto de contacto (entre 0.0 y 1.0) -> Probablemente lo cambiaré por una coordenada real.
"Y": El tanto por 1 en y del punto de contacto (entre 0.0 y 1.0) -> Probablemente lo cambiaré por una coordenada real.
"PRESSURE": La presión, en tanto por 1, que se está aplicando -> Probablemente lo cambiaré por un valor entre 0 y 255 (es lo típico, ¿verdad?).
"ACTIVE": Si el puntero en cuestión está activo o no.


La segunda función la he hecho así porque la idea es que el módulo en realidad sean varios pero con el mismo API: al menos uno para multitouch basado en SDL y otro para los Wiimotes en la Wii. El módulo SDL 1.3 ya está funcionando pero para la Wii tendré que escribir otro distinto que implemente las mismas funciones.


De esta forma lo que se consigue es que puedas pedir información sobre los punteros de la Wii a un móvil con Android y el móvil simplemente ignore tu petición: el código con soporte para multi-entrada compila en ambos sistemas sin cambios.


¿Quizás sea mejor cambiar info para que sea un valor numérico asociado a una constante?. ¿Alguna idea sobre cómo se podría hacer mejor?.


Mil gracias.

[SplinterGU]

genial joseba!

no olvides tener en cuenta los modos escalados (scale_mode y scale_resolution)

[josebita]

Ups! pues sí que me había olvidado, sí :)

[JaViS]

no olvides tener en cuenta los modos escalados (scale_mode y scale_resolution)

eso significa que voy a poder cambiar de resolucion en mi juego? :D

[SplinterGU]

no olvides tener en cuenta los modos escalados (scale_mode y scale_resolution)

eso significa que voy a poder cambiar de resolucion en mi juego? :D

yo no dije eso...

significa que no se olvide de tener en cuenta los modos escalados (scale_mode y scale_resolution)

(en los calculos de posicion coordenadas)

[josebita]

no olvides tener en cuenta los modos escalados (scale_mode y scale_resolution)

eso significa que voy a poder cambiar de resolucion en mi juego? :D

De momento no, pero no será un port de bennu completo hasta que no deje de dar violaciones de segmento por llamar a set_mode() :)
De todas formas, recuerda que los cacharritos estos son muy poco versátiles en cuanto a la resolución a la que funcionan: la mayoría sólo pueden funcionar a su resolución nativa de forma que todo lo que hagamos serán "apaños" encima de eso.

Lo ideal (que es lo que hacen muchos juegos, como el Angry Birds) es que todo el posicionamiento se haga en función de la resolución a la que funcione el móvil y sea el juego el que se adapte al móvil y no al revés. Hacer eso añade un grado de complicación a la programación, claro.

[SplinterGU]

joseba, el scale_resolution, no fue pensado para cambiar la resolucion... sino para adaptar un juego hecho en una resolucion en otra... esto permitiria correr juegos en android que no estan preparados para la resolucion android.

asi que seria importante considerar esto en la implementacion multi-touch

[josebita]

joseba, el scale_resolution, no fue pensado para cambiar la resolucion... sino para adaptar un juego hecho en una resolucion en otra... esto permitiria correr juegos en android que no estan preparados para la resolucion android.

asi que seria importante considerar esto en la implementacion multi-touch

Sí, claro, me he debido expresar muy mal. Me refería a que cuando se hace un set_mode() en android muy probablemente el juego no se pondrá a esa resolución sino a la nativa del cacharro, y eso habrá que manejarlo de alguna forma, quizás haciendo un scale_resolution implícito o algo así.

Lo del scale_resolution (y la orientación) no lo había tenido en cuenta, pero en cuanto saque un rato para hacer esos cambios que comentaba en las llamadas y en las salidas a/de multi_info() lo implementaré.

PD: Lo cual me recuerda que aún no he cambiado el funcionamiento en el código SDL1.3 para que usen las rutinas de escalado por hardware. Por lo menos me gustaría probarlo, a ver qué tal va...

[SplinterGU]

si va por hardware, mejor.

[SplinterGU]

viendo los bugs que tiene la sdl1.3 actualmente en android (y en otros) se me ocurre preguntar si no pensaste probar con la sdl1.2 (si es que existe para android)?

[josebita]

viendo los bugs que tiene la sdl1.3 actualmente en android (y en otros) se me ocurre preguntar si no pensaste probar con la sdl1.2 (si es que existe para android)?

Sí que lo he pensado, sí. De todas formas, me imagino que también tendrán sus problemas.

En todo caso el port ya va por buen camino y queda poquito. Si por el camino se me complicara demasiado lo intentaré con SDL 1.2 :)

[SplinterGU]

aun veo que no esta la 1.3 en las distros linux, por esto tampoco quiero hacer el cambio o darle soporte a la oficial...

[josebita]

aun veo que no esta la 1.3 en las distros linux, por esto tampoco quiero hacer el cambio o darle soporte a la oficial...

No, no está. La 1.3 es versión en desarrollo para la estable que será la 2.0 que... legará algún día :) Por lo menos creo que ya está en fase "beta".

[KeoH]

Joseba, ¿Sería mucho pedir una versión compilada para linux del mod_multi para ir haciendo pruebas (aunq no sea definitiva xD)? he intentado compilarla con el codeblock pero no me sale xDD y si me puedes pasar el proyecto de eclipse (si lo haces con el) del port a android tambien estaria perfect q asi puedo firmar los apk xD Ya tengo los SDK puestos y todo xD llevo 1 semana haciendo cositas con mi tablet android xD