help me with my time deltas (please)

I realised it's time to face reality with timedelta and start incorporating it into my work..

*hears applause from ash*

now with this small screenshot below, I cannot figure out how to get my swaying object controlled by SIN to run at a normal speed while in unlimited framerate, is it just a case of positioning the *timedelta in the right place, or am I missing something elsewhere.

apologies for the stupidity, as always, the code side isn't my forte.

humble thanks in advance, as always.

<img src="http://pic16.picturetrail.com/VOL699/2583063/18593104/337351199.jpg">

instead of add 4/subtract 4 from sway, try doing something like, add/subtract 10 * timedelta

instead of adding/subtracting 4 per tick which is what you're currently doing, it will instead add/subtract 10 per second, making it frame rate independant

The basic rule i use about timedelta is, if you put a *timedelta after a value, that value becomes 'per second'

if i didn't quite understand your code, just put a '* timdelta' next to the value that is being used to change the angle, you may need to increase the value a bit though as it is no longer units per tick but units per second

'.X + 200 * timedelta' moves along the X axis at 200 pixels per second

'.angle + 360 * timedelta' makes the sprite do a full 360 turn in one second

etc etc

i hope that is of some help

Looks like there aren't any time-based events there.

What are the conditions for those actions?

It's every tick.

thanks for your assistance, I'm beginning to understand it now.

would multiplying my 'every tick' incremental values by 60 be a correct assumption to getting things to their original speed in unlimited framerate mode?

If you used to make games with fixed framerate = 60FPS, then yes.

thankyou sirs! my game is on the way to becoming timedelta compliant thanks to your help!!

*humble bow*

I realised it's time to face reality with timedelta and start incorporating it into my work..

*hears applause from ash*

*applause*

Seriously, framerate independency is the way to go. Not many people think it's a big deal, but it does make for a better game.

ok, well, I implemented as much time delta'ing as needed to test things out, and, sadly it's not what games of the type i'm making do.

I need to have real pixel precision regardless of framerate, so for this game, it looks like I won't be using it.

So, If I use delta override, at 60, that should do the trick, right?

sorry ash

While i dunno what you're doing, wouldn't it still be possible to make it LOOK like a pixel precision game by changing the sampling to point and if you have to compare like, 'is player.X => this particular pixel' would you not be able to use the round() and/or ceil() expressions?

I could be way off, i don't really make pixel precision games, but then again, i've never seen much pixel inconsistancy in my games anyways and i use timedelta all the time

I could be way off, i don't really make pixel precision games, but then again, i've never seen much pixel inconsistancy in my games anyways and i use timedelta all the time

In one of my very early experiments with platforming (way, way back in the day), the character could easily make a specific jump if the game was full-screen, but missed it by a mile if the game was windowed (or was it the other way around?). I realize now the only difference was the fps had changed.

The timedelta override would have fixed it. A better graphics card would have fixed it to, but yeah...

I have to say - I personally would much rather code a game to allow for the small variations TimeDelta produces than override or avoid using TimeDelta at all. Not using TimeDelta will cause you problems, period. And possibly problems worse than the one you're trying to fix.

Deadeye: I cannot imagine how varying framerates and timedelta would cause large variations (ie. a "mile"). That can't be right. Can you reproduce an example where the variation is that significant?

If your game is a pixel retro platformer consisting of a player who can jump exactly 32 pixels high, running around a level of blocks exactly 32 pixels high, of course timedelta will cause variations. Sometimes you'll make it, sometimes you wont. The correct solution here is to make the blocks 25 pixels high or so, so you have a chance to clear them! If you turn TimeDelta off or override it, you either end up with V-Sync off and horribly torn up display (and highly dubious gameplay speed on low end systems), or have your game run twice as fast on one computer as another (ridiculously unfair on players).

Design your game to take in to account variations. Not using Timedelta has its own serious problems.

Wouldn't it be just as easy/better to have TimeDelta enabled by default in the way the events work? I am yet to figure out how to add it and get it to work... one time I tried, Construct gave me some sort of runtime error when I tried to test my game out, so I removed the timeDelta(s) and it worked fine after that.

~Sol

Wouldn't it be just as easy/better to have TimeDelta enabled by default in the way the events work?

No, this is not possible. Consider this, to make a sprite rotate 360 degrees every second:

+ Always

-> Rotate sprite 360 * Timedelta degrees clockwise

Why not make the 'Rotate clockwise' action automatically multiply its parameter by TimeDelta? Because if you call it one-off, this messes everything else up:

+ Upon pressing spacebar

-> Rotate sprite 90 degrees clockwise

Here, if you hit spacebar four times, the sprite makes a complete rotation. If you automatically tried to apply timedelta as above, it would only rotate a few degrees... that's not what you'd expect to happen!

[quote:1jxbj8rr]one time I tried, Construct gave me some sort of runtime error when I tried to test my game out

Did you report this bug?

Deadeye: I cannot imagine how varying framerates and timedelta would cause large variations (ie. a "mile"). That can't be right. Can you reproduce an example where the variation is that significant?

Well, maybe I was exaggerating a little...

But yeah, it did miss the jump on one and made it on the other, so the difference was pretty noticeable. It's just something you have to watch for when making a game I guess.

I'm not sure I could recreate the exact scenario in which it happened, because I have a better graphics card now, but if I run across the problem again in the future I'll let you know.