309A particular game’s frame listener implementation might look something like
this.
classGameFrameListener : public Ogre::FrameListener
{
public:
virtual void frameStarted(const FrameEvent& event)
{
// Do things that must happen before the 3D scene
// is rendered (i.e., service all game engine
// subsystems).
pollJoypad(event);
updatePlayerControls(event);
updateDynamicsSimulation(event);
resolveCollisions(event);
updateCamera(event);
// etc.
}virtual void frameEnded(const FrameEvent& event)
{
// Do things that must happen after the 3D scene
// has been rendered.
drawHud(event);// etc.
}
};7.3.3. Event-Based Updating
In games, an event is any interesting change in the state of the game or its
environment. Some examples include: the human player pressing a butt on
on the joypad, an explosion going off , an enemy character spott ing the player,
and the list goes on. Most game engines have an event system, which permits
various engine subsystems to register interest in particular kinds of events
and to respond to those events when they occur (see Section 14.7 for details).
A game’s event system is usually very similar to the event/messaging system
underlying virtually all graphical user interfaces (for example, Microsoft Win-
dows’ window messages, the event handling system in Java’s AWT, or the
services provided by C#’s delegate and event keywords).
Some game engines leverage their event system in order to implement
the periodic servicing of some or all of their subsystems. For this to work, the
event system must permit events to be posted into the future—that is, to be
queued for later delivery. A game engine can then implement periodic updat-
7.3. Game Loop Architectural Styles