# Object "hitching" in games with pixel rounding.

Discussion and feedback on Construct 2

### » Fri May 22, 2015 5:34 pm

When pixel rounding is on, the objects are drawn at the nearest pixel positions. ie -> 0.4 is drawn at 0 and 0.5 is drawn at 1.

Consider the following : Y = -0.5x

An object slowly moving to the right will also move upwards at half the rate it is moving to the right. However, because of the pixel rounding, the object appears to...

move right,
wait,
move right,
move up,
move right,
wait
move right,
move up,
etc...

This cause a noticeable hitching, as the object does not move up at the same time as right.

If, rather than rounding the objects position, floor can be used to eradicate this hitch. The movement appears as follows

Move right,
wait,
move right and up in the same tick
wait,

This is much more visually appealing, and is preferable to the visual syncopation resulting from rounding positions.

You can can get around this by subtracting 0.5 from the positions of all drawn objects at the end of all events and then adding it back to them at the beginning. However, of course this doesn't work with other behaviors that move objects.

The solution is to be able to specify whether you want an object rounded to the nearest pixel, or to be rounded down when using pixel rounding. This should not be hard to add.

There is also a historical precedence for this option, studying mario 3 and super mario world shows that an object never moves along one axis independent of the other unless that axis is is being changed at a greater rate than the other. If velocity x = 10 and velocity y = 5, visually y will never move without also moving x.

This effect is even more pronounced when a camera is also involved moving at dynamic rates set via x=target.x * 0.5 etc. Equations such as these result in visual transitions that create an jittering effect despite the fact that the game is running smoothly.

Anyway, any one up for discussing this? I think it is a needed feature.
B
34
S
12
G
2
Posts: 566
Reputation: 5,282

### » Sat May 23, 2015 1:26 am

I noticed that that too, primarily with 8 direction movement.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
93
S
30
G
22
Posts: 1,987
Reputation: 20,203

### » Sat May 23, 2015 6:46 pm

Another solution to this problem can be to only add velocity to position whole integers. For example:

vector2 velocity;
vector2 preIntegrated;
vector2 position;

every tick
--- preIntegrated+=velocity
---
--- If ( abs( velocity.x ) > abs( velocity.y ) ) {
--- --- if ( preIntegrated.x >= 1 ) {
--- --- --- position.x += floor( preIntegrated.x );
--- --- --- preIntegrated.x -= floor( preIntegrated.x );
--- --- --- // Integrate Y

etc

There are some bugs here but the idea is simple (negative compared to positive would have to be handled)
B
34
S
12
G
2
Posts: 566
Reputation: 5,282