Animation Speed

Oh, I understand what you both mean now, I think I need to reread the wiki on TimeDelta a few hundred more times

I don't think time delta is a 'problem'. Most people who are going to move to a custom path should be able to grasp time delta. I do and for a basic platformer engine or something like IWBTG, I would be able to handle it. The problem arises now because I'm doing something and demanding a lot of precision from it. The more I think about it the more I think I can convert it to work. Anyways, a few things.

First, I'd suggest a command along the lines of 'move object by time", which will move an object to whatever coordinates over a length of time. This doesn't accomplish anything that can't be handled now, but would address the needs of many people working on the behavioral level and would simpify some stuff for advanced users. Doesn't help me with what I'm doing, but I think it'd a good 'accessibility' thing. (also have a tick version plz )

Secondly, shouldn't there be a way to the game adjust automatically? I'm used to hearing good technical reasons for why things can't happen around here (so I'm expecting a 'no'), but I still have to bring it up just in case. I didn't have to do anything like this in Multimedia fusion 2, I could simply set the game to skip frames instead of slow down. I'm going to imagine that most of the FPS problems for most games are on the rendering end -- isn't it possible to still run logic for 60 frames while only updating things visually at a more sustainable frame rate? Or if not, some other solution? I mean, it certainly has been done before, but I can't be sure the limitations presented by the way Construct is designed that would allow/disallow certain solutions.

Construct can certainly live with timedelta,that's for sure, but automating things like other game makers have would certainly go a long way on helping along more advanced construct functions while not confusing lower level developers.

Anyways, I'm going to go play with converting my engine to see if it'll work. Either way I'll live, but I hope my suggestions are both workable and desirable.

Edit: Oh and don't worry Jayjay, I already hijacked my own thread.

Okay, I've made a deal of progress, and it seems most stuf is up to par. But since I don't have a good way to drop or boost my frame rate, I can't test a few things so I want to as another timing issue (someone should just rename this thread to something more accurate XD).

Anyways, my question is whats the best way to keep a decreasing value in sync witht he actions on screen? Especially since the (every X) action doesn't have the resolution to try and match 1 tick in 60 frames. I can do it for 20 milliseconds which might be close enough, but not as smooth. Is there a better way? I can use delta time of course, but I fear dealing with these values as decimals. Thoughts?

I don't have a good way to drop or boost my frame rate,

Set framerate mode to unlimited to boost and fix it on like 20 to drop.

Anyways, my question is whats the best way to keep a decreasing value in sync witht he actions on screen? Especially since the (every X) action doesn't have the resolution to try and match 1 tick in 60 frames. I can do it for 20 milliseconds which might be close enough, but not as smooth. Is there a better way? I can use delta time of course, but I fear dealing with these values as decimals. Thoughts?

cant you just use timedelta then use int(x) where you need it? (Construct's never really given my any problems with using floats for anything apart from using the % function)

I was playing IWTBTG because someone mentioned it. (you're a bastard

Secondly, shouldn't there be a way to the game adjust automatically? I'm used to hearing good technical reasons for why things can't happen around here (so I'm expecting a 'no'), but I still have to bring it up just in case. I didn't have to do anything like this in Multimedia fusion 2, I could simply set the game to skip frames instead of slow down. I'm going to imagine that most of the FPS problems for most games are on the rendering end -- isn't it possible to still run logic for 60 frames while only updating things visually at a more sustainable frame rate? Or if not, some other solution?

I can't think of a way to automate the timedelta adjustments. The built in behaviors ideally would do everything you wanted, and with a timedelta based engine, but I guess we're not there yet. And as faggatron said, the engine can't tell the difference between continuous and one-off movement, so it isn't really possible to add it. I don't think it is a complicated thing for users to code, even if it is frustrating to retro-fit it on to a tick based engine - I think TimeDelta is an appropriate and good solution to the problem. For example, running events at 60FPS and displaying at 75FPS means at some point you display the same frame twice without running any events, so you're not actually genuinely achieving 75FPS. It would be pointless.

I can't think of any reason you wouldn't want to use a V-synced display for games (other than complaining about TimeDelta!) and I can't think of any legitimate uses for anything to be tick-based in Construct. It should all be based off real seconds. That's technically the best solution, which results in best quality games. If MMF2 doesn't implement it, it doesn't mean it works fine, it still suffers from all the problems of tick-based engines. I say this a lot, and I'll say it again: use V-sync, and use timedelta based engines! It's the only way to design a game that isn't going to tear the display, and isn't going to run at different speeds for different people. If you have a fixed framerate, your games will look ugly because they can't V-sync. And if your game slows down due to poor hardware, it will start crawling along reaaallly slow. Timedelta engines keep the gameplay going at the intended speed even if the system can't hit V-sync framerates.

The whole premise of a fixed framerate is flawed because if a user's system can't achieve that framerate, nothing you've coded runs at the intended speed. You can fix your framerate at 60fps if you want, but someone's old PC might end up running it at 20fps anyway! Do you want the game to run three times slower than it should for them?

I'm not out to shout you down here or anything - I just think there's a clear case for never using fixed framerate and always using V-sync. I might even add a warning dialog if you choose a fixed framerate. It's not suitable for games. TimeDelta is not a difficult concept and game designers should go to the trouble of learning just a little about it, in order to design games which are fairer, better quality, and more professional.

Convinced?

> Secondly, shouldn't there be a way to the game adjust automatically? I'm used to hearing good technical reasons for why things can't happen around here (so I'm expecting a 'no'), but I still have to bring it up just in case. I didn't have to do anything like this in Multimedia fusion 2, I could simply set the game to skip frames instead of slow down. I'm going to imagine that most of the FPS problems for most games are on the rendering end -- isn't it possible to still run logic for 60 frames while only updating things visually at a more sustainable frame rate? Or if not, some other solution?

>

I can't think of a way to automate the timedelta adjustments. The built in behaviors ideally would do everything you wanted, and with a timedelta based engine, but I guess we're not there yet. And as faggatron said, the engine can't tell the difference between continuous and one-off movement, so it isn't really possible to add it. I don't think it is a complicated thing for users to code, even if it is frustrating to retro-fit it on to a tick based engine - I think TimeDelta is an appropriate and good solution to the problem. For example, running events at 60FPS and displaying at 75FPS means at some point you display the same frame twice without running any events, so you're not actually genuinely achieving 75FPS. It would be pointless.

I can't think of any reason you wouldn't want to use a V-synced display for games (other than complaining about TimeDelta!) and I can't think of any legitimate uses for anything to be tick-based in Construct. It should all be based off real seconds. That's technically the best solution, which results in best quality games. If MMF2 doesn't implement it, it doesn't mean it works fine, it still suffers from all the problems of tick-based engines. I say this a lot, and I'll say it again: use V-sync, and use timedelta based engines! It's the only way to design a game that isn't going to tear the display, and isn't going to run at different speeds for different people. If you have a fixed framerate, your games will look ugly because they can't V-sync. And if your game slows down due to poor hardware, it will start crawling along reaaallly slow. Timedelta engines keep the gameplay going at the intended speed even if the system can't hit V-sync framerates.

The whole premise of a fixed framerate is flawed because if a user's system can't achieve that framerate, nothing you've coded runs at the intended speed. You can fix your framerate at 60fps if you want, but someone's old PC might end up running it at 20fps anyway! Do you want the game to run three times slower than it should for them?

I'm not out to shout you down here or anything - I just think there's a clear case for never using fixed framerate and always using V-sync. I might even add a warning dialog if you choose a fixed framerate. It's not suitable for games. TimeDelta is not a difficult concept and game designers should go to the trouble of learning just a little about it, in order to design games which are fairer, better quality, and more professional.

Convinced?

it's not that I'm necessarily unconvinced -- which is why I am currently working toward this end -- it's that I think the situation is suboptimal. With the added stability and sensibility and just overall goodness presented by Construct, this is a trade I'm willing to make.

I just checked in MMF2 and I Can V-Sync it while insuring machine independent speed -- well, within reason. At really poor frame rates (15ish?) the game does slow down, but whatever (who's going to play a game at less than 15 frames per second?). IWBTG never really needed it so i never bothered, but it doesn't seem to do anything to the logic of the game. I just get less frames per second.

So the way i'm looking at things, what are they doing that you can't replicate? Pretty much everything else in construct, if not already superior to MMF2, is being on the track to soon surpass it. Anyways from my experience, it's not that objects are moved in a deltatime-ish fashion when subject to slowdown, but that logic is handled separately from display. if i have a value increase by 1 every cycle and a 60 frame game is only running at 50 frames per second, I still end up with 60 at the same time.

Anyways, I'll be okay. I'm just speaking for what I think would be beneficial for construct and what, from my end (which is limited, as I do not have the knowledge to understand the constructs source) seems like it should be, in some way, possible. In the end, I'm just giving my feedback, which you can do whatever you want with.

I will miss the precision of doing things tick based though and will be very happy if you DO come up with a way to handle this -- but if not, I don't doubt you'll be working on plenty of other great things. I'm just giving my two cents as someone who is serious about making games and has some experience with other software and a good idea of what he'd like to see in the hopes of both bettering construct and my own game. I just hope some of the stuff is helpful feedback and not headache inducing griping.

> I don't have a good way to drop or boost my frame rate,

>

Set framerate mode to unlimited to boost and fix it on like 20 to drop.

> Anyways, my question is whats the best way to keep a decreasing value in sync witht he actions on screen? Especially since the (every X) action doesn't have the resolution to try and match 1 tick in 60 frames. I can do it for 20 milliseconds which might be close enough, but not as smooth. Is there a better way? I can use delta time of course, but I fear dealing with these values as decimals. Thoughts?

>

cant you just use timedelta then use int(x) where you need it? (Construct's never really given my any problems with using floats for anything apart from using the % function)

I was playing IWTBTG because someone mentioned it. (you're a bastard

Heh, I forgot Fixed Frameratewould actually work BECAUSE of delta time. I'm just used to it slowing down the whiole game. Anyways the problem with decreasing by a float is when I use "=" statements in my timers. I guess I could handle this by checking for rounded values... But another example is the strings I use to detect the fighting game-esque inputs. Basically when they're running they look like...

'**,*,*,*,*,*,*,*,*,*,*,*,6,2,3' with the * representing the countdown before the input window has expired and the numbers representing directions as if on a num pad (a notation we fighter fags love, even though I could just make them all one character with the way the command reader works. ). Anyways, the string slowly decays with each element of the string getting eaten every tick, until there are no more *s. When that happens, you have ran out of time since your first input to execute the move (In this case a Dragon Punch/Shoryuken). It basically defines how fast you have to input the entire motion.

Obviously I can't delta time this, but doing it at 20ms besides per tick would work, though I'm not sure what sort of random elements this might introduce.. For example, the input window dropping by one frame/20ms since the last two characters end up getting eaten before the next frame shows. At 30 fps, this would be highly likely. A variance of 1/60th of a second isn't problem inducing (especially if the input window is reasonable), but its the time of imperfections I worry about when dealing with delta time.What if I NEEDED it to be exact?

I worry about this crap too much.

I dunno about the accuracy of the timer, but I've used it and it worked find for my purposes.

Maybe this wouldn't be more accurate but couldn't you (instead of using every x) make some value x and do:

always -> add 10*timedelta to x

x>1 -> SOME ACTION

obviously changing the numbers.

I expect this isn't actually any different than using the timer though, since timedelta is the time since the last tick, correct me if im wrong, but always add timedelta to x would just be = timer(????)

I don't actually see the point in adding skip frames, since timedelta is always preferable, and if there was an option for that would you be bothering to learn all this timedelta stuff?

I just checked in MMF2 and I Can V-Sync it while insuring machine independent speed

Are you enabling 'Machine independent speed'? If so, that was designed for a fixed framerate engine so isn't doing anything useful when V-Sync is on. It is designed to skip drawing the screen if it can't hit the fixed framerate, which won't look pretty. Games look best if you can get the game to display once every V-sync. And if it's off, tough luck - your game is framerate dependent and will run at different speeds on different computers. So I disagree, your game either displays badly or is not running at a framerate independent speed.

[quote:33omzzwg]So the way i'm looking at things, what are they doing that you can't replicate? Pretty much everything else in construct, if not already superior to MMF2, is being on the track to soon surpass it. Anyways from my experience, it's not that objects are moved in a deltatime-ish fashion when subject to slowdown, but that logic is handled separately from display. if i have a value increase by 1 every cycle and a 60 frame game is only running at 50 frames per second, I still end up with 60 at the same time.

One of the main goals of Construct is to achieve a high quality display for the game. You need V-sync to do that, and skipping frames or running logic at a different rate to the display rate is not as good a solution as just using timedelta. If I implement any of your suggestions I really believe it will result in lower quality games. And if other game development programs choose to go down that path, well, that's not my problem

If you want a counter to increase by 60 a second, just add 60 * TimeDelta to it every tick. It's really that easy. Instead of coding your games to run tick by tick and just hoping for the best that your game will end up running that fast on the plethora of computers out there, games should be coded to work out how much time has passed in the last tick (that's TimeDelta), then advance the gameplay logic by that amount of time. Oh, then you can also use motion blur, timescaling (slow-motion) and other timer-affecting features. So this is how Construct is designed: code your games to advance the game logic in units of time, not ticks.

[quote:33omzzwg]Anyways the problem with decreasing by a float is when I use "=" statements in my timers.

Timers? Can't you use 'Every X milliseconds' instead? As the name suggests, it works in units of time Or, if you decrease using a timedelta-based value, use "less than or equal". In the event, add the timer interval back to the counter (eg. 'TimerValue' less than -0.5: add 0.5 to 'TimerValue'). It will trigger reliably every half a second and this method also compensates for rounding errors meaning it is as accurate as possible.

[quote:33omzzwg]Anyways, the string slowly decays with each element of the string getting eaten every tick, until there are no more *s. When that happens, you have ran out of time since your first input to execute the move (In this case a Dragon Punch/Shoryuken). It basically defines how fast you have to input the entire motion.

[quote:33omzzwg]I will miss the precision of doing things tick based though

On the contrary, the system you have just described is most imprecise! If you use ticks to measure the time you have left to perform an action, and someone's rubbish computer runs at 30fps instead of 60fps, they have twice as long to complete the action so the game is twice as easy for them. Really, that's precise? Sure, you can sacrifice the display quality of your game to make it work, but why on earth would you do that... when you could just code your game properly?

If you need it to be exact, use a timer to determine whether the time in seconds has elapsed for them to perform the action. It's perfectly precise: either enough time has passed or it hasn't. 'TimeDelta' is accurate to within microseconds, and in the next build of Construct, the main timers are as well.

I think you are looking at this the wrong way round: tick based games are imprecise, unfair and unreliable, and just being lazy about rendering the display is a poor way to try and half-fix the problem. Whether or not other programs do it the right way or not doesn't affect how I think Construct should tackle the problem. And I think I've done it the right way: the best possible display quality, and a simple way to code timer based games. Don't be lazy or prejudiced. Timedelta for the win.

Out of interest (the reason my other game broke when adding timedelta) how would you change something (at say 60 fps) like:

always - > set x to x*0.9

to use timedelta.

Since the amount that's being subtracted is changing constantly (and not even at a constant rate) it became hard for me to work it out, then I started approximating and it went downhill from there - I used this as a vital part of my engine and when I couldnt make it work the same it just broke everything.

i will concede most of your points on this.. though I don't see how implementing something to keep logic and game speed moving at the same speed, despite display would possibly would possibly decrease the quality of games, but i take your word that you can't implement it and that the two options don't actually do anything together in MMf2 (I couldn't really test it due to the lack of scrolling in the game).

That said, while I concede your point about input windows, it was more serving as an example of something possibly ending up working weird on a time based scale. When I refer to 'precise' i mean that i will arrive to the same conclusion every time and that I can predict what will happen on every frame. i agree that slow down is in no way elegant or desirable, but I wouldn't describe it as imprecise. Right now if I were to decrease a value in respects to time delta, I couldn't for example safely do my whole 'equal' statement thing. I'm of course very glad to hear that timers will work fine, but I wanted confirmation.

Anyways, I would describe this as imprecise. I cannot be sure what the variable will be when it crosses the the desired number, and even if i set a range, frame rates of 30 or 15 could skip right over it. Can I work around it? Sure, and I am (thank you too for the reassuring information i needed to do so), and i'll be fine... but I still will be sad not to have that sort of comfort.

Anyways at this point this is mostly semantics (so no need to argue , I'm just clarifying what -I- think of as imprecise... I mean, unless you really want to ;P). Even if i don't like the few cons that exist, the pros are still very desirable.

Anyways, I think I'm good for now, as long as timers behave right (and they seem to). One small thing. I might have some other concerns at a later point regarding this, but i'm going to wait till i can test them before assuming the worst. As always, thank you for your patience with my stubborn ass.

Edit: Oh and faggatron gives a good example of what I see as impercise. Fortunately though my engine seemed to be mostly okay with the change over.

... And my concerns begin to rear their ugly heads. For now I'm ceasing all work to convert to VSync/Delta Time.

But I will not do so without showing WHY, in hopes that I am either missing something or, if there is a problem, that it gets addressed with an adequate solution.

http://kayin.pyoko.org/hatevsyncmode.cap

The actual test is the two cubes at the start. It's put in the engine as to help strain the fps. As you can see if you bother looking (no need) the delta time implementation on the actual engine is probably pretty sloppy. I was sort of messing with ways to try and make it work smoothly at low FPS, when I noticed some inconsistencies. Not sue if these were a result of me missing something, I made the test (three linesof code at the bottom). Fortunately for me,when I unplug my laptop I can throttle down the CPU, allowing me to test at much more flaky FPSs. Some of you might not be able to test this as I imagine a lot of people can run it at a high, stable FPS, but the results are real.

On consistent FPSsof 60, the cubes mostly behave properly and stop in the same spot every time. Sometimes they're off by a pixel, with the Yellow being most consistent.

At lower FPSs, (30-45) they stop in different directions. The Yellow one is still the most consistent (Though not consistent enough in my opinion) and the blue one is often radially off. Using R to restart the event, occasionaly even the yellow one stops as much as around 30 pixels too far.

This is totally unacceptable in my opinion, and these are very simple examples. I cannot risk inconsistent jumping distances or anything else. I think I can tolerate tearing and slow down (my actual preference, personally), over these issues.

(Sorry for the triple post -- you should consider allowing edits at any time, but I would just like to apologize if I'm coming off as harsh, because I'm just quite frustrated with all of this and I do not want to sacrifice quality. I am actually still experimenting with Time Delta and completely rebuilding parts of the engine, but still, the above has me very concerned. Sorry again. )

Okay, last post till I get a reply. I just did my last bit of testing for now, but under enough strain even the build in platform behavior varied, sometimes as much as 10 pixels (!!!). 14-15 frames per-second is a pretty rough time but I saw variation in the realm of 3-5 at 30ish. This is very problematic in my opinion overall.

Honestly that is currently a deal breaker for me. My gut says I should accept zero variations in jump height or time based movement. My realistic mentality says I can suck up 1-3, though it's more the rare high end that worries me(People getitng to places they aren't supposed to yet due to lag is worrisome to me, especially if there are larger, rarer jumps).

I make a plea that, if you cannot address these issues (and for most people I'd imagine this isn't a breaking issue), I quietly beg you for a way to allow animations to move on a tick scale. Currently I'm using time delta (Ironically) to figure out the FPS of the game and setting all animation speed to that, which works 'okay' but I'm sure it has to be flaky in some ways. I'd rather take speed inconsistencies between machines then gameplay inconsistencies by a LOT.

(But i'm hoping you actually acknowledge and address the underlying issue instead)

As always, sorry for being a pain in the ass.

If you're really that hard set on tick-based animation, there's nothing stopping you from doing it.

Set your animations to no loop, and 0 frames per second. That way they won't auto-play on their own.

Then make a custom tick-based animation routine of your own, manually setting the animation frame when you need it. I can't imagine this would take more than a handful of events.

If you're really that hard set on tick-based animation, there's nothing stopping you from doing it.

Set your animations to no loop, and 0 frames per second. That way they won't auto-play on their own.

Then make a custom tick-based animation routine of your own, manually setting the animation frame when you need it. I can't imagine this would take more than a handful of events.

An issue here, for example, is the need to alter the timing on a frame by frame basis. I could, say, make a string variable for each animation that stores the right information and then play it off.I know I can do it, but it'd be nice if I didn't have to make all these alternatives to features already in construct.

Anyways it's not that I'm set on a tick based system (Or else I wouldn't keep going back to pull my hair our and mess with this stuff), I'm set on precision. I want things to play out the same way every time, regardless of speed. This is more important to me than tearing or playability at low FPSs, though these things are ALSO important. Right now I'm finding my self stuck between a rock and a hard place and I'm more hoping Ashley will seem the same problem I do and will have some sort of solution. I'm totally willing to work with timedelta at this point, if it can supply what I need.

(I still think the idea (until Ashley tells me why )