Changing height of sprite via tween or manually every tick, weird issue / potential bug

0 favourites
  • 5 posts
From the Asset Store
Forget about default textbox restrictions, you can create sprites atop of the textbox
  • Hey, I'm curious if I have done something wrong, but when I change the height of a sprite smoothly over time, if the sprite is small (in screen space), the change to height appears as though it is happening at a low frame rate. The smaller the object, the lower the framerate.

    Given a different way, if an object is 32 pixels on screen, a tween from full height to 0 height, will appear to take place in obvious "discrete steps" at like 2fps. If the tween(linear) only lasts a second, you get a height change that more or less looks like full height, half height, done. The same object taking up 300 pixels on screen, will appear to have a more "steps" (basically 60 fps) to acomplish the same effect.

    Obviously a retro project will have pixel snapping and all that, but this issue affects any combo of those settings.

    Does anyone know what might be happening here to cause this? I can share a file, I just wasn't sure what the standard method of sharing was for c3.

  • Huh, I've tried it and that's actually what's happening. Kinda weird. I've noticed that it has something to do with the screen size/resolution. If my layout is 1920x1080 and I preview in fullscreen, the effect is not as pronounced (if it exists at all). But if I scale the window down further and further, the effect gets worse and worse.

    A 32x32 sprite at 1/8 resolution is effectively just 4 pixels high. And it needs to shrink 8 pixels in actuality, to reflect a single pixel of shrinking onto the scaled down sprite, which will visually result in distinct steps of shrinking.

    Looks like subpixels are not rendered correctly when scaled down? But I dunno, someone with more knowledge gotta weigh in on that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Looks like subpixels are not rendered correctly when scaled down? But I dunno, someone with more knowledge gotta weigh in on that.

    Originally I thought it was an issue with pixel stepping and the like, which was the first thing on the list of supsects, but you may be right. As I play with it more, it does indeed seem to be a rendering issue with sub pixels.

  • I tried it and it looks fine to me. Always share a project! More often than most people expect, it depends on exactly what you're doing.

    I'd guess it's some kind of mipmapping artefacts you're seeing, but that's only a guess without knowing what's really happening.

  • Ashley , thanks. I realized now after creating another project that it had to do with the way I was pinning the covering sprite (at the center), the speed of the height change (in absolute pixels over time) and the display resolution. By changing height over time (slowly over,say 5 seconds) with a center image point, the object ends up "clicking 2 pixels at a time" in height change. Basically, since the object is shrinking from both top and bottom, the way the math works you get both the top of the sprite and bottom rounding at the same time, creating a "click". If the sprite displayed is absolutely only 8 pixels on screen, and the screen is low res enough to see the pixels (1080p 15"), you can def see the height change occur in 4 "distinct" steps - which makes sense after doing the math.

    In short, setup issue, combined with a particular display.

    Thanks for the project file!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)