Vector2f rotation does not follow standard practice

Development
1

I’m talking about public void rotateAroundOrigin(float angle, boolean cw).

Standard practice with quaternion-based rotations is:

  • No mention of rotation center, it’s always around the origin.
  • Have a foo and a fooLocal.
  • fooLocal returns this for chaining.
  • No mention of rotation direction, it’s standardized.

So I’m proposing this in Vector2f:

[java] /**
* @deprecated Use rotateLocal(angle) instead of
* rotateAroundOrigin(angle, true).<br>Use -angle
* for rotateAroundOrigin(a, false).
*/
public void rotateAroundOrigin(float angle, boolean cw) {
rotateLocal(cw ? angle : -angle);
}

/**
 * Return this <code>Vector2f</code>, rotated by <code>angle</code> in
 * counterclockwise direction.
 * &lt;p&gt;
 * Use <code>-angle</code> to rotate in clockwise direction.
 */
public Vector2f rotateLocal(float angle) {
    float newX = FastMath.cos(angle) * x - FastMath.sin(angle) * y;
    float newY = FastMath.sin(angle) * x + FastMath.cos(angle) * y;
    x = newX;
    y = newY;
    return this;
}

/**
 * Return a copy of this <code>Vector2f</code>, rotated by
 * <code>angle</code> in counterclockwise direction.
 * &lt;p&gt;
 * Use <code>-angle</code> to rotate in clockwise direction.
 */
public Vector2f rotate(float angle) {
    float newX = FastMath.cos(angle) * x - FastMath.sin(angle) * y;
    float newY = FastMath.sin(angle) * x + FastMath.cos(angle) * y;
    x = newX;
    y = newY;
    return new Vector2f(x, y);
}

[/java]

Comments?

If this goes into 3.0 despite being late and rushed, I could use it for the Monkeyblaster tutorial for gamedevtut.
2

Argh where’s the edit button for the first post.
Typo in first function, the sign is reversed. It should really be

[java] rotateLocal(cw ? -angle : angle);[/java]

3

3.0 is already branched. We don’t plan to add any more code to it as that’s a recipe for another six months delay.

4

I’m almost of the opinion that the method is out of place in the engine in general. It’s an odd one.

5

Yeah, the implementation is odd with its violations of almost every standard practice.

The concept, however, does make sense, at least if JME is to cover 2D games.

6
@toolforger said: Yeah, the implementation is odd with its violations of almost every standard practice.

The concept, however, does make sense, at least if JME is to cover 2D games.

I don’t think that’s really JME’s intent… or at least not in a “painted in the corner” sort of way that this method provides. In other words, if this approach is taken then the game would always be in 2D where as a slight change in approach would transfer trivially to 3D.

I’m curious what the other core devs think.

7

There is already a quaternion-based rotation for 3D.
It’s just a convenient shortcut for those cases where you are working (and thinking) inside a 2D plane and need that vector rotated. It saves the programmer the work (and opportunity to introduce bugs) by preselecting the axis to rotate around; it also optimizes out a lot of sines, cosines and multiplications because the quaternion would have x=y=0.

So I do think it does have its justification, if JME is supposed to work well for 2D.
If it doesn’t, we probably shouldn’t a tutorial to http://gamedev.tutsplus.com/articles/news/wanted-experienced-game-programmers-to-port-a-game/ because at best, we’d get an influx of 2D game programmers.