BennuGD packager

[josebita]

mmm... si hay varios, y solo mouse es 1 solo, cuando pulso varios a la vez, cual dedo seria mouse es indefinido... cierto?

expandiste mouse a un array? o sigue siendo una struct de 1 elemento? me refiero a que tengo mouse[0], mouse[1], etc... para cada dedo? o es mouse para 1 (sea cual sea) y luego tengo los otros accesibles a traves del api de multitouch?

o tenes mouse y luego expandiste coords x e y?

creo igual que toda expansion haria incompatibles los dcbs actuales...

como lo implementaste?

otra opcion seria una nueva estructura tipo touch[N], donde se puedan especificar los dispositivos touchs... con los siguientes miembros (al menos)

cant;
x[N];
y[N];

donde N es la cantidad maxima de coordenadas, para hacerlo generico podria ponerse 10.

pero no se, pregunto como lo implementaste, que seguramente ya me comentaste alguna vez, pero no soy bueno recordando.

Si hay más de uno se coge el primero y, si este se suelta, se debería coger el segundo que se detectó. En ppio. SDL se encarga de mantener el orden de los dedos.


Sobre la forma de implementación, he dejado los módulos oficiales como están por lo que comentas: compatibilidad de DCBs. La mod_multi implementa las siguientes funciones:

Code Select Expand

multi_numpointers() <-- Devuelve el número de punteros* que hay disponibles.
multi_info(int pointer, string info) <-- Devuelve la información que se le pida del puntero que se le de.
Lo he hecho de esta forma y no con estructuras porque en teoría la mod_multi iba a servir también para el port a la Wii con sólo pedirle cosas distintas, es decir:
multi_info(0, "pressure") te daría la presión del primer dedo tocando la pantalla en Android o iOS y
multi_info(0, "WBL") te daría el peso detectado por el sensor inferior izquierdo de la balance board en Wii.
Y una llamada con códigos "erróneos" para la plataforma sería simplemente ignorada. Con una estructura se me antojó difícil hacer eso, además de que serían un montón entradas (x, y, z, presión, aceleración en los 3 ejes, batería restante, peso, nombre...)

Y el máximo de punteros que admite la mod_multi está definido a 10, aunque aún no me he encontrado con ninguna pantalla que admita más de 5 dedos simultáneos, hay bastantes que no pasan de 4 y mi móvil actual sólo es capaz de leer 1 :) Es el tamaño de una estructura, así que con cambiar un define al compilar puedo aumentar el número, si hiciera falta.

* cosa de verdad que apunta, no cosa de C que apunta a otra cosa de C.

[emov2k4]

consulta,  me estoy complicando... como hago para saber si estoy presionando un botón con el mod_multi ?
antes lo hacia así:
if (collision(type mouse) and mouse.left)   accion();  end

HELP !

[josebita]

consulta,  me estoy complicando... como hago para saber si estoy presionando un botón con el mod_multi ?
antes lo hacia así:
if (collision(type mouse) and mouse.left)   accion();  end

HELP !

si sólo vas a considerar un dedo deberías poder seguir usando eso (tras importar la mod_multi). si quieres que el usuario pueda pulsar varios botones a la vez, podrías crear un proceso que se posicione con multi_info y hacer colisión o, incluso más sencillo: comparar las x e y de los botones con las que te de mod_multi.

[SplinterGU]

mmm... si hay varios, y solo mouse es 1 solo, cuando pulso varios a la vez, cual dedo seria mouse es indefinido... cierto?

expandiste mouse a un array? o sigue siendo una struct de 1 elemento? me refiero a que tengo mouse[0], mouse[1], etc... para cada dedo? o es mouse para 1 (sea cual sea) y luego tengo los otros accesibles a traves del api de multitouch?

o tenes mouse y luego expandiste coords x e y?

creo igual que toda expansion haria incompatibles los dcbs actuales...

como lo implementaste?

otra opcion seria una nueva estructura tipo touch[N], donde se puedan especificar los dispositivos touchs... con los siguientes miembros (al menos)

cant;
x[N];
y[N];

donde N es la cantidad maxima de coordenadas, para hacerlo generico podria ponerse 10.

pero no se, pregunto como lo implementaste, que seguramente ya me comentaste alguna vez, pero no soy bueno recordando.

Si hay más de uno se coge el primero y, si este se suelta, se debería coger el segundo que se detectó. En ppio. SDL se encarga de mantener el orden de los dedos.


Sobre la forma de implementación, he dejado los módulos oficiales como están por lo que comentas: compatibilidad de DCBs. La mod_multi implementa las siguientes funciones:

Code Select Expand

multi_numpointers() <-- Devuelve el número de punteros* que hay disponibles.
multi_info(int pointer, string info) <-- Devuelve la información que se le pida del puntero que se le de.
Lo he hecho de esta forma y no con estructuras porque en teoría la mod_multi iba a servir también para el port a la Wii con sólo pedirle cosas distintas, es decir:
multi_info(0, "pressure") te daría la presión del primer dedo tocando la pantalla en Android o iOS y
multi_info(0, "WBL") te daría el peso detectado por el sensor inferior izquierdo de la balance board en Wii.
Y una llamada con códigos "erróneos" para la plataforma sería simplemente ignorada. Con una estructura se me antojó difícil hacer eso, además de que serían un montón entradas (x, y, z, presión, aceleración en los 3 ejes, batería restante, peso, nombre...)

Y el máximo de punteros que admite la mod_multi está definido a 10, aunque aún no me he encontrado con ninguna pantalla que admita más de 5 dedos simultáneos, hay bastantes que no pasan de 4 y mi móvil actual sólo es capaz de leer 1 :) Es el tamaño de una estructura, así que con cambiar un define al compilar puedo aumentar el número, si hiciera falta.

* cosa de verdad que apunta, no cosa de C que apunta a otra cosa de C.

por eso dije una struct touch

• , para wii podria ser sensor
• o pad
• o lo que sea... hay que pensarlo bastante.

[emov2k4]

upss... creo que tenemos un enredo... esta parte del foro es para BennuGd Packager y estamos haciendo preguntas del Port android !! Sorry !!

[SplinterGU]

cierto, disculpa

[josebita]

Acabo de publicar "oficialmente" el empaquetador. Es, basicamente, lo mismo que puse el otro día pero incluye una versión binaria de ANT para windows y un pequeño script que configura el entorno en caso de que no lo tengais instalado ya:
http://bennugd-mobile.blogspot.com/2012/08/man-on-moon-packager-release.html

[KeoH]

linux linux linux xDD

[josebita]

linux linux linux xDD

a ver si mañana...

[KeoH]

Me he bajado la version de windows para ver si puedo arrancarlo en plan cutre en linux xDD pero me dado cuenta q tienes el codigo compilado xDD yo que queria echarle un vistazo a los py. xDDDD . Y otra cosa .. ¿Como has generado el exe? se que habia una libreria por ahí que permitia hacer eso .. pero era una muy vieja la que ví. Este exe hace que el pc donde se ejecute el programa no requiera tener python instalado?

EDITO: Py2exe ... esa es la libreria no? xD

[JaViS]

Josebita,


ahora que el port de android tiene arreglado el soporte de scale_resolution me gustaría probar de vuelta el empaquetador que publicaste con nuestro juego. que necesito actualizar?

[josebita]

Me he bajado la version de windows para ver si puedo arrancarlo en plan cutre en linux xDD pero me dado cuenta q tienes el codigo compilado xDD yo que queria echarle un vistazo a los py. xDDDD . Y otra cosa .. ¿Como has generado el exe? se que habia una libreria por ahí que permitia hacer eso .. pero era una muy vieja la que ví. Este exe hace que el pc donde se ejecute el programa no requiera tener python instalado?

EDITO: Py2exe ... esa es la libreria no? xD

Puedes usar la versión para Mac, esa tiene el código Python directamente.
La versión para windows está compilada con cx_freeze.

Josebita,


ahora que el port de android tiene arreglado el soporte de scale_resolution me gustaría probar de vuelta el empaquetador que publicaste con nuestro juego. que necesito actualizar?

Aún no he subido los binarios con eso arreglado...

[SplinterGU]

vuelta la burra (yo) al trigo...

parece que entendi mal, y entendi a josebita que no habia tocado nada del scale_resolution y set_mode, sino que era como se usaba desde el prg... pero segun dice o entiendo que dice, JaViS si hay cambios que hacen que ahora funcione...

me podrian dar luz en esto y explicarle que se cambio en caso de ser asi... quizas me sirve para la version oficial.

[josebita]

vuelta la burra (yo) al trigo...

parece que entendi mal, y entendi a josebita que no habia tocado nada del scale_resolution y set_mode, sino que era como se usaba desde el prg... pero segun dice o entiendo que dice, JaViS si hay cambios que hacen que ahora funcione...

me podrian dar luz en esto y explicarle que se cambio en caso de ser asi... quizas me sirve para la version oficial.

La historia fue así:
necesitaba una forma (fácil) de poner el móvil por defecto a su resolución nativa. Dado que SDL_SetVideoMode(0, 0, masargumentos) pone el modo de vídeo por defecto en Android, hice que set_mode(0, 0, masargumentos) lo hiciera también.
Sin embargo la rutina gr_set_mode() del código oficial no funciona bien si se hace gr_set_mode(0, 0, loquesea) porque asume que el tamaño de la SDL_Surface resultante es 0x0 (cuando en realidad es, pongamos, 480x800) y ponía las variables "C" scr_width y scr_height a 0x0. Por eso modifiqué la rutina gr_set_mode para que al final hiciera:
scr_width = screen->w;
scr_height = screen->h;
Con eso ya funcionaba set_mode(0,0) y gr_set_mode(0, 0)

Y lo mismo para las rutinas de escalado con scale_resolution (PERO en las rutinas de escalado lo hice mal y cambié los tamaños que se pasan a SDL_CreateRGBSurface) y eso hacía que el escalado no funcionara bien. No es que el programa diera segmentation fault ni nada; simplemente el escalado no se hacía y se pintaba a un tamaño incorrecto dado que las tablas de escalado se calculaban incorrectamente.

Parte de estos cambios los hice cuando estuve tocando el código para iOS y, como en iOS la gente pone la resolución directamente sin escalado el bug no les afectaba.
Cuando la gente ha empezado a usar las rutinas de escalado en Android, el bug ha aparecido y he tenido que arreglarlo. La solución era sencilla y pasa por dejar la parte del escalado como estaba en la versión oficial.
El código resultante lo tienes aquí:
http://code.google.com/p/bennugd-monolithic/source/diff?spec=svn529&r=527&format=side&path=/trunk/modules/libvideo/g_video.c&old_path=/trunk/modules/libvideo/g_video.c&old=500

Quizás lo único interesante para el código oficial sea poner casi al final de la rutina gr_set_mode() las líneas esas:
scr_width = screen->w;
scr_height = screen->h;

De forma que el si SDL crea la SDL_Surface con un tamaño que no es el que el usuario ha pedido, el usuario pueda saberlo desde código Bennu.

[JaViS]

eso mismo.. XD