Solve Angle C: Is it Between A & B?

[Narf the Mouse]

...including cases such as between 45 and 225 degrees and between 225 and 45 degrees going the other way.

Which, for programmatical reasons, must all be handled in the same equation.

It's either that, or I re-work my roguelikes' LOS aglorithm to handle everything in 90 degree increments.

Save me a bunch of re-writing?

Thanks.

 

[Borek]

No idea what you are asking for.

x > 45 and x < 225 does the trick.

 

[KnowPhysics]

...including cases such as between 45 and 225 degrees and between 225 and 45 degrees going the other way.

Which, for programmatical reasons, must all be handled in the same equation.

It's either that, or I re-work my roguelikes' LOS aglorithm to handle everything in 90 degree increments.

Save me a bunch of re-writing?

Thanks.

Please Explain your problem clearly.

 

[HallsofIvy]

How are you "given" the angle?

 

[Narf the Mouse]

More clearly, it's for a line of sight algorithm for a roguelike. If the algorithm encounters a blocking tile, it generates a blocking angle range - minimum and maximum - produced by said tile. Thereafter, anything which is entirely obscured by said angle - Anything whos corner and middle angles are all inside the blocking angle range - Is naturally not visible.

I also compile all intersecting blocking angles, so as to reduce overhead.

The problem comes with a blocking angle from, say, 45 to 225 or vice-versa, by way of 0/360 instead of 180. That is to say, clockwise from 45 to 225. The algorith tends to think that 45 to 225, counter-clockwise, is blocked.

The conflict comes because the same algorithm must be used for all angles to obtain consistent results.

I've hacked a solution by spitting it into two halves, but I've been unable to find a complete solution on google.