- Home /
even just cubes moving seems choppy
I've created several cubes on screen, one controlled by the player and the other three are computer players. This is a fight seen somewhat like the Final Fantasy turn-based games in the past. Everything was running great, I select "Build & Run" and quickly learned the difference between Update() and FixedUpdate().. movement was way too increased when running the exe as opposed to running in the builder. So, my fixed update looks something like this :
FixedUpdate() { if(move == 1) { translateY = curAttackMoveSpeed / 100; translateY = 0 + translateY; transform.Translate(0, 0, translateY); } }
- curAttackMoveSpeed is currently set to 60.. that gives me the movement speed I want for the player when using fixed updates
The enemies are each running a copy of an enemy script that runs some code during their fixed updates as well and I have a camera rotating using the RotateAround function pointed at the player and a some movement to the side, both are very slight so the camera moves slowly.
Game ran great with Update(), found out I should be using FixedUpdate() for movements, and now it seems pretty choppy. I have 1 gig Radeon 5570 that can run Eve, Wow, you name it at highest resolutions and textures without flinching, so I know my computer can handle it. Any ideas why this would be choppy?
Answer by Eric5h5 · May 08, 2010 at 04:37 AM
You should not be using FixedUpdate for movements. Only for physics. The reason it's choppy is because it's not updating every frame...go back to Update.
As for the movement being different in a build vs. the editor, that's because your code is framerate-dependent. Multiply movement by Time.deltaTime; i.e., transform.Translate(Vector3.forward * moveSpeed * Time.deltaTime);
.
I remember Time.deltaTime from a tutorial but it's necessity wasn't explained. Thank you so much, this was exactly what I was looking for!
Not sure if you'll see this or not, but I wanted to make sure.. my ray caster collision script should go in the FixedUpdate() function even though it originates from the object that is being moved in the Update() function?
@aLucidWorld: actually that should be in Update as well. Only things like adding physics forces (i.e., rigidbody.AddForce) would be in FixedUpdate. BTW, the docs explain deltaTime a bit more: "When you multiply with Time.deltaTime you essentially express: I want to move this object X meters per second ins$$anonymous$$d of X meters per frame."
Forgot to say, the system here notifies you when there are comments on your answers, so yep, I saw that. ;)