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?