# Vector2f rotation does not follow standard practice

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.```

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.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.

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

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.

@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.

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.