fast_collision

[BoMbErLiNk]

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.

Y no es mejor un evaluador de combate independiente del jugador 1 y 2 para eso ?

Un proceso que se ejecute después que el jugador 1 y 2, compruebe si los 2 colisionan a la vez y que en ese caso aplique una tabla de prioridades basados en el tipo de ataque, en la fuerza del ataque, la ley del primero, etc para luego enviar resultados fiables en el siguiente frame ?

La precisión va a ser la misma o incluso más estable porque el que tenia un priority inferior se va a ejecutar más tarde igualmente, aunque sea ejecutarse para decirse a si mismo que tendrá un priority mayor en el siguiente frame, es decir siempre se pierde 1 frame de precisión.

Si fuera un juego de 4 jugadores sería un jaleo mover las prioridades de todos por ejemplo

Incluso aunque 2 personajes tengan un mismo priority uno siempre se va a ejecutar antes que el otro, en fenix esto iba a boleo, a veces uno a veces el otro, los ponias en la misma Z y veias como se solapaban entre ellos, en Bennu siempre se ejecuta después el que se creo más tarde

[Mr Matsusaka]

Y no es mejor un evaluador de combate independiente del jugador 1 y 2 para eso ?

Un proceso que se ejecute después que el jugador 1 y 2, compruebe si los 2 colisionan a la vez y que en ese caso aplique una tabla de prioridades basados en el tipo de ataque, en la fuerza del ataque, la ley del primero, etc para luego enviar resultados fiables en el siguiente frame ?

La precisión va a ser la misma o incluso más estable porque el que tenia un priority inferior se va a ejecutar más tarde igualmente, aunque sea ejecutarse para decirse a si mismo que tendrá un priority mayor en el siguiente frame, es decir siempre se pierde 1 frame de precisión.

Es buena idea tener un proceso neutro que gestione algunas cosas como las prioridades de los golpes, para que el player 1 no tenga mas prioridad de golpeo que el player 2.

Pero el problema que yo indico es distinto. No se trata del primer golpe, sino de los que vienen combinados despues. Si das proridad al player uno, este tendra mayores posibilidades de hacer combos mas largos que el player 2. Incluso habra combos que mientras con el player 1 salgan, con el player 2 se rompan a la mitad por culpa de que al player 1 le dio tiempo a recuperarse entre los golpes.

Una manera sencilla de testear este problema es con los clasicos golpes flojos que se combinan aporreando el boton. En caso de existir el problema, el player 1 siempre encadenara mas golpes que el player 2.

[SplinterGU]

lo que dice bomber no es un proceso que cambie las prioridades de player 1 o 2, sino un proceso que se ejecuta luego de player 1 y 2, y que decide como seran los proximos eventos/golpes... de esta forma por ejemplo, si ambos lanzan el golpe en el mismo frame, no habra en ese caso prioridad de uno sobre el otro por ejecutarse uno antes que el otro (segun la lista corriente de prioridades) sino que ambos en este caso podrian como cancelarse los golpes a si mismo, y poner por ejemplo una animacion de golpes contra golpe... yo que se... es un mejor metodo indudablemente. E incluso podria ser que segun fuerza o lo que sea, un golpe se imponga sobre el otro golpe mas debil... y esto se trabajaria con ambos player a la misma prioridad siempre, sin tener que cambiarlos ni cambiar la prioridad de ningun proceso.

no se si se logra entender el concepto... o se necesita explicar diferente...

[Mr Matsusaka]

Cuando hablo de "prioridades de golpes" no hablo de las prioridades de procesos. Prioridades de golpes es un concepto tipico de juegos de lucha que sirve para describir que golpe ha de ganar cuando los dos luchadores conectan en el mismo frame.

El problema de la prioridad (de procesos) no viene por el enfrentamiento de golpes, sino por que los combos salen distintos. Lo explico en mi anterior mensaje.

[SplinterGU]

entonces toda la charla que venimos teniendo desde hace unos dias fue inutil? nunca hablaste de prioridades de procesos? yo juraria que si...

[Mr Matsusaka]

entonces toda la charla que venimos teniendo desde hace unos dias fue inutil? nunca hablaste de prioridades de procesos? yo juraria que si...

Tengo la impresion de que no lees mis segundos parrafos. Yo hablo siempre de prioridades de procesos. Quien trajo a colacion el tema de las prioridades de golpes fue BomberLink y luego tu. Yo ya vengo diciendo durante dos post que ese no es el problema.

El problema no es el enfrentamiento de golpes, sino que los combos salen distintos

El problema no es el enfrentamiento de golpes, sino que los combos salen distintos

El problema no es el enfrentamiento de golpes, sino que los combos salen distintos

Espero que haya quedado clarito ya ;D

[BoMbErLiNk]

Es buena idea tener un proceso neutro que gestione algunas cosas como las prioridades de los golpes, para que el player 1 no tenga mas prioridad de golpeo que el player 2.

Pero el problema que yo indico es distinto. No se trata del primer golpe, sino de los que vienen combinados despues. Si das proridad al player uno, este tendra mayores posibilidades de hacer combos mas largos que el player 2. Incluso habra combos que mientras con el player 1 salgan, con el player 2 se rompan a la mitad por culpa de que al player 1 le dio tiempo a recuperarse entre los golpes.

Una manera sencilla de testear este problema es con los clasicos golpes flojos que se combinan aporreando el boton. En caso de existir el problema, el player 1 siempre encadenara mas golpes que el player 2.

Si, lo queria decir que con ese metodo podría servir tanto para el primero como para un combo, pero ojo que yo si veo bien el uso de priority, especialmente porque influye en el pintado (si son 60fps ya no me preocuparia tanto), no llegaras a ver 2 personajes dandose un puño a la vez porque uno manda sobre otro cuando ya se ha establecido la prioridad, no hay que esperar al siguiente frame en ese caso para ver resultados, a excepción del primer puño que parece no tiene ningún control si solo se usa priority por eso comentaba.

--
EDIT : Leyendo los mensajes de la página 3 parecia que se hablaba de priority y no de otras prioridades, mis disculpas  :P

[SplinterGU]

Cuando hablo de "prioridades de golpes" no hablo de las prioridades de procesos.

caramba, si que es dificil entenderte... aca dices que hablas de prioridad de golpes y luego en el otro post dices lo contrario... no te entiendo...

por otro lado, yo no hable de prioridad de golpes... voy a bajar el nivel de explicacion a ver si se explica, porque veo que no se entiende...

lo que se entiende por tu necesidad de cambiar la prioridad de los procesos es que el proceso que primero se ejecuta es el que tiene prioridad en el combo... o que tus combos y ataques dependen en gran medida de la prioridad de tus procesos... y lo que digo aca es que teniendo un proceso controlador eso no es necesario... ni tampoco es necesario cambiar la prioridad de los procesos... la cosa es asi... vos podes tener 2 procesos player, estos procesos tienen flags o variables de estado que indican accion realizada (por ejemplo, golpe de puño lanzado, patada, bloqueo, etc) y todo lo que sea necesario... como por ejemplo, colision con otro personaje... una vez ejecutados todos los players, el proceso controlador revisa dichos flags y actua en consecuencia, activando combos, iniciando/cambiando secuencias/graficos de animacion, lo que sea... sin darle prioridad a ninguno de los players sobre el otro (por lo menos no dara prioridad en base a quien ejecuto primero) y no necesita cambiar la prioridad de ningun proceso...

pero vamos, si a vos te sirve tu metodo esta perfecto, lo que debatimos aca son sugerencias/consejos/mejoras... como digo siempre, al que le sirve que la tome, al que no que lo pase por alto...

[DCelso]

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...

A esto le veo el gran problema del ripeo de sprites, habría que hacer todos los sprites con "crop", es decir, imagínate un sprite que "cropado" (recortado a su mínimo tamaño posible) tiene una caja de 32x32 pixeles, ahora a ese mismo sprite ripeado mal podría estar en una imagen de 100x100 por lo que la caja sería más gande y daría colisiones falsas.

Lo digo, porque mucha gente no usa los control points para ajustar las animaciones, en vez de usar este método de ajuste de animaciones usan el de toda la vida de ajustarlo dentro de un mismo tamaño de imagen con el editor de imágenes, y esto da el problema que digo de crop, porque si una animación de golpe tiene 3 sprites( uno quieto, otro moviendo el pie para delante, y otro dando el puñetazo) está claro que el tercer sprite necesitará una imagen más grande de por ejemplo 100x100 mientras que la primera le puede ir bien una de 32x64, pues entonces para ajustar la animación y que se vea que se mueve bien lo que se hace es agrandar todas las imágenes al tamaño más grande de las tres y luego centrar los sprites para ajustar los pies al movimiento.
Por tanto el último sprite tiene una caja medio aproximada, pero los otros dos sprites tendrán una caja megagrande.

Es por ello que, por ejemplo, el motor mugen no usa esa técnica de una caja, sino que tiene un editor a parte para poner las cajas a cada sprite de la animación (que ya si quieres puede ser tanto una como mil) y que ya el sistema usará para detectar colisiones.

Yo creo que antes de esto, más facil sería implementar la de máscara, y tener una variable local llamada graph_mask que el programador controle qué máscara poner en cada momento (imagen blanco y negro) y que el sistema use para comprobar colisiones.

[Mr Matsusaka]

Cuando hablo de "prioridades de golpes" no hablo de las prioridades de procesos.

caramba, si que es dificil entenderte... aca dices que hablas de prioridad de golpes y luego en el otro post dices lo contrario... no te entiendo...

Vamos a ver.

En primer lugar BomberLink ha sacado el tema de las prioridades de los golpes confundiendolo con las prioridades de los procesos. Yo le he dicho que me parecia bien su sistema para gestionar la "prioridad de los golpes" pero que esas no son las prioridades que a mi me daban problemas.

Luego tu ha venido sin darte cuenta de que las prioridades de las que hablaba BomberLink eran otras. Te has pensado que no habia entendido lo que ponia BomberLink y en realidad eras tu el que no habia entendido lo que eran las prioridades de los golpes, liandolo todo. Y por eso te he puesto:

Cuando hablo de "prioridades de golpes" no hablo de las prioridades de procesos.

Pero es que hasta esta frase la has malinterpretado. Cualquiera que sepa hablar castellano sabe que

Cuando hablo de "prioridades de golpes" no hablo de las prioridades de procesos.

no es igual a

Cuando hablo de "prioridades de procesos" no hablo de las prioridades de golpes.

Pues solo he hablado de prioridades de golpes para contestar a BomberLink. Por eso uso "Cuando", y "prioridades de golpes". Para indicar el unico momento en que he hablado de otra prioridad distinta a la de los procesos.

Vamos, yo comprendo que te hayas hecho un lio porque no conozcas el argot de los juegos de lucha. Sin embargo aunque al principio he hablado de las prioridades de golpeo para indicarle a BomberLink que me parecia un buen sistema el suyo, acto seguido he escrito que no era ese el problema del que hablabamos.

Y por eso digo que tengo la impresion de que no me lees los segundos parrafos. Si hubieses leido eso te habrias dado cuenta de que algo no encajaba. Tambien te habrias dado cuenta de que lo que decia BomberLink no era el problema que yo (invirtiendo mi tiempo) me habia molestado en describirte anteriormente. Y aun asi me lo has repetido como a los niños chicos, como si fuese yo el que no me habia enterado de lo que el decia!

No pensaba ponerme en serio pero, te lo voy a decir. No me has leido mis comentarios desde el principio. Ni me has leido cuando he dado ejemplos de porque la colision por pixeles me parecia problematica, pues luego has dicho:

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...

cuando me habia esforzado en explicarlo con pelos y señales durante varios posts.

Ni me has leido bien acerca del tema del Spectrum poniendo en mi boca cosas que no he dicho como

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

Cuando lo que yo he dicho es que muy pocos juegos pasarian un test de calidad (sabes lo que es un test de calidad en el mundo de los videojuegos?) no literalmente que no tenga calidad (que a lo mejor lo pienso, pero no lo he dicho). Del mismo modo decir que "no tener ni idea de diseño de videojuegos" y "no tener idea de juegos" no es lo mismo. Por ello puse la palabra diseño en negrita en anteriores entradas, para que se entendiese la diferencia. Saber de diseño de videojuegos es por ejemplo saber que la caja de colision por pixeles es una mierda para la mayoria de los generos que hay.

Y ni me has leido despues cuando la conversacion a derivado en el tema de las prioridades, cuando ha venido la momia. He explicado el problema de las prioridades y los combos como dos veces antes de que viniese BomberLink con las prioridades de golpes y aun asi no te has enterado de que BomberLink hablaba de un problema distinto al mio, no te has enterado que BomberLink y luego yo en el primer parrafo de mi contestacion hablabamos de otra prioridad, no te has enterado que en la misma contestacion, parrafo dos, le hago saber que no es esa la prioridad de la que hablamos. No te has enterado que cuando he puesto "Cuando hablo de prioridades de golpes" no significa "Cuando hablo de prioridades de procesos" pues que yo sepa son dos bocablos totalmente distintos.

No te has enterado, en definitiva, de nada. Y no te has enterado de nada sencillamente porque no has hecho el esfuerzo intelectual de leerme con atencion. Y eso es una falta de respeto. Pues llevo dias escribiendo con mi buena fe para hacerme explicar.

Fijate, BomberLink si se ha dado cuenta al leer mi contestacion de que estabamos hablando de prioridades distintas (y por lo tanto, de problemas distintos) y ha venido disculpandose (cuando tampoco hacia falta - una confusion la tiene cualquiera, como yo con lo de TIP-MODE) y en cambio tu, depues de haberla liado parda encima me vienes insinuando que soy yo el que no me se expresar.

Normalmente te habria contestado a lo que me has escrito despues, que es acerca del problema que estabamos tratando. Pero chico, has acabado con mi buena fe.

Lo que mas miedo me da es que pese a todo no vas a entender este mensaje porque nuevamente no vas a hacer el esfuerzo de leerme como dios manda.

[FreeYourMind]

No he entendido nada  ;D (que es broma hombre!  :-*)

[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...

A esto le veo el gran problema del ripeo de sprites, habría que hacer todos los sprites con "crop", es decir, imagínate un sprite que "cropado" (recortado a su mínimo tamaño posible) tiene una caja de 32x32 pixeles, ahora a ese mismo sprite ripeado mal podría estar en una imagen de 100x100 por lo que la caja sería más gande y daría colisiones falsas.

Lo digo, porque mucha gente no usa los control points para ajustar las animaciones, en vez de usar este método de ajuste de animaciones usan el de toda la vida de ajustarlo dentro de un mismo tamaño de imagen con el editor de imágenes, y esto da el problema que digo de crop, porque si una animación de golpe tiene 3 sprites( uno quieto, otro moviendo el pie para delante, y otro dando el puñetazo) está claro que el tercer sprite necesitará una imagen más grande de por ejemplo 100x100 mientras que la primera le puede ir bien una de 32x64, pues entonces para ajustar la animación y que se vea que se mueve bien lo que se hace es agrandar todas las imágenes al tamaño más grande de las tres y luego centrar los sprites para ajustar los pies al movimiento.
Por tanto el último sprite tiene una caja medio aproximada, pero los otros dos sprites tendrán una caja megagrande.

Es por ello que, por ejemplo, el motor mugen no usa esa técnica de una caja, sino que tiene un editor a parte para poner las cajas a cada sprite de la animación (que ya si quieres puede ser tanto una como mil) y que ya el sistema usará para detectar colisiones.

Yo creo que antes de esto, más facil sería implementar la de máscara, y tener una variable local llamada graph_mask que el programador controle qué máscara poner en cada momento (imagen blanco y negro) y que el sistema use para comprobar colisiones.

Dcelso, no hay problema, porque no es para todos los casos... depende del caso...
ah, bueno... si vos tenes un grafico de 32x32 y lo recortar a 100x100, te puedo asegurar que ahi tenes otro problema... pero de otra indole que nada tiene que ver con la programacion... :P
esas cosas que mencionas son obvias... repito, como vengo diciendo y repitiendo continuamente... DEPENDE DEL CASO O NECESIDAD!

Mr Matsusaka, man, tienes algun tipo de problema? si te fijas, lo que dijo bomberlink y lo que dije yo no son 100% lo mismo, lo que dije yo fue en base al proceso controlador. y en base a eso dije las cosas que dije...

a ver, yo te he leido perfectamente, parece que tu no me has leido a mi o no te has molestado en entender lo que te queria explicar...

lo que simplemente digo, que no deberias cambiar las prioridades de los procesos y que eso lo evitarias con un proceso controlador que tome las decisiones de las acciones o eventos siguientes... yo no he dicho que lo que haces esta mal, al contrario, dije que si te sirve tu sistema perfecto... es solo una sugerencia para ti o para quien quiera aplicar este metodo en sus proyectos... pero tu me hasta tenido criticando y haciendome gastar mi tiempo (que es tanto o quizas mas valioso que el tuyo) en tener que responderte a cada una de tus objeciones y defensas como si alguien te estuviese atacando.

con relacion al tema del spectrum, tampoco hace falta que digas una cosa si la das a entender o la dices a media...

sinceramente no se para que me meto en las conversaciones y pierdo el tiempo explicando cosas internas, si callado la paso mejor... y si alguien quiere saber algo interno que se meta en el codigo, creo que el codigo lo he hecho bastante clarito para que lo entienda cualquiera...

en fin... tema cerrado de mi parte...

[Mr Matsusaka]

Mr Matsusaka, man, tienes algun tipo de problema? si te fijas, lo que dijo bomberlink y lo que dije yo no son 100% lo mismo, lo que dije yo fue en base al proceso controlador. y en base a eso dije las cosas que dije...

Eso lo has dicho despues, en tu penultimo mensaje. Si, justo en ese donde me has insinuado que no me se expresar. Abuenashorasmanagasverdes!

lo que dice bomber no es un proceso que cambie las prioridades de player 1 o 2, sino un proceso que...

Para no decir lo mismo se te dan bastante mal los encabezamientos de las oraciones...

a ver, yo te he leido perfectamente, parece que tu no me has leido a mi o no te has molestado en entender lo que te queria explicar...

No, no lo has hecho. Y sigues sin hacerlo.

lo que simplemente digo, que no deberias cambiar las prioridades de los procesos y que eso lo evitarias con un proceso controlador que tome las decisiones de las acciones o eventos siguientes... yo no he dicho que lo que haces esta mal, al contrario, dije que si te sirve tu sistema perfecto... es solo una sugerencia para ti o para quien quiera aplicar este metodo en sus proyectos...

Salida de la tangente. Todo eso no tiene nada que ver con la confusion que has tenido por no leerme bien. Todo eso que dices ya estaba hablado y superado. ¿Que tal si avanzamos?

pero tu me hasta tenido criticando y haciendome gastar mi tiempo (que es tanto o quizas mas valioso que el tuyo) en tener que responderte a cada una de tus objeciones y defensas como si alguien te estuviese atacando.

Toda esta frase es una falacia en si misma como un templo. ¿Puedes quotearme en que parte te he insultado?

Y lo de gastar el tiempo no lo has entendido. Yo a ti no te he hecho perder el tiempo porque yo SI que te he leido con atencion y con la intencion de entenderte. Tu no puedes decir lo mismo.

A BomberLink le he reconocido lo practico del sistema controlador. A ti te he preguntado que porque cambiar priority esta mal para aprender. Yo no he estado a la defensiva. Hasta dos mensajes yo estaba muy tranquilo.

sinceramente no se para que me meto en las conversaciones y pierdo el tiempo explicando cosas internas, si callado la paso mejor... y si alguien quiere saber algo interno que se meta en el codigo, creo que el codigo lo he hecho bastante clarito para que lo entienda cualquiera...

Nueva salida de la tangente. ¿Acaso la confusion ha venido porque yo no entiendo el codigo? No. La confusion ha venido porque no me has leido con detenimiento durante varios post.


Y retomando el tema.

lo que se entiende por tu necesidad de cambiar la prioridad de los procesos es que el proceso que primero se ejecuta es el que tiene prioridad en el combo... o que tus combos y ataques dependen en gran medida de la prioridad de tus procesos... y lo que digo aca es que teniendo un proceso controlador eso no es necesario... ni tampoco es necesario cambiar la prioridad de los procesos... la cosa es asi... vos podes tener 2 procesos player, estos procesos tienen flags o variables de estado que indican accion realizada (por ejemplo, golpe de puño lanzado, patada, bloqueo, etc) y todo lo que sea necesario... como por ejemplo, colision con otro personaje... una vez ejecutados todos los players, el proceso controlador revisa dichos flags y actua en consecuencia, activando combos, iniciando/cambiando secuencias/graficos de animacion, lo que sea... sin darle prioridad a ninguno de los players sobre el otro (por lo menos no dara prioridad en base a quien ejecuto primero) y no necesita cambiar la prioridad de ningun proceso...

Eso ya lo habia pensado.

El problema esta en que habria que sacar tanto la funcionalidad de controles como el flujo de las animaciones. Probablemente habria que sacar absolutamente todo el codigo de los procesos luchadores para meterlo en el proceso controlador.

Es una posible solucion, pero a medio proyecto seria un caos total hacer semejante cambio.

[SplinterGU]

ok...