Are trig tables still quicker

Blitz3D Forums/Blitz3D Programming/Are trig tables still quicker

I'm looking to make a game that uses lots of trig based natsh to draw lines and construct vestor objects. Is it still more fficient to use arrays of pre-calculated values or to do the maths on the fly?

I may be looking to do several thousand calculations per frame.

Rob Farley

Lookup tables generally are faster but you loose accuracy... To be honest I really wouldn't worry about it. Try it using Maths functions and if it needs to be faster swap to a sine look up table.

Also if you're using Blitz3D (as the forum suggests) you can use the built in 3D functions. Create pivots, position them and use entitydistance, entityyaw, pointentity etc. Depends what you're doing though.

Ross C

Do a test for yourself. You will really struggle to notice ANY difference. I did a test couple of years back. It will a couple of million iterations of lookup tables and a couple of million iterations of sin/cos. The results were inconclusive.

Stevie G

On modern hardware the difference, even with 10,000 per frame will be negligible. It will not be the cause of any bottlenecks in your programs.

Stevie

andy_mc

Cool thanks, I'm using blitz3D but it will be a 2D game. I assume with the original asteroids game they must have used look up tables as co-processors didn't exist at that time. I'm not making asteroids, but that the type of graphics I'm looking to do.

Ross C

I'd stick to using SIN TAN and COS. It's not quicker or slower :o)

Sokurah

Well, I completed a wireframe game a few months ago and I had a problem with my framerate so I changed part of the game to use lookup tables instead of using sin/cos constantly and in my case it helped a lot.

Here's a quick bit of pasting from my own blog;

Amazing what a bit of optimization can do. No more framerate drops for Rip Off.
The framerate is limited to 60fps, but unthrottled, the earlier version would usually run at up to 200fps if the screen wasn’t too busy.
But the screen did get busy sometimes, which caused the framerate drop below 60fps and cause jerky movement. Now, after it's been optimized, it’ll run unthrottled at up to 1000fps and most of the time at about 500fps even if the screen is busy.
There are more bits that can be optimised, but I think this’ll do for now. :-)
I’ve noticed a few bugs though (small ones), so I’ll need to take a look at that before releasing the game, but this extra week of optimization was more than worth it.

So it will make a difference in some cases. :-)

http://tardis.dk

Ross C

Well, i ran some tests again:

Delay 1000

Dim cos_(360)
Dim sin_(360)

For loop = 0 To 360

	cos_(loop) = Cos(loop)
	sin_(loop) = Sin(loop)
	
Next

Delay 100

Global timer = MilliSecs()

For loop = 1 To 10000000

	temp = Cos(Rnd(1,360)) * Sin(Rnd(1,360))
	
Next

Print " Real SIN/COS = "+(MilliSecs() - timer)+" Milliseconds"

Delay 100

timer = MilliSecs()

For loop = 1 To 10000000

	temp = cos_(Rand(1,360)) * sin_(Rand(1,350))
	
Next

Print " Lookup SIN/COS = "+(MilliSecs() - timer)+" Milliseconds"

WaitKey()

And my code would definetly agree with you. 10 million iterations of multiplying a random integer COS by a random integer SIN. Then, the same, but this time with lookup tables. Almost twice as fast on this machine.

So apologies for the slightly wrong information :o)

nawi

You could use Blitz arrays or Banks for even faster access. If you're doing a simple 2D game you could use them, since it is so easy anyway, but you really need to start using them when doing some 2D gfx demos.

smilertoo

#10

You lose accuracy.
The tile was loose.

Danny

#11

Yep, that test above also gives me nearly twice the speed using look up tables.. Good to know..