animations based on time

[moshi]

most people use counter formulas to do animations.
the downside of this is that if your computer is busy the animation might run slower than normal, as the counter is based on the skin updates.

so why not using system time instead?
the animation will always take the same time then, it will skip frames instead of running slower.

here is the code i am using for this:

Code: Select all

[Rainmeter]
Update=(#FrameTime#)
BackgroundMode=1

[Metadata]
Author=Alex Becherer
Name=Animation System Time Example
Information=
Version=1.0
License=Creative Commons BY-NC-SA 3.0

[Variables]
NumberFrames=38
FrameTime=100

[MeasureTime]
Measure=Time
AverageSize=(1000/(#FrameTime#))

[MeasureStart]
Measure=Time
AverageSize=(1000/(#FrameTime#))
UpdateDivider=-1

[MeasureFrame]
Measure=Calc
DynamicVariables=1
Formula=(((((MeasureTime)*(1000/(#FrameTime#)))-((MeasureStart)*(1000/(#FrameTime#))))-((FLOOR((((MeasureTime)*(1000/(#FrameTime#)))-((MeasureStart)*(1000/(#FrameTime#))))/(#NumberFrames#)))*(#NumberFrames#)))+1)

[MeterImage]
Meter=Image
ImageName="#@#images\[MeasureFrame].png"
X=0
Y=0
DynamicVariables=1

the formula is more complicated than it might be neccessary, but this way the animation will start from frame 1 when you start/refresh the skin.

there are two variables here:
NumberFrames= is the number of frames in the animation. frames' names start from 1. you can duplicate frame number 1 and name it 0, just to be save.
FrameTime= is the time for each frame in milliseconds.

an example skin is here:
http://yadi.sk/d/2-d6eBrOBkMLd

[bobgrosh]

...so why not using system time instead?https://www.box.com/s/9m0zwfhjjlz3w8tssep4

WOW, I gave up on a large project involving multiple animations because it did;t scale down to slower processors.
I think now I'll have to revisit it.

This is great!


(Besides, I'm in love with your sample video. I find myself staring at my desktop instead of working.)

[moshi]

don't get too enthusiastic. this will take about the same toll on the cpu as the counter method (even a little more, but i don't think this will be noticeable).

the only difference is the way it calculates the frame numbers. the counter method will get slower when the computer is busy, this will skip frames. so it pretty much depends on the type of animation which way to choose.

[bobgrosh]

don't get too enthusiastic.

Oh I am VERY enthusiastic.
The project involved a three monitor view of a city that slowly gets built over a period of days. It then gets destroyed over a period of weeks by zombies, aliens and alien zombies. (think back to Johnny Castaway)

Periodically, skins would be activated to cause gunfire, screams and small animations as the city is slowly destroyed.

Some animations included a Michael Jackson's thriller dance done by 12 different skins (each was 40x60 px), depicting construction workers. All 12 sins had to stay in sync. Using the old method, they didn't.
A few days later 12 zombie construction workers do the dance again, later 12 alien zombie construction workers do it again.

I gave up trying to get the animations to sync up. I am pretty sure that skipping a few frames will be much better than having them all end at different times.

It never occurred to me to use the system clock to time the dances. Thanks, That is really innovative code.

[moshi]

All 12 sins had to stay in sync. Using the old method, they didn't.

think about removing the MeasureStart parts for these. so they wont start at frame 1, but they would be really in sync. else if one skin might be loaded faster than the other, they wont.