I'm working on a mobile game and I'd like to avoid using floating point math. I'm having trouble coming up with an algorithm for moving a point a specific distance toward another point. I have no issues doing this with floating point using trig functions or vector math.
Does anyone recall how this was done in those long-gone days before we had FPUs to lean on?
Thanks!
I'm working on a mobile game and I'd like to avoid using floating point math. I'm having trouble coming up with an algorithm for moving a point a specific distance toward another point. I have no issues doing this with floating point using trig functions or vector math.
Does anyone recall how this was done in those long-gone days before we had FPUs to lean on?
Thanks!
Before there were FPUs there was software that performed floating point operations.
Hardware FPUs are pretty efficient these days. They are pipelined and should perform close to fixed point math. The only downside, that maybe you're alluding to, is that these circuits generally consume a good chunk of power.
For your case, the easiest thing that comes to mind is to divide the distance into integer chunks between the two points. For example, if the distance is 100 you could scale it to 100, or 1000, or 10000 depending on your desired resolution. Then have, for example, 10,000 steps to indicate where along the path your object is. But this sounds like it's way too complicated.
For reference, how the Commodore 64 did it with software routines:
Fixed point maths. Pick a power of 2 to represent the number 1, e.g. 216 = 65536.
Every time you multiply two fixed point numbers you need to divide by the number representing 1 (so 65536 in this example), which is just a shift (>>16 in this case). Every time you divide two fixed point numbers you multiply (shift up) instead of divide. Watch out for overflows!
So 0.5 * 0.5 would be (32768 * 32768) >> 16 = 16384 which represents 1/4
PS1 used 4096 to represent 1 which didn't overflow as much. You can use 256 instead but lose fractional bits then.
You have to generate sin, cos, etc. tables for the fixed point system as well.
Simplest version:
// Helper function for calculating sqrt of ints
uint32_t sqrti(uint32_t input)
{
uint32_t op = input;
uint32_t res = 0;
uint32_t one = 1uL << 30;
while (one > op)
{
one >>= 2;
}
while (one != 0)
{
if (op >= res + one)
{
op = op - (res + one);
res = res + 2 * one;
}
res >>= 1;
one >>= 2;
}
return res;
}
struct Vertex2i
{
int x, y;
};
Vertex2i start = {0, 0}; // Starting point
Vertex2i goal = {100, 100}; // Goal point
int distance = 100; // Move distance
Vertex2i d = goal - start; // Compute the direction (d is direction)
Vertex2i end = (distance * d) / sqrti(d.x * d.x + d.y * d.y);
// end is your end point, moved about 100 units toward goal from start
I'm working on a mobile game and I'd like to avoid using floating point math.
Seconding the fixed point post above. I've worked with fixed point on nine major mobile titles for devices that lacked a proper FPU, running 3D games on devices as slow as 33MHz processors.
Knowing the mobile device and language can be helpful.
Recall that as far as the world of computing goes (not just PCs, but microcontrollers for every device on the planet), the number of devices with floating point processing ability is very small.
There are many good fixed-point libraries out there. Many are open source, and many have been optimized for various hardware.
Thanks guys. I was hoping there was something simple I was overlooking. I guess not!
It really isn't THAT hard, you just have a class that holds non-integer numbers. With operator overloading the class works exactly as you would expect floating point math to work.
There are more complex simple integer methods if all you want is simple motion toward a point and want it all done with integer math. Look at DDA algorithms, such as the fairly popular Bresenham's line algorithm that do not require sub-integer math.
That will help in making a single line, but not so much in making a complete game.
