Librería de animaciones sencilla (v0.1)

[panreyes]

Buenas.

He creado una librería de animaciones sencilla, por si os puede servir :)

Básicamente hay que crear un archivo de configuración de la animación en el que se especifiquen las animaciones, como éste:

Code Select Expand


[Global]
name=personaje
delay=2

[anim:stand]
repeat=60
next_animation=idle
first_frame=1
last_frame=1

[anim:idle]
first_frame=11
last_frame=16
repeat=10
delay=3
next_animation=stand

[anim:run]
loop=1
first_frame=21
last_frame=34

[anim:jump_up]
frames=41

[anim:jump_down]
frames=42

[anim:shoot]
loop=0
first_frame=51
last_frame=53
delay=4
next_animation=stand


Después hay que cargarlo de la siguiente forma:

Code Select Expand

animation_load_set("anims/personaje.ini");

Luego en el proceso que queramos utilizar dicha animación, elegimos la animación con:

Code Select Expand

animation_change("personaje","stand");

Y la aplicamos con éste comando antes de cada frame:

Code Select Expand

animate_me();

Si queremos hacerlo más óptimo (no tirar de strings continuamente), podemos cambiar la animación también con una variable local del proceso:

Code Select Expand


Const
anim_stand=1;
End
[...]
animation=anim_stand;


Y eso sería la base. Si luego tiráis del código, veréis que se pueden hacer más cosas y que es "trampeable" con las variables locales en caso de que necesitéis hacer modificaciones en cualquier momento de la animación.

Aquí tenéis un vídeo de ejemplo de las animaciones:
https://www.youtube.com/watch?v=GgHktkeHYlo

Y aquí el código, para que lo probéis vosotros mismos :)
https://www.dropbox.com/s/lkorvpedzwk7pfq/animaciones-1.0.divpmproject?dl=0
(Si no queréis usar DIVPM, cambiad la extensión a .7z y podéis extraerlo libremente)

Ya me diréis qué os parece, aparte de un código sucio y feo (es mi estándar xD)

[panreyes]

Adjunto códigos.

[warrior_rockk]

¡Buen trabajo!


Es casi exactamente la misma implementación que uso yo en mi módulo de animaciones a la que le hice una pequeña utilidad para editar y previsualizar las animaciones:




El flag modo permitía tener varios modos de loop (desactivado, one cycle loop, ping-pong loop, etc..)


Por otro lado...¿Que se ve en el vídeo??? ¿Nuevo proyecto en marcha? ¿Funcionando en switch?? Cuenta, cuenta!! ejej

[panreyes]

El flag modo permitía tener varios modos de loop (desactivado, one cycle loop, ping-pong loop, etc..)

Interesante :) Yo no lo había pensado, pero por suerte el formato que he elegido es compatible con varios tipos de loop.
Y sí, tendré que crearme una tool para ésto xD

Por otro lado...¿Que se ve en el vídeo??? ¿Nuevo proyecto en marcha? ¿Funcionando en switch?? Cuenta, cuenta!! ejej

Es una prueba de animaciones... aunque quizás lo aproveche para un juego de gamejam xD

[Drumpi]

Oye, no pinta mal.
La verdad es que diseñarse un sistema de animaciones es muy útil. ¿Has pensado, además, que se le pueden incorporar cosas a la animación al estilo de Unity, tipo "cuando termine, ejecutar tal animación", o una máquina de estados?

Lo ideal sería también disponer de una forma de añadir eventos, para configurar que cuando se llegue a tal frame se ejecute algo, tipo "reproducir el sonido de un paso" o "crear proceso bala". Ahora mismo sólo se podría si tuvieras una variable de acceso externo (global o local o la otra, que no me acuerdo :D) que se pusiera a un valor cuando se dispare el evento, y que otro proceso lo lea y diga "¡Ah! el evento 5, reproduzcamos un sonido".

Hace tiempo que me gustaría hacer un pequeño editor de animaciones por piezas, para hacer cosas como aquel RE 65565 de Splinter en la CrapCompo, tanto para crear videos como para usarlo en otros juegos.

[panreyes]

Oye, no pinta mal.
La verdad es que diseñarse un sistema de animaciones es muy útil. ¿Has pensado, además, que se le pueden incorporar cosas a la animación al estilo de Unity, tipo "cuando termine, ejecutar tal animación", o una máquina de estados?

Gracias :) Algo hay ya, pero muy básico.
Básicamente, cuando termina una animación puedes configurar que luego vaya a otra, pero sin condiciones.

Lo ideal sería también disponer de una forma de añadir eventos, para configurar que cuando se llegue a tal frame se ejecute algo, tipo "reproducir el sonido de un paso" o "crear proceso bala". Ahora mismo sólo se podría si tuvieras una variable de acceso externo (global o local o la otra, que no me acuerdo :D) que se pusiera a un valor cuando se dispare el evento, y que otro proceso lo lea y diga "¡Ah! el evento 5, reproduzcamos un sonido".

Hace tiempo que me gustaría hacer un pequeño editor de animaciones por piezas, para hacer cosas como aquel RE 65565 de Splinter en la CrapCompo, tanto para crear videos como para usarlo en otros juegos.

Esto ya me lo propuso Splinter. No sería mala idea para nada. Ahora mismo se puede utilizar una variable local (anim_ticks) para hacer este tipo de tareas: si el proceso está en una animación concreta y en un tick concreto, realizar una acción. Además, tienes anim_counter que se resetea en el bucle de la animación y anim_ticks que no lo hace.

[Drumpi]

Yo pensaba algo más como meter unas líneas más a las animaciones del fichero de configuración, tipo:

Code Select Expand

[anim:idle]
first_frame=11
last_frame=16
repeat=10
delay=3
next_animation=stand
event_frame=4
event_id=7

De forma que cuando la animación llegue al frame 4, ponga el valor 7 en esa "anim_ticks".
O si se pueden añadir dos parámetros de alguna forma, tipo:
event_trigger=4:7
event_trigger=8:7
Así puede generar dos eventos, en el frame 4 y en el 8, que pongan el anim_ticks a 7, para por ejemplo, en el ciclo de andar, reproducir dos veces el impacto del pie en el suelo.

...Pero claro, eso implica que tienes que crear una lista variable de eventos, con dos valores, en tu proceso.
Sólo a modo de idea.

[SplinterGU]

Oye, no pinta mal.
La verdad es que diseñarse un sistema de animaciones es muy útil. ¿Has pensado, además, que se le pueden incorporar cosas a la animación al estilo de Unity, tipo "cuando termine, ejecutar tal animación", o una máquina de estados?

Lo ideal sería también disponer de una forma de añadir eventos, para configurar que cuando se llegue a tal frame se ejecute algo, tipo "reproducir el sonido de un paso" o "crear proceso bala". Ahora mismo sólo se podría si tuvieras una variable de acceso externo (global o local o la otra, que no me acuerdo :D) que se pusiera a un valor cuando se dispare el evento, y que otro proceso lo lea y diga "¡Ah! el evento 5, reproduzcamos un sonido".

Hace tiempo que me gustaría hacer un pequeño editor de animaciones por piezas, para hacer cosas como aquel RE 65565 de Splinter en la CrapCompo, tanto para crear videos como para usarlo en otros juegos.

exactamente lo que le recomende en el discord... lo de eventos para ejecutar sonidos...

[SplinterGU]

yo lo haria por tiempo en lugar de ticks... se podria asegurar una misma velocidad sin importar la CPU y ademas sincronizaria mejor los sonidos...

[Drumpi]

¿Por tiempo? No, creo que es mejor por frame.
Por lo general, siempre se asocian los sonidos a un frame en concreto (el que el pie contacta con el suelo, justo el momento antes del retroceso de la pistola...). Si hay que sincronizar sonidos entre sí, lo ideal sería hacerlo mediante el play_sound, para que lo haga en bucle, o el is_playing_wav, aunque creo que mediante este método te puede meter un silencio si el sonido termina entre un frame y otro, que creo que era lo que me pasaba en Frikimusic cuando intentaba generar un sonido continuo por este método.

Pero bueno, dándole vueltas, con variables públicas y funciones se pueden emular señales a procesos, enviándoles la ID, creo...

[SplinterGU]

¿Por tiempo? No, creo que es mejor por frame.
Por lo general, siempre se asocian los sonidos a un frame en concreto (el que el pie contacta con el suelo, justo el momento antes del retroceso de la pistola...). Si hay que sincronizar sonidos entre sí, lo ideal sería hacerlo mediante el play_sound, para que lo haga en bucle, o el is_playing_wav, aunque creo que mediante este método te puede meter un silencio si el sonido termina entre un frame y otro, que creo que era lo que me pasaba en Frikimusic cuando intentaba generar un sonido continuo por este método.

Pero bueno, dándole vueltas, con variables públicas y funciones se pueden emular señales a procesos, enviándoles la ID, creo...

sincronizar un audio, por ejemplo, un dialogo (o lo que sea) con frames nunca dio buenos resultados, no confundir momento inicial (o de play del sonido), sino sincronizacion de audio con imagen... muchas veces hubo gente preguntando como sincronizar o diciendo que tuvo problemas... ademas los audios no se controlan en frames, sino en segundos... y ademas (otro ademas mas...) todos los engines profesionales controlan las cosas (eventos/duraciones/etc) por segundos (o fracciones de segundo)...

[Drumpi]

Sí, claro, sincronizar animación con el audio sí que es necesario hacerlo por tiempo... pero aquí hablamos de lanzar el audio o eventos en determinados momentos de la animación, no de que en determinado momento del sonido tiene que estar haciendo tal cosa.

Además, tengamos en cuenta que todos los lenguajes trabajan en función del tiempo, pero DIV, Fenix y Bennu están fuertemente atados a los Frames. Todo sucede entre un frame y otro y se sincronizan con el comando Frame. Vale, me dirás "Frame(20) y se ejecuta 5 veces", pero sigue dependiendo de Frame, no es que se ejecute 50 veces en un segundo y 60 veces en el siguiente porque hay menos carga en la CPU.

También añado ¿Te acuerdas de "Liquid Counter"? ¿Aquel juego que hice en estilo Game and watch para Wiz y Caanoo? Tiene un reloj en tiempo real, consulta la hora al arrancar, y a partir de ahí, la calcula él solo. Usando timers se desincronizaba más de un minuto por cada 10, usando un contador apenas algún segundo.

[SplinterGU]

Sí, claro, sincronizar animación con el audio sí que es necesario hacerlo por tiempo... pero aquí hablamos de lanzar el audio o eventos en determinados momentos de la animación, no de que en determinado momento del sonido tiene que estar haciendo tal cosa.

eso lo hablabas tu, en discord y aca yo hablaba de sincronizacion de una animacion con un audio, lanzar no necesita frames, puedes lanzar una animacion junto con un audio... animacion tambien puede ir con tiempo, de hecho mira Unity, anima por tiempo, no por frames...

por tiempo ademas, hace que todo corra a la misma velocidad independientemente de los frames que pueda ejecutar la CPU... eso es lo que hacen todos los juegos, corren por tiempo mas alla de los fps... un juego que corre a 1000 fps mueve a un personaje la misma distancia que un juego que corre a 30 fps... es un gran error de vision que tenemos aca... por eso, muchos juegos en div like, corren mas rapido si subimos los fps, cosa que no sucede en juegos comerciales serios...

Además, tengamos en cuenta que todos los lenguajes trabajan en función del tiempo, pero DIV, Fenix y Bennu están fuertemente atados a los Frames. Todo sucede entre un frame y otro y se sincronizan con el comando Frame. Vale, me dirás "Frame(20) y se ejecuta 5 veces", pero sigue dependiendo de Frame, no es que se ejecute 50 veces en un segundo y 60 veces en el siguiente porque hay menos carga en la CPU.

si, y es un grave error...

También añado ¿Te acuerdas de "Liquid Counter"? ¿Aquel juego que hice en estilo Game and watch para Wiz y Caanoo? Tiene un reloj en tiempo real, consulta la hora al arrancar, y a partir de ahí, la calcula él solo. Usando timers se desincronizaba más de un minuto por cada 10, usando un contador apenas algún segundo.

sinceramente no me acuerdo de ese juego... para mi es la primera vez que se de el... pero conociendo mi memoria, sin dudas lo conoci...

[Drumpi]

Claro que Unity anima por tiempo, porque así puedes ajustar a la décima de segundo cuándo ejecutar un evento.
Pero si Bennu se ejecuta a 50fps, te da igual que el evento suceda a los 0'03s o a los 0'17s, hasta que no llegue a los 0'2s no se va a ejecutar ¿Que a 60FPS sí? Vale, pero a menos que uses SET_FPS(0,0), eso da igual, porque estás estableciendo unas ventanas de ejecución, y eso es precisamente una de las cosas que hacen que programar para Div fuera tan sencillo... y aparte, que los juegos 2D del año 2000 no usaban FPS variables aun :D

Yo sigo prefiriendo el uso de los FPS, porque tengo un control más preciso de los tiempos, no hay tantos problemas que solucionar en tema de sincronización entre procesos, si el Sistema es más potente el juego da "tiempos muertos" a la CPU para otras tareas, y si es menos potente se ralentiza el juego pero no pega tirones ni parece que los objetos se estén teletransportando.

Ahí tienes el Echo en Wiz, pegando tirones, pero jugable. O la fase de carreras del SBTime, que aunque hay partes en las que se ralentiza, se juega con suavidad y no le afecta al tiempo empleado en recorrer una distancia.


Para el que no conociera el Liquid Counter:
https://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,27,577

[SplinterGU]

ahora que veo el link del liquid counter, confirmo que en mi vida lo vi...