LibKSD provides a unique feature called a decoupled game loop. Essentially, it just seperates (decouples) the AI from the drawing. At first glance, this may seem to be useless, since you will be using the same resources whether the game loop is coupled or not. What it really effects, is game scalability.In a normal coupled game loop, the AI and drawing are done in series: AI first, then drawing. All game systems have to maintain some kind timing, to prevent games that run at a normal speed on the target system, from running too fast on a more powerful system. This can be accomplished by dropping frames, or more elagantly, by adjusting the movement speed based on the difference (or delta) between the current frame and the previous one (this can easily be done using a TDeltaTimer). But this just allows keeps the more powerful machine on par with the target. Shouldn't the more powerful machine be able to render smoother graphics than the weaker? This is where the decoupled game loop comes in ...
In a decoupled game loop, the AI and drawing cycles run simultaneously. The AI loop is adjusted (via delta values) to maintain a constant movement speed across platforms. But the drawing loop is run as fast as possible. If properly tuned, the drawing loop should be able to complete one update per AI cycle on the target machine. On faster machines, it may be capable of drawing multiple frames per AI cycle. This would allow for smoother animations and more stunning graphics.
For example, imagine taking pictures of a person walking. Each step the person takes represents a cycle. If you can only take one picture each cycle, when all the pictures are lined up, the person's movement will look very choppy. But if you can take several pictures per cycle, you can see a smooth, more detailed storyboard of the movement.
Of course the game engine has to be designed specifically to run in a decoupled fashion. It requires the ability to take interim snapshots of the AI as well as have the ability to create the extra frames in between. This is very well suited to software rendered (as oppose to hardware accelerated) three-dimensional art and two-dimensional art that is rendered in real time. But it is impossible to generate inbetween frames for prerendered art, which is used in most games today.
LibKSD provides the infra-structure required to create a decoupled game-loop. Each widget has the two functions, Cycle and Draw. Cycle is meant to be used to calcuate AI (if the widget has AI! :-) and Draw to render the frames. During normal opperation (a coupled state), all the widgets cycle functions are called followed by all of the Draw functions. When in decoupled mode, a second thread is created to take over the function of calling Cycle. This decoupled mode is enabled or disabled, by calling the TApplication member function, SetDecoupled.
Alphabetic index Hierarchy of classes