Java, ¿"actionPerformed(ActionEvent e)" (Timer)?

varuk

Buenas, tengo una dudilla en Java con esto del Timer para que las acciones se produzcan cada cierto tiempo.

Tengo en en una clase que en su método "actionPerformed" hace llamadas a métodos de otras clases cada X milisegundos:

@Override
public void actionPerformed(ActionEvent e) {
		
 objeto1Funcion1();
 objeto2.Funcion2(parametros...);

}

Pero lo que quiero es que dentro de cada clase, a la que pertenece cada objeto, la función esa se lance cada 2 segundos, por ejemplo. Vamos, que la llamada a los métodos sea cada 200 milisegundos pero que la función, ya dentro de su clase, sea cada 2 segundos (para que el personaje que corresponde se mueva lentamente por un escenario).

¿Cómo sería? No sé si me he explicado. Gracias.

elkaoD

¿Y por qué no lo haces directamente cada 2 segundos? :S

1 respuesta
varuk

#2 Eso he hecho, en vez de pasarlo y luego lo otro, pues cada 2 segundos he hecho que cada objeto, en su clase con su método actionPerformed(ActionEvent e) cada uno pues que llame cada ese tiempo al método.

Buffoncete

Lo estás haciendo mal, estás intentando limitar los FPS?

En realidad cuando se programa un videojuego se suele utilizar otras técnicas para la animación que no limitan los FPS y que calculan la posición actual y la animación con respecto al intervalo de tiempo pasado desde la última.

O lo he entendido mal?

--

Edito:

Si en java quieres que un objeto duerma durante 2 segundos, tienes que hacer Thread.sleep(2000);

Y recuerda de hacer el try catch correspondiente a InterruptedException para manejar la excepcion.

1 respuesta
elkaoD

#4 nunca he sido muy fan del timestep dinámico por temas de la física.

Si por alguna razón un frame tarda demasiado en renderizarse, es posible que las físicas exploten (al usar integradores) porque el diferencial de t sea demasiado grande. Es malo, malo. Por mucho que uses integradores de mayor orden, el problema persiste (aunque es más difícil que se llegue a dar.) Si usas un timestep fijo la simulación se para y punto, tarde lo que tarde en renderizar sólo ha pasado un frame físico y con un diferencial de t razonable. Ya tuve problemas con esto en un simulador de SPH que hice en su día. La simulación explotaba y todas las partículas se iban a tomar viento.

Otra razón para usar timestep fijo es que con el dinámico las físicas del juego tienen un "feeling" diferente dependiendo del framerate. Además esto viene bien si por alguna razón quieres volver atrás en la simulación, grabarla para reproducirla o compartirla entre sistemas. Si el timestep no es fijo cada simulación será diferente.

A veces se ha usado como técnica un timestep semifijo (si timestep > cierto intervalo, se parte la simulación en mini-timestep) pero bajo mi punto de vista tiene lo malo de las dos técnicas y encima tiene que realizar varios "pases" de física por frame. Aparte de que si la física a calcular es gorda, puedes entrar en la espiral de la muerte donde cada vez hay más micro-timesteps por cada timestep.

Como mucho tener un timestep fijo para la física y uno variable para el renderizado en dos hilos, pero total nunca vas a renderizar más cambios que los que haga la física, así que timestep fijo y todos contentos :) No es la mejor solución, lo ideal es que si vayan por separado y el render interpole en los estados intermedios de la física (dado que el render y la física tienen diferente fase) pero es un currazo y no se nota (no es muy basto ver la física "medio frame" hacia atrás.)

Si no me equivoco, los frameworks gordos (XNA y demás) usan timestep fijo por esta razón.

Aquí MUUUCHO mejor explicado http://gafferongames.com/game-physics/fix-your-timestep/

k1k0_o

Y si concadenas actionPerformed?

Es decir, en el actionPerformed de 200ms pones el método que llame al actionPerformed de 2ms.

Aprovecho este hilo para preguntar si sabéis como va el rollo para hacer un countdown, porque no me sale :(. (Para delante sí, fácil, pero para atrás....)

1 respuesta
Buffoncete

#6 sabes ir hacia adelante pero no hacia atrás?

creo que no lo has pensado lo suficiente ;)

Fyn4r

si son milisegundos, no harían falta 2000 ? pregunto xd

Usuarios habituales

  • Fyn4r
  • Buffoncete
  • k1k0_o
  • elkaoD
  • varuk