I've made a simple 2D game engine using C# and DirectX and it's fully functional for the demo I made to test it. I have a Timer object that uses QueryPerformanceCounter and 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.

My worry is that when I try to implement threads, what will happen with timers? What happens with the sync?


4 Answers 4


Original answer:

Why would you implement threads? Unless they are used to resolve a performance problem, they are a waste of time you can invest in your next game project. If the game is not processor heavy I am not sure threads are a valuable improvement. They mostly affect systems powerful enough to handle the game without threads in the first place.

To answer your question: I believe there is no advantage in using multiple timers. One timer saves on memory and processing time. As far as I know, one time can be used with multiple threads. That is an issue that could be resolved in another question if you encounter a problem with threads & timers.

Reply to Krom Stern:

Why threading is negligibly important in simple 2d games:

  1. 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.
  2. Threads are not a valuable improvement for a simple 2d-game. Such a game should preform perfectly well on a single thread:
    1. 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 1000 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 1000 times faster.
    2. 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. 3.Other examples of noteable 2d-games that performed well on old machines are: Command and Conquer and Warcraft from 1995. These are shining examples that your 20 year old PC can handle a complex 2d-game without threading.
  3. This article about threading suggests it is mostly used to take advantage of multi-core systems and while older CPUs like my SU4100 exist that have multi-core, they are still more than powerful enough to support a well built 2d game without threading.
  4. 2d-Games have matured 15 years ago. 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 1997. It did completely revamp the looks of 3d games since Quake(1) which has little relevance here.
  5. When I said high-end systems, I did mean modern systems in general. I corrected that now.

Why not use multiple timers?

  1. 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.
  2. 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. This is a bad idea from game design perspective. When you are working on a game, you need to invest your time wisely. Games require a lot of work. If you happen to find a way to produce games quickly. Make more games! Instead of worrying about programming practices. Unless there is a serious problem you're facing with the current architecture, continue concentrating your effort on developing a great game. That is a difference between a game developer and a CS student.
  3. OP also did not suggest a bottleneck exists in the game that will be resolved by threading. This also hints to the possibility that threading was not used to alleviate some game performance issues. If such issues existed, game code should be looked at as there aren't any good reasons a simple 2d-game should have performance issues on a modern machine.

I hope that helps clarify why I feel that threads are not necessary and why additional timers should not be the main point of interest in the development of a simple 2d game.

  • \$\begingroup\$ @KromStern Hope this helps clear things up \$\endgroup\$
    – AturSams
    Commented Oct 14, 2012 at 18:30

It is absolutely critical to use a single timer! If you query for time for every object, that means a scene will be filled with many objects whose position is calculated at different time. You need to think about a single frame as an image of all objects, all frozen at a particular moment in time.

For more advanced physics or action simulation, you might go to two timers, one timer that changes e.g. 10 times per second and all actions are calculated relative to this one. And a second timer that is actually not independent, but is interpolated from the first one, so that you can get several frames in between the two physics updates.

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.

  • 1
    \$\begingroup\$ hmm.. if the game view did not change, why render again? Updating entities is what makes rendering a new frame different from leaving the current frame on screen. \$\endgroup\$
    – AturSams
    Commented Oct 13, 2012 at 18:55
  • \$\begingroup\$ GUI timer might be of use if there are game unrelated animations on controls (flashing buttons, etc.) \$\endgroup\$
    – Kromster
    Commented Oct 14, 2012 at 5:42
  • \$\begingroup\$ Updating entities and updating the screen are 2 different things. Updating your entities is something you might want to do more often. Besides most (non html) games have a constantly chaning view so need to be rendered often \$\endgroup\$
    – Thomas
    Commented Oct 14, 2012 at 20:19

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.

A single timer is a viable option in many cases, but while one-time-per-object might be a bit overkill, there are good reasons to have multiple timers and/or time sources.

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. For example, you can implement game logic pausing by forcing the per-frame delta time returned from that time source to be to zero, or you can implement a "slowdown" effect by scaling that delta time by some factor, such as 50%. 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!) when the game logic did, which would likely render them unusable.

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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .