Smooth camera in pixel perfect game

If you want to do something complex like have a Subviewport with a pixel aesthetic but the main game to be HD with subpixel positioning, you’re unfortunately going to have a complex setup like those videos linked. Even then, with a half modern/half vintage game you’re still going to have jitter in any parallax backgrounds because that’s part of your Subviewport.

Smoothing with pixel art works like a piano. If you slide your hand down the keys it sounds continuous, but if you slow down near the end the individual notes become more noticeable. This is why older games always had the camera move at a consistent speed. You can probably work around that too with a more complex setup, but as I mentioned before, it’s always pushing a square peg through a round hole and depends on how important certain aspects are for your game.

Some examples:
Stardew Valley went full on HD with just pixel assets, so pixels can rotate, stretch, etc.
Celeste used HD assets and just downscaled them, but isn’t pixel perfect.
Even Shovel Knight breaks a lot of rules and was really intentional about it, but everything they modernized is listed here.

that doesn’t fix the problem

I know, it’s weird

I’m sure it’s not intentional, but you’re being very vague about how it isn’t working for you, and what exactly it’s doing that you don’t want. Could you maybe post a video or something showing us the problem? It’s kind of hard to offer suggestions without a clear picture of what’s going wrong.

ok :slight_smile:

Some of the jitter there is probably unavoidable; the distance scaling on the movement of your parallax backgrounds means they’re going to be moving slowly enough that they’ll jitter as they snap from pixel to pixel. There are some things you could try to mitigate this:

  • only use pixel-perfect for the foreground; let the parallax stuff in the background move to subpixel positions, since the player is going to be looking primarily at their character and other things in the foreground
  • don’t move the camera as much; maybe consider keeping the camera still if the player is in the middle 80% of the screen – most of the problem seems to show up in the parallax, so if you can minimize the amount that changes it will help – there are various strategies for this, from having fixed “room” camera positions and transitioning between them when necessary, to having the camera looking at an invisible box filling most of the screen that the player pushes when they try to leave it
  • overlay some animated effect (leaves blowing in the wind, rain, snow, waterfall, dust motes, dripping lava…) that pulls the eye away from the jitter and breaks up the scene visually a bit
  • doing the subpixel thing will also mitigate this somewhat
  • speed things up where you can; jitter is most visible at low speeds – the further something travels, the smaller the proportion of their movement is grid quantization; if something goes 10.5 pixels and snaps, the error is ~5%, while if something goes 1.5 pixels and snaps, that’s an error of ~50%

How?

then the camera won’t be smooth and will feel like a camera from the old school games

That is good, but the jitter will still be there

???

??? I don’t think that would help

With what you want to do, there will be jitter. It’s unavoidable. Pixel-perfect implies and requires jitter. You can try to mitigate it, but you can’t get rid of it.

For pixel-perfect foreground, subpixel background, what you do is use scaled up assets; make everything 4x the size (say), so that every “pixel” is actually 16 pixels in a 4x4 grid, as we’ve discussed elsewhere. Then, when moving foreground things, snap their x and y positions to integer multiples of 4:

if foreground:
    position.x = snappedf(position.x, 4.0)
    position.y = snappedf(position.y, 4.0)

For background things, don’t quantize their positions. That will allow the background to move to “subpixel” positions, while the foreground will snap to your 4x4 “pixel” grid.

As for moving the camera less, well… Really old-school games did “room” based cameras because scrolling the tilemap was difficult or impractical. Later eras that could scroll but were relatively low resolution (320x240 was common in NTSC regions, for example) jitter was a serious problem, so decisions about things like camera movement took this into account.

Older CRT-based displays did give some “free” antialiasing, and did somewhat blend between frames due to phosphor persistence, so you could possibly emulate that to try to reduce the effect of the jitter a bit, but I think you’ll still see it.

But all of this is mitigation strategies. You are going to have jitter if you want pixel-perfect, it’s fundamental to that style.

yeah, i think that its impossible to fix then :frowning: