So I offered some of my code and was called on it. Turns out my core code is now all 3d with Quaternions etc. However 2d is even easier to avoid trig and even inverse trig. Done right you don't need all that many sqrts, but even then they are pretty fast.

The idea is simple. A complex number simply represents a unit vector in the direction the angle represents. Turns out complex multiplication is the same as adding angles and complex division is the same as subtracting angles. Since if we start with normalized values we end up with normalized values. Sure there is a little error. You can see that with the java2d demo that is included. You can even compare angles to see which is larger or smaller. Like atan2 angles are implied to be signed +-PI.

In the example the sweeping line is red when smaller than angle to the mouse and blue when larger. It turns green when its in the "acceptance cone", in this case +-8deg. Finally the funny cyan lines demonstrate interpolation.

Sorry i can't work out how to put this in a scroll box.

This code has not been unit tested. Use any way you want. I take no responsibility for this code, use at your own risk. And its in the public domain.

importstaticjava.lang.Math.*;importjava.awt.Color;importjava.awt.Graphics;importjava.awt.Graphics2D;importjava.awt.RenderingHints;importjava.awt.event.MouseEvent;importjava.awt.event.MouseMotionListener;importjava.awt.geom.AffineTransform;importjava.awt.geom.Ellipse2D;importjava.awt.geom.Point2D;importjavax.swing.JFrame;importjavax.swing.JPanel;/** * other code has too much noise. This is suppose to be clean and make it easy for the jgo use. I use a demo java2d example. We use the convention that x is the * real axis and y is the imaginary axis. * * Note that i assume things are normalized a lot. Since this always represents an angle then this should always have unit length. * * Numerical errors for doubles are rather low. But they will eventrually accumulate. But its not like you need to normalize after every operation. * * Some degen cases are not checked. In particular you can create a NaN,NaN angle if you create an angle with 0,0. * * @author bob * */publicclassComplexAngleimplementsComparable<ComplexAngle> {/** * Warning these are mutatable. */publicstaticfinalComplexAngleDELTA_ANGLE = createAngle(PI * 2 / 720);//1/2 defpublicstaticfinalComplexAngleRIGHT_ANGLE=createAngle(PI/2);

/** * paints a circle with a line from 0,0 to 10,0 */privatevoidpaintDude(Graphics2Dg2d){g2d.draw(newEllipse2D.Double(-10,-5,20,10));g2d.drawLine(0, 0, 30, 0);

}

privatevoiddrawLine(Graphics2Dg2d,Point2Dfrom,ComplexAngleangle,doublel){//here we use the example that a complex number can just be interpreted as a unit vector in the direction its pointing. //this is why, if we are normalized cos and sin are just the real and imag parts respectively. g2d.drawLine((int)from.getX(),(int)from.getY(),(int)(l*angle.cos()+from.getX()), (int)(l*angle.sin()+from.getY()));

If I were ever to do 2D stuff I'd just abuse the mathematical types and merge complex numbers and vectors into a single type. I can't think of any situations where the difference in symmetry would cause a problem. Something like this, but not immutable.

That's one way of looking at it (starting from Euler's might be easier though...haven't thought this through). The other is that when you're using angles and directly trig ops & identities that you're working in an exponential or log mapped space when you could be working in linear.

@HeroesGraveDev: It's superficial. Most problems you don't need to consider the angle or trig ops or identities...they're magically built in to the negative signature (fancy way of saying e*e = -1). The "real" benefit here is not only cheaper operations but the fact that you're adding a bunch of tools that allow you to look at the same problem in more ways.

My only concern is that handling these objects is putting both stress on the GC (stack allocation is not perfect yet) and on code verbosity (due to the lack of operator overloading). To me it feels like I'm forced to do 'boxing and unboxing' that angle every time I access it. I think that solely for that reason I'd stick to 'float angle' in most of the cases. In C++ it'd be a lot less of a burden to make the switch.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Yeap. A very real concern which is avoidable in C++: no GC (well by default), new abuse, custom allocators and...umm...oh yeah! structures! Golly wouldn't that be nice. Of course the same holds for all small object allocations. But that's really a different subject to my brain.

Well, you could switch to Scala. Then you have operator overloading. Also modern JVMs can optimize this kind of stuff really well. On the Java 7 server VM there is no performance difference between boxing the values in objects all over the place and keeping them unboxed as doubles. All the object allocations are optimized away where possible, Data is automatically put on the stack instead of the heap, etc.

For the time being all JVM languages are in the same boat w/r to the GC/cache-coherency issue. The only choice to to flatten the state data into a container and perform code replication and/or create synthetically methods to eliminate the operations. So you either do that, or wait for the invokedynamic framework to evolve enough to give the equivalent of limited pointer manipulation...ala some stuff mentioned in that arrays 2.0 presentation.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org