Animation Speed

For questions about using Classic.

Post » Mon Aug 18, 2008 6:36 pm

[quote="deadeye":ko1xmm9g]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.[/quote:ko1xmm9g]

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 :P) that separating logic and rendering would supply precise movement and control, general time independence and no tearing. And you don't need to explain anything to new people! And I won't bang my head on the wall over and over again because of this. :( )
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Mon Aug 18, 2008 9:51 pm

[quote="kayin":2r3u9j5l]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.[/quote:2r3u9j5l]

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.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Mon Aug 18, 2008 10:18 pm

[quote:ol04pk7t]strain the fps[/quote:ol04pk7t]
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.[/quote:ol04pk7t]
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 :)
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon Aug 18, 2008 10:55 pm

[quote="deadeye":131hqgya][quote="kayin":131hqgya]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.[/quote:131hqgya]

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

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="Ashley":131hqgya][quote:131hqgya]strain the fps[/quote:131hqgya]
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.[/quote:131hqgya]
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 :)[/quote:131hqgya]

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.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Tue Aug 19, 2008 2:13 am

[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[/quote:3s1anf2w]
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?[/quote:3s1anf2w]
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.[/quote:3s1anf2w]
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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Tue Aug 19, 2008 4:29 am

[quote="Ashley":38hpgvfs]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:38hpgvfs]

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 ;)
B
2
S
2
G
5
Posts: 391
Reputation: 2,432

Post » Tue Aug 19, 2008 5:23 am

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! :D
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
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

Post » Tue Aug 19, 2008 6:28 am

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. :shock:
B
2
S
2
G
5
Posts: 391
Reputation: 2,432

Post » Tue Aug 19, 2008 6:49 am

@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 :P ) that I intend on continuing with. But it is an example. Anyways, those 10 pixels are witht he built in engine, and my own creations may have worse reliability. Like I said, I saw examples of jumps with my other block test that were 4 times the distance of a normal move. Rare, yes, but that can be very significant . 10 pixels isn't a huge issue, but potential for even 32? thats a ton,especially with 32 pixel building blocks. Lag made a platform you can only reach with a double jump can now be reached with a single jump half the time. Now I could make the jump higher, but this is working on the scale of 32 tiles... So now that particular height isn't really usable... And thats kind of annoying. :(

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.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Tue Aug 19, 2008 3:20 pm

[quote="Ashley":2rnkku3n]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:2rnkku3n]

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 :P ).
B
2
S
2
G
5
Posts: 236
Reputation: 2,122

PreviousNext

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 3 guests