CHIPMUNK en bennu

[Erkosone]

El ejemplo mas claro y simple.. tienes un coche teledirigido a gasolina XD..


Te lo bajas a la plaza de tu barrio para hacerlo correr.. que bien.. el coche acelera.. pero oye.. que lejos está ese arbol.. voy a tratar de dar vueltas a el XD..


Ahora te subes el coche y te encierras con el en el WC XD.. "si no mueres asfixiado por los humos antes.." te darás cuenta de que con la misma aceleración el coche parece que tiene mil veces mas velocdiad..


Por que?


Por que lo que cambia no es el coche, ni la potencia del mismo, ni tan siquiera la aceleración del cochecillo.. lo que cambia es el espacio o mejor dicho "la sensación espacial del espectador".


Conclusión?
En la calle parece que el coche es una chufa y que no corre..
En casa parece que es un Parche carrera de 900 CV ;)

[SplinterGU]

no necesariamente... la relacion de la distancias/pixels tiene que ser otra variable... y el motor hacer los calculos y saber que gravedad 9,78 con la relacion que pixels por metro, es 500... no que si yo quiero tener una gravedad de 9,78, tener que hacer calculos para saber cuanto es...

resumen, el motor debe conocer cuantos pixels es 1 metro (o 1 cm o la distancia que sea)... y en base a eso, y sabiendo la gravedad que el usuario define para el entorno, el motor debe calcular los valores que necesite de gravedad interna...

se supone que el motor te abstrae de la complejidad de la fisica, si para usarlo, tengo que hacer calculos complejos para saber que gravedad es para simular la tierra en base a cuantos pixeles representa 1 metro... entonces no es muy practico el motor...

y que tal si yo defino todo, y luego hago un zoom de todo el ambiente? (imagino un angry bird cuando agranda el plano de vision) tengo que recalcular todo de nuevo? que tal si simplemente indico el zoom que estoy usando y el motor hace el resto de los ajustes?

vamos que esto tiene que ser simple...

seguramente no se entiendo lo que digo...

pero para mi esto deberia ser... defino gravedad (con los mismos valores de la realidad), defino relacion base 1pixel/X metros (o al reves, da igual) y luego manejo el resto con zoom (ambient_size?), etc...

[Erkosone]

nono, mira.. lo sigues mirando desde el punto de vista global "siempre con al misma resolución" pero con zoom diferentes..


El problema no es el zoom, si acercas la imágen se verá todo mas rápido vale, y si la alejas se verá mas lento vale.. esto es así en la realidad y en todos los motores de física, PERO..


Si cambias la "resolución" que muestra la escena la cosa se deforma por que todas las distancias cambian..


La cosa peliaguda es la resolución, no el zoom.




Te hago un simil con la función ADVANCE() del motor de bennuGD para 2D..
- Tengo una resolución de 320x200, en mi juego el personaje avanza con:  ADVANCE(2);


Vale.. todo es coherente y el juego va como debe..


Ahora cambio la 'resolución' de la pantalla a 1600x1050 y amplio todos los gráficos..
"sigo usando el ADVANCE(2)" pero que sucede.. que ahora el personaje se mueve como el pedo de lento.. usando la misma velocidad.


El problema no es ni los zoom ni nada de esto, es la resolución en la que muestras el juego, todo viene por esto que parece tan simple pero que en realidad no lo es para nada.

[SplinterGU]

zoom o resolucion da igual... para lo que digo...

si haces zoom, no tiene por que cambiar la velocidad, no estoy diciendo haciendo camara rapida o lenta... esto debe adaptarse solo...

realmente no se como explicarlo, esto tiene que ser simple, y evitar al usuario hacer miles de calculos cuando quien debe hacer los calculos es el motor... yo tengo que ver esto de forma global, no tienes que tener parte de los calculos a cargo del motor y parte a cargo tuyo, cuando el motor lo puede manejar perfectamente... yo no digo que el motor no sirva, sino que ya que estan trabajando con capas de abstraccion mas profundas, piensen en esto e incluyan funcionalidades para abstraer mas las cosas y que se vea y maneje de forma normal y conocida...

la idea no es que para simular la gravedad normal (por ejemplo, de la tierra) tenga que estar probando a ojo o incluso teniendo que aprender formulas que seguramente con el tiempo olvidaremos, si tranquilamente todo esto se puede manejar simplemente desde el motor.

[Prg]

He entendido la ventaja de esta variable y no se me había ocurrido...

Agregaré la variable de resolución, si alguien quiere trabajar como antes la variable tendrá el valor de 1 (por defecto) y nada se reescalará, si necesita otro valor, lo asignan y listo.  ;D

:'( Me pondrán a trabajar buscando las funciones que trabajan con fuerzas para reescalar sus parámetros
:'( :'( También las que trabajan con distancias y generar una que reciba en metros (Unidad estandar) y otra en pixeles
;D ;D ;D Lo que sí dejaré son la información de los árbitros, si la modifico daño el motor, pues él trabaja con ella, pero haré una función que dado el valor que le pases lo transforme a las unidades adecuadas y lo retorne.

Lo del zoom ya le toca al dibujado de Bennu, como se mantienen los tamaños de objetos (el objeto mide los mismo pixeles, solo que se amplió el dibujado, algo al estilo scale_resolution) y sólo se modifica el pintado no hay problema (así como lo estoy viendo yo).

La nueva variable se agrega para futuras versiones, así como la función que mencioné, y se agrega la lista de cosas por hacer.

Saludos amigos.

[Erkosone]

Miedo me da esto jeje.. pero mucho animo con ello.


Yo mas que cambiar el core de la librería lo que si que haría es enfocar los esfuerzos por fusionarla con el core de bennuGD, la primera cosa que haría sería integrar el sistema de colisiones de la chipmunk "hyper velóz" con bennu y sus process y eliminar el sistema actual por colisión entre mapas que es infinitamente mas lento.


Integraría "si yo pudiese claro.." los TYPE de los procesos con los collision_type de la chipmunk para dejar de forma automática a bennuGD el manejo de los handles de colisión y poder usar la nomenclatura actual tipo:


if( collision ( TYPE raton) )  pero manejado por la lib de física en vez de por el sistema actual.




Eso sería grandioso para el lenguaje, ganaría en rendimiento algo inimaginable, ojo! que no digo que lo que hace ahora bennu esté mal, está genial, pero la chipmunk es tremendamente mas eficiente y permitiría rendimientos en los juegos mucho mas elevados ;)


Lo comento por que ya la tienes integrada a medias, y si antes de trastearla de esta manera te propones integrarla de forma radical al core de bennu puede resultar algo barbaro, imagínate un bennu con todas las variables locales como ahora las comocemos "en formato INT" pasadas a FLOAT ya de forma nativa aprobechando que la chipmunk maneja estas variables también pero en coma flotante con muchisima mas precisión.


Ahun así, mucho animo con el trabajo que te propones hacer, es realmente interesante.

[SplinterGU]

pero las colisiones de chipmunk no son pixel perfect... en bennugd tambien tienes colisiones no pixel perfect... aunque por el tema de size y rotaciones se complica un poco la logica, pero tener mas rapidas tiene.

[Erkosone]

Tienes razón, las pixel perfect aveces son casi imprescindibles, pero las vectoriales ahorran mucho calculo y son bastante aproximadas, creo que este es un tema interesante para debatir por que muchos motores están adoptando esta técnica para las colisiones y no ya no se si es por que aprobechan el trabajo de las lib de física que ya está hecho o por que realmente son mejores en todo.. me gustaría escuchar opiniones sobre el tema, haber que opinan los demás por que es un tema interesante.

[SplinterGU]

como te dije en el otro hilo, tienes collision_box y collision_circle (por ahora basicas, luego la idea es hacerlas crecer y con este crecimiento tambien simplicar su logica)

:)

[Erkosone]

mm... en eso no había pensado.. collision circle aplicando un ajuste al radio es muy interesante ciertamente.
Gracias por la información Splinter  ;)




Por cierto, alguien necesita un tutorial sobre como se crean correctamente explosiones con la mod_chipmunk?
Lo digo por que es algo que hace falta en algunos juegos y veo que mucha gente lo pregunta por los foros de chipmunk y cada cual lo hace como cree que es.. pero no veo ningún tutorial sobre una forma coherente de hacerlo.. yo me he puesto con este tema ayer y hoy y me ha costado unas cuantas horas.. pero al final lo he logrado y funciona a la perfección..
Aunque parece algo obvio.. supongo que mas de uno agradecerá un vídeo tutorial sobre el tema, creo que voy a montarlo.. así no se me olvida a mi también jeje..

[SplinterGU]

creo que actualmente las funciones collision_box y collision_circle trabajan calculando el radio en base al tamaño del grafico (no del contenido), pero bueno, no pretende ser una colision perfecta, asi que cumple con la funcion... mi idea a futuro era agregar cosas como el radio y otras cosas mas.

pero no recuerdo, quizas ya soporta radio.

[josebita]

PSST: https://www.dropbox.com/s/d5lil63z59u0d88/chipmunk_test-debug.apk


[Edito] Adjunto los fuentes del ejemplo. Es el test20.prg que viene con mod_chipmunk pero un poquito maqueado para que funcione en el móvil (resoluciones y eso)

[Erkosone]

Prg tengo una pregunta sobre la chipmunk, al usar 'cleanspace()' hay que hacer algo antes? lo comento por que al hacerlo me peta el programa diciendo por consola que hay un error en los simpleMotor, no se si tengo que hacer algo antes de parar la escena?

[Erkosone]

Me autorespondo por lerd y no haber leído antes de preguntar..


Hay que usar let_me_alone() antes de limpiar..

[fulgorelizz]

lphysic.mass se comporta de forma global!! ... al cambiar el lphysic de algun proceso, los procesos externos a este actualizan tambien su lphysic.mass!!