On the radians / double issue again:
Computers don't know about units (meters, degrees, liters, ampères, kelvins, radians and what have you) when doing calculations; all units are usually implicit, and the function takes something as an argument or returns something that is to be interpreted as a real-world number, the documentation usually specifies what unit is expected. For many things, especially in the computing world, there are conventions that pretty much everybody adheres to: for example, the size of a data chunk is given in bytes (not 12-bit binary words, or words of 57 base-7 digits). For other types of quantities though, such as angles, the matter isn't as clear, since there are several systems being used alongside each other; in this case, there are 3 systems involved, each of which has its advantages:
- Degrees; a full circle equals 360 degrees. This format is very human-friendly, since most commonly used angles are represented as whole numbers (0, 30, 45, 90, 180). It also allows for easy conversion to and from the "clock" system (the system used by sailors and aircraft pilots to indicate relative directions: "Enemy fighters at 3 o'clock!") - each hour equals 30 degrees. OpenGL uses this format.
- Radians; a full circle equals 2 * PI. From the mathematician's point of view, this is the "natural" way of measuring angles, because it defines the angle by the length of an arc on the unit circle. In other words, an angle in radians equals the length of its arc divided by a radius. (It makes more sense when you see it sketched on paper). Also, all the trig functions can be used unchanged for various circle calculations when using radians. Downside is that angles in this format look very un-intuitive, because PI is not a whole number. The C math library (libm) uses radians.
- Allegro degrees; a full circle equals 256. Big advantage is that it allows for a number of speed optimizations, especially on older computers. Wrapping an angle into a full-circle-range, which usually requires a modulo operation, can be optimized to a bitwise-and, because 256 is a power-of-2. It is still quite intuitive (half circle is 128, 1/4 is 64, etc.); downside, though, is that it is incompatible with pretty much all other libraries, including libm.
The unit chosen is independent from the numeric encoding format you use: int, allegro::fixed, float, double, etc.
The issue with allegro's math functions is that they expect fixed-point numbers, but since they are typedef'ed as long ints, C cannot tell the difference, nor convert them correctly for you.
My suggestion is to leave the fixed-point math alone altogether, and do everything using floats (or doubles) and radians. The only point where you really can't avoid 256-based fixed-point values is when you pass angles to allegro's drawing functions, in which case you should just take the float-point value and convert it on-the-fly, like this:
#include <allegro.h>
#include <math.h>
// assuming angle to be a float:
rotate_sprite(screen, sprite, 100, 100, ftofix(angle * 128.0f / M_PI));
]]>
). I'd personally do #define DegToADeg(x) = (x) * 256/360.0f.