Why are the dots bouncing?

bug_fixed
problemsolved
resolved

#1

I am making a concept of a resizable square. I am trying to implement a rotation feature, and I’m practically certain that all my code is right. When you rotate the square, the dots just start bouncing up and down. Why is this happening? https://c.gethopscotch.com/p/zy49hmphy
@CodeHelp


#2

You don’t need to use that complicated of a sine/cosine code. You can also make the sine value universal and use it in the y position code as well. Just have the sine match up with the sine of the square, and add 45 x the clone number. The number of times you add 45 is depending on the clone.
(I hope I’m right)

Edit: you will have to change the first number (the “100” when you first spawn in the sine code) as the square changes size. That’s pretty much it


#3

I’m not entirely sure what you mean. Do you reckon you could explain it a little more simply?


#4

@MISSION_IMPOSSIBLE
The height and width properties of the square are changing as it’s rotated (they’re changing to reflect the vertical & horizontal dimensions relative to the screen) which is making the dots bounce.


#5

Here you go:
https://c.gethopscotch.com/p/zy6jt2mi6


#6

@DECODECO,
The dots need to change their position relative to the w/h of the square.
image


#7

Why are the height and width values changing when it is rotating? That makes no sense. A 200w x 100h square should still be a 200w x 100h square even if it is at a 45˚ angle.


#8

The properties don’t literally mean the height & width of the square. They mean the height & width of a “bounding box” that encompasses the image.

I agree that’s not intuitive, but that just what the properties mean…

Edit:
(The values also include invisible “padding” around the image, so even when the square isn’t rotated, the height & width properties still don’t reflect the actual height & width as displayed on the screen)


#9

Yes, this is just so you can start to get an understanding of what explanations will be added on later


#10

@MISSION_IMPOSSIBLE
Something weird’s occurring that I can’t explain (yet)

What I described above is definitely how the width/height properties were working on your project

The properties don’t literally mean the height & width of the square. They mean the height & width of a “bounding box” that encompasses the image.

However… I went back and looked at my 3D rendering projects and while using the Set Width/Height block, the input values I used matched your expectation of how the image’s height/width should work.

I need to do some more testing when I have time later on…


Edit: I see now. The input values to the Set Width/Height block refer to the width/height of the image when at a 0 deg angle (regardless of the current angle of the image)

The Width/Height properties reflect maximum horizontal and vertical dimensions (“bounding box” dimensions) of the rotated image

Both include invisible spacing around the native images.


#11

Maybe because it doesn’t match the square size?
I’m not really sure, sorry.


#12

I’m fairly sure I get it, but do you think that you could make a project showcasing the functioning thing? You could remix my project, and then change the bits where I went wrong. I’ll give credit. @ThinBuffalo


#13

Yes, this is very annoying. There should be a setting that differentiates between the two.


#14

@MISSION_IMPOSSIBLE
I’m thinking about making a tutorial to explain the differences… but it’ll be a new project.

Let me work out the trig for how to do what you want, and I’ll post the formulas…


Edit: Ok, since you’ve already created 2 object variables of Width & Height and stored the “square”'s real width & height in these variables, your fix becomes easy.

In the Corner Position & Side Position custom rules, just change the (Square)Width & (Square)Height in the formulas from the object properties (orange background) to the variables you created (yellow background)


#15

Thanks, but the corner ones still bounce. I changed both the custom rules, as well.


#16

Check again. I’d guess that you didn’t change all of the instances.


#18

Watch this gif, @ThinBuffalo
image


#19

Yep. That’s a different problem though than the “bouncing”. Let me see if there’s a simple fix…


Hopscotch 3.33.0 with new winter characters
#20

Ok, so the formulas in Corner Position & Side Position abilities need to be changed up a little.

First off, I defined a new iPad variable “Scale” so I only needed to change it one place. You can do this or just substitute the value for the variable in the formulas below.

In Square’s When Game Starts
Set Scale = 4.38

Corner Positions
Consider the upper right Dot. You have the angle offset from the square set to 45deg. That’s fine when it’s actually a square but if the width or height is changed so it’s a rectangle, then the angle is no longer 45. The angle can be calculated using inverse tangent, where Tan(theta)=Opposite/Adjacent

To fix, first change the (self)Angle to 0 for the upper-right Dot and increment the others by 90deg. So counterclockwise; 0, 90, 180, 270

Then the angular part of the formula (the bit in the Cos or Sin) is:
(Square)Rotation + arctan[(Square)Height/(Square)Width] + (self)Angle

Also the radius part of the formula (the bit before the Cos or Sin) should be calculated using Pythagorean theorem (A^2 + B^2 = C^2):
Sqrt[((Square)Height/Scale)^2 + ((Square)Width/Scale)^2]

Note: the scale value accounts for the transparent space around the image
Note: the scale value is doubled so we don’t have to add an extra divide by 2
Note: Width & Height are the object variables (yellow), not the object traits (orange)

Side Positions
This has to be split into 2 separate abilities. One for the dots on the midpoint of the width & one for the dots on the midpoint of the height.

The radius part of the formula should be:
(Square)Width/Scale for width midpoints
(Square)Height/Scale for the height midpoints

Note: Same notes as above

The angular part of formula you have is fine as is:
(Square)Rotation + (self)Angle


I saved a draft copy of your project with these edits but rather than remix I’d like you work through the edits yourself. I can publish it later if you’re having trouble.


#21

Oh boy. This may take some time. Thanks, though.