This was a tricky part, but since I use singletons, objects just need to get the good manager and use the good function to communicate with everything.

ie the cSoungManager::Foo() function need to output some text in the debug log (using cDebug() I forgot to mention in my previous post as the DebugManager) :

void cSoundManager::Foo(void)
{
cDebug *debug = cDebug::GetInstance();
debug->Print("pouet");
...
debug->Print("All ok !");
}

ie the cRender::Update() need to know elapsed time since last frame :

void cRender::Update(void)
{
cTimeManager *time = cTimeManager::GetInstance();
float elapsed = time->GetElapsed();
....
}

Drew, the idea about emulating the Windows Message pump is a really good one. You are on the right track with that. The one issue with having Singleton's everywhere is that you don't cut down on the amount of dependability in your system. In other words, if you're not careful, it becomes really easy to make brittle OO "spaghetti" code. It is good to think of your architecture in more of an event-driven way.

For example, let's discuss the Sims. The Sims is very event-driven (I may be off on these descriptions, it's been a while since I read the article about the AI in Sims 1). In Sims 1, a Sim was actually rather stupid. A Sim just had core needs it needed to fulfill and had no idea how to fulfill them. The objects in the world basically broadcast a message of what needs they can fulfill. So, the Sim didn't need to know anything about what objects did what in the game world. Not only did this reduce dependancies in the code, this also made the whole expansion pack mechanism possible. If a Sim had to know about all the different objects in the world (or if any object for that matter had to know about other objects in the world), the expansion pack mechanism wouldn't be very feasible because these objects would have to be updated everytime a new object was added that it needed to know about.

Anytime you can make a system event-driven, it "Is A Good Thing." Not only will your design contain less dependancies, but you will have an easier time building new features into your game. In this sense, Design Patterns are your friend, especially patterns like the Observer pattern.

Another example, if your system has a message pump and is message-driven, then to implement a replay feature, all you would feasibly have to do is record what events pass through the system when. Then, when you replay the game from a recorded file, the system simply pumps the recorded messages into the message pump, and the rest of your game doesn't know the difference :D.

I too am quite interested in the idea of emulating the windows message pump. Any any where I might find some info on how to go about this?
Cheers

What you want is a subscriber/publisher system, where objects can "subscribe" to receive events from certain "publishers" that send events. So an object might subscribe to your input system to receive key_down events, and any time a key is pressed, your object gets an event with the key code included. Or the object might subscribe to collision events, state change events, etc.

The following link might help you get started, and although it's Java oriented, it can be accomplished in C++ (or whatever language you like) just as well.
http://www.javaworld.com/javaworld/jw-03-2003/jw-0328-designpatterns.html