• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Magdev

Player Jittering with Camera Follow

10 posts in this topic

I'm making a 2D sidescroller in XNA  and I'm having an issue with the way the camera follows the player. When the player walks left or right, and its walk speed is a decimal number, there's jitter.

 

Lpwkcxh.gif

This is what it looks like. I had to slow the game down to 50% speed for the gif to catch the jitter frames.

(Ignore the random vertical twitching, that's just some strange graphical bug that happens when I scale the backbuffer up too far.)

 

I believe the cause of this is the relative speed between the camera and the player.

In the gif, the player's speed is at 1.5, so it will alternate between moving one pixel and two pixels per frame. This causes a sort of desync between the player and camera movement which causes the jitter.

 

I need to be able to use decimal speeds because first of all, a speed of 1 is a bit slow for the player, and 2 is a bit fast, but also, if I add acceleration/deceleration the player's speed won't always be a whole number.

 

 

Some details:

 

- Nothing is rounded in-code. All positions and velocities are floats. Rounding isn't needed since nothing can move in sub-pixels. I reduced the backbuffer resolution so changing an object's position by 1 will move it one pixel. Everything is drawn at integer positions, of course.

 

- It's not the update order. The cycle is simple right now. The player moves, then the camera is updated. Switching the order doesn't fix the issue.

 

- I remembered that Cave Story has nice and smooth camera interpolation, and large pixels, so I fired it up to see what it looks like, and I was really surprised too see that it suffers the same problem. For roughly a second after the camera starts moving, the player jitters by one horizontal pixel.

 

 

My camera movement interpolation code is this:

if (camPos != playerPos) camPos += (playerPos - camPos) * strength;

 

Any ideas on how to fix this? I'm sure SOMEBODY has had this issue before other than me (and Pixel).

 

If I need to include any more relevant code snippets, just let me know. I can't really think of any that would help at the moment.

Edited by Magdev
0

Share this post


Link to post
Share on other sites

If everything is drawn at one pixel increments but the camera moves continuously then there is going to be aliasing between the 2 values over time when the values get truncated to pixel boundaries.

 

eg. Imagine your player moves at 0.7 pixels to the right per frame.

 

Frame 1: x=0.7 renderX=0

Frame 2: x=1.4 renderX=1

Frame 3: x=2.1 renderX=2

Frame 4: x=2.8 renderX=2

Frame 5: x=3.5 renderX=3

 

Between frame 3 and frame 4 the player doesn't move from pixel 2 at all, but the camera will have moved ahead, some way towards 2.8. The camera moves continuously but the player motion does not.

 

You need to make your camera track the on-screen render position, not the logical position before rendering.

2

Share this post


Link to post
Share on other sites

You need to make your camera track the on-screen render position, not the logical position before rendering.

 

Ooh. That makes a lot of sense. I did what you said and it fixed the jittering during constant movement, but there's still jittering while the camera builds up to the player's speed.

 

JELQYJl.gif

 

I ran the game at 10% speed and output the camera's delta and position, holding a key to mark the jittering frames when I saw them.

 

sF53YpT.png

 

 It's not super accurate because of my timing, but it seems like it only jitters when the camera moving more than one pixel per frame. The player moves at a constant speed of 1.5. When the camera is at 1.5 delta, it alternates between one pixel per frame and 2. Not sure how helpful this information is.

 

I could possibly clamp the camera speed below 1, but that's probably too slow, and just a workaround rather than a fix.

Any ideas?

Edited by Magdev
0

Share this post


Link to post
Share on other sites
if (camPos != playerPos) camPos += (playerPos - camPos) * strength;
This seems dodgy to me. What happens if the distance between player and camera is smaller than the length of (playerPos-camPos)*strength? This would happen if strength>1. You don't show how you calculate strength, so I assume it's tied to elapsed time somehow. If strength>1 then the camera will over-shoot the player's position which can possibly cause camera stutter. You might try clamping strength to 1 to keep it from overshooting. Edited by FLeBlanc
1

Share this post


Link to post
Share on other sites

I saw that code but assumed you have updated it to make the camera movement relative to the on-screen player position. The problem is in my opinion that the camera may sometimes need to move faster then the player to catch it. A possible solution may be to clamp the camera movement to the player movement on screen when the player is moving (i.e. its velocity is non zero).

1

Share this post


Link to post
Share on other sites

It's not super accurate because of my timing, but it seems like it only jitters when the camera moving more than one pixel per frame. The player moves at a constant speed of 1.5. When the camera is at 1.5 delta, it alternates between one pixel per frame and 2. Not sure how helpful this information is.

 

To some degree this is an inevitable consequence of the system you have. You're essentially rounding a real number to an integer and so you have an effective error of +/- 0.5 each time. This means the movement speed in pixels varies by up to one whole pixel from frame to frame, which means it's going to jump ahead and behind a camera moving at a continuous rate. Making the camera track the pixel position like I suggested may reduce the problem but, now I think about it more clearly, it can't solve it.

 

I think the only real solution is to be able to move both the entity and the camera with subpixel precision, or to lock the camera to the entity pixel position (rather than attempting to smoothly track it after it moves).

1

Share this post


Link to post
Share on other sites

if (camPos != playerPos) camPos += (playerPos - camPos) * strength;
This seems dodgy to me. What happens if the distance between player and camera is smaller than the length of (playerPos-camPos)*strength? This would happen if strength>1. You don't show how you calculate strength, so I assume it's tied to elapsed time somehow. If strength>1 then the camera will over-shoot the player's position which can possibly cause camera stutter. You might try clamping strength to 1 to keep it from overshooting.

Strength is just a constant between 0 and 1 that I define in-code which is just the strength that the camera follows the player. No time variable is needed.

 

The problem is in my opinion that the camera may sometimes need to move faster then the player to catch it.

That's not related to the jittering problem, but it can be a problem for some people. I don't see it as a problem though. I don't think it's even possible for the player to move fast enough to leave the camera's view, but if it is, it's not really a big deal. If it becomes an issue then I can just constrain it.

 

 

To some degree this is an inevitable consequence of the system you have. You're essentially rounding a real number to an integer and so you have an effective error of +/- 0.5 each time. This means the movement speed in pixels varies by up to one whole pixel from frame to frame, which means it's going to jump ahead and behind a camera moving at a continuous rate. Making the camera track the pixel position like I suggested may reduce the problem but, now I think about it more clearly, it can't solve it.

 

I think the only real solution is to be able to move both the entity and the camera with subpixel precision, or to lock the camera to the entity pixel position (rather than attempting to smoothly track it after it moves).

 

Yeah, it does seem like the nature of the system. I have a few workaround ideas in my head, but at the very least, the first fix did make it pretty acceptable and not very noticeable. The jittering how it is now is exactly like Cave Story's jittering, which is barely noticeable, which also reinforces how it's probably not worth fixing further. Thanks a lot for your help.

 

If I come across anything that makes it better, I'll post it in this thread.

Edited by Magdev
0

Share this post


Link to post
Share on other sites

You have misunderstood my suggestion. Let suppose the player is moving 1 pixel in some direction. Since (playerPos - camPos)*strength is not related to the player movement, it can be any value. In particular, it may rounds to 2 pixels in the same direction. The result is the player moving one pixel in the wrong direction. In the next frame the player will move of 2 pixels and the camera of some other amount and you now see a jitter. The jitter is caused by the difference between the camera position and the player position not being a monotonic function. My suggestion is thus to make it monotonic by clamping the camera position so that it does not move faster than the player. When the player is still you clearly have to catch the player if you do not want the player to exit from the screen.

1

Share this post


Link to post
Share on other sites

You have misunderstood my suggestion. Let suppose the player is moving 1 pixel in some direction. Since (playerPos - camPos)*strength is not related to the player movement, it can be any value. In particular, it may rounds to 2 pixels in the same direction. The result is the player moving one pixel in the wrong direction. In the next frame the player will move of 2 pixels and the camera of some other amount and you now see a jitter. The jitter is caused by the difference between the camera position and the player position not being a monotonic function. My suggestion is thus to make it monotonic by clamping the camera position so that it does not move faster than the player. When the player is still you clearly have to catch the player if you do not want the player to exit from the screen.

Ooh. I understand. Yeah, I'll definitely try that.

0

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  
Followers 0