•      Sign In
• Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just \$5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

# Hey, the rotations don't work!

10 replies to this topic

### #1Sik_the_hedgehog  Crossbones+   -  Reputation: 1811

Like
3Likes
Like

Posted 07 July 2013 - 06:48 AM

float deg2rad(float angle) {
return angle * 3.1415926 / 128;
}

Jeez, I wonder why...

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

Sponsor:

### #2slicer4ever  Crossbones+   -  Reputation: 3945

Like
5Likes
Like

Posted 07 July 2013 - 03:15 PM

hmm,

32 = 45 degrees
64 = 90 degrees
96 = 135 degrees
128 = pi

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.
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

### #3Bacterius  Crossbones+   -  Reputation: 9060

Like
7Likes
Like

Posted 07 July 2013 - 08:49 PM

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.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #4Sik_the_hedgehog  Crossbones+   -  Reputation: 1811

Like
5Likes
Like

Posted 08 July 2013 - 07:21 AM

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

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

### #5slicer4ever  Crossbones+   -  Reputation: 3945

Like
0Likes
Like

Posted 08 July 2013 - 07:44 AM

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.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

### #6Sik_the_hedgehog  Crossbones+   -  Reputation: 1811

Like
2Likes
Like

Posted 08 July 2013 - 08:07 AM

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

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

### #7DekuTree64  Members   -  Reputation: 986

Like
2Likes
Like

Posted 11 July 2013 - 08:37 PM

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.

### #8BGB  Crossbones+   -  Reputation: 1554

Like
2Likes
Like

Posted 24 July 2013 - 10:01 AM

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

### #9Solid_Spy  Members   -  Reputation: 420

Like
0Likes
Like

Posted 28 July 2013 - 11:12 AM

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

Edited by Solid_Spy, 28 July 2013 - 11:13 AM.

### #10Sik_the_hedgehog  Crossbones+   -  Reputation: 1811

Like
0Likes
Like

Posted 29 July 2013 - 01:14 PM

I think his idea was to save space.

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

### #11BGB  Crossbones+   -  Reputation: 1554

Like
0Likes
Like

Posted 12 August 2013 - 08:36 AM

I think his idea was to save space.

yep.

partly it is also that some parts of my 3D engine are currently also based around using 64-bit tagged references (IOW: dynamically-typed data), and if a value can be fit into 56 or fewer bits, then it allows it to be stored directly in the reference without having to allocate additional memory.

granted, the usability of something like this does depend some on having usable numerical precision.

PARTNERS