Whiplash6:

How do you change the refresh rate?

Here. This was with XNA 1.0 - I haven't tried it with 2.0, mainly because (as Shawn said), once you get more stuff on screen, you don't really notice dropping frames, or at least I haven't in my game.

 

 

HadesSpaniel:

Whiplash6:

How do you change the refresh rate?

Here. This was with XNA 1.0 - I haven't tried it with 2.0, mainly because (as Shawn said), once you get more stuff on screen, you don't really notice dropping frames, or at least I haven't in my game.

 

 

Thanks, I just did it and it still jumped.

Any other ideas?

I am convinced there is some deeper problem here.  I have the exact problem as you say.  It sounds like it could be a monitor timing problem, but I noticed the 'jumps' can sometimes be a little clustered together.  This should not happen if it is the monitor timing.

Whiplash6:

Seems the more simple it gets, the worse it gets.  For example, this lags the worst

http://www.phstudios.com/test/SpaceShoooter-Windows.ccgame

All this is, is a sprite that can be moved. 

 

EXACTLY!!!

I spent over ten hours trying to find what was wrong and the symptoms are exactly what are you describing.  I had a DrawUserPrimitives call at the beginning of every frame.  It drew only one point, but removing it caused the entire game to get more 'lag'.  It don't think it's a monitor timing issue because the jumps often cluster up.

Like the title says, retail games do not have this "jumping" -- even when v-sync is on.  They may run at 59 FPS, but they maintain that frame rate.  The simplest XNA game "jumps" constantly.  This can't be a monitor problem.  And, yes, if this "jumping" was in retail games I would notice it.

Whiplash6:

Seems the more simple it gets, the worse it gets.  For example, this lags the worst

http://www.phstudios.com/test/SpaceShoooter-Windows.ccgame

All this is, is a sprite that can be moved. 

I can't seem to get to this file. Do you have the source somewhere that can actually be downloaded?

One thing that may make XNA "jump" (at least on my system) is the improper use of the GC system. Most commercial games handle memory manually, or at least with a system they know well. So watching the allocation of memory could significantly help with the occasional jumpy lag from GC

Sorry my server crashed and I had to upload everything again.

Here is the file:  http://www.phstudios.com/test/SpaceShoooter-Windows.ccgame

Louis Ingenthron:

One thing that may make XNA "jump" (at least on my system) is the improper use of the GC system. Most commercial games handle memory manually, or at least with a system they know well. So watching the allocation of memory could significantly help with the occasional jumpy lag from GC

We've confirmed that this isn't a garbage collector issue.

I just tried your sprite game and it jumped just like you said.  I think you are creating a little garbage.

I've made a scrolling list test project with some of my code that can be downloaded here:

http://cid-637a093a33abf7c6.skydrive.live.com/self.aspx/Public/FramerateTestProject.zip

As far as I know there are 0 memory allocations in Update and Draw.

 

I then tried Spacewar and it did not jump.

I think this debunks the idea that it is monitor timing.

Shieldshock:

I then tried Spacewar and it did not jump.

I think this debunks the idea that it is monitor timing.

Not necessarily. It might just prove the theory that once there is more going on you don't notice the jumps. Or perhaps the timing gets adjust when there is more going on and the jump less noticeable.

I tried the demo and did see a little twitch, but I would consider that hardly noticeable (I mean I only saw it because that was the only thing going on and I was specifically looking for it). If there was some other stuff going on on-screen and I wasn't trying to spot the "jump", who knows whether I would've even seen it.

Shieldshock:

I just tried your sprite game and it jumped just like you said.  I think you are creating a little garbage.

I've made a scrolling list test project with some of my code that can be downloaded here:

http://cid-637a093a33abf7c6.skydrive.live.com/self.aspx/Public/FramerateTestProject.zip

As far as I know there are 0 memory allocations in Update and Draw.

 

I then tried Spacewar and it did not jump.

I think this debunks the idea that it is monitor timing.

Well also remember EVERY small sample provided by ANYBODY (including microsoft) jumps.  All of their how to, small samples, and sometimes NetRumble.

Oh and the framerate test jumped like crazy too (even more than my small game).  When I display the FPS, it does not drop at all

I see all ridiculous ideas come out. Here are some more from me:

- What cpu priority given tested apps get... standard "normal" or non-standard.

- Check billboard sample pliz and rate its "jumpiness".

- Get some Profiler...

- Check some game that doesn't use spritebatch... generate quads by hand.

 

I will test some apps in search of jumps also.

Nick Gravelyn:

Not necessarily. It might just prove the theory that once there is more going on you don't notice the jumps. Or perhaps the timing gets adjust when there is more going on and the jump less noticeable.

That is ridiculous.  I notice right away when the game jumps.  It is not just one sprite jumping.  The whole screen jumps in unison.

That said, I checked spacewar and it has a variable timestep.

I think this is the deal... If you have fixed timestep on, you update 60 times per second and draw about 60 times per second, regardless of monitor refresh rate.  As far as I know, most monitors update at about 59.8 frames per second (something a little less than 60).  With fixed timestep this will cause the little jumps.  If you choose a variable timestep, the game will try to run exactly at the refresh rate of the monitor.  Switching the little examples to use variable timestep takes the jumps out for me, so TRY USING VARIABLE TIMESTEP.  If it works after you do that, we know what the problem is.

Honestly I'm not saying the variable time step isn't a solution. It clearly works for you. And the problem does stem from the monitor refresh rate (just like Shawn said earlier). I'm merely saying that lots of games use a fixed time step and nobody complains about their update rates. They aren't doing anything (much) different than the XNA game loop I would assume. Perform Update(), perform Draw(), wait until it's time for next frame. Yet you don't see people complaining that their favorite PC games are jerking every few seconds.

What I am saying is perhaps the simplicity of your tests could be why it is so noticeable. That and you are staring at the screen waiting to see a jump. Also you are drawing a concrete conclusion (that the only fix is to run in variable timestep) without really testing it. You don't know that Space Wars doesn't jump because of the variable time step unless you have run Space Wars in fixed time step. And even then all the logic and rendering might be dependent on the variable time step which could slant the results.

Another solution as well would be to use a fixed-time step but still take into account the elapsed time for motion. Then you get the best of both worlds. For some systems where the math is too hard in variable time step, just deal with the small glitch by assuming the game runs a perfect 60fps to help simplify the math. For others (such as basic linear motion), use the elapsed time to compensate for the glitches. I've always done this in my games which might explain why I've never noticed this before.

So does it update so fast it lags?  That would explain why the larger the game gets the less it lags or "jump".  How would it look wile using elapsed time?  Ill give it a try then report back

Ahhh ok I did this in the Game1 constructor and it doesnt jump anymore:

IsFixedTimeStep = false;

Can you explain why it jumps when running on true even when I have very little stuff going on?  And also, should I provide this line of code in every game I make or is it a bad idea?  SpaceWar has it so it shouldnt be that bad right?

 

Shawn mentioned the cause a number of posts back:

Windows is a multitasking operating system. That means it is impossible to ever have a Windows program run 100% smoothly. Every now and again, some other process is going to wake up, and that will make your game stutter. How often this happens and how noticable the stutter is depends entirely on what software you have installed on the box, but it will always happen to some extent. You can minimize the effects of this by running in fullscreen mode (or running on Xbox :-)

The other factor is if you are using fixed timestep, your game framerate may be slightly out of phase with your monitor refresh, which will cause a dropped frame or catch-up frame at periodic intervals, to get the two back in sync. The only way to prevent that is to switch to variable timestep mode so your game can run at exactly the same rate as the monitor refresh, but I can't recommend doing this as it makes your game logic much more complex and requires a good understanding of calculus.

So yes switching to IsFixedTimeStep = false will solve the problem, but that will make it harder to update some aspects of your game. Physics, for instance, will become less stable with varying time steps. That is why I suggested using a fixed time step and simply using the elapsed time to work out linear motion and things with simple fonts. This should take care of the jump without making your whole game run in variable time step.

Nick Gravelyn:

Shawn mentioned the cause a number of posts back:

Windows is a multitasking operating system. That means it is impossible to ever have a Windows program run 100% smoothly. Every now and again, some other process is going to wake up, and that will make your game stutter. How often this happens and how noticable the stutter is depends entirely on what software you have installed on the box, but it will always happen to some extent. You can minimize the effects of this by running in fullscreen mode (or running on Xbox :-)

The other factor is if you are using fixed timestep, your game framerate may be slightly out of phase with your monitor refresh, which will cause a dropped frame or catch-up frame at periodic intervals, to get the two back in sync. The only way to prevent that is to switch to variable timestep mode so your game can run at exactly the same rate as the monitor refresh, but I can't recommend doing this as it makes your game logic much more complex and requires a good understanding of calculus.

So yes switching to IsFixedTimeStep = false will solve the problem, but that will make it harder to update some aspects of your game. Physics, for instance, will become less stable with varying time steps. That is why I suggested using a fixed time step and simply using the elapsed time to work out linear motion and things with simple fonts. This should take care of the jump without making your whole game run in variable time step.

Ah ok so you recommend instead of using position+=velocity; to use the physics formula to update position?

x = x + velocity * time +  0.5 * acceleration * time * time is the physics formula.  You suggest using that instead?

Whiplash6:

Ah ok so you recommend instead of using position+=velocity; to use the physics formula to update position?

x = x + velocity * time +  0.5 * acceleration * time * time is the physics formula.  You suggest using that instead?

Those are two very different formulas (the physics one you gave requires the starting position and so on). I simply meant replace your

position += velocity;

with

position += velocity * (float)gameTime.ElapsedGameTime.TotalSeconds;

That should take the glitches into account and make your motion smooth without you having to resort to using variable time step all over the place.

Nick Gravelyn:

Whiplash6:

Ah ok so you recommend instead of using position+=velocity; to use the physics formula to update position?

x = x + velocity * time +  0.5 * acceleration * time * time is the physics formula.  You suggest using that instead?

Those are two very different formulas (the physics one you gave requires the starting position and so on). I simply meant replace your

position += velocity;

with

position += velocity * (float)gameTime.ElapsedGameTime.TotalSeconds;

That should take the glitches into account and make your motion smooth without you having to resort to using variable time step all over the place.

 

It still jumps like crazy (actually worse this time)

Are you on fixed time step or variable time step? What exactly does your code look like (copy and paste directly from your source)?