Hi,

i've done a simple test which tells me that the IsFixedTimeStep = true causes jittering. Firstly I could not figure what caused the jittering, but setting IsFixedTimeStep = false made the game run smoothly.

I don't understand this. I've read the Shawn's article: http://blogs.msdn.com/shawnhar/archive/2007/11/23/game-timing-in-xna-game-studio-2-0.aspx which tells that when the timestep is true, Update is called as many times as needed to catch up to the current time

How did i do this:

I downloaded the sample "How To: Render a Model" from http://msdn2.microsoft.com/en-us/library/bb203933.aspx

i modified the update method to respect the total game time to be accurate

        protected override void Update(GameTime gameTime)
        {
            RotationX = 30; 
            RotationY = (float)(gameTime.TotalGameTime.TotalMilliseconds / 10);

            gameWorldRotation = Matrix.CreateRotationX(MathHelper.ToRadians(RotationX)) * Matrix.CreateRotationY(MathHelper.ToRadians(RotationY));

            base.Update(gameTime);
        }

        protected override void Update(GameTime gameTime)
        {
            RotationX = 30; 
            if (IsFixedTimeStep)
            {
                RotationY += 2;
            }
            else
            {
                RotationY = (float)(gameTime.TotalGameTime.TotalMilliseconds / 10);
            }

            gameWorldRotation = Matrix.CreateRotationX(MathHelper.ToRadians(RotationX)) * Matrix.CreateRotationY(MathHelper.ToRadians(RotationY));

            base.Update(gameTime);
        }

• the PC you're running it on (CPU, RAM, GPU)
• Operating System
  
• are you running Windowed?
• What happens when you switch to fullscreen?
• finally... can you give us repro application? A zip would be fine

It behaved the same on these configurations:

•  Intel Quadcore 6600 2.4Ghz, 3gb RAM, Geforce 7600GT, Windows Vista
•  Intel Quadcore 6600 2.4Ghz, 2gb RAM, Geforce 7100GS, Windows 2003 R2 .

Both running windowed

Switching to Fullscreen caused even the IsFixedTimeStep = false version to jitter on the 7100GS 1280*1024

here is the code and executable

http://net.aspone.cz/Model.zip

1) Ensure that all your updates and draws get processed in time - set a min target spec machine and ensure you hit your update time.  If some other process kicks in and interferes with your game, live with it - this what happens when writing games for Windows.  If it's the GC - fix up the problem by allocating memory upfront and reusing objects.  Don't update your HUD every frame (score.ToString(SCORE_FORMAT), etc), only when info changes

2) Try to interpolate / extrapolate the drawing position.  For interpolation - work out how much of the current frame has passed and lerp between previous and current position.  You could even try smoothing updates by keeping a list of the last x update times and averaging them.

http://www.flipcode.com/archives/Main_Loop_with_Fixed_Time_Steps.shtml

The nested discussion died with Flipcode but the main post is there for you to get the gist.

I used to roll my own fixed step loop too - physicsy type game objects updated deterministically, particles and effects as and when.  I prefer the simpler approach now though.

Whiplash6:

I just got World in Conflict and notice the jump there too.  Wonder why it doesnt jump on any of my other games.  So what can cause this jumping besides a video card since I went through 2 already (testing with 2, not 2 were damaged).

I think Whiplash's problem is/was simply that something is grabbing the cpu periodically resulting in dropped frames, so his is not really an XNA issue at all, though the discussion of how to program around things like this is interesting.

Did you ever try changing the priority of your game in the task manager to High or even RealTime (save your work first) to see if that fixes it?  If not it might be a hardware/driver issue.  Try unplugging all peripherals (especially USB devices including hubs) and even stripping the box down to the bare minimum if you have to.  If you can get to a state where the problem is gone, then you can put things backk one by one until you figure it out.

One lonely peripheral with a crappy driver would explain all of his problem I would think.  It's probably *not* the video card, but something that's periodically interrupting the system looking for attention and the driver's running so long to handle this that you drop a frame (or even multiple ones).

F.

Sure enough, I unchecked the option for displaying the second hand and the problem vanished.  If I turn it back on, the problem returns, so there's a clear causal relation between the stuttering and the second hand on the clock.  Needless to say, I don't run the sidebar anymore, because of such interference.

As for XNA's problem, I suspect it's a combination of things within the framework itself, not limited to the garbage collector.  I strongly suspect delays in synchronization mechanisms at the operating system level as well as the software mechanism for fixed timesteps, which could all cause the games to play catch-up more frequently than they should have to, given the high computational power of some of your boxes.  In addition, there will of course always be the occasional hiccup introduced by a multitasking OS, although it may not be as consistent or easily identifiable as the sidebar clock example that I gave.

- Win XP Pro

- Intel Dual Core 2.2 Ghz

- Nvidia 7900 GTX

- LCD Monitor 59hz refresh

Anyway, yeah, fixed time step don't work so well in XNA, because it's implemented at the wrong place, and/or you can't perfectly match the Vsync interval with your intended fixed time step. If you want to use fixed time step, you should set it to something that isn't too close to 60 -- say, 100, or perhaps 120.

 Update takes too long, a second Update is called to catch up to the correct time, so internal movement is updated twice for the subsequent draw frame.

 Draw takes too long, so Update is once again called twice in a row to catch up to the current time, updating internal movement and position twice.

 The Framework jumps in and freezes the Update-Draw cycle in order to do some housekeeping, causing the game to fall behind and once again have to call Update twice in a row.

The first two scenarios can be caught and avoided in the game code I believe, using a combination of IsRunningSlowly, ElapsedGameTime and ElapsedRealTime.  The third scenario though, I haven't figured out a way to recognize.  It seems whenever the Framework jumps in to do housekeeping, the values for IsRunningSlowly flag and the elapsed times will vary depending on where in the Update-Draw cycle the Framework jumped in at.  Anybody have any ideas or other theories? 

charlie:

Update takes too long, a second Update is called to catch up to the correct time, so internal movement is updated twice for the subsequent draw frame.

 Draw takes too long, so Update is once again called twice in a row to catch up to the current time, updating internal movement and position twice.

 

 I'm not sure how Update() or Draw() could take too long when running the samples provided on this site. They are very small amounts of code.

Now, I do get the jumping on very very basic games (you mentioned Alien Aggressors and I get it on that game as well) and I also get it in the professional created game World in Conflict.  I recently got the nVidia 9600GT and it still does the jumping. 

Yet I barely get this in the Net Rumble starter kit and I never get it in the RPG starter kit.  But every small sample provided by MS (aiming sample for example) I get major jumps.

Alright, here is just about the most simple program possible to demonstrate any slowdown during XNA programs.

http://www.nfostergames.com/ZippedPrograms/XNAFixedTimeStepTest.zip

This holds a cornflower blue background during times which is gets more than ~40fps, if it ever drops below that the screen will turn red.

My personal results:
Fixed timestep: Screen flickers red every couple of seconds, very briefly.
NO fixed timestep: Screen still flickers red, but slightly less often.
NO fixed timestep, AND vertical retrace turned off: Screen only flickers a couple of times initially, then stays blue for at least the next minute.

I had less red flickers during fullscreen mode.

My guess is that either XNA has a problem, or background Windows apps briefly interrupt (which is why windowed mode sees this more), or occassionally XNA ends up waiting for the GPU slightly too long with slows the next frame a bit.

Lord Ikon:

Alright, here is just about the most simple program possible to demonstrate any slowdown during XNA programs.

http://www.nfostergames.com/ZippedPrograms/XNAFixedTimeStepTest.zip

This holds a cornflower blue background during times which is gets more than ~40fps, if it ever drops below that the screen will turn red.

My personal results:
Fixed timestep: Screen flickers red every couple of seconds, very briefly.
NO fixed timestep: Screen still flickers red, but slightly less often.
NO fixed timestep, AND vertical retrace turned off: Screen only flickers a couple of times initially, then stays blue for at least the next minute.

I had less red flickers during fullscreen mode.

My guess is that either XNA has a problem, or background Windows apps briefly interrupt (which is why windowed mode sees this more), or occassionally XNA ends up waiting for the GPU slightly too long with slows the next frame a bit.

Here are my personal results as well:

Fixed timestep: A few red flashes during startup and then one every 30 or so seconds
No fixed timestep: A flash maybe every once a minute tops. Probably less than that.
No fixed timestep and no vsync: No flashes ever (within the 2-3 minutes I ran the game)
Fullscreen (fixed timestep and vsync both on): No flashes ever

So I'm still convinced that while there might be some part of the XNA framework that exascerbates this behavior, I do believe that the specific hardware and drivers also play into this. I never notice the jump in any of my games on Windows; only in these little demos where the screen is flashing at me.

Nick Gravelyn:

Here are my personal results as well:

Fixed timestep: A few red flashes during startup and then one every 30 or so seconds
No fixed timestep: A flash maybe every once a minute tops. Probably less than that.
No fixed timestep and no vsync: No flashes ever (within the 2-3 minutes I ran the game)
Fullscreen (fixed timestep and vsync both on): No flashes ever

So I'm still convinced that while there might be some part of the XNA framework that exascerbates this behavior, I do believe that the specific hardware and drivers also play into this. I never notice the jump in any of my games on Windows; only in these little demos where the screen is flashing at me.

Personally, I use elapsedGameTime in all movement functions. It doesn't matter if I'm getting 2fps, or 200fps, I'll be moving the same speed either way. The only way I see this causing an issue is if people are relying on the fact that they'll be getting a fixed speed at all times, which is a bad assumption considering everyone's computer will be running different hardware and software combinations.

Now it could be my computer, but with lots of people experiencing the same problem with different hardware configurations makes it seem unlikely.