How do I... avoid jitters in a retro project

Okay,

Given collision resolution in construct is accurate to 1 pixel (+/- o.05 ish) for a total margin of error of around a 10th of a pixel, it is possible with settings on retro to experience jitters. This of course occurs when an object is pushed out of a collision but a different amount each frame. If the average jitter caused by collision resolution falls within the boundary for rounding objects draw position to one pixel or another then you get actual visible jittering. Does this all make sense?

Given that that the collision resolution error margin is 10% of a pixel you end up getting visable jitters for around 10 percent of any objects life time while being constantly resolved.

Now, in the past, I have gotten around this by implementing my own collision detection and resolution, and the response was always the same. So even if there was a small error due to binary being converted to decimal or the reverse, it was the same every time. This meant no jitters. But when I use constructs collision detection and resolution, I get jitters.

These jitters basically mean you really can't have a polished 2d retro project. You can always not use retro settings, and simulate them by creating 4x sprites with nearest neighbor interpolation, but this is a fair bit of work and means that performance is likely to be lower. In other words, I know of this work around, but would rather not use it. Does anyone else know how to work around this?

I should also point out that box2d's collision detection and resolution resolves to a stasis point and then maintains that point, so you don't get any visible jittering for the most part. I only tend to notice it when I am using construct 2's custom collision resolution tools (custom movement). I would tend to think of this as a bug but figured I would post here first. I can't think of a good reason why given the same distance of intersection each frame why the resolution would vary by a whole 10th of a pixel?

Do you have any visual examples, such as a capx showing the problem? because I'm not sure I understand. I mean, I think I do, but I haven't noticed it before. An example would help get your point across.

I'm also wondering if perhaps there might be camera movement influencing any pixel rounding?

Prominent - I'll get an example capx up. As for camera movement, that can surely cause seeming jitters, especially if a camera is moving slowly. In any retro project, I always avoid any camera smoothing as this causes problems. I still have camera movement that may be independent of the player object but its decimal point is tied to the players so that it rounds in favor of the players drawing position if that makes sense. It depends on the games needs of course.

Do you have any visual examples, such as a capx showing the problem? because I'm not sure I understand. I mean, I think I do, but I haven't noticed it before. An example would help get your point across.

I'm also wondering if perhaps there might be camera movement influencing any pixel rounding?

My last post kind of skirted the issue, I just realized. For the most part you need either a camera that is near the drawing pixel boundary ( x.5, or y.5) or an object. If the object is being resolved every frame due to gravity or something pushing it down then you get the problems I was talking about.

I have this issue too. I used this tutorial to make a smooth scrolling camera.

As the camera "settles" on the player when you stop moving, it will jitter 1px to the right, then 1px to the left, then stop on the character. My "resolution" is set to 256x144 and my tiles are all 16x16, so single pixels are noticeable. It's most notable when there is a foreground scrolling parallax layer. I probably gotta tweak the lerp settings, but I thought I'd mention this regardless.

Make sure you test on Chrome,.... Firefox sucks for C2.

What does Firefox have to do with it?

I can see why it would jitter. The distance the Sprite moves each frame will vary with dt, and since the "push out" action works something like the following I could see why some frames the Sprite would move and some it wouldn't.

While

Sprite overlaps solid

--- move backward 1 pixel

There are two reasons why box2d doesn't jitter. The first is it uses a fixed timestep, and secondly it calculates how far to push out.

You probably could do either and eliminate the jitter.

R0J0hound - I actually never use a fixed timestep... including with box2d. Also, when I spoke of resolving a collision using the custom behavior, I meant that I use push out of solid as an action in custom behavior. That behavior is only accurate to within a 10th of a pixel. If the camera is at position x.5 and y.5 then the object in question can appear to jitter.

I have gotten around it by forcing the camera to round to the nearest whole integer when coming to a rest, which skirts the problem nicely. I have been thinking though, I think the renderer could use an upgrade. The fact is, if you move a camera slowly through a scene with a number of objects at arbitrary locations you can really see jitters. An object at x.5 will move before an object at x.0 if you are scrolling sideways. If objects render positions are calculated before being rendered, you can force those shenanigans away. I once made a script that saved an objects position, rounded it to the nearest whole number before rendering, and then at the start of a new frame restored the position (not logically programmed the way I described it, but it essentially provided that). If you round scroll position to the nearest integer, it effectively does the same thing, depending on the circumstances. Its weird too but it also ties into jagged increments in moving on the x and y axis too. The system I made was to make sure a characters position over time didn't draw an ugly line if you know what I mean. Like in pixel art? Does that make sense? I even made a nes like system where I stored only whole numbers in c2's position and then stored the remainder decimals in a custom script. In mario 3 on the nes, for example, everything was calculated in a 4 units per pixel. So an object moving at 1 pixel per frame was said to be moving at 4 units per frame. Of course, unless you can guarantee a specific frame rate, its all only nice theory.

bclikesyou - yeah, the general lerp camera is pretty bad at causeing jitters. The bigger your pixels, the more you notice it. I tossed out the lerp camera pretty early on. It takes alot more work but, you can program a camera that accelerates and decelerates to keep an object within an arbitrary bound region. I clamp my values to essentially force certain constraints that minimize slow movement, and other potential jitter producers.

I think it's just one of those things that have to be dealt with when dealing with rounding floating point positions to integer.

As far as rounding the camera position, couldn't you use two variables to store the floating point camera position and always round them when setting the scroll position?

I've done something similar to what you described before, but it was mainly for collision precision purposes instead of rendering.

Ruskul Thanks for the heads up!

What does Firefox have to do with it?

My firefox spits and sputters with HTML 5 games. Whenever I am thinking I am having a performance problem, I look up and see that i am testing on Firefox. When i switch to Chrome the performance is the way i would expect it to be.

Not sure if it is Firefox itself or some kind of plugin is installed, but I can not get Firefox to play C2 games without massive lags, hitches , and random unknown Hard disk usage.

I use Firefox as my default browser so i am not obligated to share my privacy with Google. i also don't like the "OK google" Microphone spy that seems to randomly enable itself. I only use Chrome for testing my games.

I can use Unity, Flash, and other game engines with Firefox without too may problems, just not C2 games for some reason. The performance just goes in the toilet after 1 or 2 minutes.

The only Plugins I use Is Adblock PLus, and Adblock Element hiding, Disabling them does nothing to help.

R0J0hound - That is it in a nutshell. Though I never saved the floating point for x and y because it didn't seem necessary at the time based on how my camera works (its movement comes form being clamped, to flexible boundaries) I like the smoothness of the camera moving in sub pixels, I just don't like it to stop and sit at a sub pixel. So I only round it when the camera is not in motion.

> What does Firefox have to do with it?

>

My firefox spits and sputters with HTML 5 games. Whenever I am thinking I am having a performance problem, I look up and see that i am testing on Firefox. When i switch to Chrome the performance is the way i would expect it to be....

That is weird, I never have any problems with firefox at all. I normally test chrome because I export to desktop via chrome so , you know..

jojoe

I always test everything with FF - I don't actually have chrome installed - and never have any big janks or issues with it.