TimeDelta

I'm terribly sorry to have to bug you all about TimeDelta again, but i don't understand how i can use it to make my game run at the same speed, no matter what the refresh rate whatever monitor might be.

http://apps.sourceforge.net/mediawiki/construct/index.php?title=Time_Delta

I have looked here, and I don't understand it. I've never come across a situation as used in the example. I don't know what the distance the object is covering. I don't know how to translate that example into something that works the other way around.

I've rewritten this at least 10 times and i still can't figure out how to explain myself.

I would like my game to run the same on any monitor. As far as i know the 'always' command is out the window for this? And 'Every x ticks' too?

Always-- object Set Y to object +1

How would i rewrite what that does, with the magical 'TimeDelta'?

Somehow i need to replace 'Always' with 'TimeDeltAlways'.

So could i use (TimeDelta*60)-- object Set Y to object +1?

Ok, hope that is somewhat understandable, numbers mince my thought process(and frustrate the hell out of me). If i haven't been clear or I've left something out etc, please do ask for me to clarify and I'll do whatever i can.

Think of it this way - how much do you want an object to move per second?

Like this. Want an object to move 100 pixels per second? Then use always, set x position to .x+(100*timedelta). Want it to be twice as fast? Use 200 instead.

You don't need to replace the always. Timedelta is a value that over the course of a second will add up to 1. So if you did: always set x to .x+(1*timedelta) then every second the sprite would be 1 pixel farther. Each frame it will move the fraction of a second the frame took to render. So if you're doing 60 frames per second, then it will move 1/60th of a pixel per frame. Does that make sense?

I think i get it, now i just need to figure out the correlation between +1 and the TimeDelta equivalent.

So when i have;

Always-- object Set Y to object +1

It's moving 1 pixel, every tick(FPS60), so that's 60 pixels a second.

With TimeDelta, +1 became 200*TimeDelta to get an approximately similar speed.

Is there a direct correlation, can i match all my +1s and +5s to a specific TimeDelta number?

What you really need to do is get out of the habit of using .x+number - the more you do it, the easier it gets. You'll get used to it.

The correlation is the fps - if your .cap is running at 60 fps, then .x+1 and .x+(60*timedelta) should produce the same results. I'm not sure why you're getting x+(200*timedelta) at the same speed as .x+1. Is the application using v-sync, fixed or unlimited fps? You can check your fps by checking the 'show fps in caption' option in the application properties.

I figured that it was down to the FPS, but the whole 200 thing is throwing me off.

I have got the game in Vsync, and i have the FPS displaying all the time. My refresh rate is 60, but I have been changing it to look for differences.

I've just had a play around with it. I have one event set up

Always-- Rain:Set X to Rain X-(60*TimeDelta)

And one with

Always-- Rain:Set X to Rain X-1

I toggle one off and one on, and there is a drastic difference in speed. I have the Y set to 180 and 3 respectively and TimeDelta is in slow motion.

Now 200 was just an approximation but it's certainly closer to the original speed. From one to the other it seems that even 240*TimeDelta(4*60) isn't as fast as +1.

What do you think?

fps = frames per second, f/s

timedelta = time elpsed per frame (in seconds), seconds per frame, s/f

1/ (60 [f/s]) = (1/60)[s/f]

if you were moving 1 pixel per frame at locked 60fps, in 60 frames you moved 60 pixels

Thus:

Always-- object Set Y to object +1

Becomes:

Always-- object Set Y to object +(60*Timedelta)

and this:

Always-- object Set Y to object +5

Becomes:

Always-- object Set Y to object +(5*60*Timedelta)

that is, assuming you were running at locked 60fps.

There shouldn't be a discrepancy between + 1 and TimeDelta * 60 if your refresh rate is 60Hz. You should probably post your CAP so someone can take a look at it.

Anyways, here's a CAP I rigged up where there are two separate objects being moved using the two methods. There's only a slight discrepancy due to rounding errors.

TimeDelta example

Madster,

and if we assume it's V-sync?

What I'm trying to get is a game that runs the same speed no matter what the refresh rate is.

Arima has been helping push me towards this, and your run down has some nice formatting in it i will take on board, namely

Always-- object Set Y to object +(5*60*Timedelta)

Now, this would have the game running at 60 ticks per second no matter what the frame rate(well, if it was higher) or refresh rate was correct?

Linkman2004- Hey, cheers for the look in, I'm not on my computer at the moment, so i can't try it out just yet.

Would there be a discrepancy between + 1 and TimeDelta * 60 If my refresh rate wasn't 60? Because the whole reason behind this question is to take the refresh rate out of the equation.

If your refresh rate was something like 75, like my main computer, then there would be a difference between + 1 and 60 * TimeDelta. To achieve the equivalent of + 1, it just becomes (your refresh rate) * TimeDelta.

So basically, if you want your game to have the equivalent of what + 1 is on your computer, but still run the same on everybody's computers regardless of refresh rate, you'd just use (your refresh rate) * TimeDelta

You don't need to change your monitor's refresh rate to test different framerates - change the framerate to 'Fixed' at 10fps in application properties, or set it uo 'unlimited' (which should reach a few hundred frames per second at least), and the difference will become obvious.

The problem is framerate dependent code (like set X to .X + 1) doesn't have a fixed speed (it depends on the framerate), and TimeDelta code does have a fixed speed. So how can you possibly convert between them? TimeDelta always means one speed, and without TimeDelta it could be any speed, depending on your framerate. So to convert to or from framerate-dependent, you have to pick a framerate as your reference, and 60fps is a common one so a good choice.

My advice, though, is to completely ditch framerate-dependent code. Forget it. Just always use TimeDelta, and get everything moving at the right speed using that. Don't bother converting between them, it's totally unecessary if you start making your game right off the bat with TimeDelta. Also, don't forget the built in behaviors are already framerate-independent, so you don't need to worry about them.

I hope that's clear, it can be a tricky area to explain! By the way, you should avoid the 'Every X ticks' event in games, because as the name suggests, it runs depending on the framerate (every 10 ticks is once a second at 10fps, but ten times a second at 100fps!). You always want to use 'real world' times, so use 'every X milliseconds'. TimeDelta is another way of using real world times, so with the two, your game should run at the same speed everywhere!

What Ashley said is a perfect explanation. However, if your game requires pixel perfect collisions, and you don't want to risk an object "skipping through" parts of your level because the frame rate dropped too much, then that's when you should use a fixed frame rate. Time delta also has an option to prevent skipping like that from happening by slowing down the game if it drops below a certain frame rate. But if you're doing a low res game, i'd say use fixed rate. The tearing is barely noticeable, and it evens adds that old console nostalgia look.

MAJOR DIFFERENCE BETWEEN FIXED RATE AND TIMEDELTA

Timedelta- makes your game have skip lag.

Fixed rate- makes your game have slowdown lag.

I'd disagree and say you should never publish a game with fixed framerate mode, but people can and do ignore me on that one

I have played around with the different settings, and using the fixed frame rate really slugs the game, it's gets jerky and awkward feeling.

Ashley, Thanks for that tip about adjusting the frame rate, obvious now, but I do usually tend towards doing things the long awkward difficult and barely functional ways.

Now I don't mind showing graphics off...but when it comes to code, I'm so terrible at it i prefer to hide it away. But if you guys could give me an idea as to how to sort this out into the TimeDelta light?

2 ticks would work out to 0.03 milliseconds, and 5 to 0.08, but because the time, is system based, I would need to add TimeDelta to the milliseconds? Is that correct? And i want 0.03 to be a derivative of 60?

Aha! I think I understand why you're confused. Forget the conditions - you use timedelta in the actions only.

So instead of what you're doing:

every 2 ticks

left arrow is down

• subtract 1 from camera x

do this:

left arrow is down

• subtract (amount per second*timedelta) from camera x

Since you're using every two ticks, the event is running every other frame, resulting in 30 pixels moved per second. To get a speed equal to that, you'd use (30*timedelta). Like this:

left arrow is down

• subtract (30*timedelta) from camera x

That's right, since TimeDelta is the time since the last tick, you want to use it in events that run every tick.