gameTime.ElapsedRealTime bug?

[Netrix]

In an XNA game, in your main constructor, add "double elapsed = 0;".

Then put "elapsed = gameTime.ElapsedRealTime.TotalSeconds;" at the beginning of your main Update(GameTime gameTime) function.

Run it, then after 30 seconds, add a breakpoint, then check the "elapsed" amount of time. It should be much higher than 30 seconds. This happens both on the Zune and Windows.

Does anyone know if this is a know problem?

[sableholic]

GameTime.ElapsedRealTime Property

It's not a bug, its just the elapsed real time since the last frame (ie the last call to draw method was made).

[Netrix]

Originally Posted by sableholic

GameTime.ElapsedRealTime Property

It's not a bug, its just the elapsed real time since the last frame (ie the last call to draw method was made).

Yes, I am very well aware of that. It is a bug. It would be correct if games run at 6.666 frames per second, but they do not.

Each time that Update() is called, on average it claims that 0.15 seconds has passed since the last frame. That means that about 6.666 frames should be displayed per second. One Zune 30, 60 frames are drawn per second.

[sableholic]

Originally Posted by Netrix

Yes, I am very well aware of that. It is a bug. It would be correct if games run at 6.666 frames per second, but they do not.

Each time that Update() is called, on average it claims that 0.15 seconds has passed since the last frame. That means that about 6.666 frames should be displayed per second. One Zune 30, 60 frames are drawn per second.

It's not a bug and you can't use that to determine the FPS. See Shawn Hargreaves comment here:
Shawn Hargreaves Blog : Displaying the framerate

> Surely 1 / gameTime.ElapsedRealTime.TotalSeconds

> will therefore give the current framerate.

That will tell you how long it was since the previous call to Update, but that is not the same thing as your framerate!

a) If the game is dropping frames, Update will be called more frequently in order to catch up. You want to time the number of actual draws that are taking place, not just these extra catch-up logic frames.

b) The time for a single Update can fluctuate widely, so the figure you get out of that will be too flickery to be easily readable.

[Netrix]

I was not using it figure out the frame rate. I know to put it in the Draw() function and not the Update() function if I want to know the frame rate.

I was using the code above to determine the amount of time that had passed. I know I could have used two variables (lastTime and currentTime), then subtract the former from the latter, but I figured that was not necessary.

The MSDN explanation says that it tells the real time since the last frame, but apparently it tells the real time since the last Update() call. So then. To correct my previous statements: Each time that Update() is called, on average it claims that 0.15 real seconds has passed since the last Update() call. That means that about 6.666 Update() calls are made per real second, unless by real time they mean something other than the actual time of which all of my clocks keep track without any problems.

Also, there is no visible lag, so obviously Update() is being called much more than it makes it seem.

[MarcusMaximus]

Originally Posted by Netrix

Also, there is no visible lag, so obviously Update() is being called much more than it makes it seem.

actually that's not necessarily true. studies have shown that a program responding in surprisingly long periods of time(on the order of 1/5 to 1/10 of a second) appears instantaneous to the users.

[Netrix]

Originally Posted by MarcusMaximus

actually that's not necessarily true. studies have shown that a program responding in surprisingly long periods of time(on the order of 1/5 to 1/10 of a second) appears instantaneous to the users.

Each time Update() is called, I have the ElapsedRealTime added to a double variable. Since it says that 0.15 seconds passes between Update() calls, that means that it thinks that about 6.66 of those Update() calls are called each second. (0.15 times 6.66 is approximately 1.0)