Jerky Scrolling Background After Few Minutes

Post reply
Not favoritedFavorited Favorited 0 favourites
  • 11 posts
From the Asset Store
Touch (scroll, zoom, swipe)
$10 USD
All popular touch mechanics - scrolling, zooming, swiping
paradine's avatar
paradine
Star icon Star icon Star icon Star icon Star icon
Star icon Star icon Star icon Star icon Star icon

  • Hello,

    I accidentally found something strange when testing the scrolling background where the moving image becomes jerky after a few minutes (around 2 minutes).

    Is there something wrong with the action that causes the jerky scrolling background?

    Here is my video to show it.

    Subscribe to Construct videos now

    and also the action. I have try using dt also but the result is same.

  • You definitely need to use dt, not to fix this issue, but to make sure your game runs correctly on different framerates.

    Does this problem happen on PC, in preview? You probably have to wait longer than 2 minutes.

    Does it still happen if you touch the mobile screen from time to time? Perhaps the phone detects no user activity and lowers the framerate or enters some kind of battery-saving mode.

    There could also be a problem with offsetting the image in tiledbackground too far. Try this:

    TiledBackground: Set image X offset to (Self.ImageOffsetX-60×dt)%Self.ImageWidth

  • Yes, sure. I just wanna try in various way.

    I didn't find this issue on PC in preview but frame per second detected 60 in debug mode. It should be 30 fps because I set max delta-time is 1/30. Maybe I misinterpreted it.

    Does it still happen if you touch the mobile screen from time to time?

    I test this. it's still become jerky after around 2 minutes.

    I tried your method, it looks ok. The moving image still normal after 5 minutes.

    TiledBackground: Set image X offset to (Self.ImageOffsetX-60×dt)%Self.ImageWidth

    Great thanks.

  • It should be 30 fps because I set max delta-time is 1/30. Maybe I misinterpreted it.

    No, that action doesn't limit the fps. I suggest removing it.

  • It's actually a known issue with the TiledBackground:

    github.com/Scirra/Construct-bugs/issues/7763

  • It's also noted in the manual:

    Avoid indefinitely increasing the image offset, such as by always adding to it. On some devices, a very large image offset can start to exhibit rendering glitches due to precision issues on the GPU. You can avoid this by wrapping the image offset back to 0 after it exceeds the image size.

  • Avoid indefinitely increasing the image offset, such as by always adding to it.

    Never noticed this! However, in the example browser there are many examples that use this same approach.

  • couldn't this me solved internally by c3 by wrapping image offset by texture size before passing it to the gpu?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • a very large image offset can start to exhibit rendering glitches

    From what I can see, the offset is not that large. 1 pixel per tick, at 60 fps for 120 seconds = only ~7200 px

  • Interesting stuff. The precision of the numbers on the gpu varies depending on the hardware but the renderer does guarantee at least some minimum precisions.

    Webgl1 gives at least 24,16 and 10bit for highp,mediump and lowp float numbers.

    Webgl2 gives at least 32,16 and 10bit for highp,mediump and lowp float numbers.

    But my phone happens to give 32bit for all three.

    Presumably your phone implements the minimum spec or close to it. With less bits floating point numbers have bigger gaps between values when farther from zero. That’s why limiting the offset to be within the size of the image helps since it’s keeping values closer to zero.

    A significant example of that would be the so called “farlands” in Minecraft when exploring extremely far away.

    Anyways, I thought it was interesting. Also the fact that lowp,mediump and highp all are 32bit on my phone means if I was to make a shader I wouldn’t encounter issues that other users would see when I use mediump or lowp.

  • couldn't this me solved internally by c3 by wrapping image offset by texture size before passing it to the gpu?

    I think it's worth experimenting with this, but like many things, it's not as simple as it seems - it can only be applied for the "repeat" wrap mode; it doesn't work with tile randomization; it doesn't work with a nonzero image angle; it might break use cases like scrolling around a fractal generated by a shader that is moved by changing the image offset; possibly there are other edge cases I can't think of right now. So even with automatic wrapping, there are still cases you'll run in to precision issues and have to work around it another way. I think it's a bit close to a stable release to make a change like that, but we'll try it out for the next release cycle and see how it goes.

Post reply
  • 11 posts
Index icon Return to board index
Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)