Karoshi MSX Community

Estaba acabando de pulir la gestión de movimientos del personaje en mi juego de plataformas, y me ha surgido la duda sobre opciones para los saltos y caidas. Lo que he hecho (y sobre lo que leí creo que en estos foros) es lo siguiente. Tengo una tabla de saltos/caidas del estilo de la siguiente:


Cada posición indica lo que tengo que sumar o restar a la coordenada Y del jugador. Es decir, en cada iteración del bucle principal hago algo tal que


Cuando el personaje va a saltar, inicio index a 0. I cuando empieza a caer, lo inicio a 15.

¿Que otras técnicas usáis vosotros?

Por otro lado, para el control del personaje me decidí por una máquina de estados (o Autómata Finito Determinista, Nerlaska ;-), y es bastante cómoda.

Saludos

Si al final te harás un crack ;-)

Lo de los saltos .. hombre .. puedes montarlo restando un tiempo o hasta colisión (en la subida) y restando hasta colisión (en la bajada) sin necesitad de tablas.
Algo más o menos de la siguiente manera .. teniendo en cuenta que tienes 2 estados .. el de SALTANDO (JUMPING) y el de caida (FALLING) ...

switch (player.state)
{
    ....

   case PLAYER_STATE_JUMPING:
   {
      if (jump_timer > 0 && Player_Up_Collision () ==  false)
      {
         jump_timer--;
         player.y -= PLAYER_JUMP_SPEED;
      }
      else
      {
         player.state = PLAYER_STATE_FALLING;
         player.frame = PLAYER_FRAME_FALLING;
      }
   }
   break;
   case PLAYER_FALLING:
   {
       if (Player_Down_Collision () == false)
       {
          player.y += PLAYER_JUMP_SPEED;
       }
       else
       {
          player.state = PLAYER_STATE_QUIET;
          player.frame = PLAYER_FRAME_QUIET;
       }
   }
   break;
}

Algo así más o menos :-)

Yes. De momento tengo cuatro estados: andando, saltando, cayendo y esperando. Este último es, simplemente, un estado de espera entre los saltos. Más adelante deberé añadir el estado de subir escaleras.

De todas formas, el código que propones salta y cae a velocidad constante. Yo estaba hablando de tener una velocidad no constante: que a la subida vaya frenando poco a poco y a la bajada vaya acelerando. Esto es lo que consigo con la tabla anterior.

Si bueno .. porque la velocidad es constante .. pero puedes tener una variable aceleración/deceleración y te sirve igual.

Pues a mi me gustaria ayudarte

Para realizar lo que estas diciendo tan solo tienes que aplicar la formula del tiro parabolico en el eje "y", y aplicar el movimiento rectilineo y uniforme en el eje "x". Esto siginifica que tendras un momiento acelerado en el eje "y" y un movimiento con velocidad constante en el eje "x".

la formula para el movimiento parabolico es

y=yo+vo*t+1/2*a*t^2

donde "yo" seria la posicion "y" del personaje en ese momento (que se podría eliminar si realizas una tabla de movimientos relativos, tal como propones)

"vo" seria la velocidad del impulso del muñeco al iniciar el salto que seria constante a elegir por ti

y "a" seria la aceleracion que la tierra ejerce sobre el muñeco (9.8 m/s^2) que tambien es constante, por lo que te quedaria la ecuacion del siguiente modo

y=vo*t+4.9*t^2

en esta formula dando valores a t, que seria el tiempo, obtendras diferentes valores de y, que serian los valores que deberias incluir en la tabla (db valor1, valor2, valor3, etc) cuantos mas valores incluyas y cuantos mas cercan esten unos valores (de t me refiero) de otros mas suave sera el movimiento, conseguiras el efecto de un salto parabolico acelerado.

y respecto al movimiento en el eje "x", se podria hacer simplemente sumando siempre un mismo valor constante, puesto que el movimiento es a velocidad constante, si deseases tambien incluir aceleracion en este eje, se podría volver a aplicar la formula del tiro parabolico.

Creo que con este metodo puedes conseguir un efecto mas realista para el movimiento de tu programa.

Espero que mi propuesta sirva para ayudarte en algo, y creo que con tan solo una tabla puedes conseguir el efecto de aceleracion que deseas.

Un saludo.

Ese es más o menos el criterio que seguí en el "Caverns of Titan"; por aquello de no complicarme mucho utilicé una tabla de salto fija como la que se describe, la diferencia es que ya que la amplitud del salto no superaba (no debía) los 20 píxeles no me compliqué la vida y use los valores del seno, que no describen un salto real; pero para el caso daban el pego.
El mejor modelo que se puede usar es el cálculo en tiempo real, tal como explica Nerlaska, utilizando aceleración y aritmética de coma fija; si no recuerdo mal, en el Pong512 de Sapphire hay un buen ejemplo del uso de esta última técnica.

...pero te puedes ahorrar la variable t, tiempo, dado que estás realizando los cálculos en tiempo real.

Por ejemplo, defines una velocidad de caída inicial de VY=1.

Y en tanto se mantenga el estado caída, puedes hacer VY=VY+0.02 (ajústalo según tus intereses). También puedes establecer un máximo de velocidad de caída (una velocidad terminal, como sucede en las caídas reales), tipo IF VY>2.5 THEN VY=2.5

Este no es un mal modelo, ya que la caída es un movimiento con aceleración constante (g=9,8). Por lo tanto, el incremento de la velocidad será lineal y función del tiempo, esto es, una integral de la aceleración. Por lo tanto, Vt+1=Vt+k. Sólo te hace falta ajustar los valores a la escala del juego.

Después, claro está, Y=Y+VY.

No es muy complicado, pero tienes que implementarlo todo utilizando aritmética de punto fijo (es lo más cómodo). Afortunadamente, para esto se incluyó el soporte de punto fijo en el ensamblador asMSX, que es mucho más rápido que utilizar punto flotante y funciones aritméticas complejas. Es decir, puedes hacer cosas hermosas como

INCREMENTO_VELOCIDAD_CAIDA: dw fix(0.25)

Que sería equivalente a dw 0040h

Simplemente indicar que en el Pong512 sólo trabajo con la posición X,Y de la bola y el vector velocidad. No hay una aceleración tal cual, simplemente que el vector velocidad ve incrementado su módulo (y modificada su dirección) cada vez que la pelota incide en uno de los bates hasta una velocidad máxima.

El caso es que da el pego ;D ;D

Pues yo, en mi caso, la mismita que tu  ;). Un puntero que avanza sobre unos valores positivos/negativos en una lista que se suman a Y.

Sapph , pero di que me copiaste la idea en esa Ru de Murcia  :D. El caso es que despues la mejoraste bastante simplificando la tabla de modulos para que cupiese en 1024bytes! Yo creo que incluso podrias haberle incluido FX y música a ese pong, alguna variación en los gráficos (*)... en fin una lástima  ;D ...

(*) Ponle el Cheat Jon!! ;D

Que lo pongo!, eh?.. Que lo pongo!  :D :D :D :D

A ver que me aclare... usando aritmética en punto fijo, y, por ejemplo, haciendo vy=vy+0.02 y, claro, y=y+vy, tendré vy (y por lo tanto, y) con decimales. Obviamente habrá que redondear al final, para no perder precisión que para este caso es crítica. Esto provocará que, por el redondeo, los valores que pueda tener "y" sean del estilo 10,11,11,12,12,12,12,... donde el primer once, por ejemplo, se corresponde al redondeo de 11.1, el segundo al redondeo de 11.9 y así. ¿Correcto?

Esto es equivalente a tener una tabla de incrementos del estilo 0,1,0,1,0,0,0. Ya digo, quizás los números de ejemplo que he puesto no son muy buenos pero la idea se pilla, ¿no?

Entonces no hace falta usar aritmética en punto fijo ni nada. Se precalculan los valores de incrementos ya redondeados y listos. Claro, si se supone que la velocidad de caida puede crecer indefinidamente puede resultar una tabla de salto muy grande. Pero, como comenta robsy, hay una velocidad máxima de caida.

No se si me he explicado. Quiero decir que no veo la ventaja de hacer los cálculos on-line con las fórmulas y aritmética en punto fijo respecto a tener una tabla precalculada de velocidades ya redondeadas.

WYZ, claro que sí. Te pregunté cómo lo hacías tú y me pasaste una tabla que luego optimicé lo más que pude para que resultase lo más pequeñita posible. Aún hay unos 19 bytes libres... ¿alguna sugerencia?

(*) CHEAT, CHEAT! CHEAT! cmptr:) :whip:

Correcto, solo que el redondeo no es necesario ya que en el byte superior tienes la parte entera y en el inferior la parte decimal (número de doscientos cincuentaavos de entero).


Exacto. Los incrementos estarán en forma de dos bytes: uno para la parte entera y otro para la parte decimal, claro que puedes ahorrarte los bytes de la parte entera si todos los incrementos son decimales... ::) de qué me suena eso... ::)


¿Quién ha dicho que ambas aproximaciones hayan de ser excluyentes? Con aritmética de punto fijo puedes hilar más fino y mover tu personaje 3/4 de pixel si te lo propones :D

Claro! Como dice Sap, sólo hay que coger el byte alto del resultado, pero tienes que mantener en memoria el valor completo (2 bytes).

Por ejemplo

; Incrementa la velocidad
ld hl,[VY]
ld bc,fix(0.02]
add hl,bc
ld [VY],hl

; Ajusta posicion

ex de,hl
ld hl,[Y]
add hl,de
ld [Y],hl

; Obtiene la coordenada de pantalla

ld a,h

Algo así debería funcionar. Igual se me ha colado alguna morcilla, verificadlo. Y la precisión que pierdes es muy poca.

Creo que lo pillo, Sapphire. Con punto fijo tienes algo más de precisión. Será cuestión de ver si me hace falta en mi juego. Thanks!

OK, robsy. Esto es lo que necesitaba para acabar de pillarlo. La cosa es que pensaba que las operaciones en punto fijo eran más costosas, y, claro, pensaba que tenerlo precalculado era mejor. Siendo así, esta es una muy buena opción.

Pues sí, se puede eliminar t, la verdad es que se puede hacer de muchas maneras, yo simplemente he utilizado el modelo fisico que se enseña en 3º de BUP (de mis tiempos) en el que no se tiene en cuenta el rozamiento del aire, ni si el cuerpo es o no aerodinamico, etc, etc. que para un salto de un metro (p.e) pues da el pegote.

Sin embargo mi metodo posee un detalle que creo que es por lo menos curioso y es que se puede relacionar el movimiento en "y" con el movimiento en "x", con tan solo eliminar el parametro "t" del sistema de ecuaciones

y=yo+vo*t+1/2*a*t^2
x=v*t

donde "v" seria la velocidad cte en esa direccion.

asi por ejemplo para avances en x de 1 pixel tendriamos el valor de ascenso o descenso en "y" (de forma acelerada/desacelerada segun vaya hacia arriba o hacia abajo) en una sola tabla.

Sigo pensando que se consigue mucho realismo así, sobre todo para evitar movimientos que puedan parecer antinaturales. Pero en fin, este es tan solo mi punto de vista.

Otro saludo.

Jos'b ahi tienes razon, pero al final hablamos de lo mismo. El fin es conseguir el movimiento con el minimo numero de cálculos y si los saltos van a ser trayectorias constantes a las que solo hay que añadir la posicion inicial x,y lo mejor es que esten precalculadas. Si ademas se te ocurre que el personaje puede tener distintos tipos de salto añades otras tantas trayectorias. Uno de los mas originales es el doble salto del castlevania symphony of the night y lo facil que es hacerlo ;D.

... o el salto proporcional al tiempo que se mantenga pulsada la barra espaciadora en el MAZE OF GALIOUS! Sin embargo, las caídas no son muy realistas en este juego, a pesar de lo cual la animación es - para mi gusto - fantástica.

Bufff, mi rutina de salto caida no la entiendo ni yo  scrms:) Y eso que esta todo medio precalculado... Lo mio es codigo obtuso  :spank:

Pues yo voy a incluir un pequeño programilla en el que utilizo el metodo que explique ayer para realizar saltos, y ademas incluyo en el mismo fichero las explicaciones teoricas del metodo y un ejemplo practico.

Con esto no quiero que nadie piense que me quiero pasar de listo, porque  el tiro parabolico es mas viejo que el c...., pero si me gustaba demostrar de que no es tan dificil como parece una vez que se conoce.

Para ejecutar el archivo, hay que compilarlo y con el blueMSX elegir la opcion de insertar directorio y cargar con BLOAD.

A mí como a Robsy, tambien me gustaria recibir el feedback de este ejemplillo, a ver que os parece.

Y respecto al codigo solo tengo que decir que llevo cuatro dias programando en ensamblador, así que tendra muchos defectillos.

Un saludo a todos.

Voy a colgar otra vez el fichero, corrigiendo un par de erratas que he descubierto en los datos.

No se nota mucho la difierencia (bueno, en realidad no se nota nada)

Espero que no se sobrecarge el servido. ;D ;D

¡Bota, bota la pelota! :D

Un poco más abajo, los más vaguetes de la casa podrán descargarse la versión ROM de la demo de Jos'b, que por cierto, resulta muy ilustrativa  :)

Ahora estaría bien que intentaras la conversión a movimiento en tiempo real, primero conviertiendo las coordenadas de la pelota a valores con coma fija (16 bit: byte alto la parte entera y coordenada XY real, byte bajo la parte fraccionaria en 256-avas partes), luego jugando a incrementar con valores decimales y creando una tabla más grande y precisa con valores de 16bits y finalmente si te animas, a utilizar una aceleración vertical para calcular la altura de la pelota para cada X en tiempo real. Te aseguro que podrás comprobar la diferencia en cuanto a suavidad y sensación de realismo ;)

P.D.: La conversión está hecha a partir del primer listado de Jos'b

Solo era un ejemplillo  ;D, esta claro que cuanta mas informacion le metas (datos y precision) mejor sera el movimiento, pero bueno, para muestra basta un boton.

Lo unico que quiero mostrar es que se consigue un movimiento bastante natural usando el movimiento parabolico, y se puede conseguir un amplio abanico de saltos variando basicamente el angulo de salto y la velocidad inicial en la misma formula.

Y luego que cada uno use el metodo que quiera. ;D ;D

Ya lo mirare  ;D Aunque mi problema no es el salto, es que he metido la gamba en el scroll  ::) Me toca cambiarlo :P

Bueno, ahora no sólo he pillado el concepto sinó que lo he sufrido en mis carnes ;-)
Había empezado todo el tema de saltos, aceleraciones y demás con tablas precalculadas (o sea, puestas a ojo ;-), y ya tengo clarisimas las ventajas de las operaciones en punto fjio. De todas formas, como lo que tengo hecho queda suficientemente bien, creo que voy a dejarlo así. El punto fijo, en próximos proyector 8P

Subiría lo que tengo hecho, pero como lo tengo todo metido en mi proyecto de juego, y tengo planes de presentarlo en alguna dev (digamos la del 2015 o así), pues creo que subiendolo incumpliría las normas de la dev, no?