c++ – How do I make a correct rebounce in a field with an angle totally different than 0

c++ – How do I make a correct rebounce in a field with an angle totally different than 0

[ad_1]

I am utilizing box2d and rebouncing a field every time it hits the underside or high of the display screen, i am utilizing world positions right here, the utmost is 20.0f which is the worth of boundarySize:

void Recreation::ClampScreenY( Field* pBox)
{
    bool isColliding = false;
    auto pos = static_cast<b2Vec2>( pBox->GetPosition() );
    auto aabb = pBox->GetAABB();
    auto angle = pBox->GetAngle();


    if( aabb.upperBound.y >= boundarySize )
    {
        pos.y = boundarySize - boxSize;
        isColliding = true;
    }
    else if( aabb.lowerBound.y <= -boundarySize  )
    {
        pos.y = -boundarySize + boxSize;
        isColliding = true;
    }
    
    if( isColliding && !pBox->GetWasColliding())
    {
        auto vel = static_cast<b2Vec2>( pBox->GetVelocity() );
        vel.y *= -1;
        pBox->SetVelocity( vel );
        pBox->SetPosition( pos );
    }

    // replace
    pBox->SetWasColliding( isColliding );
}

I have been testing this on a field with angularVelocity = 0 and angle = 0 and it really works. Nonetheless this rebounce impact shouldn’t be working for containers which can be rotating or which have an angle != 0. Why is that this taking place? I am getting out of bounds drawing. There’s clearly one thing mistaken with this math.

Angle = 0 works effective and rebounces completely:

enter image description here

Angle != 0 crashes:

enter image description here

The ClampScreenY perform is known as within the UpdateModel perform I created which is resposible for updating the logic of the sport.

After the sport calls the UpdateModel, it calls the ComposeFrame which pulls all objects(i simply have one right here):

void Recreation::ComposeFrame()
{
       auto vertices = box->GetVertices(); // for debugging
       box->Draw();
}

The decision to box->Draw() crashes when colliding with high of the window within the state of affairs of the picture 2 (when the angle != 0). Looking on the 4 vertices values I see that

vertice[2] {x=-0.651163101 y=20.7524509 }

so the y > boundarySize, this should not actually be taking place because the Clamp perform was purported to handle this. What provides?

Possibly once I name SetPosition it solely updates the field within the subsequent iteration?

[ad_2]

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply