0 Favourites

Object "hitching" in games with pixel rounding.

  • 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.

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • I noticed that that too, primarily with 8 direction movement.

  • 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)

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)
Similar Topics Posts Views Last Post
Unread sticky
763 305,698
asikanddestroy's avatar
asikanddestroy
Unread hot topic
232 177,682
Tetriser's avatar
Tetriser
Unread hot topic
266 15,903
GameeApp's avatar
GameeApp