I have this frame-based counter I use instead of the timer-class because everything in my game is frame-based. This counter ensures that everything runs fine even when used on old computers.
I would like to know if it makes sense to create a tenth-second-frame-based-counter (or even a twentieth-second-frame-based counter). Basically it would be nearly the same counter like the one below except for the fact that the framesPerSecond-variable is divided by 10 or 20 and instead of using seconds I use tenthsesonds or twentiethseconds.
Is that a good or bad idea? Is there basically a difference between frame-based counters and timers when used on old computers?
I’m not sure about this topic therefore I ask.
{
import flash.events.*;
public class BasicFrameTimer extends EventDispatcher
{
public static const TIME_IS_UP:String = "timesup";
public var countUp:Boolean = false;
public var min:int = 0;
public var max:int;
public var maxSet:Boolean = false;
public var seconds:int;
private var frameCount:int;
public var started:Boolean = false;
private var framesPerSecond:int;
public function BasicFrameTimer(framesPerSecond:int) {
this.framesPerSecond = framesPerSecond;
}
public function start():void {
frameCount = 0;
started = true;
}
public function stop():void {
started = false;
}
public function reset():void {
if (countUp) {
seconds = 0;
} else {
seconds = max;
}
}
public function update():void {
if (started) {
frameCount++;
if (frameCount > (framesPerSecond)) {
frameCount = 0;
if (countUp) {
seconds++;
if (maxSet == true && seconds == max) {
stop();
dispatchEvent(new Event(TIME_IS_UP));
}
} else {
seconds--;
if (seconds == min) {
stop();
dispatchEvent(new Event(TIME_IS_UP));
}
}
}
}
}
}
}
There is a difference between a
Timerand using aframe eventwith implications for how the stage is updated, not just on old computers.You can set the suggested frames-per-second settings as part of the
.flafile, and the compiled.swfwill do its best to keep up with the suggested setting. If it can’t, it starts skipping frames to keep up.If you’ve defined some interactions, such as an animation, to happen on frame events, or via a frame counter, they will execute with the frames, meaning that a higher fps will cause a faster animation. If, instead, the animation relies on a timer, they will execute along with the timer.
Executing with a timer will preserve real-time interactions at the cost of some choppiness for animations. A good way to test that you’ve correctly implemented a timer for an update cycle is to bump the fps down to
1or2and see if the animation completes within the same amount of time (±1s).As you’ve tagged game-development, I’d recommend using a combination.
A cycle using
Timershould be used to check input, load resources and check game state (input,load,update)A cycle using
ENTER_FRAMEshould be used to modify drawable assets (render)A cycle using
EXIT_FRAMEshould be used to unload resources (unload);The reason for the combination is that you’ll be able to perform the simple calculations on a regular time interval, but you wont waste time with any rendering-specific logic until rendering is actually necessary. Additionally, it will allow your time-critical assets to stay in sync even on slow machines.