Resolver lógica del colisión con mapa de durezas

[alicesimu]

Buenas a todos,

A ver si alguien me echa un cable para resolver la lógica para programar la detención de paredes solidos y que el personaje no pase de esa pared.

Mi situación es un juego que funciona en una grilla de 32x32 píxels por cuadro.

Tengo un mapa de 10x10 cuadros, equivalente a
10 x 32 = 320pix de ancho y alto. Es un mapa de 10x10 cuadros = 320x320 pix.

Uso un mapa de durezas de 10x10pix
Uso el color blanco RGB(255,255,255); para representar bloques solidos.

Esos bloques son de 32x32 pix, un cubo.

El color negro es vacío, paso libre.

Para programar ese proceso que se desplaza a 2pix x frame, en 4 direcciones.

Al moverse debería comprobar si el siguiente (el que tiene delante)cuadro del mapa de durezas 10x10 existe color blanco, de ser cierto se reposiciona a una coordenada anterior.

Parece sencillo pero no me acaba de ir bien solo en la paredes; superior y izquierda.
En cambio las paredes; inferior y derecha si funcionan perfectamente.

X32=X/32;Y32=Y/32;
Con esto sabremos en que casilla estamos en el mapa de durezas.

Que sabéis? Algún ejemplo de juego en cuadricula por mapa de durezas.

[DCelso]

pues debería de ir, es así de facil o de dificil,
Hay dos opciones

Metodo 1:

guardas x e y del proceso en dos variables
cambias x e y a la nueva posición
haces map get pixel del x/32 e y/32 de tu proceso y miras que color es.
si es color de dureza
cambias x e y al valor antiguo. si no, todo ok.

Metodo 2:
creas variables x nueva e y nueva.
escribe en ellas la nueva posición a la que quieres ir.
haces map get pixeld de xnueva/32 e ynueva/32 y miras que color es
si no es color de  dureza entonces
cambias x e y a los valores nuevos x nueva e y nueva
si no no haces nada.

Usa el que mas coraje te de, pero esto tiene que ir siempre.

NOTA: si no pones puntos de control a tus procesos, se usará el centro de tu proceso para la comprobación. asi que puede que necesites corregir los puntos de control a la posición del medio de los pies del personaje para que quede mejor

[alicesimu]

Asi es la logica mas sencilla que se entiende ,como me has explicado.

la cuestion es que es un juego de grilla de 32x32pixeles, cada cuadrado.
el personaje se mueve a 2 pixeles por fotograma.

las cordenadas del personaje, las tengo que dividir en 32...

X32=X/32;Y32=Y/32;

asi sabre en que casilla esta.
gracias a eso, se en que posicion dela grilla del mapa de durezas esta.

Supongamos que estamos en las cordenadas X=32 y Y=32 del personaje
en la grilla le corresponde X=1 y Y=1
Eso es correcto...

El problema lo tengo cuando el personaje se mueve 2pix por fotograma, con sus graphs de animacion...
esto seria... en cada fotograma de juego

cursiva= casilla 1
Negrita= casilla 2

32 -> 34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64

Para llegar hasta la casilla X=2 , tendria ser valido, en coordenadas del proceso sobre => X=48
ya que si dividimos 48/32= 1,5 ... la variable es tipo INT, asi que se redondea a 2.
el calculo es correcto.

la cordenada X=64 seria el punto exacto, de la casilla 2 de pleno 100%. Esta claro.

LA cuestion es....
En que momento hay que hacer la comprobacion de la pared solida en el mapa de durezas, que esta dividido a 32 sus dimensiones del mapa real de juego.
Si lo hago constantemente fotograma x forograma, cuando el personaje se mueva este por encima de => 48pix... lo considera la casilla 2 y ya me esta mirando si comprueba la siguiente casilla 3, si hay pared.
de ser cierto, me reposiciona en la casilla ajustada del numero 2, es decir 2*32=64 me pondria de coordenadas al personaje.

El efecto es que "parece" que la pared te atraiga a los 16pixeles del personaje, como si fuese un iman... las coordenadas de reposicion son coorrectas,si.

pero cuando nuestro personaje pasa del 48pix .... hace ese efecto de reposicionamiento, sin aun haber llegado a la coordenada 64 de forma natural... eso esta mal...

el problema lo tengo en 2 sitios: el momento a comprobar la pared y la reposicion de coordenadas en el punto exsacto.

me hago un lio, QUIEN debe comprobar la pared, y cuando reposicionar.

Es tan sencillo como hacer un juego de Bomberman
https://www.youtube.com/embed/xlp_M92ri-U

jajajaj aparentemente sencillo, me siento tan estupida a veces  :-[ :-[ :-[

[DCelso]

hazlo en el loop del jugador y tal cual te puse anteriormente.
no hay que reposicionar nada solo juegas frame a frame con la posicion en la que está actualmente tu proceso y con la que va a ir. usando por ejemplo el método 2 que puse. quedaría asi:

Code Select Expand


process jugador()
private
  xnueva;
  ynueva;
begin
   loop
    xnueva = x;
    ynueva = y;
    if key(_up) ynueva= ynueva - 2; end
    if key(_down) ynueva= ynueva + 2; end
    if key(_left) xnueva= xnueva - 2; end
    if key(_rigth) xnueva= xnueva + 2; end
    if (map_gep_pixel(0,id_durezas,xnueva/32,ynueva/32) <> rgb (0,0,0))
     x = xnueva;
     y = ynueva;
    end
    frame;
   end
end


Listo calisto si intentas avanzar y es negro, no avanza, x e y valen lo que vaían antes.
si no es negro avanza en lo que hayas tocado de teclado, x e y valdrán xnueva e ynueva, el código pasa por todos los if, así que puedes hacer diagonales pulsando dos teclas.

[alicesimu]

aaaaaaaahh

es justo al revés que yo hacía, y me hacía una picha un liooo  :o ::) ::) :P :P

lo pondre en practica, graciaass!!

[DCelso]

Si te refieres con lo del revés a comprobar a posteriori, .., también debería de ir y sin efecto de movimiento
Hay gente que le gusta mas comprobar despues de mover que antes de mover. Ambas sirven igual,
a mi la de comprobar despues me parece un poco más liosa de entender y necesita de una asignación adicional por eso no la uso.

Code Select Expand


process jugador()
private
  xanterior;
  yanterior;
begin
   xanterior = x;
   yanterior = y;
   loop
    if (map_gep_pixel(0,id_durezas,x/32,y/32) == rgb (0,0,0))
     x = xanterior;
     y = yanterior;
    end
    if key(_up) y= y - 2; end
    if key(_down) y= y + 2; end
    if key(_left) x= x - 2; end
    if key(_rigth) x= x + 2; end
    frame;
   end
end


[Yawin]

Ten cuidado con el efecto tunel. Este efecto se produce cuando un objeto se desplaza tan rápido que de un paso al siguiente hay más distancia recorrida que anchura de la pared.

Si no vas a cambiar velocidades ni anchuras no hay problema, peor a nada que quieras cambiar algo puede darte problemas.

[alicesimu]

Graciass investigare cual se adapta mejor a mi sistema,pero vaya soy bastante flexible.

pero me has dado una idea que es mucho mejor, con el primer mini codigo.


Lo del efecto tune, ya lo tube en algun antiguo proyecto, un juego de plataformas, y para prevenirlo tenia que comprobar mas minuciosamente esos pixeles, cuando la velocidad la supera x frame. es tan sencillo como añadir un bucle tipo repeat until... hasta que....
lo malo que tiene un costo de CPU adicional comprobar mas pixeles en un mismo fotograma de juego.
contra mas velocidad/distancia, mas pixeles a comprobar, mas costo cpu...