Bennu Game Development

Foros en Español => Sugerencias => Topic started by: Windgate on November 26, 2009, 11:24:27 AM

Title: fast_collision
Post by: Windgate on November 26, 2009, 11:24:27 AM
Los que hemos trabajado en proyectos 2D con gran cantidad de procesos activos sabemos que collision (type xxx) supone un consumo de memoria excesivo, ya que collision tiene en cuenta la geometría de todo proceso de tipo xxx, incluyendo transparencias, p.ej. un donut no detecta colisiones en su centro.

He estado trabajando con las "collision" en 3D y en ellas se asigna una geometría básica a cada elemento para que la detección de colisiones sea aproximada y se consuman muuuchos menos recursos.

Mi sugerencia es un mecanismo de detección de colisiones en 2D que no atienda a transparencias, sino simplemente a la anchura y altura de los gráficos implicados.

Por ejemplo, para una bala consumiría mucho menos ignorar la información de transparencias, incluso sería deseable poder interpretar colisión rápida en el detector, en el objetivo o en ambos a la vez.

¿Qué opináis? El código de collision no debería ser muy difícil de modificar ya que se trataría de eliminar código más que añadirlo :P
Title: Re: fast_collision
Post by: DjSonyk on November 26, 2009, 03:30:17 PM
Humm a priori y sin mirar el codigo ,pienso que le metodo es el de siempre el mascaras, sin ser el mas rapido es el mas preciso, pero otra forma es la utilizada bastante el los juegos 2JME rectangulizar el grafico en rectangulos pequeños y comprobar sin chocan ignorando los colores que chocan,(transparentes,simi,ect),pero vamos que ese metodo para los moviles esta bien pero para ...... me parece una chapuza....
Title: Re: fast_collision
Post by: l1nk3rn3l on November 26, 2009, 04:52:13 PM
me parece una buena sugerencia para un nuevo modulo..
Title: Re: fast_collision
Post by: panreyes on November 26, 2009, 05:40:04 PM
He visto el código fuente, y creo que se podría mirar de mejorar la colisión que tenemos.
Por ejemplo, no comprobar procesos que, por el tamaño del gráfico, size, size_x, size_y y la posición de estos, es seguro que no colisionan. Eso mejorará el rendimiento en muchos casos, creo.
Title: Re: fast_collision
Post by: DjSonyk on November 26, 2009, 07:06:17 PM
Para ello se deveria comprobar la distancia/posicion entre ellos,lo cual lo que se gana por un lado se pierde por otro...
Title: Re: fast_collision
Post by: Windgate on November 26, 2009, 07:26:32 PM
La ineficiencia de collision es absoluta, pero si se quieren detectar colisiones bien detectadas no queda otra...

Para juegos con masificación de procesos se hace necesario tener una matriz a modo de tablero y comprobar en las celdas adyacentes, collision es inviable.

La collision ( ) actual está bien como está, yo propongo "otra" fast_collision que únicamente atienda a anchura y altura de los gráficos. Gracias por mirarlo PiXeL, he tenido tiempo para pensar pero no para echar un vistazo... Lo haré
Title: Re: fast_collision
Post by: Drumpi on November 26, 2009, 11:23:22 PM
Hombre, si no tenemos en cuenta "angle", con una simple resta de las coordenadas entre los procesos que interactúan basta, es más, en muchos casos bastará con hacer una única resta, porque al no tener una misma coordenada vertical ¿para qué mirar la horizontal?

De todas formas, ya se habló de las "collision_box", no recuerdo en qué se quedó, si era algo pendiente de añadir en el módulo correspondiente, si ya estaba implementado en el código...
Title: Re: fast_collision
Post by: SplinterGU on November 26, 2009, 11:26:00 PM
Quote from: PiXeL on November 26, 2009, 05:40:04 PM
He visto el código fuente, y creo que se podría mirar de mejorar la colisión que tenemos.
Por ejemplo, no comprobar procesos que, por el tamaño del gráfico, size, size_x, size_y y la posición de estos, es seguro que no colisionan. Eso mejorará el rendimiento en muchos casos, creo.

Pix, esos tipos de chequeos ya estan incorporados... y se evita hacer el calculo si los graficos no chocan por coordendas...

vamos a ver... el colision actual, es preciso, por pixels... esta en plan desde hace tiempo otros tipos de colisiones... circulares, rectangulares, etc...
Title: Re: fast_collision
Post by: SplinterGU on November 26, 2009, 11:27:52 PM
Quote from: Drumpi on November 26, 2009, 11:23:22 PM
Hombre, si no tenemos en cuenta "angle", con una simple resta de las coordenadas entre los procesos que interactúan basta, es más, en muchos casos bastará con hacer una única resta, porque al no tener una misma coordenada vertical ¿para qué mirar la horizontal?

De todas formas, ya se habló de las "collision_box", no recuerdo en qué se quedó, si era algo pendiente de añadir en el módulo correspondiente, si ya estaba implementado en el código...

Claro, ya lo habiamos hablado, pero aun esta pendiente... seran cosas de la version 2.0 o >1.0
Title: Re: fast_collision
Post by: Windgate on November 27, 2009, 12:13:54 AM
Después de muchos meses amenazando, me voy a descargar TODO Bennu y vamos a intentar compilar a semejante cabronazo peludo y obeso a ver qué se puede hacer 8)
Title: Re: fast_collision
Post by: Mr Matsusaka on February 18, 2010, 07:53:45 AM
En mi opinion las colisiones por pixel que vienen dadas desde la epoca del Div2 son peores que unas mas sencillas hechas por cajas. Al menos a mi, no me gusta que una bala que colisione en la capa de mi protagonista me mate... Tampoco me gusta que los combos de un juego de lucha salgan o dejen de salir dependiendo del enemigo y de si este es mas flaco o tiene melena... o que un golpe no colisione porque pilla justo en medio de las piernas del enemigo...

Si a esto ademas le sumamos el consumo de recursos pues la eleccion creo que esta clara. Al menos en un juego de lucha que tengo en proyecto lo hago con colisiones de cajas y ha quedado perfecto y ahora estoy seguro de que un determinado combo que sale contra un determinado personaje, va a salir contra ese y contra cualquier otro.

Lo que mucha gente cree que son unas colisiones chapuzeras, son en realidad las que se han venido haciendo en los juegos profesionales desde tiempos inmemoriables. U acaso os creeis que en la practica se nota mucho si la colision esta hecha por pixel o por cajas de colision? Podeis decirme algun juego 2D que se note que sus colisiones estan hechas por pixel?
Title: Re: fast_collision
Post by: Windgate on February 18, 2010, 08:37:30 AM
Lo ideal sería disponer de ambos métodos, o de alguna manera tener un proceso fantasma con el gráfico en recuadro que sea sobre el que realmente se compruebe la colisión... Sería una opción que se podría probar...

Lo que dices de las colisiones con la capa del personaje, ojo. Para evitar eso es posible trabajar los personajes "por partes". Por ejemplo, en un juego de combate 1 vs 1 lo ideal es tener separado un proceso con el puño o el pie del personaje que se superponga sobre el personaje completo (Usando puntos de control por ejemplo).

De esa forma las colisiones se comprueban sobre esos procesos pie, puño, etc. que sólo aparecen cuando el personaje está golpeando. Con eso evitas lo que tú dices, si lo haces de otra manera es tedioso tener que comprobar si ha habido colisión del pie del personaje A con la cara del personaje B o al revés...
Title: Re: fast_collision
Post by: Mr Matsusaka on February 18, 2010, 09:12:14 AM
Quote from: Windgate on February 18, 2010, 08:37:30 AM
Lo ideal sería disponer de ambos métodos
No se me malinterprete, no estoy a favor de la eliminacion de la colision por pixeles. Simplemente quiero expresar que para mi, en los videojuegos, una colision mas austera por cajas, resulta a la larga mejor. Luego que cada uno use el metodo que mejor le parezca.

Quote from: Windgate on February 18, 2010, 08:37:30 AMLo que dices de las colisiones con la capa del personaje, ojo. Para evitar eso es posible trabajar los personajes "por partes". Por ejemplo, en un juego de combate 1 vs 1 lo ideal es tener separado un proceso con el puño...

De esa forma las colisiones se comprueban sobre esos procesos pie, puño, etc. que sólo aparecen cuando el personaje está golpeando. Con eso evitas lo que tú dices, si lo haces de otra manera es tedioso tener que comprobar si ha habido colisión del pie del personaje A con la cara del personaje B o al revés...

La explicacion que das es tan valida para la colision por cajas como la colision por pixeles. Tambien la colision por cajas necesita de un X e Y originales como referencia, y a partir de ahi calcular si las cajas se superponen o no.

El problema no radica en la colision del que golpea, sino de quien recibe. Pues en ese caso el que colisiona es el enemigo con todo su cuerpo. El personaje de la capa no esta golpeando, sino recibiendo un disparo (por ejemplo) y este, al tocarle en la capa lo mata. Imaginate un cuadro de animacion en el que la capa se mueve por el viento haciendo nuestro personaje mas vulnerable. No se como lo ves, pero en mi opinion una cuestion estetica como esa no deberia afectar a la jugabilidad...

Tendria una solucion, y seria separando el personaje y la capa haciendolos procesos distintos. En un juego arcade o plataformas no habria problemas.

Sin enbargo en un juego de lucha la cosa aun seria problematica. Tal como he dicho, determinados combos dejarian de salir dependiendo del rival. Aparte de que descubrir todas estas incongruencias entre todos los combos y enemigos posibles seria una tarea titanica, partir los frames problematicos en varios procesos no hace otra cosa mas que complicar la historia.

El tercer problema, que un golpe bajo se ponga entre las piernas del enemigo y no haga colision, no tiene un remedio limpio con la colision por pixeles. Yo he llegado a ver un "hadoken" que va por el suelo tipo Power Wave que de vez en cuando atravesaba a cierto enemigo. Este enemgo tenia las piernas muy flacas y alargadas. Si a esto le unimos que el "hadoken" va muy rapido, podia darse el caso de que pasase al rival sin colisionarlo. Con las cajas de colision este problema quedo solucionado.
Title: Re: fast_collision
Post by: Drumpi on February 18, 2010, 01:41:31 PM
Quote from: SplinterGU on November 26, 2009, 11:26:00 PM
Quote from: PiXeL on November 26, 2009, 05:40:04 PM
He visto el código fuente, y creo que se podría mirar de mejorar la colisión que tenemos.
Por ejemplo, no comprobar procesos que, por el tamaño del gráfico, size, size_x, size_y y la posición de estos, es seguro que no colisionan. Eso mejorará el rendimiento en muchos casos, creo.

Pix, esos tipos de chequeos ya estan incorporados... y se evita hacer el calculo si los graficos no chocan por coordendas...

(..)

Pues no se hasta qué punto eso es verdad, o hasta dónde se ha hecho eficiente. En el primer boss del segundo nivel de "Echo" comprobaba los choques de los disparos con las naves por el clásico método de collision, y en cuanto metía 5 disparos, la negrita me escupía en la cara.
Cambiando el método a detectarlo por proximidad (resta de coordenadas), el juego va casi fluido al máximo. No se si es que primero tiene que hacer los cálculos de dónde están los pixels por angle, size y demás, pero collision sigue siendo una función lenta (más rápida que antes, igual de útil, pero a evitar en sistemas con pocos recursos ;D).
Title: Re: fast_collision
Post by: Windgate on February 18, 2010, 08:11:02 PM
La ineficiencia del uso de collision es bastante grave si no tenemos una CPU decente, p.ej. en la Wiz veo que has sentido el placer de ver lo que consume :D

En cuanto al juego de luchas, con capas, espadas largas, etc... A ver si alguien se anima a hacer un ejemplo, yo ando a full con el 2D y me da "pereza", pero sería curioso, entiendo que muchas partes de las que hablas (p.ej. la espada y la capa) deberían manejarse como procesos independientes que detectar o no colisión con otros procesos:

La capa ignora la espada enemiga
La espada ignora el puñetazo enemigo
El puñetazo ignora la capa enemiga...

Curioso, si alguien se anima a programarlo adelante ;D
Title: Re: fast_collision
Post by: DCelso on February 18, 2010, 08:31:13 PM
piedra, papel, tijera
Title: Re: fast_collision
Post by: Windgate on February 18, 2010, 10:12:34 PM
lol es cierto xD

Bueno, algún elemento más habrá, pero vamos, la idea es tener subprocesos gráficos y sólo detectar colisiones entre "algunos" de ellos.
Title: Re: fast_collision
Post by: DCelso on February 19, 2010, 02:28:28 AM
Pues entonces,
http://www.youtube.com/watch?v=S5eLybE03gc
Title: Re: fast_collision
Post by: SplinterGU on February 19, 2010, 05:20:08 AM
a ver... a ver...

genericamente, no hay sistema de colision mejor o peor... hay un sistema de colision mejor o peor para cada caso...

A saber, hay 3 tipos de colisiones basicas (o a mi se me ocurren ahora mismo):

1) las colisiones por cajas, que son colisiones cuadradas y son las mas simples y basicas, y lo logico es usarla para graficos sin rotacion (no es lo mismo que por proximidad), son muy rapidas pero poco precisas
2) colisiones circulares o por proximidad, estas van bien tanto en graficos con rotacion como sin rotacion. son medianamente rapidas, y con una precision intermedia en la mayoria de los casos o dependiendo de como las usemos.
3) colisiones precisas o por pixels, son costosas en cuanto a velocidad, pero muy perprecisas.

bien, nadie puede decir cual se usa en juegos profesionales y cuales no, las 3 se usan... y depende de la mania de cada programador o de la precision que busquemos en nuestra colision.

ahora si queremos buscar algo intermedio entre costo/precision, lo mas adecuado son las circulares.

PD: DCelso, estas fumado? :D o estas muy acelerado o yo estoy muy lento, no te estoy entendiendo... :P que quisiste decir con eso de pierda, papel o tijera?
Title: Re: fast_collision
Post by: Mr Matsusaka on February 19, 2010, 06:18:22 AM
Quote from: SplinterGU on February 19, 2010, 05:20:08 AM
bien, nadie puede decir cual se usa en juegos profesionales y cuales no, las 3 se usan... y depende de la mania de cada programador o de la precision que busquemos en nuestra colision.
Hombre, yo si me aventuraria a decir que las colisiones de un 99% porciento de juegos 2D estan hechos con colisiones por cajas. Porque? Pues sencillamente porque la era dorada de los juegos 2D acabo con la playstation y la saturn, y los juegos 2D que han salido desde entonces son pocos. Todos los juegos salidos anteriormente salieron para maquinas limitadisimas en hardware (SNES, megadrive, NES...) en las que sencllamente la colision por pixeles supondria un lujo que no se podrian permitir.

Incluso en la Saturn tenemos ejemplos de juegos 2D con colisiones por cajas, como el Guardian Heroes, que mediante un truco muestra las cajas de colision de todos los personajes. Cualquier juego de la Capcom o SNK (grandes exponentes en juegos donde se usan colisiones masivamente) usan colisiones por cajas. El MUGEN tambien usa cajas de colision.

Aparte de que la colision por cajas es mucho mas rapida, tiene la ventaja de que no hay que trocear a los personajes en distintos procesos (lo cual en ciertos juegos puede ser mucho trabajo), y la automatizacion es total: los golpes funcionaran siempre igual contra todos los enemigos. Nos ahorramos problemas y mucho trabajo.

Cualquier juego de lucha o de accion, a la velocidad que va, uno no ve si realmente los pixeles de un personaje se superponen sobre el otro cuando golpea. Sencillamente no se necesita de tanta precision porque el ojo humano no lo percibe. Tal vez en un simulador si se requiera de cierta precision para calculos internos, pero al menos yo, no conozco ningun simulador de vuelo en 2D.

En lenguajes tipo DIV si que se usan obviamente. Pero porque esta ahi y siempre sera mucho mas facil usar la funcion collision que hacerse la rutina de colision por cajas uno mismo, por muy sencilla que esta sea.
Title: Re: fast_collision
Post by: SplinterGU on February 19, 2010, 06:55:32 AM
te equivocas, la colision por pixel se usaba incluso en el viejo y amado zx spectrum... es mas, los juegos profesionales la usaban, los que usaban colisiones por cajas eran los menos profesionales, los hechos por aficionados o iniciados... he incluso, algunos de estos se atrevian a hacer colisiones por pixels.

te olvidas un pequeño detalle, antes no existian los modos de 16 o 32 bits... como sea, la colision por pixel no necesariamente tiene por que ser exageradamente lenta... es mas, la actual colision por pixels puede ser mejorada en performance... y mucho... pero bueno, es un tema pendiente que cuando tenga ganas y tiempo lo hago, pero bueno, el problema es que casi nunca coinciden, cuando tengo tiempo no tengo ganas y cuando tengo ganas no tengo tiempo...

creo que estamos mezclando muchas cosas... el conceptos de procesos en vez de sprites son solo de los lenguajes like div... te puedo asegurar que se usaba muchisimos colisiones por pixels (bits), tanto te lo puedo asegurar como que me pase gran parte de mi adolescencia desensamblando juegos y haciendo rutinas y mejorando rutinas para tratamientos de sprites, colisiones, etc.

repito, no se necesita hacer muchos calculos para la colision por pixels, si la programacion y los datos extra estan pensados teniendo en cuenta eso... si, es mas rapido por box, pero tampoco es la muerte una colision por "pixels", mas si tenemos en cuenta que se usaba con exito en una maquina de 3.5mhz...

EDIT: es cierto que en la mayoria de los casos no preocupa mucho si colisiona con una caja o no... pero te puedo asegurar que es muy feo perder tu ultima vida, a nada de finalizar el juego, por una colision por caja cuando ves claramente que el proyectil de paso por al lado y ni te toco... repito, depende del caso, pero no hay mejores o peores tipos de colision...
Title: Re: fast_collision
Post by: Mr Matsusaka on February 19, 2010, 08:20:08 AM
Quote from: SplinterGU on February 19, 2010, 06:55:32 AM
te equivocas, la colision por pixel se usaba incluso en el viejo y amado zx spectrum... es mas, los juegos profesionales la usaban, los que usaban colisiones por cajas eran los menos profesionales, los hechos por aficionados o iniciados... he incluso, algunos de estos se atrevian a hacer colisiones por pixels.
No tenia la menor idea de que en el Spectrum se hiciesen cosas asi. Ahi me has pillado. Sin embargo me parece un poco falaz declarar las colisiones por caja menos profesionales. Te parece menos profesional por ejemplo el Marvel VS Capcom por tener colisiones de cajas que un juego de Spectrum con colisiones por pixel?

El Spectrum era una maquina donde se experimentaba mucho, y una colision por pixel se me antoja mas a una virgueria de programacion que a una herramienta util para hacer juegos. En general los programadores del Spectrum eran grandes ingenieros informaticos, pero con muy poca idea de hacer videojuegos. No se si se entiende la diferencia...

Me equivoco al pensar que tras la epoca del Spectrum ya no se usaron mas las colisiones por pixeles en juegos profesionales?

Quote from: SplinterGU on February 19, 2010, 06:55:32 AMcreo que estamos mezclando muchas cosas... el conceptos de procesos en vez de sprites son solo de los lenguajes like div... te puedo asegurar que se usaba muchisimos colisiones por pixels (bits), tanto te lo puedo asegurar como que me pase gran parte de mi adolescencia desensamblando juegos y haciendo rutinas y mejorando rutinas para tratamientos de sprites, colisiones, etc.
No, si yo decia procesos porque estamos en un foro de un lenguaje Div-like, pero ahora que lo dices, en Bennu tener que partir a trozos los sprites es incluso peor que hacerlo en C o cualquier lenguaje de bajo nivel, porque para mostrar cada nuevo trozo estamos obligados a llamar a un proceso extra, con el consiguiente consumo de recursos. Que tampoco es para tanto, pero cuantos menos procesos innecesarios llamemos, menos bugs, menos problemas, menos trabajo...

Yo a lo que me referia en realidad, es al trabajo que nos cuesta a nosotros, no pretendia hablar de lenguajes de programacion. No deberiamos estar complicandonos la vida con trabajo que lo unico que hace es alargar el desarrollo mas y mas. La automatizacion que te da la colision por cajas, se convierte en un quebradero de cabeza con las colisiones por pixel. Eso si pretendes tener un juego bien acabado claro esta.

Con las cajas de colision no tienes que preocuparte del tamaño de sprite ni de nada. Artisticamente no estas limitado. No tienes que hacer ñapas del estilo de tener que cambiar un grafico determinado porque sino cierto combo no conecta bien.

Quote from: SplinterGU on February 19, 2010, 06:55:32 AM
repito, no se necesita hacer muchos calculos para la colision por pixels, si la programacion y los datos extra estan pensados teniendo en cuenta eso... si, es mas rapido por box, pero tampoco es la muerte una colision por "pixels", mas si tenemos en cuenta que se usaba con exito en una maquina de 3.5mhz...
Efectivamente no es la muerte. Pero sigue siendo mas lenta. Y nos obllga a partir y retocar graficos si la queremos tener bien implementada.

Quote from: SplinterGU on February 19, 2010, 06:55:32 AM
EDIT: es cierto que en la mayoria de los casos no preocupa mucho si colisiona con una caja o no... pero te puedo asegurar que es muy feo perder tu ultima vida, a nada de finalizar el juego, por una colision por caja cuando ves claramente que el proyectil de paso por al lado y ni te toco... repito, depende del caso, pero no hay mejores o peores tipos de colision...

Te pongo el ejemplo contrario. es muy feo perder tu ultima vida, a nada de finalizar el juego, por una colision por pixeles cuando ves que el proyectil toco solo la punta de la capa del personaje, que ademas estaba ondeando en el aire con lo que la bala nos mato cuando aun estaba a tomar por culo del cuerpo del personaje.

Si las cajas de colision estan bien definidas, no tiene porque haber ningun problema. Si has metido mal alguna coordenada y colisiona feo, solo tienes que cambiar un numero para corregirlo. Y lo arreglara para el resto de personajes que usen esas mismas coordenadas. En cambio para solucionar el tema de la capa, ya tienes que estar separandola en determinados frames, y si hay mas personajes con elementos largos tres cuartos de lo mismo.

Por cierto, me gustaria saber titulos de juegos con colisiones por pixeles. No es que no me lo crea, pero ya que estamos no viene mal documentarse y aprender algo nuevo.
Title: Re: fast_collision
Post by: SplinterGU on February 19, 2010, 03:41:27 PM
bien...

dije que en esa epoca los juegos que usaban colisiones por caja eran los menos profesionales, no dije que si usas colision por caja es un juego menos profesional... vengo diciendo que no hay mejor o peor y mas profesional o menos... depende de la necesidad que uno tenga.
Con respecto a que los que usaban la spectrum eran ingenieros con poca idea de videojuegos, en eso no estoy para nada de acuerdo, los mejores juegos de la historia se crearon en esa epoca y muchos de los mejores programadores que existieron de esa epoca eran compatriotas de Uds. A mi entender España fue una gran influencia en este sentido en aquella epoca, y no eran precisamente gente con pocas ideas.

Si bien Bennu tiene procesos, y obviamente consume mas que lo mismo hecho en C, el problema de consumo real no esta realmente en el procesamiento, sino en el dibujado en pantalla... por eso, un test de un juego hecho en C y un juego hecho en Bennu, no dista mucho la performance... por supuesto, hablando siempre de render por software... hay pruebas que lo demuestran...

por otra parte, hacer lo mismo en bennu significa menos trabajo comparado con C u otros lenguajes... por eso cualquiera sin conocimientos de programacion puede hacer un juego en bennu...

creo que nuevamente te equivocas, es mas simple hacer un colision que ir comparando por cajas donde colisiona, no entiendo cual es el quebradero de cabezas o el trabajo extra... colision es una sola funcion...

nop, no tendrias que partir graficos ni retocar graficos, todo se puede hacer internamente en el motor...

ah, y me vas a decir que por colision por cajas no va a tocar la capa? por otra parte, hablando de bennu, la capa si no colisiona deberia ser otro proceso... y hablando de cualquier otro lenguaje, a nivel pixel, la capa no deberia ser parte de la mascara de colision...

jejeje... es que aun no te lo crees...

como sea, lo importante es que todo depende de lo que necesitamos y como lo implementamos.

EDIT: agrego un dato mas, ante si se sabia hacer juegos, explotar recursos y sacarle provecho hasta la ultima optimizacion de codigo... ahora lo programadores actuales saben mas que nada usar SDKs...
Title: Re: fast_collision
Post by: Drumpi on February 19, 2010, 05:34:02 PM
Depende qué compañía y qué máquina, es capaz de exprimir recursos o no: RARE exprimió al máximo la N64, y de NES sacó oro sin usar SDK.

De todas formas, la colisión por cajas es el sistema más usado. Aun recuerdo esa última parte del Battletoad In Battlemaniacs de SNES, porque en ocasiones los misiles explotaban sin tocar a la nave.
Es muy probable que en épocas de Spectrum y demás se usase colisión por pixel, más que nada porque la parte gráfica se ligaba mucho más al resto del código que hoy día, dada la limitación de recursos. Como había que pintar un pixel del personaje, de paso, comprobaban si colisionaba. Ahora son como dos o tres pasos: comprobar la posición, comprobar colisiones, ordenar las z y dibujar, lo cual es mucho menos eficiente.

De todas formas, en un juego de lucha es mejor usar colision box, sobre todo si queremos usar sprites realistas, sin trozos. Tened en cuenta que un golpe sólo va a impactar contra el cuerpo, la cabeza y/o las piernas, que suelen estar en la misma vertical, en el centro del personaje +/- unos pocos pixels. Las capas al viento y los brazos estirados nunca he visto que hicieran perder energía al ser golpeados.

Es más, usar collision box y poder añadirle un ángulo es más que suficiente para hacer un buen juego, la diferencia es imperceptible salvo que vayas a menos de 10fps. Es más, implementando eso, y pudiéndolo ubicar en puntos de control de los mapas ya se puede hacer cualquier juego de lucha.

Lo raro es que no haya salido Momia, porque en juegos de lucha y colisiones de este tipo es el que más experiencia tiene.
Title: Re: fast_collision
Post by: La momia que fuma on February 19, 2010, 07:10:37 PM
Quote from: Drumpi on February 19, 2010, 05:34:02 PMLo raro es que no haya salido Momia, porque en juegos de lucha y colisiones de este tipo es el que más experiencia tiene.

Si Mr Matsusaka, como yo sospecho, es el viejo Neolok, creador del Total Devastation, Hardcore Fight y KOF Flames of courage (me equivoco? :P) por ahi andamos de experiencia, de hecho el tendrá más que yo xD

En mi caso yo pase de las cajas de colision y usaba graficos aparte con la parte que golpeaba del personaje (brazo, pierna, etc). 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), aunque supongo que sería mas o menos solucionable ajustando el efecto retroceso al golpear al rival en la esquina o algo asi...el proyecto aun está abandonado.

No me decidí por cajas de colisión al ser estas cuadradas, tenía miedo de que en futuros personajes con golpes especiales de graficos grandes y en diagonal, estos conectasen sin tocar al rival (O incluso en patadas normales altas, tenía miedo de englobarlo en una caja y que el golpe conectase con una esquina gráficamente vacía de esta), pero en lo poco que dejé hecho podría haber funcionado con cajas sin que se notase la diferencia.

Creo que los Mortal Kombat 2D, algunos al menos, usaban el mismo sistema (Aunque los MK siempre me parecieron una boñiga de marca mayor, pero bueno xDDD)

Quote from: SplinterGU on February 19, 2010, 03:41:27 PM
Con respecto a que los que usaban la spectrum eran ingenieros con poca idea de videojuegos, en eso no estoy para nada de acuerdo, los mejores juegos de la historia se crearon en esa epoca

Bueno, bueno, en esa época habia maravillas, si, pero había que rebuscar bastante entre millones de bazofias injugables (más o menos como en el catálogo de la Wii xDDDDDD)

Lo que si que es cierto es que aquí en españa eramos la leche :)
Title: Re: fast_collision
Post by: BoMbErLiNk on February 19, 2010, 08:53:29 PM
Yo he usado hibridos entre colisiones a precisión de pixel, zonas concretas de impacto (multiples puntos de control) y cajas de colisión, y creo que cada una es buena en momentos dados, uso las 3 realmente, incluso se pueden setear desde opciones  ;D.

A mi de poco me sirve hacer una colisión a precisión de pixel en un grafico con perspectiva, un muro, le vas a dar a la punta, al centro y a la otra esquina, o por ejemplo, los ataques basados en energia, a veces chocas con la onda invisible que provoca el movimiento y no necesariamente con el sprite en si, o el peor de los casos rozas el pelo del personaje, el sombrero o el arma y te los cargas  :P.

Lo mismo para la zona rectangular de impacto, no contempla las areas invisibles del grafico, y todo lo que sea pequeño resulta raro, un misil chocará mucho antes de tocarte realmente.

Y sin embargo en los mejores juegos tecnicamente de la era 16 bits en los ataques generalmente no llegas a tocar el personaje para golpearlo, si quitas esta constante lejos de mejorar la experiencia del juego con precisión la empeoras porque algunos ataques estan diseñados de una forma visual atractiva pero que dificilmente chocaria con el otro personaje de no tener una caja más grande
Title: Re: fast_collision
Post by: SplinterGU on February 19, 2010, 09:26:03 PM
exacto, por eso digo que no hay mejor o peor sistema, todos dependen del caso en particular... o el tipo de juegos... en juegos suaves es evidente que lo mejor sea por pixels, en juegos donde la velocidad es un factor importante, obviamente va mejor por cajas o el de proximidad...
Title: Re: fast_collision
Post by: DCelso on February 19, 2010, 10:29:58 PM
pues vamos a ver, en spectrum y sistemas antiguos uan de  las técnica más usadas era detección de colisión por máscara.
Una máscara es una imagen igual que la del sprite pero solo en blanco y negro, donde el blanco representa que no hay colisión y el negro que sí la hay. Pruebas de eso las podemos ver con un programa buscador de sprites en roms, siempre vemos dos veces el sprite, una vez con detalle, el sprite en sí y otra vez en sombra, la máscara. Fijaos por ejemplo en emuzwin, que trae un editor de gráficos para adaptar los juegos a 256 colores y vereis que siempre se ve el sprite y al lado su máscara.
Las tres técnicas que conozco yo son esas:
1.- colision por cajas. En estas hay dos formas distintas de hacerlo, un sprite tiene una sola caja que lo contiene, lo más facil de hacer, el tamaño de la imagen. Y otra más avanzada como en mugen que cada sprite tiene dos listas de cajas, cajas en las que el sprite recibe daño (pej cuerpo, manos, piernas) y cajas en las que el sprite hace daño (espada, puño, arma, pie), las cajas pueden solaparse por lo que puede haber regiones en las que hagas daño y a la vez recibas daño, esta técnica será más precisa y ala vez más lenta cuantas más cajas y más pequeñas le pongas al siprte, así que siempre se tiene que llegar a un compromiso intermedio :D
2. colisión por máscara, esta la facil es solo tener una máscara por sprite y la dificil es tener dos máscaras por sprite, una para saber donde recibe daño y otra para saber donde hace daño.
3.- colixión perfecta por pixel, parecida a la máscara pero más compleja porque no puedes hacer lógica símple de and, or, xor como con las máscaras. tienes que hacer condicionales y dependiendo del color hacer o no hacer daño.

Lo suyo sería que se pudieran hacer las tres, con parámetros adicionales al collision por ejemplo, if collision(type enemigo, USING_BOX) o USING_PIXEL_PERFECT, o USING_MASK.

En cuanto a piedra papel tijera, ha sído un símil a lo que comentaba windgate de la espada ignora la capa, la capa ignora la mano, etc
se parece a piedra gana a tijera, tijera gana a papel, etc.

Title: Re: fast_collision
Post by: SplinterGU on February 20, 2010, 12:32:17 AM
exacto!

yo no queria dar pistas de las mascaras... para no dar ideas a otros... shit! pero ya lo habia mencionado tiempo atras...

claro, la mascara es el mismo grafico pero solo representados por 1 y 0, con lo que con un par de rotaciones y un and a nivel bit esta resuelto el tema, con esto, con un int (de bennu) podes controlar colision con 32 pixels a la vez...

pero wait... colision por mascara es lo mismo que colision por pixels, solo cambia la granularidad no son cosas diferentes... por mascara es lo mismo que hacer una colision con graficos de 1bit.

eso que mencionas del editor de 256 colores es otra cosa... pero si, a grandes rasgos es lo mismo...

esa numero 3 que describis dependiente del color, no es la que se usa en bennu, y no deja de ser una por mascara, pero mascaras mas compleja... la colision por pixels de bennu termina haciendose un AND aunque no a nivel bit... como sea, conceptualmente es lo mismo...

la optimizacion, que se podria hacer a la actual colision de pixel seria crear dinamicamente la mascara con solo 2 colores... seria pixels transparentes bit 0, pixels no transparentes bit 1...

maldito DCelso ( :D ) me arruinaste la futura sorpresa!
Title: Re: fast_collision
Post by: Mr Matsusaka on February 20, 2010, 02:36:21 AM
Quote from: SplinterGU on February 19, 2010, 03:41:27 PM
Con respecto a que los que usaban la spectrum eran ingenieros con poca idea de videojuegos, en eso no estoy para nada de acuerdo, los mejores juegos de la historia se crearon en esa epoca.

Muy pocos, muymuymuy pocos juegos del Spectrum pasarian los test de calidad que se vienen haciendo desde entonces en el mundo de las consolas. Los programadores del Spectrum por regla general, tenian muy poca idea de diseño de videojuegos.

Por ejemplo, en el Phantomas 2, un enemigo podia aparecer aleatoriamente justo al lado tuyo, restandote vida por el mero hecho de comenzar la partida XD En los Saboteur nunca llegue a entender como funcionaba el combate. Nunca sabes si estas golpeando al enemigo o no. Puedes pasarte el rato pensando que le estas machacando la cabeza al enemigo hasta que te eliminan a ti XD La dificultad de muchos juegos del Spectrum venia dada por detalles asi.

Eso si, no niego que habia algunos juegos maravillosos dentro de tal caos de programacion de garage. incluso con defectos de diseño un juego puede acabar por ser divertido, pero desde luego profesional muy poco.

Quote from: SplinterGU on February 19, 2010, 03:41:27 PM
por eso, un test de un juego hecho en C y un juego hecho en Bennu, no dista mucho la performance...

Es bueno saberlo.

De todos modos mi punto es que un proyecto siempre ira mas rapido en su desarrollo sino tenemos que estar recortando graficos, llamando procesos y limando los bugs que puedan eventualmente salir.

Quote from: SplinterGU on February 19, 2010, 03:41:27 PM
creo que nuevamente te equivocas, es mas simple hacer un colision que ir comparando por cajas donde colisiona, no entiendo cual es el quebradero de cabezas o el trabajo extra...

Es justo lo que he dicho antes.

Escribirse una rutina de colision de cajas se tarda un ratito. Correguir bugs que puean salir y terminar de pulirlo otro ratito. Pero una vez escrita y funcionando ya no tienes que tocar mas. En cambio con la colision de pixeles tendras que arreglar sprites cada vez que metas un enemigo y determinado movimiento no encaje bien por su diseño.

Quote from: SplinterGU on February 19, 2010, 03:41:27 PM
ah, y me vas a decir que por colision por cajas no va a tocar la capa? por otra parte, hablando de bennu, la capa si no colisiona deberia ser otro proceso... y hablando de cualquier otro lenguaje, a nivel pixel, la capa no deberia ser parte de la mascara de colision...

jejeje... es que aun no te lo crees...

A lo mejor es que no me he explicado bien. Las coordenadas de caja de colision no tiene necesariamente porque venir definida por el rectangulo que define el grafico. Las puedes definir tu mismo en un array.

Por poner un ejemplo. En un juego de lucha, te basta con tres cajas de colision para todo un personaje. Las cordenadas para una caja para los estado en el que el personaje esta de pie, las coordenadas para todos los estado en el que el personaje esta agachado, y una caja para cuando el personaje esta en el aire.

Se puede hacer mas complejo pero en principio y a nivel amateur algo asi es suficiente y te vale para todos los personajes que tengan un tamaño similar, lleven capa, lanza o lo que sea. Que tienes un personaje muy grande? Le añades una dimension al array y añades tres cajas para personajes grandes. Idem para personajes muy pequeños.

Quote from: SplinterGU on February 19, 2010, 03:41:27 PM
EDIT: agrego un dato mas, ante si se sabia hacer juegos, explotar recursos y sacarle provecho hasta la ultima optimizacion de codigo... ahora lo programadores actuales saben mas que nada usar SDKs...

Claro, por eso ahora los puesto de trabajo en los videojuegos estan diferenciados entre "ingeniero informatico" y "programador de videojuegos" XD El programador de videojuegos no tiene porque saber como esta hecho el motor, le basta con saber utilizarlo.

Quote from: La momia que fuma
Si Mr Matsusaka, como yo sospecho, es el viejo Neolok, creador del Total Devastation, Hardcore Fight y KOF Flames of courage (me equivoco? Tongue) por ahi andamos de experiencia, de hecho el tendrá más que yo xD

El mismo que viste y calza. Para servirle a usted :D

Quote from: La momia que fuma
No me decidí por cajas de colisión al ser estas cuadradas, tenía miedo de que en futuros personajes con golpes especiales de graficos grandes y en diagonal, estos conectasen sin tocar al rival.

Ya te pasare la ultima version del Total cuando lo tenga a mano y ya veras que no hay dferencia a la hora de jugar. Y a mi me ha ahorrado muchos quebraderos de cabeza

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.
Title: Re: fast_collision
Post by: SplinterGU on February 20, 2010, 03:10:16 AM
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.
Title: Re: fast_collision
Post by: SplinterGU on February 20, 2010, 03:14:07 AM
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.
Title: Re: fast_collision
Post by: DCelso on February 20, 2010, 07:06:15 AM
 ;D. SplinterGU, sorry.
Title: Re: fast_collision
Post by: Drumpi on February 20, 2010, 01:48:45 PM
¿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
Title: Re: fast_collision
Post by: 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...

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.
Title: Re: fast_collision
Post by: La momia que fuma on February 20, 2010, 03:37:46 PM
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.
Title: Re: fast_collision
Post by: Mr Matsusaka on February 20, 2010, 04:03:26 PM
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.
Title: Re: fast_collision
Post by: Mr Matsusaka on February 20, 2010, 04:16:01 PM
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.
Title: Re: fast_collision
Post by: SplinterGU on February 20, 2010, 09:13:04 PM
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.
Title: Re: fast_collision
Post by: Drumpi on February 21, 2010, 01:12:24 AM
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
Title: Re: fast_collision
Post by: SplinterGU on February 21, 2010, 01:32:34 AM
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...

Title: Re: fast_collision
Post by: Mr Matsusaka on February 21, 2010, 02:21:15 AM
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?
Title: Re: fast_collision
Post by: Mr Matsusaka on February 21, 2010, 02:33:53 AM
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.
Title: Re: fast_collision
Post by: SplinterGU on February 21, 2010, 03:19:59 AM
jejeje, "TIP MODE" es "MODO CONSEJO"... una estupides...
Title: Re: fast_collision
Post by: SplinterGU on February 21, 2010, 03:22:30 AM
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...
Title: Re: fast_collision
Post by: BoMbErLiNk on February 21, 2010, 04:11:10 AM
Quote from: Mr Matsusaka on February 20, 2010, 04:03:26 PM
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
Title: Re: fast_collision
Post by: Mr Matsusaka on February 21, 2010, 04:54:27 AM
Quote from: BoMbErLiNk on February 21, 2010, 04:11:10 AM
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.
Title: Re: fast_collision
Post by: SplinterGU on February 21, 2010, 05:34:15 AM
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...
Title: Re: fast_collision
Post by: Mr Matsusaka on February 21, 2010, 06:07:15 AM
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.
Title: Re: fast_collision
Post by: SplinterGU on February 21, 2010, 06:48:17 AM
entonces toda la charla que venimos teniendo desde hace unos dias fue inutil? nunca hablaste de prioridades de procesos? yo juraria que si...
Title: Re: fast_collision
Post by: Mr Matsusaka on February 21, 2010, 07:17:22 AM
Quote from: SplinterGU on February 21, 2010, 06:48:17 AM
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.

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

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

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

Espero que haya quedado clarito ya ;D
Title: Re: fast_collision
Post by: BoMbErLiNk on February 21, 2010, 08:04:17 AM
Quote from: Mr Matsusaka on February 21, 2010, 04:54:27 AM
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
Title: Re: fast_collision
Post by: SplinterGU on February 21, 2010, 08:45:05 AM
Quote from: Mr Matsusaka on February 21, 2010, 06:07:15 AM
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...

Title: Re: fast_collision
Post by: DCelso on February 21, 2010, 12:18:15 PM
Quote from: SplinterGU on February 21, 2010, 03:22:30 AM
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.
Title: Re: fast_collision
Post by: Mr Matsusaka on February 21, 2010, 05:05:42 PM
Quote from: SplinterGU on February 21, 2010, 08:45:05 AM
Quote from: Mr Matsusaka on February 21, 2010, 06:07:15 AM
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:

QuoteCuando 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

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

no es igual a

QuoteCuando 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:

Quoteno 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

Quotesencillamente 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.
Title: Re: fast_collision
Post by: FreeYourMind on February 21, 2010, 05:33:11 PM
No he entendido nada  ;D (que es broma hombre!  :-*)
Title: Re: fast_collision
Post by: SplinterGU on February 21, 2010, 06:45:31 PM
Quote from: DCelso on February 21, 2010, 12:18:15 PM
Quote from: SplinterGU on February 21, 2010, 03:22:30 AM
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...
Title: Re: fast_collision
Post by: Mr Matsusaka on February 21, 2010, 11:50:48 PM
Quote from: SplinterGU on February 21, 2010, 06:45:31 PMMr 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!

Quote from: SplinterGU on February 21, 2010, 05:34:15 AMlo 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...

Quote from: SplinterGU on February 21, 2010, 06:45:31 PMa 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.

Quote from: SplinterGU on February 21, 2010, 06:45:31 PMlo 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?

Quote from: SplinterGU on February 21, 2010, 06:45:31 PMpero 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.

Quote from: SplinterGU on February 21, 2010, 06:45:31 PMsinceramente 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.

Quote
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.
Title: Re: fast_collision
Post by: SplinterGU on February 22, 2010, 12:24:54 AM
ok...