Well, I DID accomplish aimed bullets in BK1, but the method was a little sloppy in order to avoid potential heavy computation.

Here's what I did and these were spread across two states to avoid a HUGE amount of computation:

-Take the center points of player and bullet, call them X1,Y1 and X2,Y2

-X2-X1 and Y2-Y1 (do 2's complement if neg and save a flag)

-Determine which is bigger

-Take the X difference as the high byte, 0 as the low byte and divide the Y difference. A decimal value is then stored.

-Whichever was bigger from before moves at a speed of 1. The smaller moves at the decimal point speed.

-If the flag was set for either of these, do the 2's complement on either one.

-In the next state, I'd do multiplication for faster speeds on the values. Generally just with shifting.

So anyway, this WORKED and the shots were indeed aimed, but the downside is that the closer a bullet got to a 45 degree angle, the faster it went. At exactly 45, it'd be moving the square root of 2 times faster than the intended speed. Not horrible, but still not as nice as I would like.

An approach of possibly using look up tables has been proposed, although that sounds like one gigantic table.

The other approach is doing the computation of: sqrt((X2-X1)^2 + (Y2-Y1)^2)

Y speed = Y / distance * speed

X speed = X / distance * speed

Square root alone is a huge operation, not to mention that I'd probably need the possibility of 4 bytes if the differences are huge.

I guess I'm at a point of wondering what would be best... The old imperfect method or something different.

Here's what I did and these were spread across two states to avoid a HUGE amount of computation:

-Take the center points of player and bullet, call them X1,Y1 and X2,Y2

-X2-X1 and Y2-Y1 (do 2's complement if neg and save a flag)

-Determine which is bigger

-Take the X difference as the high byte, 0 as the low byte and divide the Y difference. A decimal value is then stored.

-Whichever was bigger from before moves at a speed of 1. The smaller moves at the decimal point speed.

-If the flag was set for either of these, do the 2's complement on either one.

-In the next state, I'd do multiplication for faster speeds on the values. Generally just with shifting.

So anyway, this WORKED and the shots were indeed aimed, but the downside is that the closer a bullet got to a 45 degree angle, the faster it went. At exactly 45, it'd be moving the square root of 2 times faster than the intended speed. Not horrible, but still not as nice as I would like.

An approach of possibly using look up tables has been proposed, although that sounds like one gigantic table.

The other approach is doing the computation of: sqrt((X2-X1)^2 + (Y2-Y1)^2)

Y speed = Y / distance * speed

X speed = X / distance * speed

Square root alone is a huge operation, not to mention that I'd probably need the possibility of 4 bytes if the differences are huge.

I guess I'm at a point of wondering what would be best... The old imperfect method or something different.