Adapting the Hitbox to rotation (rotate sf::FloatRect)

[Raincode]

Hi there,

I am currently working with the SFML Game Dev Book, which provides SceneNodes with a getBoundingRect() function:

virtual sf::FloatRect getBoundingRect() const;

I would like to change the function, so that it takes into account the rotation of my SceneNodes in a way, that it rotates the actual rectangle, instead of resizing it to fit  the rotated Sprite. I have included a picture to illustrate.

I think my motive is clear: The overly large hitboxes would likely make the game experience, if I ever get that far, not really great. You percieve the laser missing you (not knowing its hitbox), however, it still hit you. Seems frustrating.

This is what I tried in code, which wasn't very successful. The Rectangles were not rotated, only offset in their position:

// original function body:
return getWorldTransform().transformRect(mSprite.getGlobalBounds());

// my modification
auto rect = getWorldTransform().transformRect(mSprite.getGlobalBounds());
auto transform = sf::Transform();
transform.rotate(getRotation());
return transform.transformRect(rect);
 

I hope someone can explain to me, how to correctly use SFML to achieve what I want, if possible. Again, as far as I understand it, I want to rotate a FloatRect around its center.

From the Docs I read this:

Since SFML doesn't provide support for oriented rectangles,
the result of this function is always an axis-aligned rectangle.
Which means that if the transform contains a rotation,
the bounding rectangle of the transformed rectangle is returned.

Not sure if there is a solution to my problem or I just have to compute bounding boxes differently somehow. But as things seem, I can't achieve what I show in my picture, is that correct?

Raincode

[Nexus]

sf::Rect<T> doesn't store a rotation, so you cannot use it for your purposes.

Checking for intersections between rotated rectangles is considerably more complicated than between axis-aligned ones. There are algorithms such as the Separate Axis Theorem that may help you.

Alternatively, you achieve the highest flexibility by using a library such as Boost.Geometry. It supports all kinds of operations between arbitrary polygons.

[Raincode]

Hi Nexus,

thankyou very much for your reply.

I have put further thought into it, and I have decided that simply using a smaller hitbox somewhere at the center would be the best solution when comparing effort and reward.

I have again included a picture demonstrating what I mean, in case anyone should be interested.

Raincode

[Nikie]

Is it possible to place the box in front of the sprite? Might be good enough and would make sense since you have rays of sorts, which are like a balls of energy with a trail (so there's no need for the trail to have collision).