Sprite becomes unfocused as movement increases

[BabyBlue]

Hello All,

I apologize if this is a frequent question, I've searched all over and can not find a solution. I'm hoping my eye sight isn't just going out of whack.
Whenever I create an object and code any movement, the sprite becomes very jittery as soon as I increase the speed from the bare minimum.

Video of the Issue in question:

I boiled down my code as little as possible to demonstrate the issue. I've created five separate objects with the same code in the step event:

x += 1

if x > 640
    {   
        x = xstart
    }

Object_1 has x incrementing by 1, Object_2 has x incrementing by 2, etc. Object_1 appears just as expected, however by the time I get to Object_4 the sprite in unfocused, Object_5 the sprite is so blurred my characters eyes almost look to be merged.
Every post I found people point to interpolation and subpixel movement, but I've made sure interpolation is off and I'm doing the most basic calculation possible. I've also tried rounding functions. I know its silly to complain about faster images being blurrier, but even just setting the x coordinate to increment by x+=5 produces ridiculously blurry results.

My Settings
FPS: 60
Room size: 640x360
Sprite Resolution: 32x32
Interpolate colors between Pixels: OFF
​

I also have two 144hz monitors, and no 2D game or YouTube video I watch gets this blurry with this kind of movement.
Please let me know if you have any ideas or input. I'm hoping I'm just having an air head moment and glossing over something obvious.

 

[Mr.Celsuis]

I have this exact same problem, I have looked for a solution for months, and before anyone replies “it’s monitor ghosting” it’s not, I have a 144 hrz monitor too and when I turn the room speed up to 999 the blurriness stops a bit because technically if you slow down the player’s speed it will still move fast because of the room speed. But if I move the player fast with the room speed up that high too than I can see REAL monitor ghosting, so if someone has a solution than please say.

Edit: me and the OP have the exact same specs

 

[Slyddar]

If you pause your video and use the > key to move 1 frame at a time you will see it's not ghosting, and each frame is being displayed correctly. When played on a black background the effect you're seeing is much more pronounced. So in the end the problem reverts to the monitor not refreshing quickly enough for your eyes. It does it on mine too, as the screen can't turn the pixels off quick enough and you're left with a trail. Try filming your monitor on your phone in slow motion and it will show the pixels not turning to black quick enough.

 

[RefresherTowel]

Also, in "real" games, the camera is usually locked to the player (within reason) and this, combined with the fact that players are usually focusing on whatever the camera is locked to (meaning fast moving objects on the periphery get ignored by the "detail area" of the eye), combined with the games having actual backgrounds instead of a plain colour, means that the issue that Slyddar is describing (which I believe is the actual issue) is much less noticeable with commercial games. Also, there's scaling and sometimes post-processing effects (depending on what type of game you're talking about) that also further mask any of these issues. It's likely that if you took any game you are talking about and removed everything and had their character sprite moving on a black background like that, you would see the exact same issue.

 

[GMWolf]

What you may be seeing is what I'm going to dub frame aliasing. (I'm sure there is a better term).

You game is running at 60 Hz but your monitor is 144hz. Those don't divide neatly. So you get some images displayed for 2 frames, and others displayed for 3 frames. Maybe you are perceiving this as jittery movement.

Experiment with setting your game speed to a factor of 144 (144, 72, ...) And see if that goes away.
In practice the solution would be to use delta timing to match everyone's monitor refresh speed. But since this is only really visible with very smooth movement it shouldn't actually matter for an actual game.

If that's not what you are seeing then it's most likely ghosting. Just because your monitor is 144hz doesn't mean that it won't ghost, especially when you create the perfect condition to see ghosting (black background, smooth moving sprites).

L

 

[BabyBlue]

Hey guys, really appreciate the feedback.

What you're saying makes total sense, and it feels like the most logical explanation.

I mean this is pretty much the proof in the pudding:

If you pause your video and use the > key to move 1 frame at a time you will see it's not ghosting

I guess I'm confused on two parts:
1) I would figure this would be an issue at much higher speeds. I feel like even my last example in the video I included is such a moderate speed.
2) I don't notice this issue in any GM2 movement tutorial video on youtube that almost identical logic, despite me still seeing its clear as day in my own video at the same FPS.

As for my second point, I'm sure its a number of factors. My sprite is pretty messy and low res so I'm sure that emphasizes it, but I do usually test against a light blue background.

I still got a lot to learn, thanks again for the feedback.

 

[BabyBlue]

Experiment with setting your game speed to a factor of 144 (144, 72, ...) And see if that goes away.

Holy cow this is the closest I've gotten to the end result I want! I set x += 1, set game speed to 144, and dragged the window to one of my 144hz monitors not only does it move relative to the speed I want (which again is a brisk walk at most) and there is no blurriness. Thanks for the suggestion.

I guess my next step is trying to figure out to mimic that smoothness at that object speed at 60 fps. I mean it makes sense having 144 steps a second incrementing x by 1 be smoother than 60 steps a second incrementing x by 2 ore more. I think I need to play with my visuals and camera work I guess. Thanks again everyone!

 

[RefresherTowel]

Holy cow this is the closest I've gotten to the end result I want! I set x += 1, set game speed to 144, and dragged the window to one of my 144hz monitors not only does it move relative to the speed I want (which again is a brisk walk at most) and there is no blurriness. Thanks for the suggestion.

I guess my next step is trying to figure out to mimic that smoothness at that object speed at 60 fps. I mean it makes sense having 144 steps a second incrementing x by 1 be smoother than 60 steps a second incrementing x by 2 ore more. I think I need to play with my visuals and camera work I guess. Thanks again everyone!

Just remember that, at least for now, 60FPS monitors are far more common, so if you optimise for 144hz, expect everyone else without a 144hz monitor to experience weirdness similar to what you are experiencing now. That's why GMWolf is suggesting implementing delta time, which will scale accordingly and remove the weirdness for all players. Alternatively (and much easier), don't worry about the problem as once you have a properly functioning game instead of a blank canvas test project, the issues are likely to be less noticeable (especially to players who aren't focusing on whether the issue is happening or not, unlike yourself who will probably always be eagle-eyed for it from now on).

 

[Nocturne]

An excellent site to test and check different artifacts created by FPS, high contrast sprites/backgrounds, etc.... is here: https://www.testufo.com/

And I would just reiterate on what @RefresherTowel said: At the moment, this "problem" is obvious because you are testing bright sprites on a black background, which is pretty much the worst case scenario for testing! You are forcing screen pixels to go from 100% brightness to 0% brightness in a single frame of movement, which is impossible and gives "ghosting". Once you have an actual game, with a proper background and less contrast between pixel brightness, this issue will cease to exist. I honestly wouldn't worry too much about it, and I'd make your game around a 60fps standard rather than try and adapt...

 

[GMWolf]

Yes, even though I consider delta timing the correct approach, it's not what I would recommend.

Like the others I recommend you stick to a room speed of 60 and not worry about these issues for now.

 

[gnysek]

That's a place where delta timing enters! Of course that's not easy task, but ideally, your game could have option to run in 60 FPS or 72 FPS mode, and by using delta timing could have same speed of movement and animations.

 

[Mr.Celsuis]

Although I’m not using a black background so that doesn’t really make sense. And nobody covered how the blurriness goes away when I move the room speed up to 999 like what I said in my first post.

 

[gnysek]

And nobody covered how the blurriness goes away when I move the room speed up to 999 like what I said in my first post.

It's explained above. That's just a feeling, that there's any blur. It's you eyes, your brain, and number of frames number common division with game FPS and monitor refresh rate. Also, setting game to 999 isn't a good idea, as this means refreshing screen 999 times and executing step event 999 times. Game will slow down really fast.

 

[Vusur]

So we have

1. Brightness: Bright Sprite on dark background
2. Refreshrate: Hz 'mod' room_speed != 0

I throw a third option in (didn't see it in the video, but it's quite common): The camera/view settings.
There is a 'Camera Properties' (CP), how much you see from the room in pixel and a 'Viewport Properties' (VP), how "big" the game window is when running in pixel.
If VP 'mod' CP != 0, movement can also be look like ghosting. CP should be scaled by integer.

Example:
CP with 640x360; VP with 960x480. VP is 1.5x bigger than CP (sidenote 1.5 is the worst scale you can get imho).
Look at this 1 pixel line:

Spoiler: 1 pixel line

This is slowed down to 1FPS. See how it switches between 1 and 2 pixels each step? Because what is 1.5 * 1px? 1 or 2? This can happen with bigger sprites. With faster movement, it looks awefull and jittery. At some speed, the brain corrects this jitter but now it's blurry.

Maybe your problem is related to that, @Mr.Celsuis ? In combination with the other two?

 

[Mr.Celsuis]

So we have

1. Brightness: Bright Sprite on dark background
2. Refreshrate: Hz 'mod' room_speed != 0

I throw a third option in (didn't see it in the video, but it's quite common): The camera/view settings.
There is a 'Camera Properties' (CP), how much you see from the room in pixel and a 'Viewport Properties' (VP), how "big" the game window is when running in pixel.
If VP 'mod' CP != 0, movement can also be look like ghosting. CP should be scaled by integer.

Example:
CP with 640x360; VP with 960x480. VP is 1.5x bigger than CP (sidenote 1.5 is the worst scale you can get imho).
Look at this 1 pixel line:

Spoiler: 1 pixel line

View attachment 41125

This is slowed down to 1FPS. See how it switches between 1 and 2 pixels each step? Because what is 1.5 * 1px? 1 or 2? This can happen with bigger sprites. With faster movement, it looks awefull and jittery. At some speed, the brain corrects this jitter but now it's blurry.

Maybe your problem is related to that, @Mr.Celsuis ? In combination with the other two?

Thanks for the reply but my vp is the same size as my cp, honestly I expected this, I think that mostly it’s just me criticizing every aspect of my game (I’m trying not to be a perfectionist lol)