During my previous post I made the observation that the ElapsedRealTime and TotalRealTime methods were noticeably absent from the GameTime object which is provided to the Update and Draw methods. In my post I said this was presumably because the difference between game time and real time was confusing to developers. And given that there are alternate methods to obtain wall-clock time, they probably just disposed of it.
It turns out...I was spot on! About four hours after I posted my tutorial, Shawn Hargreaves, one of the XNA developers, posted to Shawn Hargreaves' Blog precisely that. In specific, he provided four reasons for why it was removed.
- "The data was rarely used..."
- "For the ... handful of cases people need this data they can get it from any other .NET timer..."
- "... is confusing for our customers"
- ElapsedRealTime is not well defined within the Draw method.
One thing I did want to comment on though is his first assumption. Shawn said:
"This data is rarely useful. Most often, people who think they need it would really be better off just setting their game to variable timestep mode, in which case *GameTime and *RealTime collapse and become the same thing."
This isn't entirely true. In a variable timestep game, the API makes no effort to throttle or stabilize the execution of the main game loop, so there's no sleeping and no iterative calls to Update in order to maintain a steady interval. However, there's still a subtle difference between Game Time and Wall-Clock Time. In specific, game time represents the amount of time spent processing the application logic, while wall-clock time represents the actual amount of elapsed time. On the Zune, Xbox 360, and WinPhone these are likely going to be the same thing most of the time. However on the PC (and at certain points on other platforms) the application is forced to block processing. A common example is when running on the PC in windowed mode. If you grab the window frame the message pump halts, waiting for the user to release the window. During this time the entire application is blocked, so it performs no processing. Consequently, game time never advances. You can hold the window for 30 minutes, whether in fixed-step or variable-step, either way time won't advance 1 millisecond until you release the window. However, wall-clock time would have still advanced 30 minutes.
With all that said, aside from network play, it's generally acceptable for game-play to pause while moving the window. I'm not yet familiar enough with network programming to be able to say with any certainty how this will effect multiplayer games.