fast_collision

Started by Windgate, November 26, 2009, 11:24:27 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

SplinterGU

sencillamente no estoy de acuerdo en que los videojuegos de antes no tenian calidad y que los que los hacian no tenian idea de juegos, eran pioneros en el campo, obviamente que hay cosas que con el tiempo se mejoran/perfeccionan, pero si que sabian hacer juegos, es mas, algunos juegos a mi parecer son incluso mas adictivos que grandes juegos actuales... no podemos comparar, son cosas diferentes, pero no estoy de acuerdo con eso de que no tenian idea. Simplemente eso, no estoy de acuerdo.

no entiendo a que clase de bugs o quebraderos de cabeza te referis con respecto a tener varios procesos que integran un unico personaje... yo no lo veo tan complejo, pero quizas vos tenes algun ejemplo concreto que se me esta escapando... cuidado que no digo que sea mala la colison por cajas, al contrario, es lo mejor para ciertos casos.

otra cosa, vos cambias la prioridad de los procesos constantemente? yo sugiero (cambiando a TIP-MODE, documentacion interna... :D ) que si podes evitarlo, mejor... si bien actualmente bennu esta muy optimizado al respecto del cambio de prioridades, hay que tener en cuenta que cuando haces un cambio de prioridad estas sacando el proceso de una lista y metiendola en otra, con todo lo que esto implica. Por otro lado, no sirve de mucho que cambies la prioridad en un proceso cuando le das un golpe si esperas que esto cambie la prioridad para el frame en curso, el cambio de prioridad se hace efectivo en el motor en el siguiente frame.

espero haber dado algun dato util.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

SplinterGU

no se si lo que describe momia del desplazamiento sea como uno de los temas que tuvo bomberlink en su sorr, con respecto a cuando un personaje agarra a otro y este no esta alineado perfectamente, la solucion que tuvo que dar bomberlink para que la animacion sea correcta es desplazar el personaje que es agarrado para que se alinea a la animacion.
bomberlink puede corregirme si me equivoco, y momia puede decir si es similar a este el tema que comentaba.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

DCelso

 ;D. SplinterGU, sorry.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

Drumpi

¿Y sería muy costoso realizar una función de collision_box haciendo que dicha caja sufra rotaciones? lo digo porque más de uno habeis comentado que usar las collision box con un golpe en diagonal daría con la esquina, pero si la caja es un rectángulo y se gira 45º eso ya no pasa. No se si eso sería tan inefectivo como la colisión por pixel o se puede optimizar en base a cruces entre lineas rectas de ambas cajas.

Y, Neolok ¿por qué te cambias de nombre? odio que la gente haga eso, ya me cuesta seguir quien ha dicho qué, como para encima tener que aprenderme "este ahora es..." ;D
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

SplinterGU

la colision por cajas esta pensado para graficos no rotados o graficos en que la rotacion no afecte el box, o haciendo que el box cambie su tamaño dependiendo de la rotacion (cosa que ya hace la colision por pixels)... pero una caja rotada, no way... se pierde la eficiencia...

por otra parte, quiero decir, que cuidado con la cantidad de cajas que usemos para colision de array, si usamos muchas cajas por grafico, entonces podemos llegar a pecar de hacerlo mas lento que la colision por pixels... creo que esto ya lo explique pero una colision por pixels lo primero que hace es hacer una colision por cajas (1 sola), si la colision por cajas da ok, entonces analiza la colision a nivel pixels, pero solo de las porciones de las cajas que colisionan entre si... o sea, que en la mayoria de los casos y a menos que nuestros graficos colisionen de lleno contra otro, la colision no deberia ser tan costosa, depende del los incrementos en que se mueven nuestros personajes, que los haran que colisionen mas o menos cantidad de pixels. Como sea, es costosa, pero se puede minimizar.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

La momia que fuma

Quote from: Mr Matsusaka on February 20, 2010, 02:36:21 AM
Quote from: La momia que fuma
De hecho en mi Invento-Fighting había un fallo gordisimo, se podía hacer un combo infinito machacando el mismo golpe en la esquina....y el golpe conectaba solo por darle a Invento-Man en un mechón de pelo xDDD (Se parece mucho al ejemplo de la capa xD)

Eso mas que un problema de colision, se me antoja a un problema de desincronizacion.

Como sabras los procesos se ejecutan en orden, que puede ser definido con la variable priority. Cuando golpeas a un enemigo este retrocede por el impacto. Pero si esta al final de la pantalla es el que ha golpeado el que retrocede para evitar combos infinitos.

Supongo que al igual que yo, tu intercambias la prioridad de los personajes segun quien golpeo el ultimo, para que salgan los mismos combos tanto si juegas en el lado del jugador 1 o el del 2. Me equivoco en esta presuncion?

Pues no es lo mismo que un jugador con poca prioridad retroceda, que hacer retroceder a un jugador con mas prioridad que tu. El va un frame de ventaja por delante de ti xd

Lo de aumentar el desplazamiento es la solucion mas sencilla, pero no la mejor. Es posible que al contrario, ciertos combos dejen de salir si golpeas a tu rival al final de la pantalla. Y lo suyo seria que los combos salgan igual estes donde estes.

No, no venía de ahí, la verdad es que creo que al final no usaba priority (Estaban los valores de prioridad de los golpes, pero era otro asunto, claro), era simplemente que el golpe con el que se hacia el combo infinito tenía demasiado alcance y era demasiado rápido...se podia combear "consigo mismo" en situaciones normales (de la misma manera que se suele poder combear varios puñetazos debiles en un SF, en mi caso era ataque medio) hasta que el retroceso lo dejaba fuera del alcance, pero con el retroceso "inverso" de la esquina (en el que el que retrocede es el atacante) no era suficiente y quedaba al alcance del combo infinito, simplemente no me gustaba ni aumentar el (llamemosle) retroceso inverso, porque quedaría exagerado, ni ralentizar dicho ataque, sería cuestión de un punto medio entre las dos cosas. Un problema chorra de diseño, vamos.

Otra solución seria tambien lo de definir una mascara/caja de colision para el personaje, porque el combo infinito lo pillaba, nunca mejor dicho, por los pelos xD, le alcanzaba en un mechon de pelo suelto del gráfico de daño.

De paso creo que queda contestado a Splinter lo de que a que nos referiamos, creo que no tiene mucho que ver con lo del Sorr.

Mr Matsusaka

El tema del Spectrum lo vamos a dejar, aunque podria dar para otro tema aparte en el Offtopic XD

Quote from: SplinterGU on February 20, 2010, 03:10:16 AM
no entiendo a que clase de bugs o quebraderos de cabeza te referis con respecto a tener varios procesos que integran un unico personaje... yo no lo veo tan complejo, pero quizas vos tenes algun ejemplo concreto que se me esta escapando...

Jo, pues anda que no he puesto ejemplos a tutiplen XD

Quote from: SplinterGU on February 20, 2010, 03:10:16 AMotra cosa, vos cambias la prioridad de los procesos constantemente? yo sugiero (cambiando a TIP-MODE, documentacion interna... :D )

¿Donde esta esa documentacion? La he buscado pero no se donde deberia mirar...

Quote from: SplinterGU on February 20, 2010, 03:10:16 AMhay que tener en cuenta que cuando haces un cambio de prioridad estas sacando el proceso de una lista y metiendola en otra, con todo lo que esto implica.

¿Que es lo que implica? ¿Bugs? ¿Consumo de memoria?

Quote from: SplinterGU on February 20, 2010, 03:10:16 AMPor otro lado, no sirve de mucho que cambies la prioridad en un proceso cuando le das un golpe si esperas que esto cambie la prioridad para el frame en curso, el cambio de prioridad se hace efectivo en el motor en el siguiente frame.

El cambio de prioridad sirve para que los combos del player 1 y los del player 2 sean ideanticos. El problema no es el primer golpe, sino los que vienen despues. Y si el que va a recibir un combo a perdido la prioridad al recibir el primer golpe, el combo que le venga a continuacion conectara igual sin importar que luchador es.

Explicado en detalle...
Puede darse la situacion de que el player uno al recibir el primer golpe, le de tiempo a recuperarse y cubrirse justo cuando llega el segundo golpe. El segundo jugador no tendra la opcion de cubrirse porque el golpe del primer jugador llegara antes de que se acabe la animacion de recibir golpe.

Mr Matsusaka

Quote from: Drumpi on February 20, 2010, 01:48:45 PMY, Neolok ¿por qué te cambias de nombre? odio que la gente haga eso, ya me cuesta seguir quien ha dicho qué, como para encima tener que aprenderme "este ahora es..." ;D

Perdon, pero sencillamente acabe arto de mi antiguo nick. Es un nick que cree al tuntun hace muchos años. Nunca fue nada con lo que me sintiese especalmente identificado. En cambio Matsusaka, es mi apellido español traducido al japones XD

Quote from: La momia que fuma
No, no venía de ahí

O a lo mejor si viene de ahi XD

Date cuenta de un detalle. Ese combo infinito solo sale al final de la pantalla. Tu lo has visto como un problema con la colision, pero en realidad el problema viene de que el retroceso del personaje que golpea cuando tiene a su rival arrinconado no es equivalente al retroceso del que recibe en medio de la pantalla. Y porque? Pues muy probablemente por temas de prioridad.

Puedes retocar la colision, pero cuando metieses mas personajes te encontrarias con este problema de nuevo con otros golpes. Lo mejor en mi opinion es ir a por la raiz del problema en vez de ir haciendo malabarismos con la fisica.

SplinterGU

momia, es raro eso que te apliques combos a vos mismo... no se como lo tenes implementado, pero como sea, coincido en que es un problema de diseño.

Mr Matsusaka, veamos...

1) la documentacion la acabo de dar... por eso puse "(cambiando a TIP-MODE, documentacion interna... Cheesy )" porque iba a dar documentacion interna, si alguno la queria pillar e incorporarla al wiki o a lo que sea, bien...

2) cuando digo, "todo lo que eso implica", obviamente me refiero a procesamiento... buscar el elemento, quitarlo de una lista, incorporarlo a otra, actualizar hashes, etc... si bien estas operaciones estan optimizadas y se hacen algunas en conjunto, se hacen...

3) no dije que no hay que cambiar las prioridades, dije que deberia evitarse hacerlo, pero si lo haces porque lo necesitas no esta mal, es un consejo si es aplicable al desarrollo que uno lleva o no, es otro tema... si se puede evitar cambiar cosas como prioridades o Z (esta ultima mas que nada), es mejor evitarlo... pero si lo haces no pasa nada... solo consumira un poco mas de cpu.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Drumpi

Quote from: SplinterGU on February 20, 2010, 03:12:46 PM
la colision por cajas esta pensado para graficos no rotados o graficos en que la rotacion no afecte el box, o haciendo que el box cambie su tamaño dependiendo de la rotacion (cosa que ya hace la colision por pixels)... pero una caja rotada, no way... se pierde la eficiencia...

Una collision box se reduce a:
if (abs( (proc1.x*size_x/100) - (proc2.x*size_x/100)) < ((ancho_graph_p1/2)+(ancho_graph_p2/2)) && abs( (proc1.y*size_y/100) - (proc2.y*size_y/100)) < ((alto_graph_p1/2)+(alto_graph_p2/2)) )

Vamos, que se puede hacer hasta por código ;D Es fácil de entender.
Pero creo que si se determina la posición de las 4 esquinas de un gráfico, se pueden determinar las 4 rectas que lo delimitan, y estas pueden cruzarse (colisión) o no (no colisión).
Obviamente, esto es menos eficiente que una collision box, pero mucho más que un pixel perfect, porque sería comparar 8 líneas dos a dos (y no todas las combinaciones). Simplemente es resolver un sistema de dos ecuaciones buscando si existe un punto en común en cada par dentro de los límites, y en caso de que sí ¡premio!

Vamos, para mentes privilegiadas en el cálculo matemático debería ser un problema muy sencillo. Yo estoy demasiado cansado hoy para pensar con claridad ^^U zzzzz
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

SplinterGU

creo que la hiciste un poco complicada...

y eso no es una caja rotada... teniendo en cuenta rotaciones la cosa seguiria siendo una caja rectangular de dimensiones diferentes a la original, debido a las rotaciones... y seria la caja formada por el cruce de todas las esquinas cuadradas del grafico... vamos que eso es ya es parte de las colisiones por pixel actuales...

Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Mr Matsusaka

Quote from: SplinterGU on February 20, 2010, 09:13:04 PM
1) la documentacion la acabo de dar... por eso puse "(cambiando a TIP-MODE, documentacion interna... Cheesy )" porque iba a dar documentacion interna, si alguno la queria pillar e incorporarla al wiki o a lo que sea, bien...

Ahh que era una broma XD Yo pensando que eso de TIP-MODE era una variable o algo asi del lenguaje. Y yo buscando la palabrita en el Wiki, que imbecil XDDD

Quote from: SplinterGU link=topic=964.msg18052#msg18052
date=1266700384

2) cuando digo, "todo lo que eso implica", obviamente me refiero a procesamiento...
3) dije que deberia evitarse hacerlo, pero si lo haces porque lo necesitas no esta mal

Gracias por la info. En mi caso lo necesito, pues no encontre otro modo de dar neutralidad a los dos players.

La momia dijo que no lo cambia. Encontraste otra solucion?

Mr Matsusaka

Quote from: Drumpi on February 21, 2010, 01:12:24 AM
Una collision box se reduce a:
if (abs( (proc1.x*size_x/100) - (proc2.x*size_x/100)) < ((ancho_graph_p1/2)+(ancho_graph_p2/2)) && abs( (proc1.y*size_y/100) - (proc2.y*size_y/100)) < ((alto_graph_p1/2)+(alto_graph_p2/2)) )

No estoy seguro pero, el "*size_x/100" no deberia ir con los anchor_graph?

Por otra parte, en muchos juegos los personajes no varian de tamaño por lo que en esos casos nos ahorrariamos unas cuantas multiplicaciones y divisiones.

SplinterGU

jejeje, "TIP MODE" es "MODO CONSEJO"... una estupides...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

SplinterGU

implementar "box collision" simple (1 sola caja) nativamente en bennu es muy facil, de hecho ya se hace, es el primer chequeo previo a la colision por pixel... si esto colisiona se hace a nivel pixel... (creo que ya lo mencione)... vere de incluirlo...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2