Retro Style Platformer Issues (Jitters And Shaking BG Sprite

Ashley:

What I though I did, and what appears to happen when I run it, was to modify the final render texture to use point sampling instead of linear sampling. That way, when low-quality scaling is turned on and layout scale is 1.0, no linear sampling is applied to any of the displayed graphics as long as they're drawn at integer values. It's meant as a way to allow switching between linear and point sampling during runtime. And it works well for what I intended it to do.

The reason I posted it here was because it also allows for sub-pixel smoothing when graphics are drawn at non-integers, something I thought could help in the OP's situation; draw at float positions when moving, draw at integers when not. Smooth, but blurred graphics when scrolling/moving.

Not sure what you mean by referring to property names that don't exist. Which ones?

I think what people want is for the positions of sprites on screen to be moved consistently along pixels without it jittering back and forth, like in Mario, Megaman, and any other pixel-based game. There must be an option to achieve this basic functionality used by all pixel games we are overlooking

I think what people want is for the positions of sprites on screen to be moved consistently along pixels without it jittering back and forth, like in Mario, Megaman, and any other pixel-based game. There must be an option to achieve this basic functionality used by all pixel games we are overlooking

I think deactivating pixel rounding does that. Unless I am wrong, could you shiw an exemple if that is the case where this appears?

All personal opinion, take with a grain of salt:

I think the need to use delta-time just isn't very well suited for pixel art games unfortunately. Constantly fluctuating framerates and delta-time to compensate is a bad fit for smooth movement on limited pixel grids. The reason you don't see herky-jerky sprite and background movements in 2D console and arcade games is probably due in part to approximately zero of them using delta-time. They don't need to: The hardware they're running on stays the same and has a fixed, non-fluctuating framerate. In cases where too much stuff is going on for the cpu and/or gpu to handle, the entire thing just slows down.

The other thing that makes them run so smooth, and I'm just guessing here, is because they make sure to move all graphics by increments that line up nicely with the screen update rate. So they might move things by 1.0, 0.5, 1.5 etc pixel increments but *never* something like 0.15, 1.7, or 0.4.

Imagine an object moving at an even 0.4 pixels per update. If it gets drawn at integers only It'll take 3 updates before it'll appear to have moved 1 pixel, while it's actually moved 1.2 pixels. Another 3 updates it'll appear to have moved 2 pixels while actual moved distance is 2.4. But for the 3rd pixel distance travelled the game will only need 2 more updates to get to 3.2. So the visible movement update rate will be 3-3-2, 3-3-2, instead of 3-3-3 which is required for it to look completely smooth. Of course this gets even worse when you factor in fluctuating fps and delta-time.

[quote:2lihpbgl]I think what people want is for the positions of sprites on screen to be moved consistently along pixels without it jittering back and forth, like in Mario, Megaman, and any other pixel-based game.

Every tick: Set Player_Sprite.X/Y to round(Player_Sprite.X/Y)

Set Camera.X/Y to round(Player_Sprite.X/Y)

This works for me.

— - I round my camera to what ever it is following, but If I change objects, I make sure I change them back before altering there positions. This is where I wish the engine had an option for it because updating all dynamic objects at the end of all your events before a render and then undoing those changes is a huge performance drain. If you don't undo the change then you are literally moving those objects which can cause problems.

If you have a "real"velocity expressed as a float and then calculate a "facade" velocity that works nicely with everyone that is calculated every tick based on dt... The biggest thing Iv'e noticed is that you need to have the larger component of velocity (x/y) be evenly divisible by the other. I don't think moving 1,1,2,1,2,1,1,2,1,2... and so on is as bad as visually rounding just x this tick and then just y the next tick... (x,y,x/y,x,y,x,x/y)... as this gives a literal stair step movement look instead of a diagonal look... anyway...

I'm a bit surprised that Ashley doesn't understand this. He certainty is smart enough, maybe he isn't thinking about it from an asthetic standpoint and only programming?. He understands that it does what it does, and why it does it, but doesn't see the problem with that solution... after all, that IS what you are asking for with pixel rounding. I understand where he is coming from, I think . But if he would compare, as you mentioned, the arcades, and early consoles to C2, he would notice that x/y never NEVER stair step. You can run an emulator at 0.1 speed and see Mario update x/y without the smaller component ever being syncopated. You can achieve this on a modern system with variable frame rate... you just have to emulate it mathematically. The place for that is inside the engine and not the event editor.

—

https://dl.dropboxusercontent.com/u/11449416/TestsJitterDemonstration.capx

The red pixels are bad... they jitter, they use defualt pixel rounding... the green pixel is cool... he knows he shouldn't be jittering around so he doesn't... stupid red pixels