[source]float deg2rad(float angle) {

return angle * 3.1415926 / 128;

}[/source]

Jeez, I wonder why...

You know you've done too much programming when you start bitshifting everything instead of adding/multiplying as usual because it's easier to read.

Or when you've worked so much with old systems that using 256 as a circle starts feeling natural, which is what happened to me in this case (although on those I generally would use look-up tables instead of any proper calculations with angles).

yea, I could see this working if you needed to condense rotations into an single byte, and didn't need very high precesion for rotatin, of course u'd probably have to use a bit to represent which half of a circle you are rotating around.

The trick is that 256 = full circle. This has the extra advantage that wraparound happens on its own (255 + 1 = 0 if the value is a byte). Given that in games usually you don't need that much accuracy, but you need performance a lot, on old systems this was pretty common. If you could afford the space another one was 65536 = full circle (16-bit angles, I know Allegro had used this).

yea, I could see this working if you needed to condense rotations into an single byte, and didn't need very high precesion for rotatin, of course u'd probably have to use a bit to represent which half of a circle you are rotating around.

The trick is that 256 = full circle. This has the extra advantage that wraparound happens on its own (255 + 1 = 0 if the value is a byte). Given that in games usually you don't need that much accuracy, but you need performance a lot, on old systems this was pretty common. If you could afford the space another one was 65536 = full circle (16-bit angles, I know Allegro had used this).

arg, of course 256 is a full circle, i feel like such a fool for suggesting to use a special bit. it's cool to hear that retro systems did legitimately use this.

Well, you could always argue that bit 7 indicates which half of the circle it is ;P (I have actually abused this before)

well, a nifty thing about using 8 bits per angle is that it can allow fitting a rotation in a 24-bit value.

can always have something like:

32 bits: XYZ, 10 bits each (+ XZ sign)

8 bits: exponent + Y sign

24 bits: PQR rotation.

I actually experimented with things like this, mostly trying to fit full transforms into 64-bits, and vectors into 48 or 56 bits, but the precision wasn't really all that good (I was mostly experimenting with fitting vectors into tagged references).

for example (56 bit vector):

48 bits: XYZ mantissa, 15 bits each + XYZ sign

8 bits: exponent

8 bits: reserved for tag/etc

more effective is a 128 bit form:

96 bits: XYZ as floats

32 bits: rotation (PQR).

I'd say just write a 3d rotation matrix, it's not too hard ;3

I think his idea was to save space.