Elysian Shadows

Hey guys,

I'm new here.. also somewhat new to programming in general.i would like create a 2d top down shooter.. but im completely stuck on how to do the math for the bullet path from gun to mouse cursor.

im programming in blitz plus.. which is basic ..

here is a link to my photobucket which has the 1 page of code im working with. thanks for your help in advance if you get this. it would mean allot!

http://s1189.photobucket.com/albums/z430/Ryan_Geidl/

Does this help?
http://www.youtube.com/watch?v=FmWDD9AX ... ideo_title

Dude there is this great thing called pastebin.

Wouldn't trigonometry be used to figure out what the angle is to the mouse cursor or something like that? S:

jakobnator wrote:Dude there is this great thing called pastebin.

How is this related?

LeonBlade wrote:

jakobnator wrote:Dude there is this great thing called pastebin.

How is this related?

cos he posted a jpg of his code

I'm not familiar with Blitz, but most languages have this function automated, in C++ it's ATAN, arc tangent - maybe do a search for it as it would save some trig headaches.

ATAN takes the difference on each axis and works out the angle of that vector... in psuedo code, say you have 2 sets of coordinates in A and B.

D.x = A.x - B.x
D.y = A.y - B.y
Angle = ATAN(D.x,D.y)

Then with that angle, you can adjust trajectory, set the velocity of a bullet or particle, work out visibility cones, work out rotation for zombie AI, all sorts of stuff. First thing to figure out is if it returns the angle in radians or degrees. Once you have the angle, work out the bullets X and Y velocity, and update the bullets each loop based on that velocity. I would just add xs and ys to the type, struct, or whatever Blitz thinks a data structure should be called.

LeonBlade wrote:

jakobnator wrote:Dude there is this great thing called pastebin.

How is this related?

Oh, I only saw the first picture, my bad.

It seems that you have two points (Player and Mouse), and you want a vector from Player pointing towards Mouse and having some specific magnitude(the speed of the bullet).

As i see it there is no need for trigonomitry. The following steps should do:
1. make a vector from Player to Bullet
2. normalize the vector
3. scale the vector by the desired speed of the bullet.

A vector going all the way from Player to Mouse can be made by subtracting Player.x from Mouse. x and Player.y from Mouse.y and using the two values for the x and y of the vector. But stopping here will result in the speed of the bullet changing depending on how far Mouse is form Player. So we normalize the vector:
magnitude = sqrt(x^2+y^2)
x = x/magnitude
y = y/magnitude
Now the speed of the bullet will be 1 per time the position is updated. to change this, simply multiply the x and y with the desired speed:
x = x*5
y = y*5

If you don't want to deal with it, simply forget everything about vectors, and just treat the x and y values as to completely normal numbers. That will work just fine.

This vector(or the two numbers) should be stored with the bullet, and not be confused with the x and y position you already have stored with the bullet(call them something like xVelocity, yVelocity). in the loop updating the bullet, you simply add xVelocity to x and yVelocity to y. All the math should be done at the creation of the bullet(Though you can instead of the xVelocity and yVelocity store the position of the mouse at the time the bullet was fired and calculate everything every frame. This will be slower, but you can then change the point the bullets are heading for after they are fired and make heat seeking missiles ).

ismetteren wrote:As i see it there is no need for trigonomitry.

There generally isn't in game development. I like to think of linear algebra as a mathematical abstraction for trigonometry. Working with vectors is the same thing as working with the unit circle and triangles (where the edges are each component of the vector and its magnitude).

Personally, I suck ass at thinking trigonometrically. Everything is vectors and matrices in my head. But then you have the people who can pull sines, cosines, and arctangents out of their asses to solve anything... Just be able to tell when two approaches are equivalent. :D

There is a need for trig when you plan on rotating something!

I imagined this problem as a little tank, with a turret that rotates to point towards the mouse cursor. With ATAN, you would have that exact angle, rotate the turret to suit, and use SIN and COS to work out the velocity of the bullet. I find it easier to work with angles for most things. I mean, vectors and trig both have their uses and often that overlaps, but rotation is so much easier with trig than with vectors, easier and probably faster to compute as well. SQRT has never been a fast calculation.

Van-B wrote:There is a need for trig when you plan on rotating something!

I imagined this problem as a little tank, with a turret that rotates to point towards the mouse cursor. With ATAN, you would have that exact angle, rotate the turret to suit, and use SIN and COS to work out the velocity of the bullet. I find it easier to work with angles for most things. I mean, vectors and trig both have their uses and often that overlaps, but rotation is so much easier with trig than with vectors, easier and probably faster to compute as well. SQRT has never been a fast calculation.

I see your point, since he is probably going to need the angle anyways at some point. Btw, i didn't knew about the atan2 (i'm quite sure it is that function you are referring to, since atan only takes one argument, and does not work excatly like it is supposed to for this use) so i learned something new too. It seems quite useful http://en.wikipedia.org/wiki/Atan2

Ahh, I think that ATAN relies on the X and Y component to be divided somehow, and it doesn't allow for automatic quadrant checks. Atan2 rings a bell now, in the language I use it's called ATANFULL, but it works the same way as with C++. It is a damn fine command, I remember trying to work this stuff out on the 16-bit computers, having to worry about quadrants and all that. We really are spoiled these days :D.

Van-B wrote:There is a need for trig when you plan on rotating something!

Even that's arguable. Use a rotation matrix. It's the same thing behind the scenes, but what was once a trig operation is a linear algebra multiply.

Van-B wrote:but rotation is so much easier with trig than with vectors, easier and probably faster to compute as well. SQRT has never been a fast calculation.

There is no SQRT operation in rotation with vectors. It's a rotation matrix times a vector, which is literally the exact same operation in a more efficient data structure (that lends itself better to hardware acceleration, considering most consoles/GPUs can do this in hardware). It is faster.

If you look at Wikipedia, there are many ways to implement arctangent. It's a fairly complex function. Many of the ways to implement it even involve square roots themselves.

Van-B wrote:With ATAN, you would have that exact angle, rotate the turret to suit, and use SIN and COS to work out the velocity of the bullet.

Your approach is doing more work if you think about it geometrically.
1) create a distance vector between points A and B.
2) call arctan2 (which will do additional quadtrant checks before passing off to arctan, which may or may not be square rooting anyway).
3) given the angle, reconstruct the normalized hypotenuse (direction of trajectory) trigonometrically via sin/cos functions.

The vector-based spares you a step by not working with the actual angle:
1) create a distance vector between points A and B
2) normalize this vector to arrive at normalized hypotenuse (direction of trajectory)

So it really boils down to 3-4 trigonometric function calls versus a single vector normalization to arrive at the same place. Even if you were to argue that these could be implemented faster (with lookup tables (inverse square roots can be as well)), you are still adding additional calculation(s) with your last sin/cos calls.

Even if you actually NEEDED that angle (which you don't in this scenario), you could still achieve it with less work from the vector method.
Since the implicit first vector in this scenario is the x-axis, and we now know the normalized hypotenuse, both of our vectors are already normalized.

The angle between the two is simply the inverse cosine of the X component of our normalized vector. That's one additional trig function.

In the end, the problem is a matter of coming up with a direction vector of trajectory. The trig method goes through an additional step of calculating the angle before arriving at this. The vector method arrives directly.

I always meant to learn vectors and matrices, but working with trig for so long, it's difficult to see any other solution!. I should investigate this stuff for my sprite library, vertex rotation and stuff like that would probably benefit.