I've been searching the net for formulas, hoping for something i can reverse-engineer in to my method, but to no avail.

Basically:

I have an X, Y co-ordinate
I have an angle
I have a distance

How do I calculate the XY at the end of that line? I've been browsing pythagorus theory and whatnot,sine/cosine laws, etc..., but I can't quite find what I need. I hate that I have to ask this here. Ugh.

Right now, basically what im trying:

X2 = X1 + (distance * Math.Cos(angle))
Y2 = Y1 + (distance * Math.Sin(angle))

Thought that was it, but it's not. lol.

Any help?

Thanks

EDIT:
after studying some trig graphs at length, i have determined that infact:


X2 = cos(angle) * distance
Y2 = sin(angle) * distance

Assuming a starting point of 0,0, this is fairly easy to work out. But throw in a custom X,Y coord on the fly, and things seem to go awry.

_________________
"None are more hopelessly enslaved than those who falsely believe they are free."
"It is no measure of health to be well adjusted to a profoundly sick society."
"Hope is the first step on the road to dissapointment." -Jonah Orion
http://tankzgame.blogspot.com

You've got the formula for calculating the X,Y change correct here, then it's just startX + X2, startY + Y2.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

There are various formulae, depending on what axis you are measuring angles from, and whether you are measuring angles clockswise or anticlockwise.

The formulae you've given is when angle=0 corresponds with the positive x-axis, and increasing the angle turns towards the positive y-axis.

Grab a screenshot for angle=0, and mark on it the origin [point (0,0)], and where the line is supposed be. Do the same for angle = pi/2. Then we can see what is going wrong.

_________________
I ain't pushing no moon buttons.

well see, that's what I think is going wrong.

in XNA, 0,0 is actually top left, so i'm forever operating in the 'bottom right' quadrant of your typical graph.

the angles are measured clockwise in my case.

_________________
"None are more hopelessly enslaved than those who falsely believe they are free."
"It is no measure of health to be well adjusted to a profoundly sick society."
"Hope is the first step on the road to dissapointment." -Jonah Orion
http://tankzgame.blogspot.com

Try switching the cos() and sin() with each other, and see what happens. I think you may also need to make the result of the Y equation a negative number (i.e. spriteY = -spriteY).

I remember having the same problem a while back using cos() and sin() in this order in 2D with origin at top-left. Reversing the cos() and sin() for the coordinates did the trick. Things like this are a bit different when you're doing things in 3D vs. 2D.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

It likely that the error isn't with the rotation, but is being introduced somewhere else, where you've confused up-screen vs down-screen as being the positive y direction.

_________________
I ain't pushing no moon buttons.

Yeah, I'l have to re-arrange the formula to accomodate the setup. All in due time, ive cheated for the time being to achieve the desired effect, but down the line during one of my 'optomization sweeps' il try and implement the correct formula and achieve the same effect through a more robust methodology such as this.

Don't get me wrong, what i've done works perfectly.. but it feels.. dirty somehow.

_________________
"None are more hopelessly enslaved than those who falsely believe they are free."
"It is no measure of health to be well adjusted to a profoundly sick society."
"Hope is the first step on the road to dissapointment." -Jonah Orion
http://tankzgame.blogspot.com

I've run into problems like this myself in the past.

At the beginning of the project, it's important to decide what direction is what, eg in a side scrolling platformer, I might say"+X is in the direction of scrolling. +Y is up from a platform surface."

For game logic: work with that decision only. So level design, platform logic and physics all uses those axes.

In the drawing routine: Apply whatever transformations you need to the logical coordinates to create the screen coordinates you intended. I normally reserve X and Y for logical coordinates, and PX and PY for screen transformed coordinates.

This follows the golden rule of game programming: keep physics and drawing separate!.

_________________
I ain't pushing no moon buttons.

Yep, been bitten by that one a few times. I always used to use the top right of the screen as 0,0 but when I started tinkering with OpenGL, it uses the bottom right for the origin. This makes Win32 mouse selection interesting as you either have to flip the mouse Y coord (window origin), or fudge the screen coords with a transform.

Anyway, I wrote a few bits and bobs including the early engine for Amber, my GUI lib and font rendering libs with different origins depending on what seemed best at the time, but when I came to put them all together, all hell broke loose. Upside down text, broken mouse selection, incorrrectly culled polygons, etc, etc.

So don't be like me, pick a co-ordinate system at the beginning and stick with it.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

Yeah, ive got the basis of my game engine complete.

The stage im at now, is that everything that I want to work, Works. its bug free, solid, robust, reliable code. However, its messy. It's not as clean as I'd like. My next move is to go through the code and 'clean' it up -- clear up 'loose' code, tidy things up, make things more modular and 'object oriented'... right now my game is like a car with the hood popped and the engine parts all over connected with wires.. everything runs correctly, but the parts are everywhere.

I need to tuck things away nicely into my engine.

Then, it's on to multiplayer programming. Client/Server problem solving. Yikes. lol.

In a turn based game it's not so bad to add this on. But for a real-time game, you have to think about multiplayer from the start.

Clients have to be temporally syncronised. All players must be at the same time. You don't want one player 3 seconds ahead of another player. It's not trivial to do this, because any communication of server time is going to be lagged by an indefinite amount.

Clients have to be logically synchronized There is lag (maybe 50ms or more) when sending data over IP. and you don't want to wait this long after every redraw. It would kill your framerate. So the game physics has to freewheel some of the way, and then correct itself when data comes in. This requires two copies of the game physics. One that is true, and one that is freewheeling from the most recent true. Also, you must use a fixed time-step, because variable time-steps can create unpredictable outcomes.

_________________
I ain't pushing no moon buttons.

basically what im thinking is that all the position information will be stored serverside, and updated by each respective client when they move.

Then, when a certain client needs to know where a certain object is, the client will poll the server and get the info, and act accordingly.

My biggest confusion with netcode is the hit detection.

I have pixel perfect collision detection. But of course the server isn't comparing pixels. So does the hit detection happen client side? If so, who's client? (because of even tiny bits of lag, it could detect a hit on my computer but not on yours, etc) ive always been fuzzy on how that works. Logic/Fairness would dictate that the server should decide collision.. but it cant. can it?

not sure how all that works.

_________________
"None are more hopelessly enslaved than those who falsely believe they are free."
"It is no measure of health to be well adjusted to a profoundly sick society."
"Hope is the first step on the road to dissapointment." -Jonah Orion
http://tankzgame.blogspot.com

You can do pixel perfect collision detection server side... you just don't draw any of the pixels

_________________
Whatever the mind can conceive and believe, it can achieve

The simplest form is a null-video.
Split off the video drawing/blitting code in a separate VideoSystem class, and make a NullVideo implementation that simply returns immediately on each call.

The disadvantage is that you are still computing what to render at what place. One step further is to disable that code as well further saving CPU time.

On the other hand, all clients do render shiny pixels to the screen, so unless you have other useful computations to do at the server instead, there is little point in making the server much faster (other than to conserve CPU time).

realized something after i typed it.. polling the server for info wouldnt work, i'd have to have the server spamming everyones position constantly.

Hmm..

_________________
"None are more hopelessly enslaved than those who falsely believe they are free."
"It is no measure of health to be well adjusted to a profoundly sick society."
"Hope is the first step on the road to dissapointment." -Jonah Orion
http://tankzgame.blogspot.com