Messages

1

General discussions / Re: SFML Game Development -- A book on SFML

« on: April 07, 2015, 06:29:23 am »

Perhaps I could move the World member from GameState into Application, then add it to the State::Context?

What you can do however is put another object in Context, which acts as a bridge between the two states. An example is a dedicated small class that offers a method to query the player's position. World would then initialize that object (or a pointer to it).

Thanks for the suggestion. I later realized that what I'm trying to achieve almost fits an Observer or Mediator pattern:

http://sourcemaking.com/design_patterns/mediator:

...Mediator defines an object that controls how a set of objects interact..

The "small object" you suggest could be the Mediator between State objects.

http://sourcemaking.com/design_patterns/observer:

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Alternatively, the State class could inherit from an Observer interface, allowing State objects to publish and subscribe to whatever changes a state decides to publish.

In any case, you've pointed me in the right direction.

Thanks

2

General discussions / Re: SFML Game Development -- A book on SFML

« on: April 05, 2015, 02:11:16 am »

Hi, I'm working through the book, currently at Chapter 5. Up to this point in the book, the game FPS stats are implemented as members of the Application class. After working through the State and StateStack code, it occurred to me that I could make the stats into a "DebugState" object, essentially the same as the MenuState, so that display of the stats can be toggled on and off with the "D" key.

I'd also like to show the Player Aircraft's coordinates on the DebugState layer. However, after the code reorganization with the State objects, the Aircraft object is now a private member of the World object, which is in turn a member of the GameState object, and not so easy to access from another State object:

class GameState : public State
{
   ...
    private:
        World mWorld;
}

class World : public sf::NonCopyable
{
    public:
        explicit                            World(sf::RenderWindow& window);
    ...
    private:
       
        Aircraft* mPlayerAircraft; <-- need to get x,y from this member
};

class Aircraft : public Entity {...}

class Entity : public SceneNode {...}

class SceneNode
{
    public:
        sf::Vector2f getWorldPosition() const; <-- method to get x,y
}

 

Perhaps I could move the World member from GameState into Application, then add it to the State::Context? It would then be accessible to all States, in the same way as the Player object:

class Application
{
...
private:

    sf::RenderWindow        mWindow;
    TextureHolder           mTextures;
    FontHolder              mFonts;
    Player                  mPlayer;
    World                  mWorld;

    StateStack              mStateStack;
};

// Constructor
Application::Application()
    : mWindow(sf::VideoMode(640,480), "States", sf::Style::Close)
    , mTextures()
    , mFonts()
    , mPlayer()
    , mWorld(mWindow)
    , mStateStack(State::Context(mWindow, mTextures, mFonts, mPlayer, mWorld))
{
    ...
}
 

Any ideas or hints are welcome!

3

General / SFML Game Development Book - Chapter 3 - toTextureID function

« on: January 03, 2015, 10:37:19 pm »

Hi SFML book authors,

I have a question for you about the toTextureID() function on page 62: Why is it defined as a global function? Aren't globals evil? .

I can see that the function might not make sense as a member of the Aircraft class, as it's not really part of the Aircraft API, but couldn't it be a member of ResourceHolder or ResourceIdentifiers, perhaps generalized to take other Resource types? Or am I just anticipating changes to the code at later stage in the book?

BTW, as a beginner to intermediate C++ programmer, I appreciate the way you've included the new C++11 concepts. I learned C++ about 6 years ago & haven't applied it very much since then (one of the reasons I wanted to experiment with SFML). I like to learn by doing, so the book provides a good way to get some practical exposure to the new C++11 features. Every page sends me off Googling about C++!

Thanks
Philip