🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Why is so difficult to do clean pixel art with modern game engines?

A topic by onepixolforever created 1 year ago Views: 2,177 Replies: 6
Viewing posts 1 to 7

Hi!

Can anybody explain to me why 2d sprites in motion are so jittery? Is there a technical reason?

So far I've tried 3 engines:

With Game Maker Studio and Unity and both have the same problem:

The test sprite moving through the screen is extremely jittery. (You can see the GMS studio test in this videohttps://youtu.be/37MTje2eeTE

)

I just don't know why this happend (and I've tried every possible v-sync, aa, resolution configuration )

With Love2d this problem almost doesn't exists and the sprite scroll way more fluidly.

I'd like to make a test with UE4 but I don't really know how to use it.

Anybody have this problem? Is there a solution?

Thanks!

(+1)

My first thought is that the movement is not pixel-perfect.

Let's say your games resolution is 640x360, but it is scaled up to 1920x1080. When the sprite moves, the pixels on the sprite move at a subpixel level (essentially occupying space between two pixels), causing a visual effect that appears to be jitter. Now, this is just speculation, and may be totally wrong. But if this is the case, a way to fix it in unity would to draw your scene to a render texture.

Have you tried on different hardware?

The issue may be related to the "advanced rendering feature" used by popular 3d engine (like Unity) which are not properly rendered by your own PC (especially if you have and integrated GPU or you're on a laptop). Try exporting into binary format for another PC to see if this issue is replicated.

(Edited 1 time)

Pretty funny music, haha.


But yeah, I think I'd agree with Travis; it might be that the movement's not being moved "cleanly" across whole pixels; when the renderer draws the object, it does the best it can with the sprite not "on grid", and might draw it "rounded off" to a position, which is different on the next frame. Another way to fix this might be to move it as you like, but snap the drawn position of the sprite to solid intervals of whole pixel steps.

Yup, I think that's what SolarLune said. I've been having this problem A LOT in the past with GM:S.

The problem is that graphics cards these days are all designed for 3D Unreal engine-type games (which makes sense, given it's the more difficult problem computationally). In order to do 2D stuff correctly though you have to work backwards. In Beat Bros (Unity game) every quad is first snapped to the nearest pixel, then drawn to a low-res render texture, before it's all blown up to screen size with the point filter. Note that unless the monitor's resolution is a direct multiple of your game's, you will get slight inconsistencies between the pixel sizes. But this is hardly a problem visually on 1080p monitors, unless you are doing a very high-res pixel art game.

As for GM:S, I find the best way to handle upscaling is to have the viewport be the same size as the view in-game, and then change the size of the window to an integer multiple of that (with code on run-time in the first room's creation code)... this keeps the application surface pixel-perfect, but stretches it to cover the larger window. If you have graphics interpolation turned off, it's drawn without interpolation, and as a result you get crisp crunchy pixels <3

(Also, if you remember the "lines between tiles" issue, this way to upscale graphics also resolves that)