[r188] Decimal error in angle on created

Bugs will be moved here once resolved.

Post » Sun Nov 16, 2014 6:29 am

Objects created at an angle have a decimal error
When I place a sprite in the editor at any angle besides 0, it will give it a very small decimal. Image
The angles are also consistent. setting it to 180 in the editor always resulted in 180.00000500895632 degrees with multiple objects in different projects.

Description of Capx
The Capx has multiple objects at different angles in the editor, and logs their angles to the console on creation.

Steps to Reproduce Bug
  • Add a sprite
  • Set it to an angle other than 0
  • Observe the actual angle given

Observed Result
Crazy decimals.

Expected Result
Regular decimals that I gave the objects

Affected Browsers
  • Chrome: YES
  • FireFox: YES
  • Internet Explorer: NOT TESTED

Operating System and Service Pack
Windows 8.1 64 bit

Construct 2 Version ID
r188 beta, also happened on r184 stable
You do not have the required permissions to view the files attached to this post.
B
46
S
14
G
7
Posts: 603
Reputation: 8,106

Post » Sun Nov 16, 2014 7:31 am

Isn't this the same floating point rounding 'error' (which is normal) that's been brought up a number of times?
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Sun Nov 16, 2014 8:02 am

@codah Not really. That happens when you're doing maths with numbers usually. But I would assume it would set properly if you're explicitly telling the value to be a certain number. How come the angle doesn't get set weird when I set the objects angle through an event? It's only happening when the object is created.
B
46
S
14
G
7
Posts: 603
Reputation: 8,106

Post » Sun Nov 16, 2014 9:00 am

oh ok. I didn't actually load the capx as I'm on 187b (although I'm pretty sure that's what it is :), somehow).
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Sun Nov 16, 2014 12:18 pm

This is the same gotcha as "expecting math calculations to be exact", but it's not obvious why: the runtime actually stores angles in radians, since that's how all the math is worked out, and the conversion between radians and degrees involves a slightly lossy multiply/divide. Closing as not a bug... this is another reason you should rely on values being "close enough", not exact. (The new 'Is within angle' system condition is useful for this type of thing - you can say "Is within 0.5 degrees of 180" for example, and it's accurate to the nearest degree.)
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

Post » Sun Nov 16, 2014 7:48 pm

@Ashley Thanks for the reply. I didn't expect this problem to occur when setting a value without doing any actual calculations to it. How come this doesn't happen if I use the Set Angle to 180 action then? Isn't that doing the same thing?
B
46
S
14
G
7
Posts: 603
Reputation: 8,106

Post » Mon Nov 17, 2014 12:51 am

EncryptedCow wrote:@Ashley Thanks for the reply. I didn't expect this problem to occur when setting a value without doing any actual calculations to it. How come this doesn't happen if I use the Set Angle to 180 action then? Isn't that doing the same thing?


It's because 180 degrees is equal to 1 radian, so it's a simple conversion (so it's actually equal to pi, too).
B
103
S
38
G
19
Posts: 962
Reputation: 17,996

Post » Mon Nov 17, 2014 5:28 am

C-7 wrote:
EncryptedCow wrote:@Ashley Thanks for the reply. I didn't expect this problem to occur when setting a value without doing any actual calculations to it. How come this doesn't happen if I use the Set Angle to 180 action then? Isn't that doing the same thing?


It's because 180 degrees is equal to 1 radian, so it's a simple conversion (so it's actually equal to pi, too).


Still confused. Does the engine set the angle when it's created differently than when you use the action?
B
46
S
14
G
7
Posts: 603
Reputation: 8,106

Post » Mon Nov 17, 2014 12:32 pm

No, 180 degrees is not equal to 1 radian. 1 radian is 57.2957795 degrees.

I thought the same thing would happen at runtime since it has to do the same calculation. Perhaps it's rounding it slightly (which the text object does by default for example), or in the past we've had issues where the exporter uses a different precision.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 6 guests