Question For A Pythagorean Specialist

[Junrall]

Pointing to two spots in front of the player is straight forward. (If there is a simpler method... please let me know)


My question is... how do I point to two spots, in relation to the player, 35, 45, 90, or any chosen degree to the left or to the right? (in the images above and below spot1 is 50 units away from player and spot2 is 50 units from spot1)

[Spirit]

I have no idea how to code or whatever nor if you have coordinates, but if you do:

x = startingpointcoordinate + length * sinus (angle)
y = startingpointcoordinate + length * cosinus (angle)

would get your coordinates.

In your example with the player being 0,0 and the angle 45°.

x1 = 0 + 50 * sinus (45°)
y1 = 0 + 50 * cosinus (45°)

x2 = 0 + 100 * sinus (45°)
y2 = 0 + 100 * cosinus (45°)
or use the new coordinates you got for spot1.

[Sajt]

To get two points 45 degrees to the left and right, each 50 units away from the player, add a yaw offset to the player angles:

makevectors(self.v_angle + '0 45 0');
dot1 = self.origin + v_forward * 50;

makevectors(self.v_angle + '0 -45 0');
dot2 = self.origin + v_forward * 50;

You don't have to normalize v_forward, it's always unit-length (unless you changed it yourself).

In your first picture, note that:

(normalize(v_forward) * 50) + (normalize(v_forward));

is thus the same as:

v_forward * 50 + v_forward;

Which is of course the same as:

v_forward * 51;

[Teiman]

another simple-lame way to do that, could be to generate the points from photo1, then add enough v_left ( or -v_left ) to have the ones on photo2.

is just better to use sin and cos, anyway..

[Junrall]

is just better to use sin and cos, anyway..

I like Sajt's method because it is easy to use... however I'm not sure how to pass an arbitrary degree value to makevectors(self.v_angle + '0 45 0'); And, whenever I look down, the two points move downwards and and towards each other... eventually overlapping one another. What I want is to be able to look up or down and have the two points remain where they are.

I did end up using sin and cos... and like the control I have with it. Also, with the following code, the spots do not drift when I look up and down, but do move with my left to right rotation... which is just what I want.

Code: Select all

spot1 = normalize(v_forward) * distance * mathlib_sin(degrees) + normalize(v_right) * distance * mathlib_cos(degrees);

Lol... I may have over coded the above (as usual!)... I'm sure it can be shortened in some way!

I sure like that Mathlib v2! I'd like to see more of these types of qc utilites! Thanks FrikaC!

[Sajt]

If you want to ignore the player's pitch angle (look up/down) completely, then do this:

makevectors('0 1 0' * (self.v_angle_y + yawoffset));

Where yawoffset is your angle (e.g. -45 or 45).

If you're new to how QuakeC's vectors work, here is a more verbose but more readable version of the same thing:

local vector ang;
ang_x = 0; // no pitch
ang_y = self.v_angle_y + yawoffset; // offset yaw
ang_z = 0; // no roll
makevectors(ang);

If you do want the player's pitch to be taken into account, and thus you want these positions to be in the same position on the screen at all times, you'd have to implement some matrix math. But I assume that that isn't what you were trying to do anyway.

You should know that sin/cos is exactly what makevectors does (in fact, mathlib probably uses makevectors in order to use those functions), so there's no point in not using makevectors here.

Also, you might want to use self.origin + self.view_ofs as the origin instead of self.origin.

pos = self.origin + self.view_ofs + v_forward * distance; // distance is e.g. 50

The player's camera is located at self.origin + self.view_ofs. If you don't add view_ofs you will be working from about the player's chest level.

[Junrall]

Sajt: Excellent info! Yes I am new to quake vectors... especially when it comes to trying to figure out what is available... such as .v_angle_y
I kinda figured that there was a "something_y" that I needed to work with.
I wish there were a specific place to go for in depth descriptions and examples of this stuff... though, if a person digs enough, there is a lot of info embedded within this forum and the thousands of mods.

I'm actually starting to informally make notes (with pictures/videos) of a few things I have learned. Ha! maybe I'll find time to put something together that others can use as well.

Thanks again! Later tonight I'll play around with the info you have given... and take notes!

[Junrall]

Ok, here it is later tonight...

Sajt: Works like a charm! Is it safe to assume that your code is processed faster than what I was doing?

[Sajt]

If you look at the source to the mathlib_sin and mathlib_cos functions (http://www.inside3d.com/frikbot/qc/mathlib.qc), you'll see that they are calling makevectors. So by calling sin and cos you're calling makevectors twice, which is a waste...

Of course, speed-wise it doesn't really matter because this would only actually affect your framerate if you were doing it thousands of times per frame. But it is "good practice" and "cleaner" to do it this way (calling makevectors instead of sin/cos), which is a big deal to obsessive programmers like us...