Jump to content
  • Advertisement
Sign in to follow this  
squicklid

class heirarchy structure

This topic is 5041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If I have a class called Game, and it has private members called Screen and World, like so:
class Screen
{
public:
    Blit(blah);
};

class World
{
public:
    drawWorld();
};

class Game
{
private:
    Screen screen;
    World world;
}

How can I use the Blit function in Screen, from the World Class? I could obviously change both screen and world to be global, but is this desireable?

Share this post


Link to post
Share on other sites
Advertisement
World must know about Screen, either by having a global instance of Screen (there is just one ?) or by giving a reference to World during construction.


Version 1:
Screen screen;

Version 2:
class World
{
Screen& screen;
public:
World(Screen& screen) : screen(screen) { ... }
};

Share this post


Link to post
Share on other sites
Okay, so are you saying that I need to have an instance of Screen in every portion of the game, such as World, Town, Battle....etc?

Share this post


Link to post
Share on other sites
No, you have just one defined in some .cc file. In the Screen.h you might append:


...
extern Screen screen;


Don't expect any order of global constructors.

Share this post


Link to post
Share on other sites
oh ok sounds good. I was orignally thinking of using a pointer, but i guess the reference variable is pretty much the same thing but without all the ->'s.

Share this post


Link to post
Share on other sites
Yes, the compiler internally handles it like a pointer, but a reference is more efficient (no checks for NULL when casting for example).

The global Screen object has the advantage that the reference can be resolved at compile time resulting in code without indirection.
The disadvantage is some kind of inflexibility, e.g. if you plan to have more than one screen.

Share this post


Link to post
Share on other sites
Aye, what if World had a member such as:

Screen * ptrDisplay;

That you could fill with a pointer to the screen?

for instance, in the constructor for the Game object...

Game()
{
screen.init(); // or Whatever initializes the screen
world.ptrDisplay = &screen;
}

And then, in drawWorld:

drawWorld()
{
// whatever you need to do to get it ready to blit
this->ptrDisplay->blit(Whatever needs blittin');
}

Would that help?

EDIT: Aye, a reference would work as well. I'm not quite sure why I always feel the need to use pointers instead... call me old fashioned. ;) Or stupid. ;)

Share this post


Link to post
Share on other sites
a singleton-like setup might work for you. What I mean by that is, don't make your screen a singleton class, because it may make a lot of sense down the line to be able to have multiple screens at the same time and all of that kinda stuff ... but create another class, something like ScreenManager or something, that simply provides the "global access" part of the singleton puzzle.

So you have a Screen class which supports whatever functions a screen supports.

And you have a World class, which supports managing all the things a world manages. And also has a function to draw the world onto a screen.

Then, for now, you simply a a very small ScreenManager class, which (in the first version) simple provides 2 functions: GetCurrentScreen(), and SetCurrentScreen() - and internally stores a pointer to a screen object.

Then your main creates the screen at app start time, sets it as the current screen, and deletes it at app cleanup time.

Then your World class simply uses GetCurrentScreen() whenever it needs a screen.

...

Later, when you want to have multiple different views of the same world, or multiple worlds or screens, you refactor a little bit of your code, for instance you can make drawWorld take the Screen it draws on as a parameter ... then your main or game can simple pass the current screen when it calls drawWorld. Another option would be to have a WorldView class, which has the logic for drawing a view on the screen, and has a pointer to a screen, and a pointer to a world ... then when you call Draw() on the WorldView object, it calls view.drawWorld(screen); or something like that ...

Share this post


Link to post
Share on other sites
Whoa, that was an intense description. But I think I understood it. I think I'm still gonna go with the reference object however. Because, I am only making a smalltime programming-practice game. But thanks anyway.

Share this post


Link to post
Share on other sites
no prob, always do what you understand ... and make it bigger later - IF you ever need to :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!