¿Qué os parecería una nueva variable local, predefinida para todos los procesos, llamada collision_graph?
La idea sería la siguiente: Si esta variable está establecida se utilizaría para comprobar las colisiones con ese gráfico y no con el que se está mostrando.
Lógicamente, el gráfico asignado en collision_graph no sería visible, sólo utilizado para comprobar colisiones.
¿Qué os parece la idea?
Eso significa 2 graficos por proceso, me temo que lo que hace lento el uso de procesos es que cada uno tenga un gráfico assignado, ahora imaginate 2... Eso es lo mismo que usar mapa de durezas
Quote from: FreeYourMind on August 21, 2012, 07:59:02 AM
Eso significa 2 graficos por proceso, me temo que lo que hace lento el uso de procesos es que cada uno tenga un gráfico assignado, ahora imaginate 2... Eso es lo mismo que usar mapa de durezas
Hombre, no tanto dado que el segundo gráfico no se usaría nunca más que en el momento de checkear la colisión. Lo que sí que haría sería usar más memoria.
Pixel, ¿no te vale con las rutinas de colision collision_box y collision_circle que creó Splinter?. La idea viene a ser algo similar.
Os pongo un ejemplo, el Pang.
Quiero que la bola sea capaz de colisionar con el personaje un poco sin matarlo, dando cierto margen.
Para ello ahora mismo estoy utilizando una variable cacona que cuenta los frames colisionados, pero preferiría utilizar un método como el que comento. En otros casos, la forma en la que lo soluciono es con subprocesos que tienen el gráfico a utilizar en las colisiones, con alpha 0, o cambiando el gráfico antes de colisionar y revirtiéndolo después.
para eso puedes usar puntos de control
Quote from: FreeYourMind on August 21, 2012, 10:26:16 AM
para eso puedes usar puntos de control
No entiendo, ¿a qué te refieres? :?
le pones un punto de control en cada ojo del gráfico prota por ejemplo, y la colision la controlas en ellos, así la pelota colisionará un poco con el muñeco antes de matarlo. Los puntos de control se asignan en un gráfico en el editor de fpg, yo por casualidad nunca los he usado, pero pensaba que tu lo sabias de sobra.
Es lo que se suele usar en los juegos de lucha, para dar golpes y golpear sólo con una parte del brazo o pierna..
Hasta donde yo sé los puntos de control se utilizan para centrar los gráficos de diferentes tamaños y posiciones en una animación :\
pues que alguien nos acuda, porque yo pensaba que servia para eso y para mucho más xD
Yo creo que no es una mala idea, aunque la implementación de un grafico diferente para la colision generalmente implica un poco mas de complejidad. por ejemplo, ubicar ese grafico en un punto de control determinado o quizas hacer un collision_box de otro grafico diferente, etc. Por lo que sigue siendo mejor opcion tener un proceso separado.
Creo que una solucion mejor sería poder comprobar colisiones de otros procesos:
collision(type enemy[, collision_proccess]);
eso se puede hacer actualmente...
...
/* start collision test (don't use FRAME in this block or restore graph before FRAME) */
bgraph = graph;
graph = collision_graph;
... collision(...)
...
graph = bgraph;
/* end collision test */
frame;
Quote from: FreeYourMind on August 21, 2012, 10:43:02 AM
le pones un punto de control en cada ojo del gráfico prota por ejemplo, y la colision la controlas en ellos, así la pelota colisionará un poco con el muñeco antes de matarlo. Los puntos de control se asignan en un gráfico en el editor de fpg, yo por casualidad nunca los he usado, pero pensaba que tu lo sabias de sobra.
Es lo que se suele usar en los juegos de lucha, para dar golpes y golpear sólo con una parte del brazo o pierna..
"de que estas hablando willis?" explica mas porque no te entendi que quieres decir.
pero si responde, la colision es contra el grafico (collision normal), se pone el grafico con respecto al punto de control 0, o sea, el centro, y luego se collisiona grafico contra grafico.
no entiendo que dices de los puntos de control, pero explica, quizas tengas razon y solo es que no entendi que quieres decir.
Quote from: PiXeL on August 21, 2012, 10:24:13 AM
o cambiando el gráfico antes de colisionar y revirtiéndolo después.
eso tienes que usar.
sabes que rechazo agregar funciones o complicar las actuales para hacer cosas que ya se pueden hacer facilmente...
a uds que les encantan las clases, piensen en collision como un metodo de una clase, y los procesos como una clase o entidad.
la filosofia es relacion "objecto->mundo exterior".
Oye Splinter una pregunta, ya que ha salido el tema de los puntos de control .... supongamos que tengo un proceso cuyo grafico tiene definidos varios puntos de control. Creo que era con las funciones de get_real_point se podia acceder a las coordenadas en pantalla de un punto de control de ese grafico .. pero solo desde el proceso que tiene ese grafico, no desde otro proceso que quiera averiguar donde esta ese punto en pantalla no?
asi es, si quieres de otro grafico, debes cambiar la variable graph antes de llamar a la funcion.
no me refiero a obtener la posicion de esos puntos de otro grafico del proceso ... sino obtener esos puntos de un proceso desde otro proceso. En vez de que esa funcion de la posicion de los puntos de su proceso llamador, que lo haga de cualquier proceso cuya id se le de como parametro. ¿Como podría hacerse eso? Imagina que tengo un proceso que se dedica exclusivamente a poner estrellas en la posicion de la cabeza de los enemigos, primero tengo que saber donde esta exactamente la cabeza del bicho q tendra un punto de control en cada grafico del personaje. No se xDD imagina eso xDD
Quote from: KeoH on August 21, 2012, 10:01:50 PM
no me refiero a obtener la posicion de esos puntos de otro grafico del proceso ... sino obtener esos puntos de un proceso desde otro proceso. En vez de que esa funcion de la posicion de los puntos de su proceso llamador, que lo haga de cualquier proceso cuya id se le de como parametro. ¿Como podría hacerse eso? Imagina que tengo un proceso que se dedica exclusivamente a poner estrellas en la posicion de la cabeza de los enemigos, primero tengo que saber donde esta exactamente la cabeza del bicho q tendra un punto de control en cada grafico del personaje. No se xDD imagina eso xDD
primero no hay otros graficos de 1 proceso, hay graficos, que no pertenecen a ningun proceso, tu los asignas segun necesitas.
ahora, suponiendo que pid es el proceso que quiero obtener el punto de control, entonces
x=pid.x
y=pid.y
graph=pid.graph
flags=pid.flags
get_real_point....
Quote from: SplinterGU on August 21, 2012, 09:58:22 PM
asi es, si quieres de otro grafico, debes cambiar la variable graph antes de llamar a la funcion.
Esto no me vale para todos los casos, porque si compruebo la colisión desde otro proceso el cambio de gráfico no me sirve :\
¿Tan mala idea sería implementar algo así? ¿Cuántos de nosotros utilizamos subprocesos para máscaras colisionables y cuántos árboles habremos matado ya con tanta CPU malgastada? xD
Quote from: PiXeL on August 30, 2012, 10:00:52 AM
Quote from: SplinterGU on August 21, 2012, 09:58:22 PM
asi es, si quieres de otro grafico, debes cambiar la variable graph antes de llamar a la funcion.
Esto no me vale para todos los casos, porque si compruebo la colisión desde otro proceso el cambio de gráfico no me sirve :\
¿Tan mala idea sería implementar algo así? ¿Cuántos de nosotros utilizamos subprocesos para máscaras colisionables y cuántos árboles habremos matado ya con tanta CPU malgastada? xD
como que no se puede hacer? si se puede cambiando el grafico y demas variables y luego restaurarlo.
la filosofia es que los procesos procesen cosas de si mismo... implementar esa funcion se puede, pero puede llegar a dar problemas de deathlock... no es la primera vez que esto se propone, incluso creo que lo has propuesto tu tambien, y ya explique en su momento que problemas podria dar esto.
edit: me quede colgado con lo de la funcion... pero ahora, el titulo propone "nueva variable collision_graph", no estas hablando de collision_x, collision_y, etc... asi que tranquilamente puedes switchear la variable graph para hacer una colision con un grafico diferente antes del frame...
no veo el problema... en base a la propuesta, seria solo 1 variable...
algo asi
local
collision_graph;
end
#define SAVE_GRAPH_FOR_COLLISION(x) collision_graph=graph; graph = x;
#define RESTORE_GRAPH_FOR_COLLISION() graph=collision_graph;
...
SAVE_GRAPH_FOR_COLLISION(<aca pongo collision_graph>)
...
haces el collision aca
...
RESTORE_GRAPH_FOR_COLLISION()
...
entre save y restore no debes usar frame y solo 1 vez usar SAVE a menos que uses restore antes.
no le veo problema de cpu, son 3 asignaciones de variables.
Quote from: SplinterGU on August 30, 2012, 03:35:11 PM
la filosofia es que los procesos procesen cosas de si mismo... implementar esa funcion se puede, pero puede llegar a dar problemas de deathlock... no es la primera vez que esto se propone, incluso creo que lo has propuesto tu tambien, y ya explique en su momento que problemas podria dar esto.
Me quede pensando en eso que decis y me gustaria saber cuales son esos problemas que mencionas, porque tengo que admitir que yo también pense en mas de una vez porque no se puede consultar muchas cosas sobre un proceso desde otro proceso, como por ejemplo, colisiones, puntos de control, etc.
Gracias!