This post is a portion of Part 4 in my on going series about 2D Game Development using the Allegro 5 library. These posts are in course order. You can see all of the posts in this course by clicking the “2D Game Development” button at the top of this site.

• Part 4.0 – A Look at Timing
• Part 4.1 – Timing Our Game Loop
• Part 4.2 – Putting the Timing Together

An Event in Time

In the last part, we looked at the event system as a means of receiving input from the user. Events are not limited only to this function, however. By definitions, events are only that – events – and can be raised by many different objects. One such object, a timer, will fire off an event at a set interval. These intervals can be as short or long (reasonably) as you want. What that means to me as a game developer is that if I push a button that should perform an action in exactly 12 seconds (hypothetically), I can make the button push register a timer which will raise an event in exactly 12 seconds. No longer do I need to track the action of the button push to find out when 12 seconds has elapsed. I am confident that the system will let me know when the time is right.

Introducing the Game Loop

The game loop is something we used in the last part, but wasn’t really talked about. Essentially, the game loop is a command loop the repeats over and over until the game program is closed. Inside this loop is where we test for inputs, handle game logic, update the game, and then render it. A majority of the work that a game does happens inside of the game loop. Therefore, it is important to keep the loop running at peek performance to prevent unwanted lag.

Know your intervals

While the timing of single actions (such as the above button press) is a very useful ability, it pales in comparison to the true usefulness of timers: a consistent game loop. On a computer, commands are always being processed. Data is always being handled, and all of the bits and pieces are constantly whirring in sync. These actions take place even if your computer is idling. Like any system, the rate at which work is done can speed up or slow down depending on workloads and queues. Usually, this fluctuation is so small it is unnoticeable. When dealing with something intense, like a computer program, then this lag becomes quite noticeable. On top of all of this, a computer is usually capable of running most basic 2D games at thousands of cycles every second. This means that our basic games that perform updates every cycle will run so fast that they are unplayable. Even more on top of all of that, my computer might run at a different speed than yours. This will cause us to have two different experiences when playing the same game, and that’s not good.

The solution to all of that is simple. Enter the ALLEGRO_TIMER object. We can set this object up to fire off an event every 1/60 of a second (the industry standard by the way, though some action games dip as low as 1/30 of a second in order to process all of the carnage). What this allows us to do is only update and draw our content 60 times a second, or 60 “frames per second” (FPS). The rest of the time is either used to process other command or is wasted (but a good waste). Processing our game at a fixed interval like this ensures that everyone has the same experience, the game stays stable at a playable rate, and no lag is encountered. Sounds like a good deal to me.

Int he following videos, we are going to look at implementing a timed game loop using the code we saw in Part 3.