Are Integer Positions Actually Useful?

[zicklag]

Hey @PsichiX I wanted to bring up the topic of integer coordinates again, if you don't mind discussing!

Bevy Retro uses integer coordinates for sprites, currently. I thought that that would be helpful just to simplify things because you should never be able to mis-align pixels by setting a fractional position.

Now that I think about it though, I'm realizing that there are difficulties when doing simple things like moving a character on the screen when they need to move at a speed slower than 1 px per tick ( I'm using a fixed timestep so the logic is in "ticks" and I don't have to take the delta-time into account for movement logic ).

If I want a character to move at less than 1 px per tick, I have to write logic that keeps track of which frame I'm on and only moves the player once every so many ticks. This makes it more difficult to do things like smoothly animating anything. If I wanted to make even a simple position and velocity system, I would have to add extra data to suplement the integer positions so that I could actually calculate the movement correctly.

I'm getting the feeling now that I should just use floating point coordinates so that I can move the player less than one pixel in any direction and the renderer will just round the coordinates to avoid pixels not lining up correctly. This instantly makes all of the math just work like normal.

---

On a side note, I was also thinking of adding rotations and scale to the engine, and it would make the most sense to use floating points for those, too, I think, so maybe I'm not actually gaining anything by using integers here.

[zicklag]

A quick conversion of the hello world example to floating points shows that it makes it way easier just to change the speed of a sprite and move it at any speed you want, but then the diagonal movement can be very jagged as it rounds the coordinates. :/

In our game Bounty Bros. I handled this manually by saying "if the player is moving diagonally make sure that you always increment the x position and y position at the same time so that it doesn't 'wiggle'".

🤔

I'm going to have to think about whether or not that makes this more difficult to solve, or if there is a way to get around the jagged movement issue.

[zicklag]

I did find out that you can get around the jagged movement with floats in a similar way that you can with integers. The code sample below shows how.

The takeaway is that floats haven't yet made it harder to do anything.

fn move_player(
    mut last_direction: Local<Vec3>,
    keyboard_input: Res<Input<KeyCode>>,
    mut query: Query<&mut Position, With<Player>>,
) {
    for mut pos in query.iter_mut() {
        const SPEED: f32 = 0.2;

        let mut direction = Vec3::new(0., 0., 0.);

        if keyboard_input.pressed(KeyCode::Left) {
            direction += Vec3::new(-SPEED, 0., 0.);
        }

        if keyboard_input.pressed(KeyCode::Right) {
            direction += Vec3::new(SPEED, 0., 0.);
        }

        if keyboard_input.pressed(KeyCode::Up) {
            direction += Vec3::new(0., -SPEED, 0.);
        }

        if keyboard_input.pressed(KeyCode::Down) {
            direction += Vec3::new(0., SPEED, 0.);
        }

        if direction != Vec3::new(0., 0., 0.) {
            if last_direction.partial_cmp(&direction) != Some(Ordering::Equal) {
                **pos = pos.round();
            }

            **pos += direction;
        }

        *last_direction = direction;
    }
}

[zicklag]

After discussing with my team, it seems that we will most likely actually want to support both aligned and un-aligned pixels in Bevy Retro, so that the player and enemies can move smoothly and accurately while the background and non-moving items stay aligned. This will involve some rendering changes and means that floats will be used, at least, for character movements.

That means that our decision comes down to whether or not we use floats for all sprite positions, or if we use floats for unaligned sprites and we use integers for aligned sprites. I think we should probably use floats for all of them.

@PsichiX I think this pretty much answers the question, so maybe I don't need much input, but feel free to chime in if you have any thoughts. :D

[zicklag]

We moved to using Bevy's own Transform system, and it's working great. It was also essential for integration with Rapier physics so I think it was the right move.