Why is scrolling a Tiled Background choppy?

I'm using a 256x256 graphic in a Tiled Background on a 720x1280 game. It has a Bullet behavior to make it scroll down, and a check to reset its position to make the illusion of an infinite scroll.

It's as simple as can be, but it's choppy even on my PC, not to mention mobile. On the PC, it's smooth for the first few seconds, but then the chop settles in. On mobile, it's choppy right from the start.

The frame rate is great (60 on PC, 55-60 on mobile), CPU use is minimal, and WebGL is active on both. I can't think of any reason that it's not smooth as silk.

I've played with all the graphic project options (sampling, scaling, etc), but none of them has any effect. It's still chop, chop, chop.

An example is attached. Does anyone have any idea what's going on?

Thanks!

Well, Delete the Bullet and the scorll to behavior from the Tiled Background,and if you want to make the camera scroll to the tiled background, add the scroll to behavior.

Hope that Help

Interesting. I can't say for sure, but it's possible that the bullet behavior is interacting unfavorably with the reset point.

I think, instead of the bullet behavior, you could try some combination of System -> Every X Seconds and TiledBackground -> Move Y pixels at angle 90. The larger X is the better, in terms of CPU utilization, but your results may vary.

bullet behavior is not for scrolling a background!

Have a look at this tutorial on how to do it right:

Well, Delete the Bullet and the scorll to behavior from the Tiled Background,and if you want to make the camera scroll to the tiled background, add the scroll to behavior.

I'm wanting to make an "infinite runner" type of game, which doesn't work well with the Scroll To behavior. With it, to "loop" would require repositioning every sprite relative to the background. It is much simpler to reposition the background relative to the sprites. But thanks for the thought!

bullet behavior is not for scrolling a background!

Actually, it is. It's the officially recommended method in the samples included with C2. Also, behind the scenes all the Bullet behavior is doing is exactly what that video describes. Bullet just puts a friendlier face on it.

Interesting. I can't say for sure, but it's possible that the bullet behavior is interacting unfavorably with the reset point.

I think, instead of the bullet behavior, you could try some combination of System -> Every X Seconds and TiledBackground -> Move Y pixels at angle 90. The larger X is the better, in terms of CPU utilization, but your results may vary.

Thanks for the suggestion! Unfortunately, doing it in that manner ties the scroll to the frame rate. Which means if the rate drops the game will "slow down" without compensating for the drop. The change needs to be multiplied by the "delta time" (dt), which is the elapsed time since the last tick. That gives a smooth game time regardless of the frame rate. (And what the Bullet behavior is doing behind the scenes.)

TrickyWidget , you are correct about the bullet behavior, this isn't the cause of the problem.

There are two factors that I know off that affect your scrolling test.

1) The whole HTML5-browser engine that always have some kind of jerkiness in movement, no matter how simple a scene is. It just isn't smooth, there are many topics about this and I'm not very optimistic about it. Unfortunatly, there is nothing you can do about it.

2) In your events, don't just subtract 256 from the Y, instead use this: Set Y to self.Y - 256. Most of the time, the TB isn't exactly >=0, depending on the scrolling speed it might be many pixels ahead on the tick that fill this condition. So, if it's lets say Y=10 and you subtract -256 you won't get Y=-256 but Y=-246 hence a visual "jump". If you use the self.Y-256 however, you ensure that the subtraction compensate for the TBs current Y value and there won't be any discontinuations in the movement.

1) The whole HTML5-browser engine that always have some kind of jerkiness in movement, no matter how simple a scene is. It just isn't smooth, there are many topics about this and I'm not very optimistic about it. Unfortunatly, there is nothing you can do about it.

Ah, that's discouraging. Though it matches my experience with my other projects.

2) In your events, don't just subtract 256 from the Y, instead use this: Set Y to self.Y - 256. Most of the time, the TB isn't exactly >=0, depending on the scrolling speed it might be many pixels ahead on the tick that fill this condition. So, if it's lets say Y=10 and you subtract -256 you won't get Y=-256 but Y=-246 hence a visual "jump". If you use the self.Y-256 however, you ensure that the subtraction compensate for the TBs current Y value and there won't be any discontinuations in the movement.

Ah ha! Of course. That was exactly it. Now it's smooth as silk on my PC. Still choppy on mobile, but that can perhaps be addressed.

Thank you very much!

TrickyWidget , you are welcome!