ElapsedRealTime and TotalRealTime in XNA Game Studio 4.0

ElapsedRealTime and TotalRealTime in XNA Game Studio 4.0

  • Comments 21

I often refer back to internal design documents and bug databases while writing these "what's new" blog posts, but it rarely makes sense to quote directly from them. In this case, though, the existing text seems clear enough that I shall simply plagiarize it.

It all started when I filed this bug:

The RealTime members of the GameTime class are confusing and not really useful for anything. Since developers are always better off using the *GameTime members, maybe we should remove *RealTime entirely to avoid confusion?

Because this alters an API that we already shipped, it had to go through a formal DCR ("Design Change Request") process, to make sure the implications were properly understood, and to give the stakeholders a chance to approve or veto the change. Here is the more detailed text I wrote up to explain the DCR:

The GameTime class currently exposes four properties:

  • TimeSpan ElapsedGameTime;
  • TimeSpan TotalGameTime;
  • TimeSpan ElapsedRealTime;
  • TimeSpan TotalRealTime;

This DCR proposes removing the two *RealTime properties, and also changing the two GameTime constructors to remove the associated *RealTime parameters.

These properties were intended to provide a more direct connection to wall clock time, bypassing the smarter logic used to compute the *GameTime values. However, experience has shown that:

  1. 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.

  2. For the (vanishingly rare) handful of cases where people really do need this data, they can get it just as easily from any of the other .NET timer APIs (Stopwatch, Environment.TickCount, DateTime.Now, etc). There is no need for us to provide an alternative way of accessing that same data.

  3. Putting this data in our GameTime class is confusing for our customers. We frequently see people not knowing which version of the data to pick, erroneously guessing they want the *RealTime values, and then running into trouble because this does not actually do what they want.

  4. The ElapsedRealTime value is especially confusing, as it is not at all well defined what this means (or should mean) during a Draw method. Since RealTime does not have the same tick concept as GameTime, what should this value be relative to? Our current implementation arbitrarily picks one definition, but this is not really useful for anything.

Dev cost: 2 hours.

The DCR was approved, so ElapsedRealTime and TotalRealTime are gone from Game Studio 4.0.

  • Just out of curiosity - is 2h minimal dev cost, or was it really so much work?

    I mean this looks like only few places to remove (which would look like 30min, no dependent behaviour to alter?)

    Anyway seems reasonable.

  • I've not had a chance to play with XNA GS 4.0 yet as we're still in the 'asset production' stage for our next title, but it's great to see that 'streamlining' and 'making it more accessible' was also a part of the team's priorities (it's easy to forget about these things when adding new features).

    I know the time for this discussion has already passed, but I did find it useful differentiating between GameTime and RealTime when making Ikaroids. We implemented a 'time-dilation' system where the player could speed up / slow down game time with certain abilities. It was easy to implement this by modifying the GameTime variable each frame. We then used the real time variables keep the interface animated at a fixed pace (especially useful is using 'TotalRealTime' in generating a 't' for sinusoidal blinking functions for interface elements).

    Obviously, we're only talking an hour or two to implement an alternative system, but I just wanted to stick my oar in to defend the presence of the RealTime values!

  • Hmmm, 2 hours seems rather low when you consider all the additional time needed to do things like update unit tests, samples, documentation, simple sanity tests that it works on each platform etc etc.

    Though I guess it depends how the XNA team divide work up...

  • I questioned the same thing when I originally moved from MDX to XNA and seen those propertys. Thanks remove away :]

  • Interesting comment conflict here!

    w says:

    > Just out of curiosity - is 2h minimal dev cost, or was it really so much work? I mean this looks like only few places to remove (which would look like 30min, no dependent behaviour to alter?)

    But David Black says:

    > Hmmm, 2 hours seems rather low when you consider all the additional time needed to do things like update unit tests, samples, documentation, simple sanity tests that it works on each platform etc etc.

    That 2 hour estimate was purely dev cost: there was also a doc cost and test cost to be considered. Those were also very low, though: in the order of a couple hours each.

    The dev work breakdown probably went something like:

    Remove these properties: 5 mins

    Update affected unit tests: 5 mins

    Check that no samples are affected by this change: 5 mins

    Rebuild entire product across all platforms: 1 hour

    Run automated test pass: 20 mins

    Get code review for these changes: 10 mins

    Enjoy a well earned cup of tea: 15 mins

    The doc work was roughly similar - removing things is generally much quicker and easier to verify than adding new stuff!

    Note that hour waiting for the product to build: that part is where I usually find time to post on the forums, write blog articles, etc :-)

  • Thank you! These have always seemed to be extra and unnecessary properties to me. I figured they had some far edge use, but more often than not saw them confusing new developers.

  • Thats quite an interesting example of development time breakdown for XNA.

    Also you seem to assume everything goes OK and you dont need to fix anything. Which I guess isnt such an issue for something this simple, at least for fixing internal stuff.

    Also I guess MS has a very well equipped test department who can put things through a lot of intense testing.

    (I would have run some functional tests as well, especially if I suspected certain platforms needed it).

  • > Thats quite an interesting example of development time breakdown for XNA.

    This is very much a corner case example, since the change was so trivial and low risk. Removing a property that nobody uses is easy to verify: you just compile all the test code, get compile errors from the handful of tests that used to verify this property, delete those tests since they are no longer needed, and then everything "just works".

    It's obviously way more complex if we change functionality rather than just removing (as tests then need to be reviewed and updated to match the new behavior) or when we add new stuff (in which case new tests need to be written, corner cases analyzed, etc).

    Also, such a small change ends up with a much higher proportion of the time spent on overhead tasks (building, running tests) rather than actually coding.

    For adding a new feature (eg. state objects) the breakdown is typically more like:

    API design/review: 2 days

    C# API implementation: 1 day

    Windows C++/CLI implementation: 0.5 day

    Xbox C++ interop code: 0.5 day

    Windows Phone C++ interop code: 0.5 day

    Write new tests: 1 day

    Update existing tests that were broken by this change: 0.5 day

    Rebuild product: 1 hour

    Run automated test pass: 20 mins

    while (test pass failed)

    {

      Fix problems: anywhere from 5 minutes upward

      Rebuild product: 1 hour

      Run automated test pass: 20 mins

      if (iteration count > 10)

      {

          Phone girlfriend: "will be late for dinner"

      }

    }

    Code review: 1 hour

    Check in!

  • Shawn, one thing I did want to comment on is your first assumption. You said:

    "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.

  • Hi , Shawn

    Please give us back , tom millier's Managed Directx 2 Version of timers and let people do the timing them self,,

    is can easy hook up with windows , and xbox360 proformance counters , and the phone as well

    Best regards

    Michael Hansen

  • Sorry , i fogot somthing

    remove the gameclock and gametime from the game.dll and put it a seprate dll or include in the xna.framework.dll

  • Sorry again ,,

    Make the new timer class static , so we can acess the timer every where , as well the content manager and the graphics device

    all has to be static class or acess point

    no more pass a void(GameTime gametime)

    wicth is verry slow compare the the static method

  • > Please give us back , tom millier's Managed Directx 2 Version of timers and let people do the timing them self

    You are more than welcome to do timing yourself if you prefer that. The GameTime class provided by XNA is 100% optional.

  • >Make the new timer class static , so we can >acess the timer every where , as well the >content manager and the graphics device

    >

    >all has to be static class or acess point

    >

    >no more pass a void(GameTime gametime)

    >

    >wicth is verry slow compare the the static method

    What about unit tests for your code? If you pass gametime around, you may call Update(gameTime) functions in your test with prepared gameTime structure, without relying on some global static object. Though now when I'm thinking about it, I'm not sure if GameTime has public constructor...

  • Sorry for spam, no idea why I thought it doesn't have constructor, must have been other class I've been thinking of.

Page 1 of 2 (21 items) 12
Leave a Comment
  • Please add 2 and 5 and type the answer here:
  • Post