Players of my LD entry are complaining about jittering movement. I implemented the movement like this:
[java]
public void update(float tpf) {
final Vector3f camDir = cam.getDirection().clone();
camDir.y = 0;
camDir.normalizeLocal().multLocal(tpf * walkSpeed);
final Vector3f camLeft = cam.getLeft().clone();
camLeft.y = 0;
camLeft.normalizeLocal().multLocal(tpf * walkSpeed);
walkDirection.set(0, 0, 0);
if (left) {
walkDirection.addLocal(camLeft);
}
if (right) {
walkDirection.addLocal(camLeft.negate());
}
if (up) {
walkDirection.addLocal(camDir);
}
if (down) {
walkDirection.addLocal(camDir.negate());
}
}
[/java]
I multiply the walkspeed with the timePerFrame to have a constant movement even when the FPS rate drops. But is there a best practice to do that so that no jittering appears? Should I remove the tpf part in the equation?
Woah, near impossible to play for me. It’s lagging all over, when I move it’s like I’m a rocket, and moving mouse around lags like hell…
This is a rather simple game, anyone should be able to run it, no? Just put a constant in instead of tpf and limit the FPS to 30 , 40, 50 or something.
No, thats not a good way and the framerate decoupling probably isn’t the culprit here. Do you have the manufacturers graphics drivers installed with full opengl support?
Not sure if that’s directed to me, but yes my drivers are all up to date, if that’s what you meant at.
I had that problem with my game, it was caused by adding the camera control before the playercontrol.
By adding playercontrol first, then the camera, the position of the player will be updated before the camera which should take out the jaggy movement.
But now you are using first person view so it should be unrelated.
I thought the physics movement was already framerate independent, so multiplying by tpf could cause weird things?
Oh this is for a characterControl? Then yes, the vector for that should be constant.
@tiagoparreira said:
Not sure if that's directed to me, but yes my drivers are all up to date, if that's what you meant at.
Yes it was. And I meant if its drivers from the manufacturers web site (not from the internal windows drivers).
Yes, it’s proper drivers from their site.
@normen said:
Oh this is for a characterControl? Then yes, the vector for that should be constant.
[...]
yes - sorry I forgot to mention that. So the the walkdirection is multiplied by the tpf within jbullet's tick I assume?
I see. Thanks 