So in my game I am detecting the future position of a mob to shoot at it. I have all the maths worked out, but I have reached a problem. I need to find the theta and I am not sure which angle I should calculate... here's the math I have so far:

You see that commented line with -diffY?Depending on if you are calculating the angle from the bullet to the target, or the target to the bullet, you may get a negative number. You may also get a negative number depending on the target's position relative to the bullet, and vice versa. So, if the bullet goes the wrong way, try the -diffY one.

works perfect, the angle is correct but now the bullet is shot, moves towards where the mob will be and then arcs up to the mob... I think this has something to do with my adding to x and y maybe incorrectly

Was I before Chuang Tzu who dreamt about being a butterfly, or am I now a butterfly who dreams about being Chuang Tzu?

works perfect, the angle is correct but now the bullet is shot, moves towards where the mob will be and then arcs up to the mob... I think this has something to do with my adding to x and y maybe incorrectly

It's probably because you're calculating new velocities each step. So, as the bullet gets closer to the target, the distance changes, and since your velocity is based on the distance, it changes as well. You should set the velocity once, and only add it the position on every other update.

Ah yes, a good example of this is in the code for my game PixelZombies. You can check out an example here https://github.com/Sammidysam/Zombies/blob/master/src/weapons/Bullet.java but the code is really bad and I apologize. But the bullet takes the arguments x (mouse click x), y (mouse click y), manx (where the person firing the bullet is located x), and many (where the person firing the bullet is located y) and then calculates the angle. Then, when moving, the code

1 2

x += Math.cos(angle) * SPEED;y += Math.sin(angle) * SPEED;

is called. Is this what you are looking for? You can find the game here if you want to see it in action to make sure it works.

Ah yes, a good example of this is in the code for my game PixelZombies. You can check out an example here https://github.com/Sammidysam/Zombies/blob/master/src/weapons/Bullet.java but the code is really bad and I apologize. But the bullet takes the arguments x (mouse click x), y (mouse click y), manx (where the person firing the bullet is located x), and many (where the person firing the bullet is located y) and then calculates the angle. Then, when moving, the code

1 2

x += Math.cos(angle) * SPEED;y += Math.sin(angle) * SPEED;

is called. Is this what you are looking for? You can find the game in action here if you want to see it in action to make sure it works.

Yeah, this is what I was getting at. However, I usually do something like this:

Ah, does that increase speed by doing less trigonometric functions? If so, I'll be sure to do that when updating my code in the future (as I need to fix it as it currently sucks).

Yeah, no need to call sin() and cos() on every update. Just set it once and you'll save yourself many nanoseconds that will add up in the long run, especially if you have dozens of bullets on the screen at once..

Your variable names aren't clear, and your code needs to be organized. Create a fire() and update() function, instead of having it all in your update(). Your code is more complicated than it needs to be.

I started making a tower defence game a while ago and wrote some code for firing slow bullets at moving targets. My method of predicting the future position was originally similar yours but I found that this method is not exact and if the target is moving too fast or is too far away the bullet would miss. My solution at the time was slightly modifying the method to make it iterative, giving more accuracy for more iterations. This works ok but I thought there should be some exact solution and this the method I worked out:

This method seemed to work perfectly when I tested it. Also this solution doesn't use any sines, cosines, or arctangents so it could actually be faster as well as more accurate (you probably don't have to worry about speed too much but if you had lots of towers rapid firing it could matter).

I could post the derivation if anyone wants it but it would take a little while to type it all out... You can probably find find a derivation on the internet somewhere anyway.

EDIT: I made a slight mistake and left a factor of 2 out in the calculation of b.

EDIT2: Changed the calculation of t1 and t2 slightly due to Roquen's post below.

I missed this reply. OK, you have some direction (x,y) the end result of atan2, sin & cos just yields a normalized version of the same direction..sos = (float)(1.0/Math.sqrt(x*x+y*y); x *= s; y *= s;

quadratic: Maybe my brain's not working and I'm too lazy to check, but I think what you have can lead to catastrophic cancellation. The value of disc itself as well can be very inaccurate via just plain-jane cancellation (I want to think up to 50% of the bits can be junk).

quadratic: Maybe my brain's not working and I'm too lazy to check, but I think what you have can lead to catastrophic cancellation. The value of disc itself as well can be very inaccurate via just plain-jane cancellation (I want to think up to 50% of the bits can be junk).

I'm not really sure if cancellation would affect it much. If b^2 was similar to 4ac then sqrt(discriminant) would be small compared to b in the calculation of the time so the cancellation error shouldn't matter much there. I've been doing too much physics where if something is small you often ignore it to simplify the otherwise unsolvable maths. This can lead to inaccuracies like you said.

Possibly if the targets velocity was very similar to the bullets velocity then "a" would be small and could have significant error, in most practical applications though the bullet should be going significantly (at least, say, 1%) faster and the cancellation error wouldn't matter.

Anyway, due to the way the bullet's velocity is calculated at the end the bullet will still hit the target even if there was large error in t; It will simply move at a different speed to BULLET_SPEED. I checked this by adding 50 to the time before the bullet velocity is calculated. For the configuration of enemy and tower I was using to test it, the time came out to be about 65 so this is a huge relative error but the bullet still hit! (it went at about half the speed)

EDIT: I read this and you're right; I've edited it to do it that way but there can still be a loss of 50% of the significant figures. There doesn't seem to be any way around that except by implementing the b^2 - 4ac calculation in quadruple precision, but 50% is still the precision of a float so it's not too bad. Thanks for reminding me, I hadn't even thought of those errors.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org