CHIPMUNK en bennu

[Prg]

puf! he quedado con la boca abierta eso del agua es genial...

pregunta, porque el 3er video el que parece un angrybird, los objetos se mueven como en camara lenta, como si estuvieran en un lugar con poca gravedad? a pesar de que la bola cuando la arrastras se mueva a velocidad rapida? puedes poner un test con una gravedad mas realista (si es que es la gravedad, claro)?

Splinter, subí la gravedad a 500, la anterior era 50. También le puse más peso a la pelota y modifiqué un poco las fuerzas de los objetos.

Te paso el video

http://www.youtube.com/watch?v=GYBUKxIh4TE

Prg, ¿contra qué versión estás compilando ésta última mod_chipmunk?

Quiero actualizar la mod_chipmunk que viene con Android y necesitaré compilar la Chipmunk tb. Veo que la última disponible es la 6.1.3

Chipmunk-6.1.2 . No sabía que había 6.1.3 ...  Deja reviso esto y si es necesario compilamos con esta otra. ¿Chipmunk está en android? He probado tu packager para android, me ha gustado mucho, pero el ratón no me ha funcionado... luego te comentaré en el hilo correspondiente, pero he esperado porque se que aún trabajas en ello, no quiero preguntar por algo que aún no está implementado... La mod multi no la encontré en windows... Bueno, Dejar reviso esto.


Saludos :)

pd: ya revisé... en la página viene hasta la  6.1.2 ... Este es el link http://chipmunk-physics.net/downloads.php

[josebita]

Prg, ¿contra qué versión estás compilando ésta última mod_chipmunk?

Quiero actualizar la mod_chipmunk que viene con Android y necesitaré compilar la Chipmunk tb. Veo que la última disponible es la 6.1.3

Chipmunk-6.1.2 . No sabía que había 6.1.3 ...  Deja reviso esto y si es necesario compilamos con esta otra. ¿Chipmunk está en android? He probado tu packager para android, me ha gustado mucho, pero el ratón no me ha funcionado... luego te comentaré en el hilo correspondiente, pero he esperado porque se que aún trabajas en ello, no quiero preguntar por algo que aún no está implementado... La mod multi no la encontré en windows... Bueno, Dejar reviso esto.


Saludos :)

pd: ya revisé... en la página viene hasta la  6.1.2 ... Este es el link http://chipmunk-physics.net/downloads.php

Si la bajas pone en el fichero descargado pone 6.1.3, pero en la descarga pone 6.1.2, ¡qué lío!

Y sí, las versiones de Bennu para Android que ya hay liberadas (las que vienen con versiones anteriores del packager) vienen con una versión anterior de la mod_chipmunk integrada por defecto.
Las librerías no oficiales que vienen con mi BennuGD para Android son: mod_chipmunk, mod_multi y mod_curl, lo demás es estándar.
Quisiera actualizar la mod_chipmunk del PPA y la que viene con Android a la última, porque la verdad es que merece la pena.

Sobre la mod_multi en Windows, imagino que tampoco has buscado mucho :)
http://code.google.com/p/bennugd-monolithic/downloads/detail?name=bennugd-module-multi-fake_win32.7z&can=2&q=

Y ahora mismo estoy haciendo algunos cambios a SDL/BennuGD pero las cosas que traerá la nueva versión son:
* Soporte nativo para joysticks por bluetooth y USB (OUYA y similares). Pixel tiene por ahí una copia del ripollés con soporte para joysticks.
* Soporte nativo para ratones. La idea es que el usuario pueda -si quiere- distinguir el ratón del touch.
* Arreglos para el problema de las GPU Adreno (¿?)
* Quizás un nuevo módulo para acceso a sensores. De esa forma podréis acceder a los datos de todos los sensores del teléfono: acelerómetros, giroscopios, magnetómetro (brújula), GPS... El API probablemente será similar al de los joysticks. Tengo que escribir un nuevo API para sensores para SDL, así que puede que salga y puede que no, pero creo que sería muy interesante.

[Prg]

Tienes razón... ya revisé y sí hay nueva versión. Los cambios son pocos:

CHANGES SINCE 6.1.2:
* BUG: Fixed a couple of very specific but fatal bugs that occur when sleeping is enabled and filtering collisions.
* BUG: Fixed an issue with cpvslerp() between very similar vectors.
* BUG: Fixed an issue with grab friction in ChipmunkMultiGrab. (Pro only)
* MISC: Implemented the cpConstraintGetImpulse() functionality for spring joints.
* MISC: Added more functions to chipmunk_ffi.h

Qué te parece si compilo con esta versión, doy una revisada que no haya problemas y subo esta versión.

Gracias por la mod_multi. je je je.. No la había visto... Tu packager está genial...

Ok...
Compilada...

http://www.mediafire.com/?5uadq5zljhurzqv

Agregué:

void cpBodyActivateStatic(cpBody *body, cpShape *filter) – Similar in function to cpBodyActivate(). Activates all bodies touching body. If filter is not NULL, then only bodies touching through filter will be awoken.

void cpBodySleepWithGroup(cpBody *body, cpBody *group)

When objects in Chipmunk sleep, they sleep as a group of all objects that are touching or jointed together. When an object is woken up, all of the objects in it's group are woken up. cpBodySleepWithGroup() allows you group sleeping objects together. It acts identically to cpBodySleep() if you pass NULL as group by starting a new group. If you pass a sleeping body for group, body will be awoken when group is awoken. You can use this to initialize levels and start stacks of objects in a pre-sleeping state

quedaron así:

    {"ACTIVATESTATIC" , "II",   TYPE_INT, modActivateStatic},  parámetros:
id -> proceso que se activará
shape-> lphysics.shape que se usará como filtro, 0 si cualquier shape del proceso...
    {"SLEEPWITHGROUP" , "II",   TYPE_INT, modSleepWithGroup },
recibe dos id de procesos...

Nota:
Para quienes descargaron La versión anterior de mod_chipmunk, pueden seguir con ella. Esta tiene cambios mínimos y sólo se adjunta aquí para que la versión de linux (de Josebita) y la de windows estén a la par...

Saludos

[josebita]

Tienes razón... ya revisé y sí hay nueva versión. Los cambios son pocos:

CHANGES SINCE 6.1.2:
* BUG: Fixed a couple of very specific but fatal bugs that occur when sleeping is enabled and filtering collisions.
* BUG: Fixed an issue with cpvslerp() between very similar vectors.
* BUG: Fixed an issue with grab friction in ChipmunkMultiGrab. (Pro only)
* MISC: Implemented the cpConstraintGetImpulse() functionality for spring joints.
* MISC: Added more functions to chipmunk_ffi.h

Qué te parece si compilo con esta versión, doy una revisada que no haya problemas y subo esta versión.

Gracias por la mod_multi. je je je.. No la había visto... Tu packager está genial...

Ok...
Compilada...

http://www.mediafire.com/?5uadq5zljhurzqv

Agregué:

void cpBodyActivateStatic(cpBody *body, cpShape *filter) – Similar in function to cpBodyActivate(). Activates all bodies touching body. If filter is not NULL, then only bodies touching through filter will be awoken.

void cpBodySleepWithGroup(cpBody *body, cpBody *group)

When objects in Chipmunk sleep, they sleep as a group of all objects that are touching or jointed together. When an object is woken up, all of the objects in it's group are woken up. cpBodySleepWithGroup() allows you group sleeping objects together. It acts identically to cpBodySleep() if you pass NULL as group by starting a new group. If you pass a sleeping body for group, body will be awoken when group is awoken. You can use this to initialize levels and start stacks of objects in a pre-sleeping state

quedaron así:

    {"ACTIVATESTATIC" , "II",   TYPE_INT, modActivateStatic},  parámetros:
id -> proceso que se activará
shape-> lphysics.shape que se usará como filtro, 0 si cualquier shape del proceso...
    {"SLEEPWITHGROUP" , "II",   TYPE_INT, modSleepWithGroup },
recibe dos id de procesos...

Nota:
Para quienes descargaron La versión anterior de mod_chipmunk, pueden seguir con ella. Esta tiene cambios mínimos y sólo se adjunta aquí para que la versión de linux (de Josebita) y la de windows estén a la par...

Saludos

Dame un día o dos para que la suba al PPA. ¿Hay que cambiar alguna cabecera como había que hacer antes? Es que para el PPA no puedo compilar con el codeblocks y compilo con un script de bash.

En fin, muchas gracias y ánimo con la librería.

[Prg]

En lugar de cambiar la cabecera compila con un define así:
CP_USE_DOUBLES=0

creo que se debe hacer

-DCP_USE_DOUBLES=0 o algo así...

Tanto la libchipmunk como la mod_chipmunk deben llevar este define así. Esto era lo que hacía la cabecera... je je je

[josebita]

En lugar de cambiar la cabecera compila con un define así:
CP_USE_DOUBLES=0

creo que se debe hacer

-DCP_USE_DOUBLES=0 o algo así...

Tanto la libchipmunk como la mod_chipmunk deben llevar este define así. Esto era lo que hacía la cabecera... je je je

Ah, ok.
Se hace así, sí.

En cuanto lo suba al PPA aviso.

[Prg]

El curro que has metido en la parte de vectorizar un grafico es flipante, realmente bueno, gracias por compartirlo con la comunidad y gracias por compartir el source, es algo muy interesante.

Erksone, ayer pensaba que quizá puedas usar el algoritmo del test 18 para tu editor de terrenos. mod_chipmunk genera una lista con los vértices y los almacena en un arreglo, luego desde código bennu se generan los terrenos. Tú puedes aprovechar eso para tu editor.

La ventaja de tu editor sería almacenar en un archivo fuente los puntos, permitir edición y ajustes extras y además podrías agregar objetos que se cargaran como procesos en el juego, asignarles propiedades físicas: fricción, elasticidad, masa, estado (dormidos, despiertos), coordenadas, gráfico, ángulo, etc.

Con ese editor sí que sería muy sencillo hacer un juego... je je

No he visto bien tu proyecto, sólo he leído algunos de los mensajes que lo describen, pero creo que algo de esto te podría servir.
Saludos

[josebita]

Me columpié: BennuGD para Android -aún- no incluye la mod_chipmunk por defecto.

Pero la próxima versión binaria que saque la incluirá.

[Erkosone]

El curro que has metido en la parte de vectorizar un grafico es flipante, realmente bueno, gracias por compartirlo con la comunidad y gracias por compartir el source, es algo muy interesante.

Erksone, ayer pensaba que quizá puedas usar el algoritmo del test 18 para tu editor de terrenos. mod_chipmunk genera una lista con los vértices y los almacena en un arreglo, luego desde código bennu se generan los terrenos. Tú puedes aprovechar eso para tu editor.

La ventaja de tu editor sería almacenar en un archivo fuente los puntos, permitir edición y ajustes extras y además podrías agregar objetos que se cargaran como procesos en el juego, asignarles propiedades físicas: fricción, elasticidad, masa, estado (dormidos, despiertos), coordenadas, gráfico, ángulo, etc.

Con ese editor sí que sería muy sencillo hacer un juego... je je

No he visto bien tu proyecto, sólo he leído algunos de los mensajes que lo describen, pero creo que algo de esto te podría servir.
Saludos

Hola Prg, he mirado el ejemplo que usa el generador de terrenos, el algoritmo es tuyo? podrías explicarlo?
Yo tengo uno para vectorizar sprites que estoy integrando en el api que he montado, pero sería interesante escuchar como funciona el tuyo, no en código si no en pseudo código o con una explicación de los pasos que siges para lograrlo, en cuanto tenga implementado el mio en el api si quieres podemos compartir conocimientos para ver la forma mas optima de hacerlo, aunque viendo el resultado en velocidad del tuyo está claro que es bastante bueno.


Lo que estoy montando yo es algo un poco distinto pero similar en esencia, consta de 2 funciones, la primera y mas importante es esta:
Physics_sprite_calculate_shape( int file, int graph );
Esta función crea la lista de vectores para un gráfico pasado como parámetro y la almacena en la propia lista de C_Point del gráfico para usarse posteriormente.


La segunda la montaré mas adelante cuando tenga esta completamente funcional, es la que crea el shape para el proceso y esto tengo que investigarlo mas a fondo ;)

[josebita]

Ya deberíais tener la última mod_chipmunk disponible en mi PPA. Avisad si encontrais algún problema.

[master]

Estaría bien hacer el port de la versión actual a caanoo y wiz, yo tengo caanoo, pero no se como se hace.

me imagino que se debe tener el SDK y el entorno de desarrollo, pero no se como se hace, ni como se debe compilar

[Prg]

Ya deberíais tener la última mod_chipmunk disponible en mi PPA. Avisad si encontrais algún problema.

Gracias :)

Erksone, claro que te comentaré el algoritmo. De hecho ya lo hice a grandes rasgos en tu hilo.

De forma específica es así:

-Calculo los bordes, uso un sistema similar a la morfología matemática, pero lo acelero un poco más:

for(i=1;i<anc;i++){
            for (j=1;j<alt;j++){
                gr_put_pixel( map, i,  j ,I(mapa1, i,j) && !( I( mapa1, i,j-1 ) &&
                                                              I( mapa1, i-1,j ) && I( mapa1, i+1,j ) &&
                                                              I( mapa1, i,j+1 )
                                                            )
                             );
            }
        }



-Limpio los bordes para dejarlos 8-conexos, eliminando en lo posible los vecinos en las verticales y horizontales innecesarios (uso unas máscaras y a chi para ello)

for(i=1;i<anc;i++){
            for (j=1;j<alt;j++){
                if (gr_get_pixel( map, i,j )==1){
                    chi= (gr_get_pixel( map,i+1,j)!=gr_get_pixel( map,i,j-1))+ (gr_get_pixel( map,i,j-1)!=gr_get_pixel( map,i-1,j))+ (gr_get_pixel( map,i-1,j)!=gr_get_pixel( map,i,j+1))+ (gr_get_pixel( map,i,j+1)!=gr_get_pixel( map,i+1,j))+
                         2*(
                            ((!gr_get_pixel( map,i+1,j))&gr_get_pixel( map,i+1,j-1)&(!gr_get_pixel( map,i,j-1)))+((!gr_get_pixel( map,i,j-1))&gr_get_pixel( map,i-1,j-1)&(!gr_get_pixel( map,i-1,j)))+((!gr_get_pixel( map,i-1,j))&gr_get_pixel( map,i-1,j+1)&(!gr_get_pixel( map,i,j+1)))+((!gr_get_pixel( map,i,j+1))&gr_get_pixel( map,i+1,j+1)&(!gr_get_pixel( map,i+1,j)))
                            );
                    if (chi==2 &&
                        (   (gr_get_pixel( map,i-1,j)==1 && gr_get_pixel( map,i,j+1)==1) ||
                            (gr_get_pixel( map,i-1,j)==1 && gr_get_pixel( map,i,j-1)==1) ||
                            (gr_get_pixel( map,i+1,j)==1 && gr_get_pixel( map,i,j+1)==1) ||
                            (gr_get_pixel( map,i+1,j)==1 && gr_get_pixel( map,i,j-1)==1)
                         )
                        )
                    gr_put_pixel( map, i,  j ,0);
                }

            }
        }


-Luego recorro cada borde encontrado, almacenando sus coordenadas en arreglos dinámicos. 

Tengo una función de calculo de centroide,  una de cálculo de distancia euclidiana y una de cálculo de distancia de un punto a una recta.

Reviso si el primero punto de la lista y el último están cerca (menos a 5 pixeles de distancia manhattan).

INLINE int iguales(cpVect *a, cpVect *b,float c){
    return (fabs(a->x - b->x)+fabs(a->y - b->y))<c;
}

Si la distancia es menor a 5, considero que los bordes son figura cerrada, si no es así es una linea.

-------Figura Cerrada
Calcular centroide
Seleccionar el punto con mayor distancia al centroide como primer punto de la aproximación.
Selecicionar el punto más alejado al anterior como el segundo.
Considerar una recta cuyos puntos extremos sean estos dos.
Seleccionar el punto con mayor distancia a la izquierda de la recta hacia esta. Si es mayor a un umbral agregar a la aproximación poligonal.
Seleccionar el punto con mayor distancia a la derecha de la recta. Proceder igual.
Si se agregan nuevos puntos, generar nuevas rectas entre ellos (tendríamos ya un cuadrilátero que une los cuatro puntos). Calcular distancias nuevamente pero ahora sólo por los puntos adyacentes externos (viene explicado en el pdf que te pasé). El algoritmo termina cuando ya no hay recta que tenga puntos adyacentes que superen el umbral.


-------Figura abierta
Se consideran los primeros dos puntos los extremos de la lista.
Se genera una recta entre estos dos puntos y se procede como en el caso anterior.


Para finalizar...
Los puntos se agregan a una nueva lista y se exportan...

Esto es el algoritmo...

Saludos

[Erkosone]

Hijo como mola, veo que tienes bastante claro el tema trigonométrico, da gusto tener gente así por aquí.
Muchas gracias por la explicación, siempre da ideas escuchar los métodos de los demás ;)

[SplinterGU]

para recorrer el mapa si lo vas a hacer en sentido vertical y horizontal, barriendo filas 1 a 1 (o columnas) no usar gr_get_pixel, sino acceder directamente al buffer de video.... ir procesando 1 fila a la  vez, en lugar de 1 columna y recorrer todas las filas, esto sera mas rapido.

[Prg]

para recorrer el mapa si lo vas a hacer en sentido vertical y horizontal, barriendo filas 1 a 1 (o columnas) no usar gr_get_pixel, sino acceder directamente al buffer de video.... ir procesando 1 fila a la  vez, en lugar de 1 columna y recorrer todas las filas, esto sera mas rapido.

Sip, tienes razón. gr_get_pixel tiene multiplicaciones, la suma del desplace y las revisiones de los límites. Acceder al buffer directamente me permitirá usar sólo suma para moverme, sin ningúna revisión, aunque el tema de la profundidad me tocará trabajarlo a mí, pero seguro se optimizará muchísimo más con alguna variable de avance inicializada al principio en el caso de 8, 16 y 32 bits; el caso de gráficos de 1bit requerirá un código extra...
Haré el cambio la próxima vez que entregue versión. Viendo que todo funciona hay que optimizarlo :)

Muchas Gracias por la sugerencia :)