level of difficulty: 3/5

Here is a general representation of the problem:

steps:

1. when distance between T and i is bigger than a fixed size -

2. figure out the angle, better yet the radian between T (touched point) and i and the point straight line that crosses the circle horizontally.

3. then find the sizes of the adjacent and opposite sides of the triangle in the circle by finding: cos/sin(radian)max_radius

4. then, depending on which quarter we are talking about, I will either subtract or add , opposite to Yi and adjacent to Xi to get P(x, y) and also keep in mind the width/2f and height/2f so that the coordinates of P are exactly the middle of the ball.

This happens when the ball is shot at the approximate angle of -177 degrees

previously it looked like this:

with this formula (v0y is minus because of the inverted Y axis):
ball.vy = - ball.v0y - (ball.GRAVITY * time);

but now the code is:

        if (quarterOfLaunch == 1 || quarterOfLaunch == 2) // throwing the ball downwards.
            ball.vy = ball.v0y - (ball.GRAVITY * time);  // the vertical velocity changes constantly.
        else 
            ball.vy = ball.v0y + (ball.GRAVITY * time);

After playing with the physics for a bit, this is the current state:

Basically what happens when the ball changes its' trajectory is that the VY reaches 0 after being minus (-1) and then flips to positive (1) as it should, but the velocity-changing system flips the number when it reaches max height.

Here's the solotion:

Calculate Vy after the system.

There are 3 types of collisions:

1. right wall
2. floor
3. left wall

But first, I must figure out how to change the direction of the ball after thrown:

Discussion: Changing Direction #34

1. right wall

premise:

Attributes:

1. velocityX = -1 * Math.abs(velocityX);

1. left wall

premise:

1. floor

premise:

combined:

where do i even start??

The issue: we don't want to draw just up to the ball Rect, but to to ball itself:

first try:

אבל מה עושים במקרה כזה:?

This problem is caused from the velocityX being impossibly tiny (7.717558E-5 for example).

so one solution might be setting velocityX to 0 AS IT SHOULD BE when the angle is 90 or -90.

I've tried it and it's not the problem.

Found the source of the bug:

if (ball.velocityY == 0 || ball.x >= ball.range * ball.ratioPXtoM)
                ball.velocityY *= -1;

To be honest i have no idea why it was there in the first place, but that happens sometimes...