Time.deltaTime not framerate independant

Hi guys,

I’ve got a strange problem with Time.deltaTime. I am moving my character between two points, and I need the walkcycle to animate smoothly between the two, and be ready to repeat at frame 1 when the user holds down the button to move continuously.

What I’ve got at the moment is:

pix.animation.CrossFade("Walkcycle");
				
for (var t = 0.0; t < 1.0; t += (Time.deltaTime / pix.animation["Walkcycle"].length - .01)) {

	pix.transform.position = Vector3.Lerp(startSpot.transform.position, endSpot.transform.position, t);
			
	yield; 
		
}

This works perfectly on iPhone, web, and pc (on a slower computer), but on the PC build and in the editor on a new macbook pro and my gaming pc, things go crazy. The lerp between the positions takes much longer (as if the walkcycle.length has somehow stretched?), so the character moves super slowly between the two points.

I have tried both Update and FixedUpdate. With Update, on a faster PC, the character moves uncontrollably fast. With FixedUpdate, it’s too slow.

If I set the time multiplier to a static value (in this case, 0.78), which fixes it on a faster PC, it seems to create another problem on slower systems: the animation sometimes takes a couple of frames longer than the position lerp (especially if the cpu is chugging), so when the user holds down the button to move continuously between points, it finishes the last frames of the original walkcycle, then just slides the rest of the way.

I have tried CrossFadeQueued, but then it tends to play the walkcycle one time to many when I reach the endspot.

Does anyone have a suggestion? I need framerate independence across all systems, even the fast ones.

Thanks for your help!

deltaTime is the frametime since last frame so that value itself is highly frame dependent.

yet if you use it correctly (as a multiplier within the Update function it will compensate for Updates frame dependence and make code frame independent.

I don’t quite understand what you mean… Could you give me an example, or maybe explain how I’m doing it wrong?

don’t see anything wrong but you might potentially be tricked by the iphone that normally will run on that low framerates that errors don’t show up while the desktop potentially runs at hundreds of frames

Hmm, in that case, is there a way to use a fixed value, but force the animation to repeat until the character stops, but not longer?

(Time.deltaTime / pix.animation["Walkcycle"].length - .01)

doesn’t work. If you have a fast machine, and/or a long animation, that will give you negative numbers.

Maybe you meant

Time.deltaTime / (pix.animation["Walkcycle"].length - .01)

which makes me question, why do you need to use the -.01 anyway? Sounds like a hassle to try to make up for animations not being set up properly. A hard-coded value (.01) could never be a good thing here, besides.

Also, the whole for loop is goofy. Why not just do

for (var t = 0.0; t < pix.animation["Walkcycle"].length; t += Time.deltaTime)

?

Even better, why don’t you get rid of the for loop and use this instead, to lerp with?

I don’t know what you mean by this. You have a yield statement. That doesn’t work in Update or FixedUpdate.

Thanks for your suggestions Jessy, I will try them asap. The yield statement is there because this whole thing is in a coroutine being called in FixedUpdate.

I implemented the -0.1 because the animation wasn’t looping properly (even though it does if played in a loop), there was some sort of 1 frame gap since the character lerps between two points, thereby repeating the first point on the second lerp (ex. lerp from 1-10, then 10-20, 10 gets played twice).

For normalizedTime, would you mind giving me a simple example on how to use it instead of the for loop? I can see that this could solve a lot of problems for me if I can get it working.

Thanks again :slight_smile:

Sorry, I meant lerp. How would I use normalizedTime to lerp the values?

Update: Jessy, I tried using your for loop which increments until x < walkcycle.length, but the lerp only moves to about 75%, and I don’t really understand why. Shouldn’t it divide evenly, then spread the movement out over the exact number of frames of the walkcycle?

This is too complicated without having the project available. You can PM me a .unitypackage if you want.