Time Delta problems

For questions about using Classic.

Post » Sun Aug 29, 2010 10:58 pm

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.
B
2
S
2
G
3
Posts: 406
Reputation: 2,062

Post » Mon Aug 30, 2010 1:47 am

[quote="KrushBrother":1u8gadum]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.[/quote:1u8gadum]
You are partly wrong, please have a look at the links I posted above, it is explained in detail there (incl from Ashley)
Image
B
23
S
8
G
10
Posts: 1,820
Reputation: 8,242

Post » Mon Aug 30, 2010 3:46 am

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.

[url:1oyj66t7]http://tropple.com/caps/time.cap[/url:1oyj66t7]
B
3
G
2
Posts: 31
Reputation: 737

Post » Mon Aug 30, 2010 4:02 am

[quote="KrushBrother":1z3nnrj7]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.[/quote:1z3nnrj7]

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/
B
3
G
2
Posts: 31
Reputation: 737

Post » Mon Aug 30, 2010 10:48 am

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.
B
2
S
2
G
3
Posts: 406
Reputation: 2,062

Post » Tue Aug 31, 2010 1:48 am

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:
[code:34nirq2d]
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"
[color=#BF40FF:34nirq2d]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.[/color:34nirq2d]

On DeathTimeline period start "YouDied"
[color=#BF40FF:34nirq2d] Do your usual player died stuff, such as playing sad music, subtracting 1 from lives, starting enemy gloating animations etc.[/color:34nirq2d]

During DeathTimeline period "YouDied"
Player.y is > scrollYbottom (ie gone off the bottom, mario style)
DeathTimeline finish period "YouDied"
[color=#BF40FF:34nirq2d]This starts the fading period.[/color:34nirq2d]

On DeathTimeline period start "Fading"
[color=#BF40FF:34nirq2d]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.[/color:34nirq2d]

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

And go from there
B
2
G
2
Posts: 42
Reputation: 734

Previous

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 5 guests