5
\$\begingroup\$

I have set-up an empty test project consisting of a System.Diagnostics.Stopwatch and this in the draw method:

spriteBatch.DrawString(font, gameTime.TotalGameTime.TotalSeconds.ToString(), new Vector2(100, 100), Color.White); spriteBatch.DrawString(font, stopwatch.Elapsed.TotalSeconds.ToString(), new Vector2(100, 200), Color.White);

The GameTime.TotalGameTime displayed is slower than the stop watch (by about 5 seconds per minute) even though GameTime.IsRunningSlowly is always false, why is this?

The reason this is an issue is because I have a server which uses stopwatch and it is faster than my client game. For instance my client notifies the server it has dropped a mine which explodes in one minute. Because the stopwatch is faster the server state explodes the mine before the client and they are out of sync. I don't want to have to notify the client when the server explodes it as this would use unnecessary bandwidth.

\$\endgroup\$
3
  • \$\begingroup\$ And you're sure the stopwatch isn't IsRunningFast? Which one is running on real time? Why aren't you using the same time keeping methods in both places? \$\endgroup\$ Commented Oct 8, 2012 at 13:45
  • \$\begingroup\$ I can't find a property of stopwatch that is IsRunningFast? It is the stopwatch that appears to be real time and the GameTime is slower than real time. The reason I'm not using the same method in the game and on the server is because I thought that the GameTime was essentially the real time? If I use a stopwatch on the client as well - would the stop watch count the same time regardless of performance on different machines? IE: would 3 different players on different spec machines all match the server stop watch? \$\endgroup\$ Commented Oct 8, 2012 at 14:26
  • 1
    \$\begingroup\$ Sorry, that was a joke. I don't use XNA so I'm not sure what's happening. I would just use one time library for the whole set up. Additionally, notifying the client when the mine explodes is unlikely to put heavy strain on your bandwidth. Don't prematurely optimize. You're not going to be able to count on the timers running independently to be exactly synced in any case. \$\endgroup\$ Commented Oct 8, 2012 at 14:30

1 Answer 1

Reset to default
7
\$\begingroup\$

The answer is in the MSDN entry for GameTime http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gametime.totalgametime.aspx

Fixed-step clocks update by a fixed time span upon every clock step. This results in uniform clock steps that may not actually track the wall clock time. Fixed step clocks were popular on console systems where one had tight control over code and a fixed system performance. Fixed-step clocks are also useful when trying to achieve deterministic updates for debugging, offline rendering, or other such scenarios.

So basically game time != real time

The solution to your problem is to not have the server tell that a mine was placed and that it will explode in one minute, but to have the server first tell that a mine was placed and then after a minute have it tell that the mine exploded. This will roughly make all clients run at the same speed. (However to really do this right you should run in lockstep.) As usual with these kind of questions I refer you to the excellent Gaffer on Games article 'fix your timestep'. You might also want to take a peak at this article since it talks about synchronizing time dependent state via the server (it doesn't apply to just physics)

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.