Time Delta problems

So I just learned about Time Delta the other day, and good thing too. I'm having some problems with it though D:

Basically, I've got some code that works like this:

"Every 100 milliseconds - Add 1 to Value"

"If value is 50 - Do this"

"If value is 100 - Do this"

"If value is 150 - Do this"

and so on.

How do I apply Time Delta to this code? I've tried, but certain things still aren't working right when I run the game using Unlimited FPS. Also, unless I misunderstood, Time Delta varies. This means the value will never actually be exactly 50,100, or 150, right?

Er... By nature if an event occurs every X ms it's timesynced to begin with. The problem with unlimited FPS is some computers might run the game at 100fps, some at 20fps, so on and so forth. You never know. So moving something by 50 pixels every step will vary wildly depending on how fast the game is rendering.

If you're doing things in steps of time anyway, you don't need to worry about it.

Maybe you could elaborate exactly what you're talking about, because what you've listed is the same as doing 100ms x 50, x 100, x 150 (5 seconds, 10 seconds, 15 seconds).

Why don't you just "do this every x ms" (every 5, 10, 15 seconds) ? Why bother adding to a counter?

EDIT: Missed this question:

[quote:10frcve3]Also, unless I misunderstood, Time Delta varies. This means the value will never actually be exactly 50,100, or 150, right?

Sure it varies a little (or can a lot), but it ultimately depends on how much you're doing each step. If you load resources at random times during the game it'll sky rocket when you do, compared to if it's humming along just doing the same stuff every frame.

TimeDelta is usually a very small number. For example 0.0013. It's the time it takes your computer to perform 1 game loop. Even on a "slow" computer, it's usually a very small number (compared to whole numbers). Most computers can render a basic game at 60fps solidly with vsync on. Mine can run my sample projects upwards of 10,000 at times with it off. That's a really small number

I can't think of a reason you'd need to be using TimeDelta in a cumulative fashion like I think you're attempting (even though it's not in your sample you give). Construct does this for you by offering the "every X ms" event.

But again, unless you elaborate more, I can't even fathom what it is you are trying to accomplish. But to answer your question... if you are adding it cumulatively every gamestep... if you're casting it into an integer, it will eventually land on the whole number you're after. Yes. But if you happen to do something time consuming at that moment, it may skip over the number you are after. I'd encourage you to use greater than/equal to as opposed to just equal to.

But for more accurate time calculations, just use what construct offers.

Also, i think using the timer in such small amounts can be in-accurate..

I believe timedelta is used to make something happen x times per second, for example-

Always : Move sprite1 1 pixel left.

This will make sprite 1 move 100 pixels left per second if the game is running at 100FPS,

However with timedelta,

Always : Move sprite 1 pixel left * timedelta

Will move it 1 pixel left per second, no matter what FPS the game runs at. So to achieve the same effect you'd want to change it to-

Always : Move sprite 1 pixel left *timedelta *100

Not sure if this helps or is relevant, but i believe, if possible you want to use timedelta instead of using the timer.

Well basically, when my player dies, a value is constantly added to. When that value reaches certain numbers, things happen..like the screen fading to black or going to a different layout.

It works fine when I use V-Synced Mode, but everything happens waaaay too fast when I use Unlimited Mode. I read that if something like this happens (anything running too fast when you use Unlimited mode) then Time Delta should be applied..otherwise you'll have some problems on certain computers..but I guess this situation is different?

Well basically, when my player dies, a value is constantly added to. When that value reaches certain numbers, things happen..like the screen fading to black or going to a different layout.

It works fine when I use V-Synced Mode, but everything happens waaaay too fast when I use Unlimited Mode. I read that if something like this happens (anything running too fast when you use Unlimited mode) then Time Delta should be applied..otherwise you'll have some problems on certain computers..but I guess this situation is different?

So when your player dies you're trying to delay a little bit of time then fade the screen out or restart the level ?

So when your player dies you're trying to delay a little bit of time then fade the screen out or restart the level ?

Yessir. I figured my above method was simple and effective enough, but I guess not D:

Okay, so what you'd want to do is when your player dies, store the time in a variable for just that.

For example, death_time. Then when death_time has a value to compare, if the difference between it and the current time exceeds your delay (5 seconds, for example), then do your function/action/magic.

I will provide a .cap later if you like, I gotta go right now though. Good luck

You might also want to read these threads:

"Every 100 milliseconds - Add 1 to Value"

"If value is 50 - Do this"

"If value is 100 - Do this"

"If value is 150 - Do this"

So you would want to change this to -

Always - add 50 * Timedelta to value

"If value is 50 - Do this" Will take 1 second

"If value is 100 - Do this" Will take 2 seconds

"If value is 150 - Do this" Will take 3 seconds

If you halved that value (50 to 25) then the steps would take twice as long. Also note that timedelta uses decimal places, so it will be hard for it to land precisely on "50". So if you modify those variables to greater than/less than etc.

It seems rediculous at first, but it does get very comfortable quite quickly. Have a look through the second topic Tulamide linked to, it is one where he helped me come to terms with Timedelta.

It was my understanding that using "Every x milliseconds" will result in the same speed whatever computer it's run on, and whatever frame-rate it ran at, because it's already factoring in the time delta and will run based on actual time passed.

In which case, your first post should run fine.

It's when you use "Every x ticks" that the speed is affected by frame-rate and computer speed.

Correct me if I'm wrong, because all of my game is based on "Every x milliseconds".

Krush.

It was my understanding that using "Every x milliseconds" will result in the same speed whatever computer it's run on, and whatever frame-rate it ran at, because it's already factoring in the time delta and will run based on actual time passed.

In which case, your first post should run fine.

It's when you use "Every x ticks" that the speed is affected by frame-rate and computer speed.

Correct me if I'm wrong, because all of my game is based on "Every x milliseconds".

Krush.

You are partly wrong, please have a look at the links I posted above, it is explained in detail there (incl from Ashley)

Anyway, I made a cap file to demonstrate my previous post. It's not very exciting, at all.

Just a quick hack to show the OP one of the many options he could use.

http://tropple.com/caps/time.cap

It was my understanding that using "Every x milliseconds" will result in the same speed whatever computer it's run on, and whatever frame-rate it ran at, because it's already factoring in the time delta and will run based on actual time passed.

In which case, your first post should run fine.

It's when you use "Every x ticks" that the speed is affected by frame-rate and computer speed.

Correct me if I'm wrong, because all of my game is based on "Every x milliseconds".

Krush.

For simulation events (eg: movement, motion, physical behaviors) you should be using TimeDelta.

For things that simply must fire at steady intervals (health regeneration, maybe), you should be good.

Try to think of these as multiple parts of a single system; don't just use one or the other. Different tools for different jobs. I can't see basing motion on "every x ms." That would drive me nuts. But tossing in a timeDelta in your equations is easy

Likewise if I just want to check for something every second or so, give or take, it's a pain to make a variable and increment it by timeDelta every step... thus the convenience of "every x ms."

Hope this helps. And not to plug gaffer, but everyone should read his article on time stepping. It's essentially the best things written on the topic.

http://gafferongames.com/game-physics/f ... -timestep/

I'm more than familiar with timedelta (you have to be with c++), and that by multiplying by timedelta you'll always get the same speed.

i.e. 1 second divided by 100 ticks will always be the same as 1 second divided by 10 ticks or 1 second divided by 1000 ticks, all taking 1 second to complete.

The thing is, the sort of timing I'm talking about for my game mainly involves 100 millisecond or above uses of the "Every x Milliseconds" function, and these aren't action parts of the game, but mainly timed movements.

You'd have to be running a pretty crappy computer to drop below that speed.

I need to put my other computers together so I can check any differences in speed.

Supposing I was to replace the "Every x Milliseconds" in my game.

What would I replace it with?

Remember, we're not talking about adding a value to a sprite position, but rather checking a condition every x milliseconds.

Krush.

For sequencing events like this, I find that using timelines gives me more control.

Eg. In my project I was doing an instructions screen where I have some sprites from the main game in a looping example. Ie. dude gets shot, falls down, goes splat, repeat. The timeline is set up so that each period can only advance by trigger (by making each period -1). The trigger to advance is a specific event, which in this case is the collision event. This forces everything into a nice sequence.

So your timeline might look like:

Period      Name     Interval    Duration
1             Idle           0             -1
2             YouDied     0            -1
3             Fading       0            -1
4             ExitLayout  0            -1
[/code:34nirq2d]
Note the first one is an idle state, because a timeline will start automatically at the start of the layout or when loaded.

On Collision between enemy and player
 DeathTimeline finish period "idle"
This will then begin the automatic sequence. If you want it to strictly be time based (eg. 5 seconds) then you can make your timeline do that instead of being -1 and waiting for an end period command.

On DeathTimeline period start "YouDied"
 Do your usual player died stuff, such as playing sad music, subtracting 1 from lives, starting enemy gloating animations etc.

During DeathTimeline period "YouDied"
Player.y is > scrollYbottom (ie gone off the bottom, mario style)
 DeathTimeline finish period "YouDied" 
This starts the fading period.

On DeathTimeline period start "Fading"
Do your fade thing here. You could use a during period event here that will basically be an "always" as long as the current period is running. 

On (screen is fully faded, etc.)
 DeathTimeline finish period "Fading" 

And go from there