[source]float deg2rad(float angle) {
return angle * 3.1415926 / 128;
}[/source]
Jeez, I wonder why...
[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)
I use 65536 for a full circle. Much more convenient than degrees or radians, due to the auto wraparound and ability to reinterpret it as signed 16-bit for a -180 to +180 degree value (particularly handy in AI when you're deciding whether to turn left or right). And you can still use a 32 bit int if you need to go over one rotation.
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).