Sprite getLocalBounds implementation

[lid6j86]

I'm writing an entity class which very closely mirrors the sprite class (with some extras), and as I look through the source code, I have a question about getLocalBounds().

I noticed that the textureRect (which is being used as the Source Rectangle and Destination Rectangle at the Position location I'm assuming) is an intRect, which makes perfect sense.  What I don't understand is why getLocalBounds returns a FloatRect, especially considering it simply pulls the textureRect width and height and casts it from an integer to a float.

    IntRect        m_textureRect; ///< Rectangle defining the area of the source texture to display

////////////////////////////////////////////////////////////
FloatRect Sprite::getLocalBounds() const
{
    float width = static_cast<float>(std::abs(m_textureRect.width));
    float height = static_cast<float>(std::abs(m_textureRect.height));

    return FloatRect(0.f, 0.f, width, height);
}

Is it common to need the local bounds as float values instead of integer values?

[eXpl0it3r]

I'm not sure what Laurent's motivation was at the time, but from my perspective having local and global bounds returning different types would be inconsistent. From a user perspective when getting bounds you're operating within the player space/coordinate space which is built on top of floats. That the sprite internally pulls it's information from integer values shouldn't concern the user. Besides that if you'd apply a similar design for other things, where the local bounds wouldn't be pulled form integer values, you'd have to adjust the API again.

[lid6j86]

that's sort of what I was suspecting, but wanted to make sure.  Thanks for the clarification

[Nexus]

sf::Sprite is just one class that provides getLocalBounds(). Other drawable objects such as sf::Text or sf::Shape provide this method, too. The latter accesses sf::VertexArray::getBounds(), which computes the bounds from float coordinates.

[lid6j86]

I am curious about one thing, was there a particular design decision behind just making the destination size the same as the source size for sprite (i.e. simplicity, etc...) over keeping a separate source rectangle and destination rectangle (for stretching, for instance)?

Also, the reason why the texcoords are not bounded between 0-1 is because you are utilizing openGL's subimage?

Trying to get behind the 'why' so that I can understand the classes better and perhaps utilize similar logic in my own designs.  Thanks for the help and clarification

[Laurent]

was there a particular design decision behind just making the destination size the same as the source size for sprite

They are not the same. Like any other sf::Drawable, a sprite can be translated, rotated and stretched with the functions inherited from sf::Transformable. Having a destinationRect property would provide the same functionality, except less generic and more limited (ie. no rotation).

This point of view is typical from people coming from SDL 1 and more generally old graphics APIs, where sprites where just "blitted" (copied pixel per pixel) from an image buffer to the screen buffer. Nowadays, 2D graphics is similar to 3D, you have a world where entities can be transformed freely, the GPU takes care of transforming and rasterizing everything correctly.

[lid6j86]

i see, so you just implemented the functionality elsewhere while simplifying things