|
sin and cos etc with lookup table
Thought that fast sin() and cos() etc functions might be nice..
how is it done the fastest way? Heard that you could use bitshifts or something like that some way to make it lightning fast...
was planning to something like this
Snale
+--My humble and superior homepage
Snale+--My humble and superior homepage
How do you get 180*10?
How do you get -90 to 90?
Why are you returning abs(angle)%180*10?
I don''t know about bitshifts but quadrants are used to cut your lookup table to 45 entries.
From your code I don''t think you have a clue as to what you''re doing. I start by figuring out the basics first.
Ben
http://therabbithole.redback.inficad.com
How do you get -90 to 90?
Why are you returning abs(angle)%180*10?
I don''t know about bitshifts but quadrants are used to cut your lookup table to 45 entries.
From your code I don''t think you have a clue as to what you''re doing. I start by figuring out the basics first.
Ben
http://therabbithole.redback.inficad.com
Um, can we stick with a simple look-up table here? We don''t need to redifine sin. Just keep it simple. From what you have, you are making a faster sin function, but in vain, since a simple reference into a global array is faster still.
|
By doing a bit of testing I found a couple of interesting things.
abs(angle) % 180 * 10 don''t really work since it will always return the values for negative angles
example:
sin( 30 ) = -0.5 should be 0.5
sin( -30 ) = -0.5
It doesn''t really matter though. It''s actually slower than the standard sin function so modification is rather pointless.
A straight lookup-table variant is about 5 times faster than the standard sin but it has downsides, like not being able to feed it with an angle higher than 180 or less than -180. I don''t use sin that much anyway so I think I''ll stick with the standard.
Snale
+--My humble and superior homepage
abs(angle) % 180 * 10 don''t really work since it will always return the values for negative angles
example:
sin( 30 ) = -0.5 should be 0.5
sin( -30 ) = -0.5
It doesn''t really matter though. It''s actually slower than the standard sin function so modification is rather pointless.
A straight lookup-table variant is about 5 times faster than the standard sin but it has downsides, like not being able to feed it with an angle higher than 180 or less than -180. I don''t use sin that much anyway so I think I''ll stick with the standard.
Snale
+--My humble and superior homepage
Snale+--My humble and superior homepage
>>like not being able to feed it with an angle higher than 180 or less than -180.
Come on Snale think about it
![](smile.gif)
Zipster has posted the answer, except for negative addressing mainly because he
wasn''t asked to do that!!
I think you are looking too hard at the code and not the problem.
First thing your array can contain almost any amount of angles (Up to a point).
You could be using fractions of an angle. Or anything. Remember anything you can build
with Sin or Cos can be stored in a suitably sized array.
If you really want to do negative addressing, which I assume is to make your code
more readable then ...
To quote and edit Zipster..
The_Angle_We_have=-180;
The_Sin_Value_We_Need = sinTable[ The_Angle_We_Have+180];
Think of the big picture, step back and shout EUREKA!!
![](smile.gif)
you could use look-up tables, but for a more precise result assembly would probably be the fastest. glVelocity has a little library that has sin and cos aswell as sqrt() functions in asm.
HHSDrum@yahoo.com
HHSDrum@yahoo.com
My HomepageSome shoot to kill, others shoot to mame. I say clear the chamber and let the lord decide. - Reno 911
I could use make a big lookup table to get higher precision etc etc but is it really woth wasting that memory to speed up a function I almost never use in my current project, seems like wasted time to me. ![](sad.gif)
Good looking code should always be top priority. Who needs speed anyway? Life is so fast paced today so taking a cup of coffee while the next frame is rendered is completely ok with me
An ASM solution might be the best speed/every thing else compromise.. I''ll have to look into that
Snale
+--My humble and superior homepage
![](sad.gif)
Good looking code should always be top priority. Who needs speed anyway? Life is so fast paced today so taking a cup of coffee while the next frame is rendered is completely ok with me
![](smile.gif)
An ASM solution might be the best speed/every thing else compromise.. I''ll have to look into that
Snale
+--My humble and superior homepage
Snale+--My humble and superior homepage
I guess you mean angles that *potentially* are out of the scope of a lookup table?
Like..
angle = atan(2.0 / fov * maxscale / xscale);
s = sin(angle);
c = cos(angle);
Have not looked at the assembley library you are talking about
but are there comparisions with say the MSVC standard libs?
On another note I have heard that building an arctangent table is pretty tricky. The code above is only called exactly once every frame or when something changes , which is infrequent. So I have never bothered investigating building arctangent tables.
Like..
angle = atan(2.0 / fov * maxscale / xscale);
s = sin(angle);
c = cos(angle);
Have not looked at the assembley library you are talking about
but are there comparisions with say the MSVC standard libs?
On another note I have heard that building an arctangent table is pretty tricky. The code above is only called exactly once every frame or when something changes , which is infrequent. So I have never bothered investigating building arctangent tables.
>>but is it really woth wasting that memory to speed up a >>function I almost never use in my current project, seems like >>wasted time to me.
Yes if you hardly use it then it is a waste of time. However lookup tables can be a very handy tool. Some famous programmer,cannot remember who, quoted "In the end most optimisations come down to cacheing". But yes a large lookup table can cause considerable cache misses so it not always a good strategy.
>>Who needs speed anyway?
Sadly games do need speed. However if it not a game then feel free to make the user wait as long as possible. He could read your pretty code whilst waiting![](wink.gif)
Yes if you hardly use it then it is a waste of time. However lookup tables can be a very handy tool. Some famous programmer,cannot remember who, quoted "In the end most optimisations come down to cacheing". But yes a large lookup table can cause considerable cache misses so it not always a good strategy.
>>Who needs speed anyway?
Sadly games do need speed. However if it not a game then feel free to make the user wait as long as possible. He could read your pretty code whilst waiting
![](wink.gif)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement