This project is read-only.

Operations

Because of the fine-grained nature of the system, it is important to ensure all the little bits of (enabled) update logic gets executed every cycle.
However, there are operations (e.g. activate a new Master Layer as a modal dialog) that if executed inline with the call, would horribly disturb this guarantee. In the mentioned case, a new Input Manager would be pushed, and a bunch of new packages would be added to the system and start executing (on the next update) before you have a chance to perform any other bookkeeping. This may sound like overkill, but there can be much worse.
The system is guaranteeing it won't do this to you, so you can maintain a consistent update state every cycle.
To facilitate this, the operations are queued for execution after all update packages have executed. This ensures a consistent state when the operation takes place.
All pending operations are executed before the update cycle ends; this includes operations that can "spawn" additional operations.
This infrastructure is also available to you. A good example of when to use this is when "firing" events that are triggered during the update cycle. This allows delegates attached to the event to have a consistent state (i.e. all enabled Update Packages have executed) when they are executed.

Last edited Jul 7, 2008 at 6:11 PM by escapellc, version 1

Comments

No comments yet.