This topic is 3633 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Im curious to how much overhead the GetTickCount() gives, im using it quite alot now in my code and im curious if I should put it out to a global and update it as I see fit? Stefan

##### Share on other sites
What is quite a lot and are you positive that you are calling it as rarely as possible?
GetTickCount is lighter to call (and much more inaccurate) than timeGetTime, which itself is lighter than QueryPerformanceCounter - the 3 most commonly used timers.
(RDTSC is the lightest - 1 ASM call - but cannot be trusted on DualCore's, unless you set the process' affinity mask to a single CPU, and not at all with Mobile CPU's either)

##### Share on other sites
I imagine that it would be quite fast. GetTickCount() is just a function call and a memory read, I assume.

##### Share on other sites
You really should have a central component that handles time for your application. Other components (such as physics) should simply accept a frame time parameter and not directly access the system clock.

##### Share on other sites
yes as coderx75 saiz, store the current tick/time somewhere + use that, ideally u want things to be able happen predeterminly

##### Share on other sites
Quote:
 GetTickCount() is just a function call and a memory read, I assume.

Pretty much - though the function call is indirect (DLL) and a "divide" (multiply/shift) plus synchronization are involved. Still, at about 10 clocks, it's as good as a global variable and faster even than RDTSC.

Quote:
 You really should have a central component that handles time for your application. Other components (such as physics) should simply accept a frame time parameter and not directly access the system clock.

Good advice. It's more convenient to pass around time as a double (seconds since startup), and having your own component insulates the rest of your code from changes (e.g. needing a higher-resolution timer later).

##### Share on other sites
Slightly unrelated question - In a typical game loop, is it OK to call GetTickCount()/timeGetTime()/whatever only once per-frame, or will that not be precise enough in certain situations?

I was also worried once about the overhead of GetTickCount(), so I implemented something like this:

class Timer {public:    Timer() { reset(); }    void reset() {        time = 0.0f;    }    void update(float timeDelta) {        time += timeDelta;    }    bool elapsed(float period) {        if (time > period) {            reset();            return true;        }        return false;    }private:    float time;};

Then each frame I would call update() with the time difference between frames in seconds (which I calculated once in the main loop using GetTickCount()). I suppose using this kind of timer might also help to implement a pause state for a game.

At the time it worked just fine, but I'm wondering if there are any problems with this approach in a more complicated game (I used that class in a tetris game)?

##### Share on other sites
In a more complicated game, you should get the value of GetTickCount() once per-frame, and store that somewhere. The rationale for this is that frame times can be potentially longer than the precision of GetTickCount() - which is about 15ms on modern systems.

That means, that if your game was running at 30fps, you have 33ms per frame. Because of this, GetTickCount() at the beginning of your frame will probably return a different value than if you called it at the end of the frame. Depending on how you do your timing, this can cause unwanted behaviours.

##### Share on other sites
Quote:
 Original post by Sc4FreakIn a more complicated game, you should get the value of GetTickCount() once per-frame, and store that somewhere.

Was this directed at me or at the OP, because that's exactly what I'm doing.

Quote:
 The rationale for this is that frame times can be potentially longer than the precision of GetTickCount() - which is about 15ms on modern systems.That means, that if your game was running at 30fps, you have 33ms per frame. Because of this, GetTickCount() at the beginning of your frame will probably return a different value than if you called it at the end of the frame. Depending on how you do your timing, this can cause unwanted behaviours.

I don't understand this. It sounds like you say that you should call it more than once per-frame, otherwise it might not be accurate enough. Could you please explain this a bit more?

##### Share on other sites
You generally want everything in a given frame to behave as if it happened instantaneously - so all at the same time step. Consider that a frame is basically a snapshot at a given time. If your time step is constantly changing throughout the frame then different parts of the frame will have different update times. This could cause some very odd effects (object motion may jitter as it gets updated at different times within a frame for instance). To prevent this you should calculate a frame time at the start of the frame and use that for everything in the frame.

##### Share on other sites
Jerax - Thanks, I now understand what Sc4Freak meant, but I still don't understand this part:

Quote:
 Original post by JeraxConsider that a frame is basically a snapshot at a given time. If your time step is constantly changing throughout the frame then different parts of the frame will have different update times. This could cause some very odd effects (object motion may jitter as it gets updated at different times within a frame for instance).

Could you please give a concrete example?

##### Share on other sites
Concrete example is anything that performs calculations of time between current frame and last frame.

If ball time current - ball time previous = some value, then advance ball x units.

Something that doesn`t qualify as an example would be a profiler, which performs timing of specific blocks of code.

##### Share on other sites
Quote:
Original post by Gage64
Quote:
 Original post by Sc4FreakIn a more complicated game, you should get the value of GetTickCount() once per-frame, and store that somewhere.

Was this directed at me or at the OP, because that's exactly what I'm doing.

Oh, right. I guess I should probably read the post before replying. [lol]

Quote:
Quote:
 The rationale for this is that frame times can be potentially longer than the precision of GetTickCount() - which is about 15ms on modern systems.That means, that if your game was running at 30fps, you have 33ms per frame. Because of this, GetTickCount() at the beginning of your frame will probably return a different value than if you called it at the end of the frame. Depending on how you do your timing, this can cause unwanted behaviours.

I don't understand this. It sounds like you say that you should call it more than once per-frame, otherwise it might not be accurate enough. Could you please explain this a bit more?

Often, you want everything within a frame to have the same timestamp, since a frame is supposed to represent a single "instant" in time.

It can also cause behaviour dependant on the framerate - let's say my game loop looks like the following:
1) Spawn any needed projectiles
2) Destroy all projectiles marked as "dead"
3) Execute all events on all "living" projectiles

Let's say I spawn a projectile, that has an event that tells the projectile to explode in 1 millisecond, and which has a lifetime of 1 millisecond (ie. it'll explode when it dies). If every "time" within a certain frame is the same, then the projectile will be correctly spawned, then in the next frame the projectile will explode.

But if you call GetTickCount() every time you want the time, and the frame is long (over 30 milliseconds), then you can run into problems. For example, assume that the projectile was spawned at time 0. 15 milliseconds later, you get to step 2, and find that the projectile is now older than 1 millisecond so it is destroyed in the same frame. When you get to step 3, the projectile no longer exists, and it no longer explodes.

But if you only call GetTickCount() once per frame, then every action in the frame will occur in the same "instant" of time. This is a rather contrived example, but it illustrates the problems which can occur if you have a frame which spans over a period of time, rather than representing an instant of time.

##### Share on other sites
Sc4Freak - That example was just what I needed to hear, and I now understand what you mean. I was worried that the approach I use is too "simple", but looks like it's actually the way to go.

Thanks a lot for the detailed explanation. I'm afraid I can't rate you any higher (just checked), otherwise I definitely would have.

##### Share on other sites

This topic is 3633 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628726
• Total Posts
2984410

• 25
• 11
• 10
• 16
• 14