Game programming timers

Flipping rapidly through the pages of the flip book causes the image to appear to move. This is one of the earliest forms of animation, known originally as the kineograph. We can explore the basics of animation by having a circle move across the canvas from top to bottom. Drawing is how elements are displayed on the canvas. As you learned in the previous chapter, an element is first created and given a position, then it is added to the canvas.

Now that the ball is on the screen, we want to wait a moment, then move the ball toward the bottom of the canvas. If we moved the ball right away without waiting, then the user would only see the ball after it has been moved. This delay is essential to creating the animation effect.

We can move the ball with the move x, y method. This method will move the object x pixels in the x direction, and y pixels in the y direction. In our case, we want the ball to fall straight down, so we will have x change by 0 and y change by But how do we have the program wait before moving the ball?

And what about repeating the process? A loop won't quite work, as there's no way to have a loop pause between iterations. We'll need to use a new tool, the timer , to create our animation. Timers allow us to call a specified function repeatedly with a pause, or delay, between each function call. Timers and loops are similar in that they both repeate code, but they are actually quite different.

A loop has no sense of time or delay -- it enters the next iteration as soon as one iteration finishes. A timer calls a function at specific intervals until the programmer tells the timer to stop. The ability to call a function over and over with a pause in between is very helpful when creating animation. For example, the code above to move the ball can be placed into a draw function:.

We can then set a timer in start to call this draw function every 75 milliseconds. The full program looks like this:. This will move the position of the ball 25 pixels down every 75 milliseconds. We can track the position of the circle each tick of the timer:. Introduction to Computer Science Introduction 1.

Programming with Karel 1. Introduction to Programming with Karel 1. More Basic Karel 1. Karel Can't Turn Right 1. Functions in Karel 1. The Start Function 1. Top Down Design and Decomposition in Karel 1. Commenting Your Code 1. SuperKarel 1. For Loops 1. If Statements 1. While Loops in Karel 1.

Control Structures Example 1. How to Indent Your Code 2. Basic JavaScript and Graphics 2. Hello World 2. Variables 2. User Input 2. As for the threads, this is a completely different question. Threads are about dividing the work, and not having separate time. If you have 4 cores, one main thread calculates the new time, and then divides the objects into 4 groups and each thread can calculate changes to one group. Then they all inform the main thread they are done, and the main thread can render all the objects at once.

Notice how this way, even though 4 threads worked, they all calculated changes at the same, fixed moment in time. In a simple game I would use at least 2 timers on 2 separate threads , one for the update loop and one for the rendering loop.

If updating your entities takes a long time this won't affect the game's fps and you still can get at least 60 fps. Also, updates might not need to be processed 60 or more times per second, maybe only on user input. I don't know what's the better choice: use only one timer in the game loop to update everything in the game, or an independent timer in every object that needs one. In general, you want one time source for each batch of things that should operate on the same timeline.

Typically you'll have all your game logic objects slaved to a single time source, but you might also have a few extra timers for rendering systems -- perhaps one for the primary in-game rendering and one for interface rendering.

The reason you'd want to do this is because it allows you to implement certain behaviors very easy by simply scaling your time sources relative to real time.

If your object updates are correctly written to handle it, you can even rewind time this way. If you do that you'll want to be using a different time source for things like your HUD render effects, otherwise they would slow down or pause!

It is often useful to separate out the actual real-time clock from the presentation of the per-frame time deltas the actual time source , allowing you to drive multiple time sources off any given clock to ensure you're using a single canonical "current time" and simply scaling its delta appropriately in each source.

There are also reasons to use a separate clock entirely for things like physics, which tend to work better with fixed time steps. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Learn more. Game programming and quantity of timers Ask Question. Asked 9 years, 3 months ago. Active 9 years, 3 months ago. Viewed 2k times. Improve this question.

Add a comment. Active Oldest Votes. Reply to Krom Stern: Why threading is negligibly important in simple 2d games: Implementing threads, like any programming task is time consuming.

More so when it is dealt with for the first time as everything becomes simpler with experience. Threads are not a valuable improvement for a simple 2d-game. Such a game should preform perfectly well on a single thread: Commander Keen was one of the first platformers I played on the PC. That was 21 years ago. It is not a simple 2d-game.

According to Moore's law PCs have become approximately times faster since then. If it was possible to write a complex 2d- game back then that performs well without using threads, I do believe it is possible on a machine that is a times faster. In fact systems today are very forgiving to 'passable' and 'second-rate' 2d game code.

Look at source from LD compos where developers only have 48 hours to make a complete new game with a framework of their choice. Other examples of noteable 2d-games that performed well on old machines are: Command and Conquer and Warcraft from These are shining examples that your 20 year old PC can handle a complex 2d-game without threading.

This article about threading suggests it is mostly used to take advantage of multi-core systems and while older CPUs like my SU exist that have multi-core, they are still more than powerful enough to support a well built 2d game without threading. If you look at great 2d games like 'Castlevania: Symphony of the Night' you will see that technology did not greatly affect the quality of 2d games since It did completely revamp the looks of 3d games since Quake 1 which has little relevance here.

When I said high-end systems, I did mean modern systems in general. I corrected that now. Why not use multiple timers? Like I stated before which I think does not require any references: more objects mean more memory usage and more processing power. This should be obvious in most cases. The op did not state a valid game reason for adding multiple timers.

This suggests to me this decision may be based on reasons related to learning and practicing programming.