heh... yeah...
whoops

you can also tell I''m retyping stuff rather than copying it from source code

--Tr][aD--

ps. Does anyone happen to know the actual mathematical formulas for sin, cos, and tan?

yeah
sin(theta)
cos(theta)
tan(theta)


seriously:

    sin(t) = t^1/1! + t^3/3! + t^5/5! + t^7/7! + ... forever increasing in precisioncos(t) = t^0/0! + t^2/2! + t^4/4! + t^6/6! + ...tan = sin(t) / cos(t), i forget if it expands to something or not...e(t) = t^0/0! - t^1/1! + t^2/2! - t^3/3! + ... could be wrong here, but its something like this    

Edited by - Magmai Kai Holmlor on November 12, 2000 3:49:47 PM

ok, thanks. i''ve always wondered that.

umm.. Quake1 used fsin/fcos in it''s innerloops and really that game is one of the best optimizitaion feats ever... but hey go kill the cache use a lookup

yes, and as pointed out, Quake was calling these maybe 100 times/frame or more... 2-3 per vertice per frame... and if you're underwater with some moderately complex architecture, that can really stack up quick. Especially if you decide to apply the same algorithm to the verticies of models, too. (Don't remember if Quake did or not... I'm guessing no)

btw: I really don't understand all this hype about "blowing cache". I believe we mentioned that RAM access is quite fast, and the tables I'm talking about only use 8.0kb of RAM... that's the same as ONLY TWO 64x64 TEXTERES... in INDEXED COLOR mode... not RGBA... Most games keep a lot of textures in resident, so I really doubt that two more (or half of one, if you use RGBA to store them) makes that much of a difference... especially when computers these days (the ones that ppl usually play games on, anyway) usually have 64+ mb of RAM...

One little point of advice thoguh: don't use a seperate table for COS, as this IS pretty much a waste... instead, add whatever 0.25 cycles is to your input (for me it's 128) and then use the SIN table.

--Tr][aD--

Edited by - TrIaD on November 17, 2000 10:21:11 AM

quote: Original post by Magmai Kai Holmlor

seriously:
sin(t) = t^1/1! + t^3/3! + t^5/5! + t^7/7! + ... forever increasing in precision

cos(t) = t^0/0! + t^2/2! + t^4/4! + t^6/6! + ...

tan = sin(t) / cos(t), i forget if it expands to something or not...

e(t) = t^0/0! - t^1/1! + t^2/2! - t^3/3! + ... could be wrong here, but its something like this

Those are a bit wrong actually. (and who here wanted to calculate e anyway?)
They should be:

sin(t) = t^1/1! - t^3/3! + t^5/5! - t^7/7! + ...
cos(t) = t^0/0! - t^2/2! + t^4/4! - t^6/6! + ...
^note the substractions

tan(t) = t + t^3/3 + 2*t^5/15 + 17*t^7/315 + ...
e(t) = t^0/0! + t^1/1! + t^2/2! + t^3/3! + ...


Edited by - civguy on November 17, 2000 10:56:02 AM

I''d just like to point out that this particular problem is one of the easiest to implement the "Try It Both Ways And See" solution for. Just make macros for SIN(x) and COS(x) and try it out.

Personally, I use the standard functions in almost all of my code, but I use lerped low precision lookups in a few intensive spots.

I''m suprised civguy didn''t just put ''1'' for the first element of the cos(t) series.

Anyway, I would go with using the functions until you hit speed problems because you can get more precision, i.e. you can have a lookup table for every degree (12, 56, 69 whatever), but mids - 43.529 or 128.592 or something - can be lost.

-Mezz

Mezz, t^0/0! is logical term if you look at the rest of the series. Even though it means same as 1.

And you can also have lookup table that is bigger than 360 (degrees). That way you''ll get of course more precision. And you can use linear interpolation to get the sub-array values. a0+(a1-a0)*t. Although that increases one multiplication there, so it''ll very likely end up slower than using the original fsin and fcos.