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

Get help using Construct 2

Post » Fri Oct 16, 2015 5:19 pm

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?
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Fri Oct 16, 2015 5:27 pm

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?
B
43
S
19
G
65
Posts: 1,101
Reputation: 37,939

Post » Fri Oct 16, 2015 5:39 pm

@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.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Fri Oct 16, 2015 5:43 pm

Prominent wrote: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.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Fri Oct 16, 2015 8:18 pm

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.
B
42
S
11
G
1
Posts: 264
Reputation: 3,299

Post » Sat Oct 17, 2015 2:05 am

Make sure you test on Chrome,.... Firefox sucks for C2.
B
29
S
8
G
4
Posts: 767
Reputation: 5,985

Post » Sat Oct 17, 2015 3:56 am

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.
B
92
S
32
G
106
Posts: 5,272
Reputation: 69,455

Post » Mon Oct 19, 2015 6:35 am

@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.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Mon Oct 19, 2015 6:40 am

@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.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Mon Oct 19, 2015 6:56 am

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.
B
92
S
32
G
106
Posts: 5,272
Reputation: 69,455

Next

Return to How do I....?

Who is online

Users browsing this forum: nahima and 9 guests