¿Ralentizar una animacion?

[jean la montard]

Buenas

Actualmente ando metido en un Shoot em up sencillito y mas o menos va , pero tengo un leve problema con las animaciones de los enemigos, este es el codigo en cuestion



for(cont=6;cont<=10;cont++)
graph=cont;
frame;frame;frame;frame;frame;frame;frame;frame;
end;



Es una animacion de 4 frames , y la unica manera de verse es poner esos frame ahi porque sino va demasiado rapido... pero no me gusta nada este sistema

¿Se os ocurre algo?

[Segata Sanshiro]

Lo mejor es que añadas otro contador. Por ejemplo, si quieres que avance un fotograma cada N frames, mete esto en un bucle dentro del proceso del enemigo:



loop;
// ...
// Código del enemigo
// ...
i++; // Este contador nos dice cuándo tenemos que cambiar de fotograma
if( i == N); // Ésta es la condición para avanzar de fotograma
i = 0; // Reseteamos la condición
graph++; // Avanzamos el fotograma
end
// ...
// Más código
// ...
end // end del loop


De esta forma, a cada pasada del bucle, i va subiendo de valor. Cuando i llega a valer N, avanza el fotograma y se vuelve a poner a cero. Luego vuelve a seguir aumentando hasta volver a llegar a N y así sigue. Tendrás que añadir cosillas para controlar un poco que no pase de 4 fotogramas, etc., pero eso ya depende de cómo sea tu juego y la animación y tal :)

[SpaVampyre]

no sería mejor meterle un temporizador? así podras controlar mejor la velocidad, ya que ese código depende de la velocidad de proceso del bucle.

[chemaris]

en vez de poner tantos frames una opcion es usar:

frame(800);

el valor entre parentesis es el tiempo que tarda en dibujar, asi serian 8 frames

[SpaVampyre]

eso suena mucho mejor, es 800 u 8000? se me hace raro que trabaje con centésimas de segundo.

[Segata Sanshiro]

eso suena mucho mejor, es 800 u 8000? se me hace raro que trabaje con centésimas de segundo.

El valor de dentro es un porcentaje, 800% o 8000%

[chemaris]

eso suena mucho mejor, es 800 u 8000? se me hace raro que trabaje con centésimas de segundo.

para 8 frames 800, por defecto la funcion frame equivale a frame(100)

[animanegra]

yo no usaria lo de los frames(800), porke retrasaras el restro de instrucciones del proceso esos frames, impidiendo cualquier avance o ejecucion que quieras realizar de forma intermedia. Que no quieras que la animacion de un proceso en concreoto vaya tan deprisa no quira para que no quieras que ejecute codigo en todos los frames. (¿Me he explicado? :S)

[SpaVampyre]

El valor de dentro es un porcentaje, 800% o 8000%
ok, entiendo.

[Drumpi]

no sería mejor meterle un temporizador? así podras controlar mejor la velocidad, ya que ese código depende de la velocidad de proceso del bucle.

Yo creo que no, siempre he sido de la opinión que el juego debe ir temporizado respecto a la velocidad real del juego, y no al tiempo "externo" a él. Imagina por un momento que tienes alguna aplicación de fondo o que tu pc no puede y en un momento dado se ralentiza la ejecución: la respuesta a las teclas depende de la velocidad del programa, pero si los enemigos dependen de un reloj que ha seguido contando mientras tu estabas en "espera", ellos se han seguido moviendo y no has podido hacer nada para no perder una vida. Sería como los famosos lags de las partidas en red.
La idea del contador es lo que se suele usar el 95% de las veces.

[SpaVampyre]

Yo creo que no, siempre he sido de la opinión que el juego debe ir temporizado respecto a la velocidad real del juego, y no al tiempo "externo" a él. Imagina por un momento que tienes alguna aplicación de fondo o que tu pc no puede y en un momento dado se ralentiza la ejecución: la respuesta a las teclas depende de la velocidad del programa, pero si los enemigos dependen de un reloj que ha seguido contando mientras tu estabas en "espera", ellos se han seguido moviendo y no has podido hacer nada para no perder una vida. Sería como los famosos lags de las partidas en red.
La idea del contador es lo que se suele usar el 95% de las veces.
Si, pero tienes que andar probando cuantos bucles de espera has de hacer segun la velocidad del reloj del procesador, estas generando esperas a costa de proceso impoductivo, eso o no estoy pillando la idea de lo que quereis hacer, pero el hecho de dejar al programam atrapado un rato dentro de un bucle NOP para que pierda tiempo no me parece la mejor solución. (que es lo que entiendo que quereis hacer)

[Drumpi]

No te pillo. Creo que confundes Fenix con un lenguaje "normal".
Cuando haces frame, el proceso se espera a que todos terminen. Cuando todos los procesos han terminado, se realiza el volcado a la pantalla. Cuando el volcado a pantalla termina, el tiempo sobrante no se hace nada ¿cuanto sobra? pues eso no le preocupa al programador de Fenix, ya que el propio fenix se encarga de contarlo. Fenix te asegura que si tu le dices con set_fps que pinte 60 imágenes por segundo, si el PC tiene suficiente velocidad, lo hará (lo que haga en ese tiempo no lo se, eso depende de cómo esté programado Fenix, y dudo que use algo tan ineficiente como NOP). Si el PC no puede ir a esa velocidad, puedes pedirle que omita el dibujado de pantalla con el segundo parámetro de set_fps (es decir, el frameskip).

Fenix no se rige en el tiempo como todos los lenguajes: aquí la base de tiempos es el FRAME, que lo defines tu, tanto en tiempo (set_fps determina número de frames por segundo), como lo que tiene que hacer cada proceso. ¿Se pueden usar timers de tiempo real? si, pero eso va APARTE de la ejecución normal.

[SpaVampyre]

Ahm, ni me había fijado que estamos en el subforo de soporte fenix :rolleyes: