CODEWITHSUNDEEP
c++graphicssfml
Kvothe
Kvothe

Reputation: 1837

Passing control of a drawing window "deeper" into a program?

I am using SFML 2.3 to control the graphics in my program. I need a class to be able to access the window, to draw to it even if that class was not the one that originally created the window (does not have ownership). E.g. the Battle class needs to be able to draw the battle scene and manipulate characters there but the World class would need the window before and after Battle to show the player's movements in the main game.

How should the window object be handled? My initial thought is to have a GameMaster class that has the window as a static member. But rather than blunder along with this method I thought it better to check what the usual consensus was.

I realise I could always pass a reference to the window to each class that needs it but this would make the constructors for all the classes that need to manipulate the window quite bloated.

Upvotes: 5

Views: 100

Answers (2)

πάντα ῥεῖ
πάντα ῥεῖ

Reputation: 1

I'm afraid you have to decide to do a choice between using a Singleton (GameMaster) that allows access to the main window, or pass a reference to it with your dependent class objects.

I personally would prefer the latter (I won't consider adding another constructor parameter to a couple of classes as bloat), because the overall flexibility of the class design would be better than using a Singleton.

You may consider, to outsource your World class assembly code to a separate Factory class. This one could hold the necessary main window object as a member and pass it to all of the created World, Battle, etc. instances necessary to assemble the World, initiate the game mission respectively.

Upvotes: 6

Syntactic Fructose
Syntactic Fructose

Reputation: 20084

I had a similar design issue during my first application, here is how I set my program up:

App.hpp

class App{
    public:
    // Constructor simply creates main window, specify context settings
    // and set position of main window to center of screen
    App(sf::VideoMode mode);
    ~App();

    // init functions for setting up windows / graphics beforehand

    // The main loop of the program, while active, run calculates the delta time
    // for game movement, handles window events for both the console and window,
    void run();

    private:
        sf::Window d_main_window; // main window for program.
        // other data ...
        // bool for main loop , etc.. etc..
};

App is the window handling class, and contains any functions that are used to initialize any graphics (openGL) or set up the program so it can be ready to run. Then the main loop is started with app.run()

ParticleContainer.hpp

class ParticleContainer {
    public:
        ParticleContainer(/* params */);
        ~ParticleContainer

        // object specific functions

        drawParticles();

    private:
        sf::Window *d_parent_window;  // window is passed into the constr
                                      // now we can draw from inside particle
        // additional params
        // vec of all particle objects
};

The particle container object contains a pointer to the parent window, so it can draw particles to the screen. This design would allow you to create discrete objects that had the ability to draw itself to the screen, taking away the problem of some cluttered draw class. if you create a new object, all you need to do it pass the parent window pointer in giving it the ability to draw itself.

Upvotes: 3

Related Questions