Messages

76

Graphics / RenderTarget::ConvertCoords backwards

« on: September 25, 2011, 01:19:05 am »

I wanted to draw some text in RenderWindow that would be positioned near a sprite, like a label or tag always moving along with the sprite, attached to some point of it and not rotating or scaling regardless of sprite's transformations. And I was really surprised to not find a complementary function to ConvertCoords, that would convert world coordinates to screen coordinates. I believe this to be a frequently occuring task and i guess it is only reasonable to add such functionality to RenderTarget


The ConvertCoords(x, y, view = NULL) function takes x and y global coordinates and transforms them into view coordinates given the current view attached to the render window.

I think the functionality you wanted was to get the sprite's coordinates in terms of where it will be drawn on the screen. It wouldn't make much sense to have a function for sprite saying Sprite::ConvertCoords(view), meaning, you pass in a view and get it's coordinates out in terms of the view. (You could call it, GetPositionInView or something.

What you really want to do is

Code: [Select]


Window.ConvertCoords(Sprite.GetX(), Sprite.GetY());


as the window will have the view already attached to it.

77

Graphics / Inherit from sf::Sprite

« on: September 25, 2011, 01:04:02 am »

I notice that sf::Sprite does not have a virtual destructor.

In Effective C++, it mentions that if a class does not have a virtual destructor, then it is not intended as a base class for polymorphism because you can get weird partially destructed objects. For example, I have been using sf::Sprite as a base class for a simple class for a ball in a pong game.

Code: [Select]

class Ball : public Sprite {

};

But then if you have something like this,

Code: [Select]

sf::Sprite * Ball = new Ball();

delete Ball;

then only the destructor for the sf::Sprite class will be called and not the destructor for the Ball class.

This has prompted me to consider including a sf::Sprite as a member of the Ball class.

Code: [Select]

class Ball {
sf::Sprite sprite;

};

This works fine, but leads to some verbose syntax such as

Code: [Select]

Ball.GetSprite().GetSubrect().x;

to simply access the width of the ball.

The other problem is, if you wanted to extend the sf::Sprite class to, say, an AnimatedSprite class, it would only make sense to inherit from sf::Sprite

Code: [Select]

class AnimatedSprite : public Sprite {

};

What can I make of this?