ridding myself of global variables

[tks2103]

Hey everyone!

In reading a lot of the free tutorials available on OpenGL and Windows programming, I see a lot of people rely on the use of global variables. For example, check out the NeHe tutorials: http://nehe.gamedev.net/data/lessons....asp?lesson=07.

You can see that, to check for keyboard input, he has a global array of booleans called 'keys' that he uses to check when a key has been pressed. That doesn't seem a valid solution when inputs and game state variables become more complex, as they are in some of the games that I'm programming.

What's the best way to avoid implementing things like input and state variables without resorting to global declarations in C++?

I'm working with OpenGL and C++ in Windows XP if that makes any difference.

[Adrir]

Take advantage of object-orientation (within reason / performance constraints), design patterns (where appropriate) and ensure that you properly encapsulate your classes by declaring members as private.

In your example:

Usually, I simply capture the command state (keyboard, controller, instruction, etc) near the start of the update. The state is stored in some data structure in some class that the update method of the game loop can access. Read access is provided to relevent classes responsible for the update when the game is initialised. These classes may then query the command state as appropriate.

[yaustar]

The problem with the Win32 libraries is that it was designed to be used with C hence the heavy reliance of globals unless. There are ways to encapsulate all this though.

With some of the others, you just have them local and pass them to the functions that need them.

[tks2103]

Thanks for that link Yaustar, it looks like I can make a window class. Let me see if I understand it.

I guess I should write a larger game class with the game logic, state variables, etc., and I can include, as a member, that window class that I write. Then, in winmain, I can declare an instance of my game class, and use that for everything. Something like:

class Game
{
... other game state variables...
Window mywindow;
... other game classes...
};

int winmain(...)
{
Game mygame;
mygame->mywindow->makewindow
while(!mygame->mywindow->handlemessages)
{
mygame->runGame();
}
}

Is that the logic I should be using?

Thanks again guys, this is a big help...

[yaustar]

Looking at the GameDev article, it looks like the Window class should contain the game rather then the other way round as it needs to pass the messages to the game somehow. You could have them as completely separate classes and pass the instance of the game class to the windows handle function.

[forumaccount]

Step 1, make sure you understand why you're not using globals. "Gamedev.net told me globals are bad" is not a good reason, and if you're not very experienced your desire to avoid globals can lead to a mess of pointless classes.

Step 2, once you're past that... people seem to avoid globals by making everything a class, explicitly including references to every thing the class depends on, and hooking up all the references in the constructor.

I've never seen this done for a large project but I suspect that it becomes a huge pain if it's not done well. I mean... I'm just speculating here, but I assume it ends up something like this:

int main (int argc, char* argv[])
{
GameOptionDefaults god;
CommandLineOptionParser clop (argc, argv);
GameOptions go (god, clop);
MemoryManager mm (go);
GraphicsDevice gd (mm, go);
SoundDevice sd (mm, go);
InputDevice id (mm, go);
GameLogicFlow glf (mm, go);
NetworkDevice nd (mm, go);
Server server (mm, nd);
Client client (mm, nd);
Game game (mm, gd, sd, id, glf, server, client);
game.Loop ();
}

Actually that's kind of funny, maybe I'll try making a game this way.
________
AMATEUR ****

[DTR]

Don't you run a risk of stack(frame) overflow by doing that?

As far as I can see, every single object there is declared on stack.

[yaustar]

Originally Posted by DTR

Don't you run a risk of stack(frame) overflow by doing that?

As far as I can see, every single object there is declared on stack.

Depends on how big the classes are but you shouldn't unless you have a HUGE array on the stack.

[forumaccount]

Originally Posted by DTR

Don't you run a risk of stack(frame) overflow by doing that?

As far as I can see, every single object there is declared on stack.

Don't read too much in to one hastily-typed example. It depends heavily on what's inside each class and how they allocate it.
________
SUZUKI AERIO SPECIFICATIONS

[DTR]

Indeed it does.
Just worried about the collaborative effect of all the things combined.

1: The stuff we have there, however its allocated internally.
2: Possibly several threads (As those tend to cut the available stack size)
3: A carefree recursive algorithm here and there with a few thousand "rounds", each happily declaring several D3DXVECTOR3's as its helper variables in its wake.

At some point the limit will be hit.

Really depends on circumstances, but its nice to be aware of the real possibility of such scenario and its causes, should one be encountered.