Often I will want to use a speed value such as 2.5 for moving my character in a pixel-based game. Collision detection will generally be more difficult if I do that, though. So I end up doing something like this:
moveX(2);
if (ticks % 2 == 0) { // or if (moveTime % 2 == 0)
moveX(1);
}
I cringe on the inside every time I have to write that, is there a cleaner way to move a character with non-integer speed values or will I remain stuck doing this forever?
In the old times, when people were still writing their own basic video routines for drawing lines and circles, it was not unheard of to use the Bresenham line algorithm for that.
Bresenham solves this problem: you want to draw a line on the screen which moves dx pixels in the horizontal direction while at the same time spanning dy pixels in the vertical direction. There is an inherent "floaty" character to lines; even if you have integer pixels, you end up with rational inclinations.
The algorithm has to be fast though, which means that it can use integer arithmetic only; and it also gets away without any multiplication or division, only addition and subtraction.
You can adapt that for your case:
"x/y" here are not the location on the screen, but the value of one of your dimensions in time. Obviously, if your sprite is running in an arbitrary direction across the screen, you will have multiple Bresenhams running separately, 2 for 2D, 3 for 3D.
Let's say you want to move your character in a simple movement from 0 to 25 along one of your axes. As it is moving with speed 2.5, it will arive there at frame 10.
This is the same as "drawing a line" from (0,0) to (10,25). Grab Bresenham's line algoritm and let it run. If you do it right (and when you study it, it will very quickly become clear how you do it right), then it will generate 11 "points" for you (0,0), (1,2), (2,5), (3,7), (4,10) ... (10,25).
If you google that algorithm and find some code (Wikipedia has a pretty large treaty on it), there are some things you need to watch out for:
dx and dy. You are interested in one specific case though (i.e., you will never have dx=0).dx and dy are positive, negative, and also whether abs(dx)>abs(dy) or not. You of course also pick what you need here. You have to make especially sure that the direction which is increased by 1 every tick is always your "clock" direction.If you apply these simplifications, the result will be very simple indeed, and get completely rid of any reals.
There is a simple way to do exactly what you want.
In addition to a float velocity you'll need to have a second float variable which will contain and accumulate a difference between real velocity and rounded velocity. This difference is then combined with velocity itself.
#include <iostream>
#include <cmath>
int main()
{
int pos = 10;
float vel = 0.3, vel_lag = 0;
for (int i = 0; i < 20; i++)
{
float real_vel = vel + vel_lag;
int int_vel = std::lround(real_vel);
vel_lag = real_vel - int_vel;
std::cout << pos << ' ';
pos += int_vel;
}
}
Output:
10 10 11 11 11 12 12 12 12 13 13 13 14 14 14 15 15 15 15 16
Alternatives include:
Using floating-point coordinates under the hood, and rounding them.
This can cause precision problems if the coordinates have large absolute values.
Using fixed-point coordinates.
This is probably superior to the solution suggested above, but you either need to find a fixed-point math library, or code fixed-point math manually, which requires more effort.
Use floating values for movement and integer values for collision and rendering.
Here's an example:
class Character {
float position;
public:
void move(float delta) {
this->position += delta;
}
int getPosition() const {
return lround(this->position);
}
};
When you move you use move() which accumulates the fractional positions. But collision and rendering can deal with integral positions by using the getPosition() function.
