Game Development Reference
In-Depth Information
Screen refresh scenarios
5-6
, we see four scenarios listed on the left. To the right of each scenario are a number of
off to the right of each dot. The length of each line is shorter than the distance between each dot,
indicating that the work is done in the time between screen refreshes. The third scenario shows
the case where there is too much work to get done between screen refreshes, but the programmer
did not account for this. Each time the work exceeds the normal amount of time between screen
refreshes, the drawing of the next screen is delayed. Because the amount of time it takes to update
a game between frames varies, the rate at which the screen is refreshed becomes irregular. When
the screen refresh is irregular, the animation looks choppy and is perceived poorly by the user.
To avoid this, we configure
CADisplayLink
to only trigger an update every other frame by setting
frameInterval
to 2. This doubles the amount of time we have to get our work done, allowing for a
smooth animation.
This strategy can seem counterintuitive to some developers because, in the fourth scenario, there
can be long stretches of time when no work is being done. In fact, for a given stretch of time,
scenario 3 gets more frames rendered than scenario 4. The fact is that the choppy updates are
almost always more annoying to a user than a game that does not move as fast. Also keep in mind
that the native refresh rate for iOS devices is 60 frames a second, so if every other frame is skipped,
the animation rate is still 30 frames per second. That's plenty to create a convincing animation.
We have looked at a simple frame-by-frame animation, and you should now understand the basic
principles. The next two examples will build on this pattern to create animations with more than
one thing on the screen, as well as do a little refactoring to start making a framework suitable for
complex games.
