Jumpy camera?

[Pyritie]

I've made a basic "move forward" thingy, and it works fine and stuff. But when I'm holding down the up key, occassionally the screen "flickers". It's very quick, but it's pretty noticeable.

Code: Select all

if (Viewer.receiver.getKeys().get(EKEY_CODE.KEY_UP)) {
	vector3df vel = new vector3df(0, 0, actor.getMoveSpeed());
	matrix4 m = new matrix4();
	m.setRotationDegrees(actor.getNode().getRotation());
	m.transformVect(vel);
	
	actor.getNode().setPosition(Viewer.add(actor.getNode().getPosition(), vel));
	actor.getNode().updateAbsolutePosition();
	Viewer.camera.setTarget(actor.getNode().getAbsolutePosition());
	Viewer.camera.updateAbsolutePosition();
}

Full class here: http://pastie.org/367150

It's in jirr, but it's not a jirr-specific problem, I don't think. I'm probably just making a silly mistake somewhere. I've already fiddled around with the last block a bit. Haven't found anything that works, really.

This code is running on a timer that runs every 20ms. "actor" is just a class to handle various objects and stuff. Perhaps it's an FPS issue? It is running at around 600+ FPS, after all.

D2R = degrees to radians

[Munger]

I haven't looked too carefully at your example, but one really common thing that can happen is updating the thing you want to look at, updating the camera target direction and the rendering are in the wrong order. You can end up rendering where the target entity was in the previous frame. Try re-arranging the order you're doing these things.

The other thing that can happen is if you have decoupled the game update rate from the frame rate (ala Source and most modern game engines). If all your entities are updating at a rate that is not a perfect multiple of the screen refresh rate, the two will get out of sync and some game updates may appear over multiple frames. The solution here is to interpolate between frames (or extrapolate if you're in the mood and don't mind tiny collision glitches). It's far more likely to be the first situation though.

[Pyritie]

I haven't looked too carefully at your example, but one really common thing that can happen is updating the thing you want to look at, updating the camera target direction and the rendering are in the wrong order. You can end up rendering where the target entity was in the previous frame. Try re-arranging the order you're doing these things.

So move the camera node + target first, then move my character node?

The other thing that can happen is if you have decoupled the game update rate from the frame rate (ala Source and most modern game engines). If all your entities are updating at a rate that is not a perfect multiple of the screen refresh rate, the two will get out of sync and some game updates may appear over multiple frames. The solution here is to interpolate between frames (or extrapolate if you're in the mood and don't mind tiny collision glitches). It's far more likely to be the first situation though.

Yeah, I have this running on a timer that goes every 30ms.

Alrighty, so now that I've hooked up some collision to the character node, the jittering seems to have gotten worse.

Here's a video of what I mean. The video doesn't really show it very well except for right at the end.

[Pyritie]

Nope, switching around the order didn't do anything.

All of the camera updating, moving, and player node movement are all on the same timer so I don't really see how it could get "de-synced".

My code at the moment

[Pyritie]

Woot, so with some help of randomMesh in the chatroom I got it to not run on a timer and use a difference between frames to make sure that you get the same movement speed.

Now I have another problem. If I'm holding down "up" on my keyboard and making my character move forward, it goes up the terrain fine but when I go down the terrain I sort of fly in the air until I let go.

I'm probably just missing something again with the collisionAnimator stuff.

[Munger]

So you've got your movement smoothed out? Excellent.

There is a problem that will crop up in 10 years time with varying the update rate. Quake 1 (and 2?) apparently suffers from a problem where the frame times are so short that when coupled with floating point errors, the movement is considerably different between an older machine and a newer machine. Most modern FPS games run the game at a fixed update rate then blend between those updates to get smooth looking motion.

But don't worry about that now - it's really not that important at the moment.

As for your movement code, I'm glad to tell you your collision/response code must be working. Not letting the camera go under the terrain is step #1. The next step is applying gravity. You say that when you let go of the key it fixes itself. Does that happen instantly, or does it have a smooth drop? If it's instantly, you're probably just snapping the character to the ground when there's no input. If you're going to do this properly, you'll need a little bit of physics...

Your character needs a position and a velocity. You have a tick every frame that adds a bit of the velocity to the position. This sounds like what you have already. When you want to move the character, you have to add acceleration to the velocity (and then the velocity modifies the position in that tick). So how does this help your motion? Gravity is a form of acceleration (a force acting on your object). Every tick, add gravity to your velocity as well as the forces from player input and collisions.

When you collide, you've got some thinking to do and decisions to make. Realistically, your character should be 'reflected' off the surface it collides with. To make things easier, you could just make it that characters lose all vertical velocity when they touch the ground and lose part of their horizontal velocity as a kind of friction. That'll keep the mathematics simple and look good-enough to get you started.

Once you start getting more complicated than that, you might want to consider using a physics engine (like ODE or PhysX). That obviously has it's own share of hassles and sometimes for a game you'll find yourself turning things off to make it feel 'right' (like rotational velocity so your character stays upright).

I hope that's not too much for you. Let us know how you're coming along.

[Pyritie]

As for your movement code, I'm glad to tell you your collision/response code must be working. Not letting the camera go under the terrain is step #1. The next step is applying gravity. You say that when you let go of the key it fixes itself. Does that happen instantly, or does it have a smooth drop? If it's instantly, you're probably just snapping the character to the ground when there's no input. If you're going to do this properly, you'll need a little bit of physics...

I'm using gravity with the collisionAnimator like it does in the demos. I think the problem is that every "frame" I'm only telling it to move forward from its previous position so the y-axis isn't getting updated. When I'm not making it move forward then it falls down to the ground like normal. (You can see this near the end of that video I posted a few posts back.)

Your character needs a position and a velocity. You have a tick every frame that adds a bit of the velocity to the position. This sounds like what you have already. When you want to move the character, you have to add acceleration to the velocity (and then the velocity modifies the position in that tick). So how does this help your motion? Gravity is a form of acceleration (a force acting on your object). Every tick, add gravity to your velocity as well as the forces from player input and collisions.

When you collide, you've got some thinking to do and decisions to make. Realistically, your character should be 'reflected' off the surface it collides with. To make things easier, you could just make it that characters lose all vertical velocity when they touch the ground and lose part of their horizontal velocity as a kind of friction. That'll keep the mathematics simple and look good-enough to get you started.

I was thinking something along the lines of getting the distance between the character and the ground, and if it's not close enough to the ground then move the character down a bit.

Once you start getting more complicated than that, you might want to consider using a physics engine (like ODE or PhysX). That obviously has it's own share of hassles and sometimes for a game you'll find yourself turning things off to make it feel 'right' (like rotational velocity so your character stays upright).

Only problem is that JNewton is the only decent jirr-friendly physics engine out there at the moment (that I've come across at least) and it generally looks like a lot more of a pain than I had hoped for.


I'll go add the thing with the downwards velocity now. Thanks again!

[Pyritie]

Woop woop I removed the collisionAnimator and added in Y collision myself. :3

Although now I fall through the world every now and then. D:

Next I need to add something so that if the slope is too high then you can't walk up it.

[Pyritie]

Hmm. I've noticed that if I set my movement speed to slow then I don't fall through the world very much, but if I set it to fast then I fall through it a lot.