#10852 - paajjrb - Thu Sep 18, 2003 11:15 am
Hello All,
What i need to do is fire bullets from my meanie and get them to travel towards the player, i have tried to adapt code that i has seen in other posts but for some reason it isnt working. The following is what im trying so far,
int DeltaX = player.image_x - enemy->image_x;
int DeltaY = player.image_y - enemy->image_y;
float Angle = atan(DeltaX / DeltaY);
int hyp = SPEED;
bullet->delta_x = cos(Angle) * hyp;
bullet->delta_y = sin(Angle) * hyp;
This sends the bullet flying off the screen, in the opposite direction. Can someone please help
#10856 - col - Thu Sep 18, 2003 3:14 pm
| paajjrb wrote: |
...
float Angle = atan(DeltaX / DeltaY);
...
This sends the bullet flying off the screen, in the opposite direction. Can someone please help |
note that -x / y is equal to x / -y
eg.
DeltaX of -3 and DeltaY of 3 (downLeft)
will give the same Angle as
DeltaX of 3 and DeltaY of -3 (upRight)
you have to figure out which of the two you have and correct the resulting angle accordingly.
not sure what you mean by flying off screen - is the bullet too fast?
cheers
Col
#10859 - Paul Shirley - Thu Sep 18, 2003 5:09 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 10:10 pm; edited 1 time in total
#10864 - col - Thu Sep 18, 2003 6:04 pm
| Paul Shirley wrote: |
The alternative is to compute the normalised 2D direction vector and scale it.
| Code: | int DeltaX = player.image_x - enemy->image_x;
int DeltaY = player.image_y - enemy->image_y;
float scale = SPEED/sqrt(DeltaX*DeltaX + DeltaY*DeltaY);
bullet->delta_x = DeltaX * scale;
bullet->delta_y = DeltaY * scale;
|
That's pretty easy to convert to fixed point (or even integer) code and the atan is so expensive this should work out faster even if you use table lookup for sin&cos.
The net has plenty of fast integer sqrt routines to help speed this up. |
the atan is expensive, but not more so than the sqrt.
I would say that the two approaches can both be optimised down to about the same speed !
There are a number of ways to quickly generate an atan estimation that is plenty good enough for most game code.
I imagine the same is true for sqrt, although i've not looked into that as i picked up a highly optimised ARM sqrt from somewhere a while back.
one thing that might be worth a look is to use an inverse sqrt routine.
so
| Code: |
float scale = SPEED/sqrt(DeltaX*DeltaX + DeltaY*DeltaY);
|
would become
| Code: |
fixed scale = SPEED * isqrt(DeltaX*DeltaX + DeltaY*DeltaY);
|
check out this link for possibilities
http://www.finesse.demon.co.uk/steven/invsqrt.html
go here
http://www.finesse.demon.co.uk/steven/sqrt.html
and look down the page, there is an ARM sqrt that takes only 51 cycles!(the one i found a while back :))
cheers
Col
#10874 - jenswa - Thu Sep 18, 2003 8:36 pm
You should probably check if the enemie is above or below you, could even be with left and right.
So you know to what position the bullets need to go, rather than on line you have now. You only know the line the bullet is moving, not if it should move left, right, up, down or any combination of those two.
Just like col mentionned.
_________________
It seems this wasn't lost after all.
#10878 - Geno - Thu Sep 18, 2003 11:35 pm
1st thing: make a lookup table for Cosines, and remember that the cosine of a number is equal to the sine of the same number plus 90. Example:
cos( angle ) == sin( angle + 90 )
will always be true. There are many more formulas that you can create lookup tables for.
Don't use floats if you can avoid it.
Last, unless they are hero-seeking missiles(therefore alter their path in mid-flight), you could just have a them go along a predetermined line by coming up with the slope intercept equation of a line. Simply calculate the x and y ratio of a line connecting the target to the origin. That way you can avoid costly atan and cos and sin.
_________________
Out of Order.
#10880 - col - Fri Sep 19, 2003 1:20 am
| Geno wrote: |
...
Last, unless they are hero-seeking missiles(therefore alter their path in mid-flight), you could just have a them go along a predetermined line by coming up with the slope intercept equation of a line. Simply calculate the x and y ratio of a line connecting the target to the origin. That way you can avoid costly atan and cos and sin. |
This would make the bullet speed change depending on the angle. I guess if angle dependent bullet speed is in the games design specification then cool ;)
cheers
Col
#10886 - FluBBa - Fri Sep 19, 2003 10:50 am
ops
_________________
I probably suck, my not is a programmer.
#10888 - paajjrb - Fri Sep 19, 2003 11:16 am
thanks alot for all your help, i now have bullets that are actually deadly :) however i now need to get a faster collision detection algo. if the player starts firing then the enemies bullets stop moving :) ohh the joys of game programming. Ohhh Col, or anyone else kind enough to help, i looked at the page you referred me to, but unfortunately while the code looked great, i dont know how to include it into my game. I looked at other posts about it but they were a little vague. Can someone help with a step by step on how to get ARM code into a game. Thank you again to all for helping me.
#10894 - tepples - Fri Sep 19, 2003 3:29 pm
Collision detection is a search problem, and search problems can often be sped up by using sorted data. Please read my other post on this topic.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#10917 - paajjrb - Sat Sep 20, 2003 9:45 am
ok its offcial. ive gone nuts! after staying up to 4am trying to get my collision detection running faster, i woke up this morning to find that it wasnt my collision detection at all. i had just assumed it was, when the real problem was a variable that i forgot to reset to 0!!!! The game, (very basic raiden style) is now running perfectly! Thank you all!
#10930 - Geno - Sat Sep 20, 2003 8:49 pm
:D
Don't you love that? XD
_________________
Out of Order.
#10946 - tepples - Sat Sep 20, 2003 11:01 pm
When Tetanus On Drugs suddenly started skipping frames on hardware, I turned on the "vcount profiler" and spent a couple days optimizing the gameplay code and poring over the already heavily optimized graphics code only to discover that it wasn't the gameplay code or the graphics code at all; it was an upgrade to DevKit Advance R5b2, which refused to put code in IWRAM; the sound mixer took more than a frame as a result. This was one of the reasons for the long delay from TOD M2 to M3; I had to wait for R5b3 to be released so that .iwram.o would work properly again.
I did come out with one good result from the whole thing: much more efficient code for some of the more expensive board evaluations such as searching for macroblocks. I'll bet you learned something about efficient searching for collisions from this exercise as well.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.