next »

[heisenbergman]

@Schrompf: I'm just saying you don't have to take such a dismissively hostile stance against it. Like I said, I probably have no use for it, but if such seasoned developers subscribe to it, there's no harm it giving it at least some thought.

[Schrompf]

@Schrompf: I'm just saying you don't have to take such a dismissively hostile stance against it. Like I said, I probably have no use for it, but if such seasoned developers subscribe to it, there's no harm it giving it at least some thought.

You're right that I should use a different wording. And you already stated that it doesn't make a difference for you (correctly IMO). I think I already acknowledged that in my first response.

But there's one thing I don't need to admit: I already gave it some thought. I already have been there. I wrote fucking games using a sin table 15 years ago, and I already profiled the fucking result when I dropped the table for good 10 years ago. I also argued often enough against this kind of deprecated wisdom. Sometimes it would just be nice if I needn't to.

So my suggestion to everyone reading here is: use the tools given to you. Period. When you start missing your performance targets, then first PROFILE. Do NOT assume anything, do not blindly apply something you read in a forum somewhere. MEASURE. You are a coder, you're about the only profession on earth that can measure its results without complex statistic analysis of error margins or double-blind tests on comparision groups. So do it.

[motorherp]

For reference, if you want to go back the other way, from cartesian to polar, you can use the following:


radius = sqrt(x² + y²)
angle = atan2(y, x)

[heisenbergman]

@Schrompf: Maybe it's just a Java thing, then? After all, this was just presented because as quoted from the linked thread by Oskuro: Math.sin()is slow.

[Crimsontide]

It is NOT an alternative. Just forget about it, ok?

Reasoning: If you use sin/cos like this in normal code, the first level cache is usually filled with the current data. A table-based approach would require parts of the table to be loaded to first level cache, and would flush other data from there. But the table needs to be in L1 cache to be efficient, even a L2 access would already take longer than the basic math to calculate a sin/cos. It's just a few multiplications and additions after all. Look up taylor series if you want to see how few operations exactly. And all of those happen in registers without memory access, some parts even parallelized by the CPU's OOO pipeline.

If you use a table, at least map cos to sin to cut half of the table. After all it's just a phase shift, and you need to wrap around the input value anyways.

But you're right: it won't make a difference in almost any code you'll ever write. That's why my original suggestion still holds: first measure (as in: profile) then optimize.

I don't know that much about the inner workings of java, but I know from a C/C++/asm standpoint you're gonna have a REALLY hard time beating the CPU at its own game.

I say this having implemented all the trig/hyperbolic/exponential/log functions using CORDIC math for a fixed point math library (which is what they used back in the day on older processors, though on current processors its a different process from what I understand).

Schrompf may have come a across as a little hostile, but in this case he is correct.

[Schrompf]

Schrompf may have come a across as a little hostile

Yeah, sorry for that. I should really work on my temper.

[Oskuro]

I wrote fucking games using a sin table 15 years ago, and I already profiled the fucking result when I dropped the table for good 10 years ago.

In Java? Have you profiled current Java releases also? Because I never claimed the lookup table method was a suggestion for anything but a Java implementation.

I personally don't give a fuck who's an administrator and where.

How nice of you to gloss over this:

and the creator of LibGDX (one of the more popular Java game development frameworks today)

I'm sorry, but I personally give more of a fuck about the opinion of people actively working on Java game development, and actually churning out widely used libraries, than the angry rants of some random forum poster.

No, I won't bother checking your credentials since it's obvious you won't bother checking my references.

[Polly]

Using look-up tables for sin / cos went out of fashion ( for the right reasons ) after the Dreamcast era. If you're developing for older systems ( Saturn, Virtual Boy, SNES etc. ), it's usually the way to go though

But Java might as well be a exception for some reason .. no idea

[Schrompf]

I'm sorry, but I personally give more of a fuck about the opinion of people actively working on Java game development, and actually churning out widely used libraries, than the angry rants of some random forum poster.

I'm ok with that. You are free to spend your time as you wish, just as I do trying to educate random people over the internet.

And yes, maybe it's just a Java thing. I haven't checked, I didn't touch Java for several years. I expect the Java JIT to inline and hotspot optimize like any other compiler, and I expect similar performance characteristics. Maybe I'm wrong with that assumptions. But one thing is for sure: You'll never know. Because you optimized before you measured.

[mobossi]

Little late to the party but modern processors have specific instructions for sine and cosine. These are optimized way may than any code hacks that you can do in a high level language. Intel's instructions are here:http://en.wikipedia.org/wiki/X86_instruction_listings#Added_with_80387. ARM also has instructions for it.

When compiling, Java does use those instructions. I found a stack exchange article about tricking the compiler into using different trig instructions. I would NOT worry about this. The payoff is minimal for most people, and you are only going to waste time trying to optimize at this location, unless you find computing trig functions is an actual bottleneck after profiling. http://stackoverflow.com/questions/13460693/using-sincos-in-java.

Conclusion is the same as everyone else. Don't use tables. In general calls to memory are more expensive than calculations, especially on modern processors. On the surface it seems like a table look-up should take less cycles than a calculation. However, the look-up itself takes time, and your processor will just sit there doing nothing while waiting for the look-up to finish.

[relsoft]

Using look-up tables for sin / cos went out of fashion ( for the right reasons ) after the Dreamcast era. If you're developing for older systems ( Saturn, Virtual Boy, SNES etc. ), it's usually the way to go though

But Java might as well be a exception for some reason .. no idea

The Nintendo DS architecture(a much later console the the DC) still needs to use Trig luts and fixedpoint math to make games fast enough.

Luts being faster than straight FPU calls is prolly a java thing and how it is implemented by the jvm.

[Noogai03]

I remember when I first discovered how to do this - I was so happy and immediately made a little spinny spaceship thingy...
Also if you use XNA (don't know about other frameworks) you can create a vector for your distance, then rotate it with matrices
eg

Code:

//the angle to rotate by
float angle = MathHelper.ToRadians(90);
Matrix rotationMatrix = Matrix.CreateRotationZ(angle);

//your vector
Vector2 vector = new Vector2(10, 10);
//transform the vector by the rotation matrix - i.e. rotate it
vector = Vector2.Transform(vector, rotationMatrix);

Just something I use every now and then.

[nikki]

not a too big a deal but above method is offcourse way heaftier then just a cos and sin call.
which doesn't matter at all, until you use it to do gazillion of rotatioms per frame.

[Noogai03]

not a too big a deal but above method is offcourse way heaftier then just a cos and sin call.
which doesn't matter at all, until you use it to do gazillion of rotatioms per frame.

Yeah, it's just a nifty shortcut.