# TimeDelta value of 5.e-002?

### » Sun Dec 04, 2011 2:19 am

I've got an issue where I'm trying to increase a value over time,
and from everything I've read it's best to multiply it by timedelta
so that it increases evenly instead of relative to refresh speed/etc,
however it increases far too much in specific moments so I wanted
to see how high the TimeDelta value reaches, and 5.e-002 was recorded.

Is this a permanent bug that I can't do anything about, is there
a workaround? Because it's breaking my gameplay because of these jumps
of TimeDelta value.

I would be extremely grateful for anyone that can give me advice about
this topic or let me know the cause or any possible workaround/fix?sparkfeather2011-12-04 02:20:37
B
3
S
1
G
2
Posts: 58
Reputation: 1,316

### » Sun Dec 04, 2011 2:48 am

timedelta is the time that has passed between the last tick and the current one.
5e-002 means 0.05

That means, that your game's speed was 20 fps at that moment.

timedelta is always relative to the current framerate. If at times the processor doesn't have much to do and the framerate is e.g. 500 fps, then timedelta will be 0.002, at other times, when the framerate is only 10 fps, timedelta will be 0.1

Timedelta assures to do something over time, if (and only if) used on every tick.

If you do something like "a = a + 10 * timedelta", then a will raise by 10 per second, no matter the frame rate. But it does not evenly raise "a" per tick. It's just the opposite: it raises by whatever value is needed to get to a total of 10 per second, which may be a lower portion or a higher one, depending on the actual time, that passed between any two ticks.
B
24
S
8
G
10
Posts: 1,821
Reputation: 8,289

### » Sun Dec 04, 2011 3:21 am

Ahhhh, thanks a lot for explaining that so well and so quickly ^^;...
I didn't have any idea that it would equal to 0.05, because I thought
logically if it was a smaller number it should say it specifically.
I guess it was valued as a higher number recorded was because it had
5 at the beginning, rather than getting it's actual value
(I had a variable to set itself to delta value only if it was higher
than the current value).
I guess the strange bumps of values must be something else that I can't
see that I have to deal with =_=; why Dx

Anyway, thank you very! much for explaining all that for me so quickly,
means I can move on to look for other reasons without much delay ^^;
B
3
S
1
G
2
Posts: 58
Reputation: 1,316

### » Sun Dec 04, 2011 3:52 am

It might be (never tested it) that the scientific notation is interpreted as a string. If it is, then any try to calculate with such a string would lead to a simple conversion (without further explanation for now :) ). In result the number would be 5 instead of 0.05 and could cause such unecpected jumps.

If you're willing, post your cap or send it via pm, and I will have a closer look at it.
B
24
S
8
G
10
Posts: 1,821
Reputation: 8,289

### » Sun Dec 04, 2011 8:11 am

I went to build an example file to send to you with the major parts I thought may have caused the issues, however it wasn't working.
Then with further testing in other areas thanks to ruling them out,
I was able to find the answer so thank you very much :D
I discovered that it was an annoying bug.
It seems that, when you multiply a 'Clamp' number, it automatically sets
it to the maximum value multiplied by that number.
So, '(Clamp(value)+(10*TimeDelta), 0, 500))*5)' would always be 2500,
however I didn't realize this because the max value I had was based off
other variables that were always changing.

So thank you very much for leading me to the solution, this one was
really killing me and I didn't think I'd find it, thank you so much :)!
B
3
S
1
G
2
Posts: 58
Reputation: 1,316