You can save a bit of time by precalculating sine and cosine values for 360 degrees and storing them in an array. Then you use your own sine/cosine function that returns the corresponding field from the array, which is faster than calculating the same values over and over.
And don't tell me "If it's that good then do it yourself and upload a patch" cause I don't have the time.
I've got a close deadline for my project and I'm barely gonna make it.
The sine array has been outperformed by most vector math extensions, such as SSE. And math libraries for the embedded platforms usually do such things already, depending on the memory interface performance and other stuff. So better save your time for other stuff.
So to be sure I understand you right, the following is wrong?
Halifax wrote:Yeah, one thing I have to say, that you addressed, is the fact that you use cos() and sin(). I don't know if you know anything about how these are calculated, but these are very expensive (It uses multiple divisions, factorials, and exponents)...
@Halifax: Sorry you just really got me worried about it
You have to profile it - realistically- on each target platform. Realistically doesn't mean running through the table, it means letting it swap in and out of the cache, as the cost of loading the table into L1 cache may be higher then doing the calculation.
I tried this a couple of years back using Windows / Microsoft cl.exe (Athlon XP 1400), and the platform / math.h sin() and cos() were faster than table lookups (when interspersed with other memory-reliant operations) or any "fast approximate" equivalent that I could find.
Let me clarify my statement, which was taken out of context. They are expensive in regards to the simple calculations of dot products and cross products. These can also be calculated with math extensions like SSE as well.
As stated above tables wouldn't really cut it. First of all you would have to decide the precision of your table, which can increase the size drastically. For example, what if you input 3.5 or 3.54245? So usually tables do have the exactness that the real functions contain.
The only time that I would recommend using tables, from my own experience, is when you can use a integer precision table on a processor such as z80 or 68k.
