Datasheet

48 SYMBIANOSGAMEBASICS
// Tick() callback method
TInt CSkeletonAppView::Tick(TAny* aCallback)
{
ASSERT(aCallback);
static_cast<CSkeletonAppView*>(aCallback)->GameLoop();
// Return a value of ETrue to continue looping
return ETrue;
}
void CSkeletonAppView::GameLoop()
{
// Update the game internals - details omitted here
}
As I mentioned above, because Symbian OS active objects cannot
be pre-empted, if another active object event is being handled when
the timer expires, the timer callback is blocked until the other event
handler completes. The timer’s event processing is delayed, and the timer
request is not rescheduled until it runs. This means that periodic timers
are susceptible to drift, and will give a frame rate slightly lower than
expected. Additionally on Symbian OS v9, the standard timer resolution
is 1/64 seconds (15.625 milliseconds) on both hardware and the emulator.
So, for example, if you request a period of 20 milliseconds, you actually
receive an event approximately once every 30 milliseconds (that is,
2 × 15.625 milliseconds). What’s more, if you’ve just missed a 1/64th
‘tick’ when you submitted the timer, then it’ll only be submitted on the
next tick, which means that the first period will be almost 3 × 15.625
(=48.875) milliseconds. This can add up to a significant jitter.
As an example, in the
Skeleton example, I set the timer period to be
1/30 second (33.3 milliseconds), which at first sight could be expected to
deliver 30 fps The frame rate actually observed was relatively constant at
22 fps occasionally dropping to 21 fps. To deliver 30 fps, I would need
to increase the period and add in logic to see how much time has passed
between each tick, and then compensate for it when rescheduling the
timer.
Symbian OS does actually provide a heartbeat timer class, called
CHeartBeat to do this. This class is similar to the periodic timer,
except that it provides a function to restore timer accuracy if it gets
out of synchronization with the system clock. The CHeartBeat class
accommodates the delay by calling separate event-handling methods
depending on whether it ran accurately, that is, on time, or whether
it was delayed, to allow it to re-synchronize. However, this additional
functionality is not usually necessary. Extremely accurate timing isn’t
generally required because a game engine only needs to know accurately
how much time has elapsed since the previous frame, so, for example,
the total amount of movement of a graphics object can be calculated.
There is also a high resolution timer available through the CTimer
class, using the HighRes() method and specifying the interval required