The GetX() and GetZ() functions simply calculates the vector for any
and all game objects moving in the game world. It doesn't actually
move any of them. They have their own functions to actually move them.
They juste use the functions to calculate the new vector.
As for reversing sine and cosine in this instants would totally break
the engine. The reason is I use 0 as do north, 90, as east, 180 as
south, and 270 degrees as west. Yes, I know this is totally not
standard, but there is a reason I do it that way rather than having 0
as do east etc.
Are you aware of the bearing system? Basically, if you ever were to
plot a course using a ship 000 would be do north, 090 would be do
east, 180 do south, and 270 do west. It is a system I've always liked
and feel most comfortable with so wrote my engine to orient using 000
as do north. If I switch that sine and cosine as you suggest orienting
000 as do east, which is what I think will happen here, everything and
anything will immediately blow up. We are talking rewriting the enemy
A.I. system, rewriting the walk/jump/run commands, rewriting the
targeting system, speak direction functions, etc. Basically, I might
as well trash the current engine and start over from scratch. As you
can see I'm not exactly enthused of reversing the sine and cosine in
this case unless you have a pretty convincing argument why I must do
so other than it is the accepted/standard way of doing things.
On 12/11/10, Cara Quinn <caraqu...@draconisentertainment.com> wrote:
> I have a question for you. By removing the + in the getX and getY functions,
> I may have taken out a feature you wanted. Were you just wanting to
> calculate the new vector or actually change Mara's position with the two
> functions? If you simply want to calculate the new movement vector, then the
> changes I made are what you want. If you're wanting to also apply the new
> vector to Mara's current coordinates, then the += are what you want. Sorry
> if I misinterpreted. :)
> The reversal of sine and cosine is still correct though, but I wanted to
> make sure I know what you're after and what code you're using for what. :)
> I personally split up my code into less complex functions and combine them
> rather than placing a lot of steps in one method. For example, I have one
> method to simply get the angle the player is facing and another method to
> set the angle. So naturally, these really basic functions get called in
> other methods in the course of doing more complex calculations.
> Depending on what you want to do, you may not want to normalize as in my
> second note. Normalizing is good if you need to keep a particular vector but
> change its length. I.E. change velocity on a game object.
> This brings up an interesting point, in that a vector is not a point. The
> player's position in space can be represented by a point, but their movement
> can be represented with a vector. A vector is in essence, a point's movement
> in a direction over time. the confusion can come because you can represent a
> vector as it's end point. So it's not always easy to tell what someone's
> code is meant to do in this regard. -Know what I mean?… If you project a
> vector on to a point, then you end up with the same vector but another end
> point. If you project a vector on to another vector, you have a third
> vector. -Confused yet?… lol!
> Anyway, hope the changes to the code work well.
> As a note, my use of X and Y is meant with a positive Z in the up direction.
> Cara :)
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.