class Screen
{
public:
Blit(blah);
};
class World
{
public:
drawWorld();
};
class Game
{
private:
Screen screen;
World world;
}
class heirarchy structure
Author
If I have a class called Game, and it has private members called Screen and World, like so:
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?
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) { ... }};
Author
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?
No, you have just one defined in some .cc file. In the Screen.h you might append:
Don't expect any order of global constructors.
...extern Screen screen;Don't expect any order of global constructors.
Author
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.
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.
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.
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. ;)
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. ;)
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 ...
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 ...
Author
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
