Animation Speed

For questions about using Classic.

Post » Fri Aug 15, 2008 9:13 am

I've been wondering how the 'speed' setting actually transfers in real world time. I can't really test it (since step by steping it makes animations break), sdo instead of trying to work out some weird other test out at 5am, I figured I might as well ask so I can get an answer from someone who actually knows what they're talking about by the time I wake up.

I'm GUESSING that the number relates to how many frames play in a second and if I want to run one frame of naimation ever one tick (running at 60 FPS) I would set animation speed to 60. That said, if I set it to 100, are animation frames culled?

Alternatively, 100 could be one frame every frame (100% speed).

Or it could be something completely different. And if I achieve 1 frame per tick, I can assume that adjusting the frame speed, I can finely set how many ticks a frame of animation is displayed (frame speed 5 for 5 frames, for example)

Basically I want to know how fast to run an animation to get exactly one frame every tick at 60 fps The rest of the questions are just curiousities and clarifactions.

Thanks in advance.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Fri Aug 15, 2008 10:43 am

Yeah, pretty sure it's frames per second.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Fri Aug 15, 2008 3:33 pm

It's in frames per second. So an animation speed of 5 = 5 frames per second = 0.2 seconds per frame. If you want 60 frames per second, then use an animation speed of 60 - but if your game is V-Synced (and it should be), note your game will be running at varying framerates (eg. 60, 75, 85fps) and so you won't get exactly one frame per tick. But the animation speed of 60 will still run at 60fps (its framerate independent).
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,564

Post » Fri Aug 15, 2008 6:34 pm

Now, to digress my own topic. Okay - I've been using Constant Framerate because I guess I'm really really anal about things working the same way every time. While using delta time to fix general movement speed wouldn't be too hard, I'm going to venture a guess that I'm probably working on one of the most complex construct games at this time (since I'm dumb and am not waiting for 1.0 :P) -- while also not being the most qualified person to do it.. Thus creating what will be a huge, unwieldy engine held together by duct tape (Perhaps I'm too hard on my self. :O)! Anyways, delta time would have to be applied to pretty much every event and I'd have to worry about variables that used to have a clean, whole number progression changed to decimal progression (can't use = anymore :<) and blahblahblah. Could it be done? I'd guess 'Probably' -- but not by me!

Anyways, I did some testing with V-Sync to see if the timing issues with refresh rate is really that bad. Perhaps something was wrong on my end, but it seemed like instead of trying to run at 120 frames per second, it just tried to sync up as closely as it can (Interlacing frames?). Now if that is right, running V-Synced wouldn't be that bad, speed wise (I'd rather things be faster or slower and work consistently than let things possibly playing differently on other machines). Problem was, animations were still moving at the same speed they normally would, which is hella bad for me, because I key some events to the timing of animations (Attacks, generally. Most other stuff isn't as important). Now if I could realistically make the engine run at full speed on any engine this wouldn't be an issue, but as I've pointed out above, I don't believe that is realistically feasible.

So now I have some things to consider...

Do I try and work delta time into the engine? (noooo ;__;)
Do I make my own animation engine to run animations on a per tick basis? (Would be obnoxious to do, but no reason it shouldn't work)
Do I keep developing at fixed rate 60? (Oh god I wish that was the best option)

OR

Do I beg for an option in a future build that can set animation to a tick based timing, rather than a delta timing? (I like this one a lot and I think there is a case to be made for a feature like this!)

And just for the hell of it, any way we could eventually get an option to turn vsync on and off in game? I think this would make a useful option in a games setting screen, though I could always just compile two different EXEs. Not a huge deal, but I figured I'd ask while I've digressed this far, even though I'm guessing 'no'.

Anyways, sorry for being long winded and probably coming off as stubborn!
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Fri Aug 15, 2008 8:38 pm

Seriously. Ashley's right. I tried various framerate tests, and when switching between monitors, it not only looked like utter crap at another refresh rate, but it played wrong too. Timedeltas are the only way to go to ensure a consistent play experience on multiple machines. What's more, timedelta's really easy to implement. Instead of Set object x position to "sprite.x +1" it's "sprite.x +(1*timedelta)" to get it to move one pixel per second. Want it 60? Use 60*timedelta. Easy.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,422

Post » Fri Aug 15, 2008 10:13 pm

[quote="Arima":6qobubts]Seriously. Ashley's right. I tried various framerate tests, and when switching between monitors, it not only looked like utter crap at another refresh rate, but it played wrong too. Timedeltas are the only way to go to ensure a consistent play experience on multiple machines. What's more, timedelta's really easy to implement. Instead of Set object x position to "sprite.x +1" it's "sprite.x +(1*timedelta)" to get it to move one pixel per second. Want it 60? Use 60*timedelta. Easy.[/quote:6qobubts]

That is a vast over simplification of the issues presented to me and I do not dismiss timedelta lightly. If only everything I'm doing is as easy as moving a sprite by X.

First of, no behaviors are being used. Things actually run very consistently for me on different computers and monitors (even though there is occasional tearing), since there is no real conflict between time based and delta based events. Everything is custom movement -- and perhaps the basic section of movement would work with delta time, but things aren't that simple! Types of movement (dashing or sliding) is based on ticking down timer. These could both be delta timed, but now the counting variable is a decimal, and it's now harder to track when it reaches certain values (I'd have to approximate the range it might span and risk things going off twice blahblahblah), Moves can combo and gatling into each other and variances in decreasing vales can cause unexpected things to be able to link (even if it's off by a frame).

EVERYTHING has to run on the same time scale so EVERYTHING has to use delta time. It's not like a basic game where the logic is simple collision issues where it doesn't matter if they trigger out of sync with movement. This is a serious logistical problem that is not as simple as "use delta time". Even if I do decide to go crazy and try and work out a way to delta time to work, it is far from simple (unless Ashley tells me it really is that simple and I feel done. By the way Ashley, the bug file I sent you is an older version of what I'm talking about. So you can look at it to get an idea if I'm full of shit or not if you feel compelled, because an expert opinion on this would be helpful). Even if I got it to work, I'd still feel weird inconsistencies.

Anyways, thats why I'm considering all my options.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Fri Aug 15, 2008 11:54 pm

I didn't mean to trivialize the task, I meant to show an easy example. Apologies if it seemed otherwise.

As for the timer/number span issue, I solved that in a game I was working on by using "if (timer) is equal to/greater than (amount)" with "trigger once". Try it, I think it might be what you're looking for. :)

Since I don't know the details of your game, I can't really comment more than that.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,422

Post » Sat Aug 16, 2008 12:35 am

I've been thinking about that, actually. I think the best thing to do, especially to get feedback on the way I'm doing things and how they can be improved, I need to stop being a sissy marry and post that shit up (it's not like anyone can steal anything anyways)... So

Here it is!

viewtopic.php?f=16&t=1456

Hopefully now I can get some real opinions.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Sat Aug 16, 2008 1:08 am

You should always use TimeDelta. Using a fixed framerate firstly decreases the display quality - even if you set the fixed framerate the same as your refresh rate, it makes no attempt to stay in sync with the refresh rate. So it still might draw the screen mid-scan and tear - if it doesn't tear in fixed framerate mode, it's only working by chance. Not to mention if your refresh rate is NOT 60Hz (which is a LOT of monitors) then it tears all over the place. Why not have a nice V-Synced display so it looks good for everyone?

Secondly if you use a fixed framerate and the computer isn't fast enough to achieve that fixed framerate, the whole game slows down to a crawl and all your timing goes out the window anyway (by 30fps everything's going half as fast, and the play might just get frustrated and quit).

So yeah, just use TimeDelta. It's not THAT hard - everything in Construct works framerate independently for these reasons, so I wouldn't want to make a tick-based animation system. Use Every events and all that and your game can't be that hard to code.
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,564

Post » Sat Aug 16, 2008 11:42 am

Is it possible for a TimeDelta Framerate Mode? What I mean is that you set the Framerate mode to "Time Delta" and it will automatically apply the TimeDelta multiplication to any actions that don't already involve it at runtime? That would be even easier and would allow the numbers to stay the same inside the program while the objects are moved and etc at Time Delta.

For example, the value of "speed" is at 10 but Construct moves the object at "speed * TimeDelta"
"Construct 4 lets YOU make advanced games! (maybe)" Construct Classic - Examples Kit
B
86
S
28
G
13
Posts: 2,092
Reputation: 15,009

Next

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 3 guests