Sprites appear to stretch when moving at slow speed

2D
, , ,
1

I am trying to use the rigidbody movement in order to make a block fall at constant speed. However, when launching Play mode the blocks appear to stretch in the movement direction. The sprites have been created on an 8x8 grid and PPU is set to 8. I have also created a 128x128 sprite and relative PPU version, but didn’t solve the issue. VSync is active and set to “Every V Blanc”, and have tried all settings for rb interpolation.

Link to video evidence: Watch Blocks Stretching | Streamable

This is the code I am using. Versions based on transform and rb.MovePosition have been tried but with no success:

using UnityEngine;

public class BlockController : MonoBehaviour

{
    [Header("Movement settings")]

    public float FallSpeed = 0.5f;

    private Rigidbody2D rb;

    void Start()

    {
        rb=GetComponent<Rigidbody2D>();

        if(rb == null)
        Debug.LogError("Missing Rigidbody on block!");

        rb.bodyType = RigidbodyType2D.Kinematic;

        Fall();
    }

    public void Fall()
    {
        rb.linearVelocityY = -FallSpeed;
    }

}

Looking for more possible solutions. Thank you all for the contribution

2

Try enabling Unity - Scripting API: RigidbodyInterpolation2D
on the Rigidbody2D component and see if this fixes the issue. You can find it under Rigidbody2D → Interpolation in the Inspector.

4

I removed physics tag from this because physics is just updating the transform, it has no effect on rendering. If you are seeing a visual artifact, it’s more likely you are describing the rise/fall time of your display. The way to determine that is if you cannot capture it using the OS (screenshot/video capture). If you can only see if in a photo of the screen or viewing it yourself then it’s your display.

Not using interpolation simply means it updates at the fixed-update rate of 50Hz by default. That’s smooth or non-smooth motion, not stretching though. That said, the rise/fall-time of your display can lead this to look like it has a rendering “tail” as your monitor catches up.

This is a good test for your display btw: UFO Test: Multiple Framerates

5

You are experiencing the effect of subpixel rendering of pixel art.

When you move an 8px high sprite down by half a pixel, what actually gets rendered is 7-8 solid pixel rows and an additional row that’s at a lower brightness. With high contrast pixel art and slow but steady motion this becomes noticable as a slight “wavy” nature in the motion.

The naive fix is to ensure you have the pixel perfect component on the camera and to enable pixel snapping. But this will introduce another oddity: one frame a sprite moves, the next it doesn’t. This is then noticable as unsteady motion.

The only true fix, and just one of the many reasons why I would never recommend a scrolling pixel art game as an early user experience, is to ensure the motion is capped to exact pixel boundaries. This isn’t hard but also not trivial, but “depends” on various factors. So I would still recommend the pixel snapping solution initially.

But at 8 PPU and 8x8 sprites this means 1 unit equals 1/8th (0.125) of units. So if you specifically make a sprite move at 0.125 units every frame you should notice that this effect is gone for that sprite. You can move it at any multiple of that without seeing this effect.

However, you may still need to clamp the resulting transform position in LateUpdate because of the nature of floating point arithmetics accumulating small rounding errors over time which may or may not surface as subpixel rendering eventually again. Or combine it with pixel snapping doing that task for you.

6

Update: moving away from free aspect solved the issue at runtime. Defining a target resolution seems to have done the trick. If someone could point out exactly why this would be much appreciated.
Hope this can be useful information!

Uploaded video:

image

Local fixed run

image

If request, will upload a video of the smooth run.

7

Thank you all @meredoth @MelvMay and @CodeSmile for your time, I will galdly dive into your suggestions anyway!