Animation Speed

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.

Yeah, pretty sure it's frames per second.

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).

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 ) -- 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!

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.

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.

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.

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.

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!

Hopefully now I can get some real opinions.

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.

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"

Can you set an animation speed to something like "3.7" ? not just whole numbers, and will it make a difference?

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.

how would it tell the difference between something like:

on button clicked -> set x to x+10

always -> set x to x+10

the always one you want timedelta with, the button one you dont

if you know about timedeltas from the start (fallen into that trap aswell) its really not that hard to implement them

if you know about timedeltas from the start (fallen into that trap aswell) its really not that hard to implement them

The problem is that if this is a problem for someone like Kayin who made IWBTG, how hard would it get for people who have never made games before? People who Construct is aimed at. Sure, there are workarounds, but most people will lose hope before they have the effort to try them.

The problem is that if this is a problem for someone like Kayin who made IWBTG, how hard would it get for people who have never made games before? People who Construct is aimed at. Sure, there are workarounds, but most people will lose hope before they have the effort to try them.

All the built-in behaviors do this automatically for you. So it's only a problem if you go making custom movements as kayin is doing here - and if you make custom movements, you need to know about TimeDelta. Also, there's no band-aid fix for this - as faggatron said, you can't just automatically apply fixes - if you move objects by yourself, the runtime can't tell if it's a constant speed or a simple change of position.

I admit I didnt understand timedelta at first, but after reading the wiki page on it a couple of times it's easily doable for anyone capable of using construct at all. Once you know roughly where you should be adding it, there usually isn't that much thought required.

When I didn't know timedelta existed, started making a game, then tried to add it afterwards I did end up just breaking the game, so its not really ideal, as it is pretty much vital - I just can't see a better alternative to it.

One tip for doing this I think is to remember that timedelta is roughly 1/fps, so if the rate it would usually be fixed at is 60, then instead of: set x to x+5, you can do set x to x+5*60*timdelta, then when the FPS is about 60 the timedelta and the 60 cancel eachother out and you've got what you wanted. Probably just stated the obvious heh.

Also, maybe construct is aimed at people who've never made games before, but I don't think thats who it should be aimed at - what it should be is anyone who wants to make a game, but doesnt want to learn a programming language. Just as much aimed at people who want to make complicated games as people who have never made a game at all.

This is probably actually who it's aimed at but it sometimes seems people who have never made a game are the priority right now.