help me with my time deltas (please)

For questions about using Classic.

Post » Sun Oct 05, 2008 7:09 am

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.

B
4
S
2
G
5
Posts: 149
Reputation: 2,025

Post » Sun Oct 05, 2008 10:09 am

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

Post » Sun Oct 05, 2008 10:26 am

Looks like there aren't any time-based events there.
What are the conditions for those actions?
B
2
S
1
G
4
Posts: 92
Reputation: 1,384

Post » Sun Oct 05, 2008 10:36 am

It's every tick.
B
4
S
2
G
5
Posts: 149
Reputation: 2,025

Post » Sun Oct 05, 2008 11:53 am

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?
B
4
S
2
G
5
Posts: 149
Reputation: 2,025

Post » Sun Oct 05, 2008 11:56 am

If you used to make games with fixed framerate = 60FPS, then yes.
B
6
S
3
G
6
Posts: 219
Reputation: 3,013

Post » Sun Oct 05, 2008 1:26 pm

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

*humble bow*
B
4
S
2
G
5
Posts: 149
Reputation: 2,025

Post » Sun Oct 05, 2008 2:21 pm

[quote="work3":2s02bhh9]I realised it's time to face reality with timedelta and start incorporating it into my work..
*hears applause from ash*[/quote:2s02bhh9]
*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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,518

Post » Sun Oct 05, 2008 6:28 pm

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 :oops:
B
4
S
2
G
5
Posts: 149
Reputation: 2,025

Post » Sun Oct 05, 2008 11:23 pm

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

Next

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 4 guests