Sine/Cosine Approximation
Monkey Forums/Monkey Programming/Sine/Cosine Approximation
| ||
Hi all! I'm just wondering if an approximation method to calculate sine and cosine as described here: http://lab.polygonal.de/?p=205 would be worth to try on Monkey, or the speed up would be minimal. |
| ||
It makes no sense to consider that sort of performance hack unless you've specifically identified that trig functions are a major issue in your code. |
| ||
I remember using that technique back on the Amiga, and it does work well if as Muddy said it is the cause of the problem... |
| ||
you don't need sin/cos really. at a 2d vector its just x = -1 to 1 y = -1 to 1 a angle/direction is split in x & y values. |
| ||
-oops- |
| ||
The old solution for sin/cos speed (back when it really was a severe issue) was using prepopulated lookup tables. A counterargument I saw posed recently was the question of whether memory access was still cheaper than such trivial CPU actions. Personally I find the sin and cos functions just fine. What exactly are you using them for that it would be an issue? |
| ||
I'm actually curious about this. With 3d graphics though you may need the precision, which means larger tables and more memory. |
| ||
I have done some tests and I don't see any difference. I think that this method may be useful for a really very large amount of calculations, but not really needed for "normal" games. |
| ||
I've been building a rts engine that requires tons of 3d transformations. I'll definitely be applying this. :) |
| ||
i thought about doing LUTs at one point, but after profiling code, it is usually not the culprit. |
| ||
I've been reading a lot about geometric maths, algebra and opengl lately attempting to become more familiar with the how code graphics from the ground up. What usually is the culprit of graphic bottle necks? @Adam - As someone very familiar with OpenGL and Trig, what learning path would you suggest to become more familiar with graphics? Thanks! |
| ||
What usually is the culprit of graphic bottle necks? textures. @Adam - As someone very familiar with OpenGL and Trig, what learning path would you suggest to become more familiar with graphics? Hmm, big question. I started off by writing plugins for Lightwave 3D. I would say that writing an engine is the best way to learn opengl/d3d, but also be aware it takes 2-3 years and writing a game from it is foolish since most of the time is spent on the engine. second best would be to follow the nehe tutorials. To learn the basis of graphics, i'd say write a cornell box path-tracer. they're small, easy, and awesome results when done. lots of the math and trig is applicable to every engine, especially light and shadows in modern game shaders. http://www.kevinbeason.com/smallpt/ for learning trig and math, i had to refresh some knowledge recently, and i used this: https://www.khanacademy.org/math/trigonometry/ I'm a learn-by-doing guy, but for the book learners, _Real-Time Rendering_ is probably one of the best books available EVER: http://www.amazon.com/Real-Time-Rendering-Third-Edition-Akenine-Moller/dp/1568814240/ref=pd_sim_b_2 ...although, it should be used as reference and expansion, rather than a starting point. i'll stop there. i could go on for days. |
| ||
Wow! Great references Adam! I've never heard of khanacademy but it looks like an awesome web site. Some of the path tracing code looks cramped, and very complicated. It's going to take me awhile to pull it apart and really understand what's happening but I think that's expected. Please feel free to go on for days haha. I've been reading this book - [a href=http://www.amazon.com/Math-Primer-Graphics-Development-Edition/dp/1568817231/ref=sr_1_2?ie=UTF8&qid=1379015903&sr=8-2&keywords=math+game+programming][/a] Which has been great so far though some of the more complicated stuff has me scratching my head. How long have you been working with OpenGL? Thanks! |
| ||
Great links Adam, thanks! :) |
| ||
How long have you been working with OpenGL? not long amazingly, started with blitzmax! |