Hmm, have you ever created a line drawing routine? Basically, take a point (x1,y1) and (x2,y2), and pretend you are drawing a line between them, but instead of drawing the pixels, use it as a path to draw your bullets. I am sure that finding the velocities would be a lot easier, though. Hopefully somebody comes along that knows more than I do!

I'm trying to put together a routine that will calculate the appropriate X/Y velocity to go towards an object. What i've got now is really buggy, i think the general algorithm/idea is ok though. My biggest hurdle so far has been handling negative numbers, as none of my routines for multiplication/division seem to like negative numbers. What i'm currently doing is really just adjusting the Y velocity and not bothering with the X velocity. The general equation is something like this:
(object Y - bullet Y)/(object X - bullet X)

The X/Y velocities have 5 bits which act as a decimal place, but this doesn't let me use it. I hacked in the ability to handle negative numbers in the division routine (essentially turning all negative numbers positive, then negating the result afterward), but my multiplication routine doesn't like negatives numbers either.

Ok, so basically, I'm assuming this is what you want to happen:

Angle = atan2(x, y)
xVel = cos(angle)
yVel = sin(angle)

Now, yes, this will work, but it's not going to be very fast. Atan2 is just arcTangent that will give you the angle even if it's in the [90,270] region, but that thing is a little annoying to implement. Cos and Sin aren't that hard, but require lookup tables.


Before I explain this, to make things easier, dX = object X - bullet X and dY = object Y - bullet Y.

What I recommend you do is treat this as a vector problem (sorry, I'm currently in calc 3). Basically, you have your direction vector <dX, dY>. So there is no need to recalculate the direction. All you need to do is scale it to the right speed.

So, the way to do this is to first find the length of the direction vector : length = sqrt(dX^2 + dY^2). And then to scale it to the right speed, divide by the length and multiply by the new speed: <dX, dY>/length*speed.

In the end, here's what you get:
length = sqrt(dX^2 + dY^2)
xVel = (objectX - bulletX)/length*speed
yVel = (objectY - bulletY)/length*speed


The only tricky part of this routine is the square root, but I know I've seen a few around here, so that shouldn't be too difficult.

Or the quick and dirty way:
if x < objectX {x++}
if x > objectX {x--}
if y < objectX {y++}
if y > objectX {y--}

It is not pretty, but Δy/Δx will be the same and it will move somewhat diagonally.

Aside from looking awful, I don't think that would work for this purpose because typically bullets don't change direction after being fired

Quote from: Keoni29 on October 23, 2012, 01:46:58 pm

Or the quick and dirty way:
if x < objectX {x++}
if x > objectX {x--}
if y < objectX {y++}
if y > objectX {y--}

It is not pretty, but Δy/Δx will be the same and it will move somewhat diagonally.

Aside from looking awful, I don't think that would work for this purpose because typically bullets don't change direction after being fired

True

You divide by length because you want the speed to be the same no matter what the distance is.

Speed is simply how fast you want your bullets to move. 8 would be 8 pixels per frame, 1 would be 1 pixel per frame, and 96 would be 96 pixels per frame. (Assuming the units on xVel are pixels/frame of course)

You can set it to whatever you want.

Thanks, i figured that out later. I was confusing dX/Y with velX/Y.