From README

"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.

From vmath.c

#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

really consider

#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 ?