"The fast math routines are not nearly as accurate as the
standard routines, but enough for the game."
I'm not sure where this belongs, but it's discussion-worthy.
I've found myself wondering how bad I had become, until I noticed that an ai
player with an err of 0.0 would also miss direct shots.
What decided me to investigate, was the fact that after aiming slightly left
of the target ball, the cue ball would go to the right of said ball (without
any english being set).
Let's consider following scenario:
Standard 12-feet snooker table (rounded to 3.6 m)
Hardcoded 57.15 ball diameter (rounding to 55 mm)
Cue ball and target ball are close to opposite short bands (3.6m apart)
The angle a formed by the target ball, as seen by the cue ball, approximates to
a = 55/3600
(sin(a) = 55 / (sqrt(55² + 3600²))
first approximation: 55² + 3600² = 3600 ²
second approximation: sin(a) = a when a is close to 0)
The angle at which the cue ball can hit the target ball (from touching it left
to touching it right) is, assuming both balls have the same size, twice the
angle at which the cue ball sees the target ball.
h = 11/360
Now we deal with the fastmath granularity.
#define MAX_CIRCLE_ANGLE 512
The program starts storing n = 512 different values for sin and cos (actually
only half of them since it uses the symmetry of sin and cos for negative angles)
This means the granularity of implemented fastmath is g(n) = 2PI/n
The number of different positions where the cue ball could hit the target ball
is therefore P = h/g(n) = 11*n/720PI = 2.5
So from that distance, there are 2 or 3 positions (depending on cue angle) at
which the cue ball could hit the target ball. This is very low if you want to
do anything but hitting (like wanting to be accurate).
If you want to have at least P different positions to hit the ball, you
need to choose n such that h/g(n) >= P
n >= P*720PI/11
For example, to have at least 20 possible angles (10 on each side of the
target ball), you need n >= 4113
Of course at the cost of the memory (4113*sizeof(float) bytes), but I would
#define MAX_CIRCLE_ANGLE 4096
as a minimum value.
Recomputing a different fast_cossin_table according to the table size would
also be a valid option.
Was this fastmath implementation specifically tailored for target devices
having well-known limitations (I'm thinking of the WeTab, for example) ? Or
did performance issues occur, that forced to switch to a less
computing-intensive implementation of math functions ?
Thank you very much for your work on the math routines. And yes, here is a good place for discussing things like this.
I've used the fast-math routines on some machines like Netbooks and yes the WeTab. And not only the fast-math routines gives really a boost.
OK, we speak about 512 or 4096 or 8192 table entries. That are 2 KB, 16 KB or 32 KB memory. That is not the problem. I've tested with 512/4096 and 8192 table entries on slow machines. Here ist the result in comparison to the standard math.h:
512 entries are three times faster
4096 entries are also three times faster
8192 entries the same
For comparisation: on very fast machines it's the same.
irony of math with computer: The fast exp function (only used with the lensflare) works on slow machines up to three times faster and on very fast machines (with pure Intel CPU) up to three times slower ;-(
Thanks. I put a table with 8192 entries in size into the fast cos/sin functions into vmath.h. Let's test with it.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.