How do I calculate the difference between two angles, on a scale...
Adrenaline
Member Posts: 523
HI all! More questions involving circles... @Socks , your favorite!
Can anyone help me calculate the difference between two angles, on a % scale, where a 12.5 degree difference = 0%, and a 0 degree difference = 100%?
I've come close to solving this problem, but I get funky results when the angles are near the folding point (like 358 degrees and 2 degrees).
I'm sure the few sentences above are quite confusing, so I'll try to give an example.
angleA is fixed.
angleB is varying: the player controls this by rotating an actor.
I want to display an "accuracy score" when the player sets the value of angleB. The actor for angleB has a custom collision shape in the shape of an arc of 25 degrees. Therefore, if the player sets the rotation of angleB at a value that is more than 12.5 degrees to the left or to the right of angleA, the collision will miss entirely. If the collision DOES NOT MISS, I want to be able to display how accurate the player was (on a scale of 0-100).
If angleA = 10 and the player rotates angleB to = 10, the accuracy should then be 100%.
I look forward to hearing just how poorly I explained my problem 
Comments
y=ax+b
0=a12.5+b
100=a0+b
b=100
0=a12.5+100
-100=a12.5
a=-8
y=-8x+100
Hope this helps.
Use the arrow keys to rotate the actor.
You can change the game.startrotation to an angle you want to calculate %-offset with
✮ FREE templates at GSinvention ✮
✮ Available for hire! support@gsinvention.com ✮
I didn't quite understand, could you scribble a quick image to explain ?
@-Timo- this is awesome! I admit that I saw your post before you edited and attached version 2—version 1 was a tease because it was so close to what I wanted but I couldn't plug it in to my project perfectly. However, version 2 is NEARLY flawless! Thank you! If I may hold your attention on this for just a bit longer, I'd really appreciate it...
In your sample project, everything works absolutely perfectly. But in my working project, my equivalent to your "RotOffset" actor has its rotation set with other behaviors (vectorToAngle and touches/drags). The point being: my rotation of -1 degree is actually registering as 359 degrees. This causes problems when checking for accuracy when game.startrotation is anywhere close to 0 or 360.
How would you suggest I remedy this? Is there an adjustment to what you've shared with me, or do I need to rework how I'm rotating my actor?
Thanks again! This was super helpful (and quick).
@Socks , @-Timo- scribbled a quick GS project to explain better than I could lol. I'd be happy to try my hand at a more visual explanation, but if you're still interested you could quickly peek at @-Timo- 's project here.
@Adrenaline - A quick 'n' dirty solution I used for Parcel Monkey was to just rotate my image and corresponding actor 90/180 degrees...
This way my entire swing falls into the 'safe' zone, never coming close to wrapping around that 0 to 359 point.... If you want the figures to fit into your range, just offset them by the initial rotation angle... 
@Japster
What if I told you I can't avoid the 0/359 wrapping point?
My game allows for ANY degree in a full circle to be the target.
I've been avoiding attaching a sample project because my file is a mess and wouldn't make sense to outside eyes...I'm going to try to break it down and include only what's relevant so I can share with you all.
Thanks for chiming in @Japster
Here's my file. Click and drag anywhere to rotate the arc.
The number displayed in the middle is the 'accuracy' that @-Timo- helped me implement.
And you can change the 'game.randomDirection' attribute to adjust the target degrees.
You can see here that a value of 0 (or anything near that point) causes issues with the 'accuracy'.
I think I understand now !
Basically you drag the arc, if it aligns with the correct angle (in your example 0°) you get a 100% accuracy score, if you are out by 12.5° either way, CW or CCW (for a total range of 25°) then your accuracy will be 0° ? Is that the basic idea ?
One way you could do it would be to use the absolute value of the sine of the angle (rotation), so you'd never need to deal with negative numbers or the issue around 0° where the values jump from 0 to 359 . . .
Which should look something like this:
max(100-(asin(abs(sin(startingAngle-currentAngle)))
*8),0)I've stuck a max function in there to stop the range going beyond 0°, hold on, I'll knock up a quick GS project as it doubtlessly needs a little tuning.
Project attached, even if it's not right there may be some ideas you can extract from it . .
@Socks -- love it!
This one goes into my "instant appropriations" folder.
Cheers, there is one small flaw in the logic, although to be honest you could account for it pretty easily with a simple rule, I was just too lazy to perfect the idea, and that is that the expression would return the same percentage value when turned 180°, but like I say that's not too hard to resolve, depending on how this would be used.
Right -- you could use 'if abs(( self.sA - self.Rotation )*.08) < 1' in a rule to get rid of opposite end problem.
That should do it, to be honest it was a bit of a hatchet job, I'm sure it could be simplified / slimmed down.
Thank you all!
@Socks , @-Timo- , @Japster , @RThurman
Apologies for the delay, I'm at work and still haven't had the chance to check your file, Socks. But I'm sure it's exactly what I'm looking for. I'll check back in with confirmation later.
Thanks again to everyone, you're all always so helpful.
Ah right.. yeh no sure makes sense?
Great job as always @Socks !!
✮ FREE templates at GSinvention ✮
✮ Available for hire! support@gsinvention.com ✮
You guys are just awesome. Works like a charm, of course.
When I finally stop asking @Socks for help with sin and cos, he goes and throws in asin.
'asin' is pretty straightforward, it's just the inverse of sine, so . . .
If the sine of 45° is 0.7071
Then . . .
The asin of 0.7071 is 45
. . . . .
Or to put it another way if you know the vertical distance from the centre of a circle to the point where an angle hits the edge of that circle (the sine), then you can use 'asin' to work out the angle !
Makes sense to me, thanks!
While I have the attention of your helpful minds...the implementation of the solution in this thread has left me with another problem.
If you check the sample project I attached earlier, I'm using an arc that can swivel very quickly (based on the user's touch). With everyone's help here, I'm now able to detect the accuracy of the arc's placement when it collides with another actor...but I've noticed a bug of sorts. If I swipe quickly so the arc is in motion during the collision, the "accuracy" measurement is very inaccurate
! Basically, the rotation value that I'm using to measure the accuracy is changing very rapidly, so it seems like GS is gathering the rotation value at the incorrect moment. Am I asking GS to work faster than it can?
@Adrenaline - here is a version that uses the modulo function to get past the 0-360 issue. Maybe it will help with the speed/accuracy issue as well.
Thank you for the help @RThurman , I really appreciate all of the time everyone is putting into this. Unfortunately, it's yielding the same results.
Rather than spin everyone's wheels on this, I'm going to keep tinkering. Maybe I'll come up with something to solve it, or at the very least I'll unearth more to share here.
Hmm... can you describe in a little more detail what the issue is? I think you are referring to an 'accuracy' issue?
For example, you might be trying to describe the fact that it records the very last measurement, but you want it to record the 'highest' score. In this case, the 'inaccuracy' comes from the fact that as the finger is lifted off the mouse button (or the screen), a slight hand tremor is introduced -- causing an 'inaccurate' final measurement.
Or perhaps you are describing a problem with a very fast transient of one actor across another (very narrow) actor? In that case, its a problem of the device's sampling rate.
And so on ....
Perhaps with a little more description, some inspiration will happen!
Like @RThurman says, I'm also struggling to understand the issue.
I don't know -- it looks pretty elegant to me. I never would have thought to use the sine function to get rid of the 0-359 degree issue.
@RThurman no problem. I do believe it's a case of the sampling rate that you described.
At this point, I don't think breaking down my project into a more abstract version to share here would do me any good because I'd have to remove elements that factor in to the actual problem.
I wouldn't mind PMing my actual game project. I highly doubt any of the individuals who have spent their time to help me here would actually be interested in stealing anything I have...you'd probably only see your old forum answers in practice anyway!
That may be asking too much (understandable), so I'll try to explain in more detail below.
The solutions that were provided here all work perfectly, but they are using a static point of reference ---> an angle that is set and then compared to the position of the player's rotating actor.
I am only interested in calculating this accuracy when a collision takes place. This means that the accuracy value needs to be grabbed in an instant. In theory, it should work exactly the same, right? But I am getting inconsistent results.
Why? I believe it's because the rotatable actor (the arc) can spin so quickly that it sometimes collides with the other actor at one angle, continues to spin and change its own angle, and spits out the accuracy value without knowing which angle to use.
A specific example:
I've tried to side-swipe the moving actor with my arc. This should give the lowest possible accuracy because the collision is taking place at the absolute edge of acceptable angles. When I do this slowly, I am seeing low accuracy values. But if I side-swipe quickly, I'm seeing an accuracy value of 100% sometimes!
Pretty sure that's what it is, because I just tweaked my game so the arc is no longer movable after the collision is detected. This lets me see exactly where it's registering the angle. If I move the arc quickly, I can still get it to a position beyond where the collision SHOULD be detected.
By 'side-swipe' do you mean that you are trying to quickly touch the edge of the arc? Or does it mean that you swipe through the entire arc but very quickly?
Do you experience the same issue with the attached project?
Yep! Thank you for the sample project. I've edited it a tiny bit to illustrate my problem.
Go into the 'shape' actor and adjust the speed, then test. When the speed is too high, the rule isn't fired until too late and therefore a higher value is displayed in red.
@Adrenaline - yes, even a computer cannot respond infinitely fast. Like anything that has to process information, it takes time.
But is this a test of what you want the user to do? If yes, I really don't understand how you expect a human to process information and respond faster than a computer. I believe GameSalad processes a time slice every 60th of a second. Humans can't respond faster than a 20th of a second.
I found another way to work around it. Of course, there's no ignoring the processing speed...but given the specifics of my game, I was able to create another attribute that I can cross-check and sort of force the correct value to be spit out here.
I know it doesn't make sense without seeing it...but when I'm done, I'll make an announcement post for my game and you'll see what I mean! I'll discuss it in more detail there if anyone is interested.
P.S. Of course, I wasn't looking for a way to process information infinitely fast
, just wondering if anyone knew any band-aid solutions to achieve the same results (like maybe recognizing that the collision happened too quickly, and extrapolating backwards after the fact to get the accurate value).
Either way, thank you all for the help - it really has gone a long way for me!
I look forward to seeing it!
As a side comment -- studies over the past 10 have have shown a steady decline in human reaction times. Its not due to people getting slower, but 'modern' computers and operating systems are making accurate measurement harder. And its even worse for mobile devices. There is too much 'stuff' happening between the display of a stimulus and the recording of a response. (Its interesting that as raw computing power has substantially increased, software has actually decreased our processing speed.)
That is really interesting. I'm not sure I fully follow it, though.
Is this saying that raw computing power has substantially increased but it's being used for all sorts of 'stuff', so we're gradually losing the ability to accurately measure interactions (because the computing power is being used elsewhere)?