🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

How do I figure out which direction to rotate my player, as to have the smallest rotation.

Started by
12 comments, last by Alberth 5 years, 7 months ago
6 hours ago, LazyDev said:

After a while, the player can only turn left for some reason ?

This should work, independent of how many revolutions the input angles have:


	int rot = (to_angle - from_angle) % 360; 
if (rot<0) rot += 360;
return (rot < 180 ? 1 : -1); // eventually flip the sign, depending on what you expect
	

I wonder why you use degrees and integers for angles.

I suggest using 2D direction vectors or complex numbers over angles too. It eliminates worries about angle ranges and more importantly a lot of expensive trig operations, depending on what you do. 

 

 

 

Advertisement
20 hours ago, Alberth said:

You shouldn't treat code as a black box that magically produces the correct answer. The computation is right there and it's not difficult, so take some time to study and understand it. Once you understand how it is intended to work, get an example where it fails, and do the computation step by step (either in a debugger or even manually with a calculator). At which point does the example deviate from the intended answer? Why?

That is the information you want to start thinking about a solution.

 

If you want to discuss it here, please provide a concrete example of from_angle and to_angle where the code fails, so others can verify your findings, and play with the code to find the cause. It may also clarify what you mean, eg I have no idea what "left" means, the code only has positive and negative rotations, there is no left or right in there.

 

As I ran an exhaustive test while writing that code, my first random guess of your problem is that you're not obeying the input conditions. Of course my tests may be flawed as well, so I am quite interested in an example where the code gives an incorrect answer.

Here is what I use to update the rotation.


            int jump = 10;
            float pos_rot = (360 + newRot - rot) % 360;
            float neg_rot = 180;
            if (pos_rot < neg_rot)  {
                rot += jump;
                pos_rot = (360 + newRot - rot) % 360;
                neg_rot = 180;
                if (pos_rot > neg_rot) rot = newRot;
            }
            else {
                rot -= jump;
                pos_rot = (360 + newRot - rot) % 360;
                neg_rot = 180;
                if (pos_rot < neg_rot) rot = newRot;
            }
            this.rotation = new Quaternion().fromAngleAxis(rot*FastMath.DEG_TO_RAD, Vector3f.UNIT_Y);

Here is how i get the "newRot" variable.


        Vector2f mp = inputManager.getCursorPosition();
        double xDiff = (settings.getWidth() / 2) - mp.x;
        double yDiff = mp.y - (settings.getHeight() / 2);
        gl.player.newRot = (int) (Math.atan2(xDiff, yDiff) * FastMath.RAD_TO_DEG);

I used


System.out.println(gl.player.newRot < -360 || gl.player.newRot > 360);

to debug it, and it never goes over 360 or under -360. So I don't think I'm inputting anything out of the designated range.

3 hours ago, LazyDev said:

it never goes over 360 or under -360. So I don't think I'm inputting anything out of the designated range.

Except I stated as input conditions a full circle as non-negative number.

On 11/24/2018 at 11:56 AM, Alberth said:

// Rotating from 'from_angle' to 'to_angle' (range is 0..359 for both).

 

I don't know why you need 2 full circles to state a direction, looks very complicated to reason what happens in the game that way, as any direction has two valid answers.

 

Also you may want to clean up your code, variables with a constant value are polluting, especially when they have the wrong name (neg_rot means negative rotation, and that's not the same thing as "half a circle").

Your if/else to catch too large jumps is quite convoluted. It will get a lot cleaner if you first compute the actual jump you want to make and then update your rotation, rather than jump a fixed distance, and compensate in an opposite direction afterwards. The second rotation calculations in the if/else branches are totally unnecessary, realize what pos_rot (and neg_tor used to) compute, and relate that with your jump.

This topic is closed to new replies.

Advertisement