Are computers nowdays fast enough to calculate sines and cosines on the fly, or should we still be using lookup tables? How much of an increase in speed is there?

Depends on how much speed you want ;o)

I''d precalculate them and stuff em'' into a look up table...
cya,
Phil

Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states

Simply NO, they will just blow up your cache, actually make the application slower, if you''re unlucky.

/ Tooon

They should just hardcode the calculations and put them permanently on the video card

I wonder if that''s possible?


"All you touch and all you see is all your life will ever be --Pink Floyd
Quidquid latine dictum sit, altum viditur.
Need help? Well, go FAQ yourself.

For sine/cosine/tan the intel processors have a specific instruction (FSIN,FCOS,FTAN - can''t spot the inverse functions though)...

Esentially, don''t bother using lookup tables for simple calculations, but when there is for a relativly complex algorithm where thre results are requied often, it''s best to use a lookup table (eg CRC32 algorithm uses a table to lookup for a number for each byte). IMO, anyway.

Depends. Is this sin/cosine calculated occassionaly? Is it done within some inner loops?

My advice is just to use the sin()/cos() functions, until profiling tells you its too slow. Don''t bother if it''s not contributing to your execution time.

Hmmm... I''m calling sin and cos about 10 times/frame each. I''ll run a profiler on it and see if it gets any better with lookup tables.
Thanks anyway..

If you only call it 10 times a frame you won''t notice any difference.

In an FFT algorithm I wrote, I realized a massive increase in speed by using a massive (2D) table of pre-calculated sin & cos coef. instead of calculating them on the fly. (on a PII 350MHz)

Think about it, how many cpu ticks does it take to:
setup the FPU
send the 32bit floating data into 128bit floating data
do the sin/cos/tan/whatever
send the value back to 32bit floats
done

Compare that to:
load pointer
load whatspointed at
done

the cpu is very good at loading stuff from RAM

Even just calculating them all at once will give you a speed increase over on-the-fly, because the FPU doesn''t need to change its mode (or its less likely anyway...)


...
I thought on-the-fly would be about as fast, until I tried it.
And what if the bone-head playing your game has a celery and not a real cpu?

LOL

okay, last line was good...

erm... how big is this 2d table of yours (and HOW do you use 2D anyway??)

Anyone ever toy with the source to Quake (and possibly the sequals)? IN GLQuake, water and everything in it has its verticies dynamically changed every frame... so we're talking about running [3-4]*numverts*fps sines/cosines per second... (3-4 b/c both X and Y were being changed per-frame, and I think one or both used sin/cos twice in the formula... but I could be wrong)

anyway, that's a lot of calls... now if you set it up as a macro like:
#define tsin(a) tsintable[a & 512]
...it should be pretty fast... (note the "& 512" to make the values wrap... you can tell how big my table was )

--Tr][aD--

Edited by - TrIaD on November 10, 2000 9:53:35 PM

errr, don''t mean anything (prolly a typo ) but don''t you mean

tsintable[ a & 511 ];

cause 512 is %1000000000 in binary and you would end up indexing either 512 or nothing

As an aside, if I use a sintable I use a size of 4096 (so you can & with 4095).

n!