synkro
0xdeadbeef
EDIT uhm.. I have to rethink some things...
2ND EDIT okay... a variable precision is kinda ugly to code. I try a signed 16.16 now
2ND EDIT okay... a variable precision is kinda ugly to code. I try a signed 16.16 now
Oh, right... good point.rixed posted on Oct 19 2006 at 01:05 AM said:You'd better check that the compiler don't actually code a function call at all...rabidcow posted on Oct 18 2006 at 11:22 PM said:I would say don't bother making it pass by reference. If you do, check the compiled code to see if it actually passes the address rather than a copy.
You only need a quarter revolution for sine. (and then reuse the same table for cosine) I recommend using a power of 2 instead of 360 (I use 1024), because it makes some of the math slightly more efficient. You still need conversion from radians to revolutions, but it's just pi and shifting.synkro posted on Oct 20 2006 at 05:00 AM said:IV) I use normaly a degree sinus LUT with 360 fixed entries. This need rad->degree conversion or natively working with degrees what I do anyway. A precision of 1 degree should be enough for 2D stuff. Any comment on this or simple ideas to have a small but precise LUT(s)?
Division by zero should automatically throw an exception or signal or something. I think the most common thing to do with sqrt of negative is to just short out and return 0. It might be more interesting to treat the number as unsigned and get an extra bit of range.synkro posted on Oct 20 2006 at 05:00 AM said:V) I did not understand the square root code posted earlier, I'll look for solution (any hints?). But a sqrt() would need a NaN value (root from negative value) as DIV by zero should already have. As we are on it, saturation anyone?
