Animation Speed

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.

I don't mean to sound flamey here, and I definitely don't mean any disrespect... but if you can do it, then why don't you? Ashley has stated his case for why Construct is made the way it is. You're asking for a rather fundamental change to Construct's engine, and all for a problem that's very specific to what you need done (and no one else).

The level of precision that you're seeking is something that I think only God and a handful of fighting game enthusiasts who can think between animation frames would appreciate. The kind of players like my ex-roommate Karl who own their own fighting game stick and carry it with them on the bus to the arcade to practice for tournaments. Not that there's anything wrong with that... he was really friggin good.

Anyway, my point is this: If one is seeking a change to the way Construct works, and one is in the minority of users who need this change, and this change can be accomplished with events, then the logical answer is to just make it with events.

Such is the burden of specialization. It takes more work, and fewer people appreciate it.

[quote:ol04pk7t]strain the fps

Just a quick tip - set a fixed framerate of 15 or so in application properties. It's a nice way to simulate a low framerate.

[quote:ol04pk7t]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.

There are inaccuracies in a timer based game. Ticks will not fall on the same timer values every time. For example, if you have "Timer less than 50 ms" as a condition, the first execution could have tick 5 falling at 49ms (condition evaluates to true), or tick 5 falling at 51ms (condition evaluates to false). This is the difference between running the actions either 4 times or 5 times - resulting in a maximum error of one tick. So you can calculate the maximum possible values of motion etc. in your games: over 50ms that's a maximum of timedelta summing up to 0.05, and if you move at 100 pixels per second, that's a maximum of 5 pixels covered. Any errors will result in a smaller value - so you can ensure the player cannot reach locations they could not otherwise reach. It does bias advantage to the higher framerated players - they are less likely to have their values reduced by these one-tick errors - but it is a subtle variation. You can do a few things to get around it too - for example, if the timer is greater than 50ms, set the position to the maximum possible distance. You'll have a box that moves across at a uniform speed and always lands up in the same place. A few more events, yes, but I am pretty sure this is how commercial games do it as well.

In other words, the error is small, only ever reduces from the maximum value, and gets smaller the higher the framerate. I know you might feel differently, but I think a level of imprecision is going to be inherent and necessary in all games. If someone's crappy PC jumps 7 pixels short I don't think the game is THAT unfair, and I doubt anybody would ever notice either. And I doubt your game requires you to pole vault on to 5 pixel wide platforms!

It may seem nice in your mind to be able to calculate the precise values that occur over a tick based game, but I doubt a 10 pixel error would ruin your game, and it'll be a smaller error for the 95% of us that can achieve a non-hilariously-bad framerate. In a practical sense, I doubt it matters. Do you think the player can reliably perform the same actions to within a 10 pixel accuracy? And the advantages of using a v-synced timer based game are huge.

I've said everything I can to try and persuade you to avoid tick-based code - and I'm sorry to insist, but I don't want to implement features that might encourage people to go down a tick-based route, because I really think it's a poor way to design games. I want Construct users to be guided in to making well-designed games - even if it is slightly more difficult!

And no, of course this is nothing personal and I'm not offended by anything you say. This is a technical discussion, and I'm just trying to convey the pros and cons of both ways

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

>

I don't mean to sound flamey here, and I definitely don't mean any disrespect... but if you can do it, then why don't you? Ashley has stated his case for why Construct is made the way it is. You're asking for a rather fundamental change to Construct's engine, and all for a problem that's very specific to what you need done (and no one else).

The level of precision that you're seeking is something that I think only God and a handful of fighting game enthusiasts who can think between animation frames would appreciate. The kind of players like my ex-roommate Karl who own their own fighting game stick and carry it with them on the bus to the arcade to practice for tournaments. Not that there's anything wrong with that... he was really friggin good.

Anyway, my point is this: If one is seeking a change to the way Construct works, and one is in the minority of users who need this change, and this change can be accomplished with events, then the logical answer is to just make it with events.

Such is the burden of specialization. It takes more work, and fewer people appreciate it.

I don't mean it as a fundamental change, but as a possible option. If it were too much of an undertaking, I wouldn't fault Ashley for not implementing it. Also your room mate sounds like me. My stick just happens to be right next to me right now, and I went as far as making it my self (with help) out of aluminum. So I admit, in a lot of ways, I'm on the obsessed side.

But I do thing the issue in variable jump height, even in the default behavior, is problematic. Its a big deal when someone can or can't jump some where, and more problematic when things can take a more sudden jump randomly. I think this a rather important thing to address.

Anyways, fortunately I'm not working on anything currently where I need to worry about whither or not I'm going to switch to time delta later or anything, so I can wait to hear what can or will be done if anything. I'm prepared to do what I need to, to make a good game. I don't want to shoot my self in the foot, but I don't want to shoot my self in the head either.

[quote:131hqgya]strain the fps

Just a quick tip - set a fixed framerate of 15 or so in application properties. It's a nice way to simulate a low framerate.

[quote:131hqgya]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.

There are inaccuracies in a timer based game. Ticks will not fall on the same timer values every time. For example, if you have "Timer less than 50 ms" as a condition, the first execution could have tick 5 falling at 49ms (condition evaluates to true), or tick 5 falling at 51ms (condition evaluates to false). This is the difference between running the actions either 4 times or 5 times - resulting in a maximum error of one tick. So you can calculate the maximum possible values of motion etc. in your games: over 50ms that's a maximum of timedelta summing up to 0.05, and if you move at 100 pixels per second, that's a maximum of 5 pixels covered. Any errors will result in a smaller value - so you can ensure the player cannot reach locations they could not otherwise reach. It does bias advantage to the higher framerated players - they are less likely to have their values reduced by these one-tick errors - but it is a subtle variation. You can do a few things to get around it too - for example, if the timer is greater than 50ms, set the position to the maximum possible distance. You'll have a box that moves across at a uniform speed and always lands up in the same place. A few more events, yes, but I am pretty sure this is how commercial games do it as well.

In other words, the error is small, only ever reduces from the maximum value, and gets smaller the higher the framerate. I know you might feel differently, but I think a level of imprecision is going to be inherent and necessary in all games. If someone's crappy PC jumps 7 pixels short I don't think the game is THAT unfair, and I doubt anybody would ever notice either. And I doubt your game requires you to pole vault on to 5 pixel wide platforms!

It may seem nice in your mind to be able to calculate the precise values that occur over a tick based game, but I doubt a 10 pixel error would ruin your game, and it'll be a smaller error for the 95% of us that can achieve a non-hilariously-bad framerate. In a practical sense, I doubt it matters. Do you think the player can reliably perform the same actions to within a 10 pixel accuracy? And the advantages of using a v-synced timer based game are huge.

I've said everything I can to try and persuade you to avoid tick-based code - and I'm sorry to insist, but I don't want to implement features that might encourage people to go down a tick-based route, because I really think it's a poor way to design games. I want Construct users to be guided in to making well-designed games - even if it is slightly more difficult!

And no, of course this is nothing personal and I'm not offended by anything you say. This is a technical discussion, and I'm just trying to convey the pros and cons of both ways

I am very sad to hear this. I really feel strongly as a game developer working on an imprecise scale is acceptable, but I respect your disagreement. As much as I would like to V-Sync the game, consistency is far more a concern of mine. Perhaps I'll do a little more testing to see if I can reduce the variations to something I find tolerable. But would you at least humor me with two answers.

1) You said precision in time based events will be improved in the next release. Does this mean I can perform time based activities on a much faster scale -- say, reducing each burst of movement from say.. 6 to 1 or 2, to try and minimize the variations?

2) In what way would separating logic and display be either impossible or undesirable? It seems to me most games run in this way and would have the benefits of both tick based precision and computer speed/FPS independence for V-Syncing. I want this suggestion to stop haunting me.

[quote:3s1anf2w]But I do thing the issue in variable jump height, even in the default behavior, is problematic. Its a big deal when someone can or can't jump some where

We're talking a difference of maybe 10 pixels here. Do you really have areas you can't jump to if you fall 10 pixels short? Or areas you can reach if you jump another 10 pixels high? Really?

[quote:3s1anf2w]1) You said precision in time based events will be improved in the next release. Does this mean I can perform time based activities on a much faster scale -- say, reducing each burst of movement from say.. 6 to 1 or 2, to try and minimize the variations?

Sorry, I don't quite understand... are you talking about 6 milliseconds? The Every event can't trigger more than once a tick, so at 75fps you can't trigger an Every more frequently than once every 13.3ms.

[quote:3s1anf2w]2) In what way would separating logic and display be either impossible or undesirable? It seems to me most games run in this way and would have the benefits of both tick based precision and computer speed/FPS independence for V-Syncing. I want this suggestion to stop haunting me.

Suppose you run the logic at 50fps and the display at 100fps. So you'd run: logic, display, display, logic, display, display... you're drawing the screen twice without running any logic in between. Which means you're redrawing an identical screen again, because nothing's changed. That's a waste of processing time.

Suppose you run the logic at 100fps and the display at 50fps. You'd run: display, logic, logic, display... or, between every drawing of the screen, you run the game logic twice. So any 'x = x + 1' become 'x = x + 2'. Except it's twice as much processing work on the logic. Which is a waste of time.

So as far as I can see, making the logic and display rates ends up just wasting processing time. You may as well do them in sync.

We're talking a difference of maybe 10 pixels here. Do you really have areas you can't jump to if you fall 10 pixels short? Or areas you can reach if you jump another 10 pixels high? Really?

This is the only thing that caught my attention. What if someone is making a retro game, low resolution and all, I think every pixel is important.

1-3 pixels seems fine, 10 actually doesn't. I guess though if Construct isn't intended for older styles and smaller pixel art, then they can go elsewhere.

At 1080p resolution, 10 pixels is nothing ... at 320x240 or so ...

If I sound rude, I don't mean to hehe. I work with mobile phones and 10 pixels is a big deal

Here's my input, sorry to butt in and all, but i used to make tick based games, granted i was no expert, but as soon as i found out how to use timedelta properly, i found my games were MORE accurate if anything else PLUS they weren't dependant on the refresh rate being a certain speed.

With timedelta, you can do everything per second, how fast things move, accelerate or turn, or how long things take to do something, etc etc, i found i had a huge control over everything and knew the exact speeds and everything.

Plus with time scaling, using timedelta just becomes even more fun!

Everything just depends on how good your events are.

After working with timedelta, i can't actually think of a need to use a tick based engine :S

I'm sure it's been explained but there's certainly a lot of text in this thread

lol, I just realized you guys are discussing ticks (no idea how I missed that) ... I thought there was pixel differences elsewhere.

I actually have nothing to add then lol.

Jeswen: Well remember,this is the default options for jumping. You jump, I dunno... 300 pixels? Maybe less, but it's a lot. If someone is making a retroish game I'd imagine the variance would be quite less. In fact, let me test this

(Insert testing)

Okay, maybe not. at 500 jump strength I got a variance of.... .. 10 pixels. Granted this didn't happen in subsequent tests, but this is the stuff I worry about. Either way, its probably still less likely.

(edit: Oh, I see. XD Ah well.)

Arcticus: I did testing on this subject already. As has been explained in the obnoxious amount of text, time based movement can suffer from differing amount of movement and jump height based on FPSs. If you don't rely on behaviors, things will sync up perfectly frameby frame. Of course, Ashley has stated many disadvantages to this, that I think stand true for most developers.

Ashley: Clearly you never played IWBTG! As it stands I would not be able to make a similar game, as it was a game with a lot of pixel perfect jumping and traps. Granted it's also a very silly game and a design philosophy (or lack of one

Anyways, about timers, wouldn't possibly looping the event twice when necessarily be good for keeping things in sync? This point is more hazy to me then other ones, but it's just a thought.

As for the 'waste of processing', in a way I'm going to disagree. I think you're thinking on a very display oriented manner. The wayI look at it, the logic has to be run anyways. Its an exact system. Much like having an event run every 20 ms, I want all my events to run 60 times a second. Granted some people don't need it to be an exact system, but as constructs user base grows, I believe the demand for something like this will increase. I mean, I can think of things in three ways.

You sacrifice visuals and speed independence for exactness (me right now)

You sacrifice exactness for for visual, speed independence (What most people would be good with)

You sacrifice performance for exactness, speed independence and good visuals. (What I'd prefer)

You're concerned about the quality of construct games visually, but with constant fps mode, you give an undesirable out for people like me (and those in the future). With a third option you maintain the visual integrity, at the sacrifice of performance. Sort of a middle ground approach.

Much like the idea you had to have a warning prompt when selecting constant FPS, you could simply go over the costs and advantages of each mode and by all means, say standard V-Sync is best. I actually do think its a better fit for most people, but the 3rd option will be very usual when people realize the power of construct as a game development platform. I'm sure you're worried about the option being an 'easy out' for some people, but as of now, the 'easy out' is Constant FPS, which has numerous disadvantages, but will likely get used anyways. I certainly will be if I can't get a time delta system that works to my requirements. Again, I don't think I'll be the only one. So please seriously consider this. Discourage it as much as you want when you select it (probably a good idea), but I think having a system that delivers the maximum amount of flexibility to the needs of developers while maintaining visual integrity is in everyone's best interests.

We're talking a difference of maybe 10 pixels here. Do you really have areas you can't jump to if you fall 10 pixels short? Or areas you can reach if you jump another 10 pixels high? Really?

heh thats not a particularly good argument, I mean the fact is you might.

I think this proposed logic display separation would solve kayin's problem, only thing is I don't see it as a very big problem - (I mean its spot on 99% of the time right? - if you're running it at 1fps its gonna be unplayable on any mode you try - a 10 pixel variation will be the least of your worries).

Saying that it might be nice to have an option - if it's not insanely hard to add. I probably wouldn't ever use it and the same probably goes for most people - so if it is a lot of effort its probably not worth it (sorry kayin ).

> We're talking a difference of maybe 10 pixels here. Do you really have areas you can't jump to if you fall 10 pixels short? Or areas you can reach if you jump another 10 pixels high? Really?

>

This is the only thing that caught my attention. What if someone is making a retro game, low resolution and all, I think every pixel is important.

True. I wasn't thinking of retro games, I was thinking of the kind of game I (want to) make, hi-resolution displays and detailed graphics and all. I can see this is a problem for retro games (sorry I didn't check out IWBTG sooner to arrive to this conclusion ) so it becomes a problem for this special case. Still, I'm sure the error would be smaller for decent framerates, and retro-games are usually so low resolution you'd never have any drop in framerate. And the error would be further less assuming small, pixelly games would generally have things moving at lower speeds.

Running the display and logic asynchronously isn't the right solution for games which fiddle on the pixel level, but I can think of something similar. There could be a mode where the display is V-synced, but the runtime returns a constant value for TimeDelta. For example, if TimeDelta always returns 0.01 regardless of the real value, the built in behaviors and any custom timedelta-based movements would be absolutely exact and work the same way every time.

Then you have a high-quality display which is exact, but it will still run at different speeds depending on the refresh rate of your monitor. I still don't like that, it makes me think of the DOS games on the old 486 computers decades ago, which ran depending on the speed of your processor. Buy a new CPU and the whole game speeds up... some computer manufacturers even put a "slow" mode on their cases to stop games running ridiculously fast

Digressions aside, I could (somewhat reluctantly) do the same thing for fixed framerate so the display tears and it plays out the same way every time, and would only ever slow down if the processor couldn't keep up, which is unlikely for retro-style games. I guess this would also silence people who want the physics to play out the same way every time too!

So I'm proposing a kind of 'Override TimeDelta' option. I think this would solve everything that's been brought up. And if you have a change of heart, you could then easily switch your game to using real TimeDelta values

Sound good?

That sounds excellent, but some more things to consider. I think the reason I'm getting bigger numbers when it comes to test is because, unlike say, using constant 15 fps, my 15 fps environment is 'real'(as in the computer is set to not be able to catch up)In situations around 15-30 FPS, frame rate is very unstable, causing, I think, further innaccuracies are caused through this, such as the big '32' pixel leap with that one test.

So what I would recommend is a way to get the real time delta, even in this mode, and further a way to SET the artificial time delta. so in this situation I could 'update' the artificial time delta to match the display to get proper speeds and, even if it does cause some differences, these differences will be consistent and more predictable/testable. Heck, I could even have it 'forbid' certain exact time delta values that would allow a timer to overrun for one tick. I could even have it update periodically in 'safe' situations, such as when the player grounded. I could even give the players an option on how slow down effects them (instead of doing two builds, IWBTG style).

I like this solution a lot. While it's not as precise still in that different delta times may act slightly differently (which I can potentially solve!) it gives a lot of useability options I like and a lot more control over how frame loss is handled (if you like my idea of course). I think you'll like it too, though, as it gets rid of the factor of variable speeds.

Thank you Ashely, I'm glad this thread reached a comprise that is in everyone's benefit.

There could be a mode where the display is V-synced, but the runtime returns a constant value for TimeDelta. For example, if TimeDelta always returns 0.01 regardless of the real value, the built in behaviors and any custom timedelta-based movements would be absolutely exact and work the same way every time.

Actually that makes some good sense. I'd been planning a platform game with movement similar to Flashback or Prince of Persia. Since this debate over pixel precision started, I was getting a little worried about how my engine might behave, as the movement of the player sprite is largely dependent on what animation frame is playing.

For instance, to jump and pull yourself up on a ledge, you have to be pixel-perfectly lined up with it underneath. In the original games this isn't too much of a problem because the tile width and the length of the player's walking animation are designed to complement each other, so you won't ever have to make tiny little taps to get lined up just right. The player sprite just naturally stops on the exact spot where they need to jump.

With Timedelta as it is now, and these arguments suggesting that the movement could cause the player sprite to be off by as much as ten pixels would make for a bit of a headache in workarounds. (Even though PoP is designed to line you up automatically, it's not 100% perfect. Sometimes he does get off-line with the edge of the tile and "teleports" slightly to the left or right when you jump. It looks a little funny.) Doable, to be sure, but if your fixed Timedelta solution works the way I think you're describing it, then that should make things a bit easier.

Well, there's a lot of theoretical talk here. I put it to the test with a little .cap file that moves a sprite at 100 pixels per second for 1 second using TimeDelta, and measures the maximum and minimum distance it travels in that period.

I struggle to get it to have an error (difference between max and min) of more than 2 pixels. It's usually at most 1.5 pixels. Maybe these fears it could be off by 10 pixels are overblown?

Also, it performs surprisingly well at low framerates. Even if you fix the framerate at two frames per second, it still lands with nearly perfect accuracy every time.

I guess I should implement the timedelta override for its various uses, but I really think people's worries about timedelta are still exaggerated. It is remarkably accurate from what I can see. And where pixel precision matters - low res games with generally slower moving objects - it still seems accurate to within pixels. You can also get around any inaccuracy with various tweening methods, such as using a while loop to move the player until they are exactly in the right place, eliminating any error at all. I would still prefer to code it this way for uniform speed of execution, even if it's more events.

Don't worry - I'll still implement the timedelta override. But I don't think many people will ever need to use it!

If I set it to +200 instead of +100, it misses by 4 pixels instead of 2, and then goes back to 1-2 pixels at +300.

One run of +400 missed by 7 pixels.

My point was, though, isn't it unlikely that the games and movements where this kind of accuracy matters would use speeds as high as 400? That's a high speed for a platform movement, for example.

Maybe someone with experience making pixel games could shed some light on this for me.