Sign in to follow this  
Sean_Seanston

Interpolation and scrolling

Recommended Posts

Sean_Seanston    880
I'm using the game loop method described in DeWitters Game Loop Article (http://dewitters.koonsolo.com/gameloop.html) for a 2D scrolling shooter and I've come upon a problem that gives a jittery effect especially when I have something stopped on the map and therefore moving down the screen at the same speed as the level, but also less obviously at other times. The logic and rendering are separated and apart from this, the interpolation seems to work fine. Given that it's a scrolling shooter, the objects have to be kept inside the camera area and as such must be positioned on screen based on the position of the camera. So, I have the camera movement logic (updating it every time the logic is updated) going at 25 times per second as in the article and the rendering going like the article also. The problem arises because the drawing code to get the y coordinate of the object looks like this:
drawPosY = y - gameCamera.getY() + ( yvel * interpolation );

So since the camera is only updating every time the logic is updated, it's going to look a bit wrong. As for moving the camera logic into the rendering function, not only is it obviously a bad design move in some way, it also means that the camera is updating more often than the objects and so the objects can't possibly keep track of where the camera is all the time so scrolling will be ruined. I tried giving the camera its own draw coordinates that would be interpolated and then using these coordinates to determine the draw coordinates of objects but that way I found that when objects were supposed to be stationary with respect to the screen, they were jittering all over the place since the interpolation of the camera's movement was being taken into account. Essentially it was working IIRC apart from the camera's interpolation still being applied to stationary objects. Can anyone see a way of having the scrolling work with the interpolation? There must be something I'm missing out on that would be obvious to someone with more experience since I imagine issues like this must be a common occurrence among anyone using a similar game loop. I just have the interpolation set permanently to 0.0f now while I figure out a way of fixing it and at least everything works right but obviously the movement is quite jarring.

Share this post


Link to post
Share on other sites
GregMichael    135
I may not be understanding your problem quite right, but perhaps this helps.

Objects should have their coordinates in "world space"...so that they are positioned relative to the world. That is, a tree object has a fixed position on the scrolling background (it doesn't move) and so would a stationary space ship (if it's hovering in place say). If the ship then moves, it should just move relative to the background.

Then...think of the camera as looking through a window at some position within the world...the camera also moves with world coordinates so that it can look at the world in different positions.

That should work for moving the objects however you want to implement it - interpolating should just smooth things out depending on frame rate etc.

When you come to draw "what the camera can see" it should just be...

Subtract object position from camera position, if the resultant position is then outside of the viewing window (defined by how much the camera can see in width/height), don't draw it...otherwise draw it.

Share this post


Link to post
Share on other sites
Sean_Seanston    880
Ya, I have the actual camera implemented already it's just that it appears to be interfering with the interpolation working properly.

Since the camera must always be moving (25 times per second along with the rest of the logic) and the draw positions of the objects that are interpolated (>25 times per second) depend on the camera's movement... there's some jitter where the draw position of an object isn't where it should be because the camera's movement isn't being interpolated etc. like I described above.

Share this post


Link to post
Share on other sites
Spynacker    106
Maybe you should think about increasing the framerate. 25FPS is near to the limit of the human eye recognizing each frame to be a single picture and making the animation look not smooth. This might solve the problem of this jittery effect, because your eye will not be able to see it.
Independently from this advice you should take in account what GregMichael said because it is some better style to draw your world that way.

Share this post


Link to post
Share on other sites
Sean_Seanston    880
Quote:
Original post by Spynacker
Maybe you should think about increasing the framerate. 25FPS is near to the limit of the human eye recognizing each frame to be a single picture and making the animation look not smooth. This might solve the problem of this jittery effect, because your eye will not be able to see it.


As explained in DeWitters' article, the actual rendering will be done many times more than 25 times per second and if the interpolation works right then it should look perfectly smooth too.

If I can't find a way to fix this interpolation problem then I might try increasing the framerate to make it look a bit better... only then I'll have to reduce the speed of the game accordingly since everything'll be going much faster then.

Quote:
Original post by SpynackerIndependently from this advice you should take in account what GregMichael said because it is some better style to draw your world that way.


I must not have worded my original post very well. That's what I've been doing; the objects have their actual position in the world relative to the game map and completely independent of the camera. However, when it comes to drawing them, that's when I take into account the position of the camera to convert their positions to screen positions as see in my code snippet:

drawPosY = y - gameCamera.getY() + ( yvel * interpolation );



drawPosY is the screen position, y is the object's position in the world, gameCamera.getY() is the camera's position that's subtracted from y and then the interpolation is added to that.

The problem is that gameCamera is not being interpolated itself and so it's causing stuttering because it's falling behind sorta. Interpolating it didn't work either though because an object that was static on the screen was jittering since it too was being interpolated (its velocity was equal to the movement speed of the map) and so it was being drawn slightly ahead of where it should be and then snapping back.

I suppose I COULD just interpolate the camera too again and then put in an if statement saying that if an object is moving at the same rate as the camera then don't use interpolation at all but then that seems somewhat of a kludge.

Share this post


Link to post
Share on other sites
Spynacker    106
I finally read through Witters article and came across
the point where he explicitly says that the camera should
be interpolated too:
Quote:
...What you have to do then is make a "prediction" function where the car/camera/... would be placed at the render time...

Maybe thats your only problem:
You are between the frames of the game_update() and interpolate
your objects all along their velocity vectors whilst your camera is
staying in position until it gets the new step by game_update().
So its position is changing radically but the other objects stay at
their predicted position. And that might lead to your problem of
jittery objects.

Share this post


Link to post
Share on other sites
Sean_Seanston    880
Quote:
Original post by Spynacker
I finally read through Witters article and came across
the point where he explicitly says that the camera should
be interpolated too:
Quote:
...What you have to do then is make a "prediction" function where the car/camera/... would be placed at the render time...


Ah... nice, I hadn't noticed that before. I think I just read "car/camera/..." as being a load of generic objects you might want to draw and paid no attention to the part mentioning the camera.

Pity he doesn't explain how though :/

It's just the psrt where other objects need to determine their draw position based on the camera. It's kind of hard to imagine.

Quote:
Original post by Spynacker
You are between the frames of the game_update() and interpolate
your objects all along their velocity vectors whilst your camera is
staying in position until it gets the new step by game_update().
So its position is changing radically but the other objects stay at
their predicted position. And that might lead to your problem of
jittery objects.


Yeah, it's definitely due to how that's set up. I think specifically because the camera isn't moving (or rather, isn't getting a new draw position by interpolation) while other objects are getting new interpolated draw positions.

Does anyone know roughly how that should be done? I think objects that are stationary w.r.t the screen is the only real problem I have. Or perhaps rather, the problem I have is only noticeable when that happens.

Share this post


Link to post
Share on other sites
Spynacker    106
Its just the same as the other objects.
You got your per-frame-cameraposition and the direction your camera will
be moving to the next time game_update() is called. So you
just get the interpolated cameraposition the same way:
campos_interpolated=campos+camdirection*interpolation

Thats in vector maths but also fits if you are just moving in
one scalar direction.

Hope that helped.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this