fast_collision

[DCelso]

piedra, papel, tijera

[Windgate]

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.

[DCelso]

Pues entonces,
http://www.youtube.com/watch?v=S5eLybE03gc

[SplinterGU]

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?

[Mr Matsusaka]

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.

[SplinterGU]

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

[Mr Matsusaka]

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?

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.

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.

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.

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.

[SplinterGU]

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

[Drumpi]

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.

[La momia que fuma]

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.

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)

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

[BoMbErLiNk]

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

[SplinterGU]

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

[DCelso]

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.

[SplinterGU]

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!

[Mr Matsusaka]

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.

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.

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.

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.

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.

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

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

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.