789// Finally, start blending all currently-playing
// animations (including any new clips started
// earlier this frame).
g_animationEngine. StartAnimationBlending();// ...
}14.7.10. Some Problems with Immediate Event Sending
Not queuing events also has its share of issues. For example, immediate event
handling can lead to extremely deep call stacks. Object A might send object B
an event, and in its event handler, B might send another event, which might
send another event, and another, and so on. In a game engine that supports
immediate event handling, it’s not uncommon to see a call stack that looks
something like this:
...
ShoulderAngel::OnEvent()
Event::Send()
Characer::OnEvent()
Event::Send()
Car::OnEvent()
Event::Send()
HandleSoundEffect()
AnimationEngine::PlayAnimation()
Event::Send()
Character::OnEvent()
Event::Send()
Character::OnEvent()
Event::Send()
Character::OnEvent()
Event::Send()
Car::OnEvent()
Event::Send()
Car::OnEvent()
Event::Send()
Car::Update()
GameWorld::UpdateObjectsInBucket()
Engine::GameLoop()
main()A deep call stack like this can exhaust available stack space in extreme
cases (especially if we have an infi nite loop of event sending), but the real
crux of the problem here is that every event handler function must be writt en
to be fully re-entrant. This means that the event handler can be called recur-
sively without any ill side-eff ects. As a contrived example, imagine a function
14.7. Events and Message-Passing