OneSadCookie Wrote:On a modern processor, a sin/cos lookup table with any accuracy is almost certainly more expensive than just calculating the sin or cosine directly.

Cache coherency?

Nevada Wrote:Whoa there. Why are we squaring everything? The square of a ratio is not identical to the ratio itself. I realize we're trying to avoid the overhead of the expensive sqrt call, but if you square the ratio, you'll have to take the square root anyway. Hog had it right...

Oh yeah. Sin, cos, and atan2 are all very expensive (performance-wise) function calls and are very prone to rounding errors. So if we can avoid all that with one call to sqrt, the routine should perform better.

correct a/b is not equal to (a*a)/(b*b)... but no one said it was.

Skorche Wrote:Cache coherency?

Memory access latency (if your lookup isn't in L1 you're going to pay as much in stall cycles as you would in just calculating the thing).

Possibly particularly true on x86 where there is an fsincos instruction that can be used.

unknown Wrote:

Code:

#define SPRITE_SPEED2 SPRITE_SPEED*SPRITE_SPEED
...
    vector.x = new_world_dst.x - player.x;
    vector.y = new_world_dst.y - player.y;
    
    float sqd = vector.x * vector.x + vector.y * vector.y;
    if(sqd > 0.00001f) {
        float scale = SPRITE_SPEED2/sqd;
        position.x += vector.x*vector.x*scale;
        position.y += vector.y*vector.y*scale;
    }

Correct me if I'm wrong, but it seems this translates to:

x = x + (dx*dx)*(speed*speed)/(dx*dx+dy*dy) = x + [dx*speed/sqrt(dx^2 + dy^2)]^2

It should simply be:

x = x + dx*speed/sqrt(dx^2 + dy^2)

Unfortunately, the former wouldn't work even if you added it to x^2 instead, because of it's inherent non-linearity.

I think he was joking due to the incorrectness of the previous post.

No it wasn't a joke but it mistake.