Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - sbroadfoot90

Pages: [1]
1
General / FindSFML.cmake - broken on OS X
« on: November 18, 2011, 08:43:52 am »
@Laurent @Hiura,

the FindSFML.cmake doesn't work very well for OS X. It basically sets

SFML_INCLUDE_DIR to /Library/Frameworks/SFML.framework

and

SFML_LIBRARIES isn't set to anything.

I have a feeling SFML_INCLUDE_DIR should be set to /Library/Frameworks/SFML.framework/Headers, and SFML_LIBRARIES definitely shouldn't be blank.

2
General / Xcode 4 accessing resource path
« on: October 07, 2011, 01:28:15 pm »
Laurent, this is more a direct message to you, but also a pointer for anyone wondering.

I spent about 2 hours trying to work out an elegant way of accessing the Resources directory when building an app with Xcode 4, only to realise Laurent had already included this helper function in the Xcode 4 templates.

So anyone who comes across the same problem you just need to

Code: [Select]
#include "ResourcePath.hpp"

and then you can load images etc like so

Code: [Select]
Texture.LoadFromFile(ResourcePath() + "Background.png")

By the way Laurent, your helper function is much more elegant than Ogre3D's version of the same thing

3
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?

Pages: [1]