Path: chuka.playstation.co.uk!news From: SCEE Developer Support Newsgroups: scee.yaroze.programming.libraries Subject: Re: FP calculation speed. Date: Thu, 17 Apr 1997 16:16:41 +0100 Organization: Sony Computer Entertainment Europe Lines: 29 Message-ID: <33563ED9.703@interactive.sony.com> References: <01bc4b05$545e09e0$02018484@chrisa> NNTP-Posting-Host: 194.203.13.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) Chris Allmark wrote: > > Does the use of functions such as SIN(), COS() etc. have a dramatic effect > on speed. I am messing arround with a sprite routine which performs > 1000xSIN() and 1000xCOS() calculations for each of 1000 sprites during the > GsSortSprite() bit and I seem to be achieving around 1 frame per second > (wow.). I disabled the SIN & COS calcs and it flew. I am goind to > pre-calculate the data into an array - but should I have to do that ? > --- > Chris Allmark, Zoo Software Solutions > "If you can't plug it in - We don't use it !" The standard C sin and cos are very slow, due (I think) to using floating-point math and being highly accurate. In the sample programs (eg flying, dungeon, tunelfin) you'll find modules __already__ written which provide interface functions to lookuptables. They're mostly quite simple, the only ones to be suspicious of are the arc-trig functions which were knocked up quickly, but aren't hard to redo. Looking at how the sample code calls and uses the LUT trig functions will show how the PlayStation uses angles and integer math; basically, 360 degrees = 2 PI = 4096 PlayStation units. Lewis