Delta time.

[shao]

Hola, por curiosidad y quizá para futuros programas, ¿como se obtiene en gemix el tiempo que pasa entre cada frame?, lo que también se le llama delta time.
¿Existe alguna variable que lo indique?.

Para los que no lo sepan, obteniendo este valor se pueden programar juegos independientemente de los fps al que corran, es decir, los movimientos de un juego a 60 fps irán a la misma velocidad que uno a 30, por lo tanto tu juego irá a la misma velocidad en una máquina que pueda correrlo a 60 y en otra que no de más de 30 fps.

[TYCO]

Las tween concretamente se basan en segundos y no en los fps del juego. Pero exceptuando esto...

Si quieres saber cuantos segundos pasan entre Frame GLOBAL y el siguiente Frame GLOBAL... la respuesta es... ni idea! ni zorra idea! a ver si CicTec puede decirnos algo.

[shao]

Tyco ¿que diablos es frame GLOCAL?, no lo he visto en ningún manual ni libro de DIV.

Consiste en el tiempo transcurrido entre el frame actual y el anterior, tu dices el frame actual y el siguiente, eso no se puede saber hasta que "el siguiente" se convierte en "el actual" supongo.

[TYCO]

Quise decir Frame GLOBAL, fallo mio. Y a lo que me refiero con FRAME GLOBAL... es al FRAME que ves tu en pantalla finalmente, ya sabes que cada process/function tiene su Frame.. pero solo cuando se ejecutan todos los Frames de cada process/function es cuando se vuelca todo al buffer de la pantalla (o a un graph que indicadmos con los "destinations"), a ese volcado le he llamado Frame GLOBAL.

Aclarado eso, para calcular el tiempo que pasa del último Frame Global hasta el actual, por mi parte desconozco si hay alguna función.

De todas formas para que te podría hacer falta saber ese tiempo?

[shao]

Entonces sería indicando el tiempo pasado entre ese frame global y el anterior, supongo.

Es decir:
frame actual -> delta time -> frame anterior

Hacerme falta no me hace, pero podría ser de utilidad para programar juegos independientemente de fps.

Explico un poco según entiendo:

Si tu tienes un programa a 60 fps y tienes:

if(key(_right))
++x;

end

El sprite se mueve 60 pixeles en un segundo.

Si ese mismo programa lo corres en un PC que no da más de 30 fps, entonces el sprite se moverá 30 fps, entonces ese programa es dependiente de los fps del dispositivo donde se ejecuta.

Sabiendo este delta time, en vez de usar

if(key(_right))
++x;

end

Se podría usar:

if(key(_right))
x += 60 * deltaTime;

end

A 60 fps, deltaTime tendrá un valor medio de 0.01666... (1 segundo / 60 frames), es decir, se ejecutara un frame cada 0.016 centésimas de segundo.
Tu sprite se moverá 60 * 0.016 = 0.96 pixeles aprox.


A 30 fpgs, deltaTime = 1 seg / 30 fps = 0.03
Tu sprite se moverá 60 * 0.03 = 1.8 pixeles aprox.

Es decir que se movería la misma distancia aun con menos fps, por eso se obtiene que el juego se movería igual de rápido a 60 que a 30 aunque obviamente a 30 el movimiento sería algo mas tosco.

Es decir, delta time esta obteniendo continuamente el tiempo transcurrido entre el frame actual y el anterior, si el tiempo es mayor (por ejemplo a 30 fps) pues el sprite se moverá más distancia que si es a 60, ya que a 60, el espacio entre frames es menor que a 30.

Como la velocidad del pc puede variar, oscila entre una tasa de frames, pues así se conservaría los valores de movimiento aunque el pc vaya mas rápido o mas lento.

[erkosone]

esto es justamente lo que hace la funcion set_fps() jeje.. sea cual sea el pc establece un tiempo entre frame y frame.

Como bien dices shao, el tiempo es 1 / fps teoricos, y lo que se hace internamente es que una vez que todo está ejecutado para el frame actual, antes de presentarlo se mira si ha transcurrido el tiempo establecido como delta, si no es así se espera a que pase el tiempo que falta y luego se actualiza el buffer de video y diversas cosas mas.

[shao]

Si, quizá set_fps hace algo parecido pero no estoy seguro de que sea así como dices, no se si para gemix el tiempo delta es fijo, podría ser que existan pequeñas variaciones.
Quiero decir que en un segundo a 60fps el tiempo entre frames no tiene por que ser el mismo, podría variar.

[erkosone]

Pues NO, y te lo pongo en mayusculas por que mira te explico mi experiencia personal..

He programado un secuenciador musical para iOS que empecé en gemix pero por diversos retrasos en las betas y los ports terminé portando a otro lenguaje junto con mas programas.
La cosa es que descubrí que gemix es el lenguaje con mas estabilidad en FPS que existe, en serio.. supera con creces incluso al motor de SDL oficial.

Hay muchas cosas que gemix no tiene, pero estabilidad y fiabilidad en que ese tiempo es EXACTO Y MUY PRECISO te doy fe de que es así, no se como lo ha programado CicTec pero es simplemente perfecto, no falla.

Te animo a que hagas la prueba ya no con otros divlikes si no con otros frameworks en C o Java.. es una pasada, gemix tiene una estabilidad muy alta en esto

[CicTec]

Hola shao,

Como te dijo erkos, FPS ya hace algo similar internamente, y eso del delta-time que dices no es correcto, un juego o va a 60fps o a 30, ir a la misma velocidad a 30 que a 60 es una ilusion, porque lo que ves son menos fotogramas, por ejemplo durante 10 millisegundos ves la posicion de un objeto a 10,10 por ejemplo, despues otros 10millisegundos lo ves a 12,12, a 30 fps, primero lo ves a 10, 10 y despues lo veras a 20,20 por ejemplo.

[shao]

Claro, a 30 fps hay menos fotogramas fotogramas que a 60, eso es indiscutible, con la misma velocidad me refiero al desplazamiento de los sprites.

Por eso dije:

Es decir que se movería la misma distancia aun con menos fps, por eso se obtiene que el juego se movería igual de rápido a 60 que a 30 aunque obviamente a 30 el movimiento sería algo mas tosco.

A 60 fps, un sprite a 1 pixel por frame, en un 1 segundo habrá recorrido 60 pixeles.

Del modo que digo, a 30 fps también habrá recorrido 60 pixeles, pero lo habrá hecho más rápido, por eso digo que se conserva la velocidad, la de desplazamiento, no la de fps.