I'm developing a game and I want to make a sliding background. The background is not scrolling smoothly. I logged the fps, but it was ok. This is my code, I don't know what I'm doing wrong, any ideas?

public class MyGdxGame implements ApplicationListener {
    private OrthographicCamera camera;
    private SpriteBatch batch;
    Texture back;
    float offset =  0f;

    FPSLogger logger = new FPSLogger();
    public void create() {
        camera = new OrthographicCamera(320, 480);
        camera.position.set(320 / 2, 480 / 2, 0);
        batch = new SpriteBatch();
        back= new Texture(Gdx.files.internal("back.png"));

    public void dispose() {

    public void render() {
        offset +=  (400f * Gdx.graphics.getDeltaTime());
        offset = offset % 480f;
        batch.draw(back, 0, offset);
        batch.draw(back, 0, offset - 480);

    public void resize(int width, int height) {

    public void pause() {

    public void resume() {

I uploaded the code to bring more information, I looked for on internet and a lot of people have the same problem, but I didn't find solution. I have almost finished the game, change the library will be a pity, any can help me? Thanks! This is the code: https://www.dropbox.com/sh/t26gt33wcex5izn/AAD8-yBSOztZfHe4wzDPRjjQa

  • \$\begingroup\$ Is offset an integer? If so, using a float might improve the smoothness. Just a wild guess though. \$\endgroup\$ May 9 '14 at 2:42
  • \$\begingroup\$ Declare offset as a float instead of int or DWORD or whatever integral type you are using. Also, why are you drawing twice instead of once? And try to put parantheses like that: offset += ( 400 * Gdx.graphics.getDeltaTime() ); \$\endgroup\$
    – Lighthink
    May 9 '14 at 4:43
  • \$\begingroup\$ Thank you! Yes it was integer, and I fixed it, but it's still not smooth. \$\endgroup\$ May 10 '14 at 13:27

Without any further information (and you don't provide enough for us to give a positive answer for sure), the most likely solution for your problem is that you're introducing some granularity you don't realise. For example the line:

offset += 400 * Gdx.graphics.getDeltaTime();

Gdx.graphics.getDeltaTime() will return a float, and it will likely be a very small float. At 60fps, the result of that equation will be somewhere near 6.6666666... But if offset is an integer, then it will either increase by 7 units each update. That .6666666 will get thrown away, and your background will move 0.3333333 further than it should have done. Over time that error will accumulate. If the frame rate was perfectly constant, you might not notice, because it would always be 6, or always 7, and would appear perfectly constant as well, even though it's actually moving slower or faster than it actually should be.

If your framerate varies up to ~62 fps, then offset will suddenly start advancing by 6 every update instead of 7, a decrease in speed of almost ~15% even though the frame-rate has only increased by ~3%. This will manifest as a kind of jitter, moving slower or faster as the frame-rate varies.

The obvious solution there is to make offset a float, so that any movement less than 1px is preserved, and when accumulated will give the correct rate of motion. That may not be the only extra granularity in your system though, but you've not given us enough information to diagnose any better than that.

  • \$\begingroup\$ Thank you for the answer. I apologize for my bad english. You was righh, and I fixed it, but it's still not smooth. I edited the code, to give you more information, but the code it´s really simple. Thank you! \$\endgroup\$ May 10 '14 at 13:25
  • \$\begingroup\$ I uploaded the code to bring more information... thank you! \$\endgroup\$ May 11 '14 at 0:29

Well, I asked the same question in the libgdx forum so here I share the response I got in case someone has the same problem.

You didnt find a solotion, because there isnt one. Fps loggers spits out avarage framerate. Since you dont have total control over hardware, stuff is going on in the background. And this stuff will make your stuff slow down randomly. Or cause gc or something. Focus on makaing interesting game and most people wont notice. Unless you cause gc then they will.

It's a shame to have to migrate everything, but this is not a good framework at least for me.

  • 2
    \$\begingroup\$ I'm pretty sure LibGDX is fine, and you're making something wrong. This gets very clear when the code points out that you're trying to move something 400 units per second. \$\endgroup\$ May 21 '14 at 23:12
  • \$\begingroup\$ I wish that I'm doing something wrong, but no one knows what it is, the code is really simple. Why do you say that is wrong in moving something at 400 units per second? What I'm trying to move is the background and I think it is a reasonable speed. What would be the correct code to move the background without blink for you? \$\endgroup\$ May 22 '14 at 0:15
  • 1
    \$\begingroup\$ Fundamentally, every framework is going to give you the same results. The reason why you take frame delta time into account is because you expect the frame time to be erratic, on PC. How noticeable that is depends on what you're doing. Try Googling Euler and Verlet integration for an explanation as to why you can't simply take velocity * frame time and have it equate to distance covered. I don't think that's the cause of this backdrop problem (because your velocity is constant), but you'll get a better handle on the problem. Don't just naively migrate frameworks - you'll not gain anything. \$\endgroup\$
    – MrCranky
    May 22 '14 at 9:03
  • \$\begingroup\$ Hello, I think that Euler and Verlet is not necessary in this case, as I have understood the calculations are fine. I already tried in javascript and opengl and I have no problems. In libgdx forum, other user tested it with unity and had no problem neither. Why do you say that I will have the same issue with every framework? Have you tested it?... Perhaps it is due to some configuration libgdx unknown to me, but so far there is no solution. \$\endgroup\$ May 22 '14 at 15:29
  • \$\begingroup\$ "Euler is not necessary", did you realize that you're already using Euler? Anyway, moving things at 400 units per second is not a reasonable speed. If your units are pixels, you can't expect things to move 6.666 pixels per frame and still look smooth. \$\endgroup\$ May 23 '14 at 3:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .