OK, I think this thread has been totally blown out of the water, dragged to shore, and beaten to death now O_o

Bapa:

OK, I think this thread has been totally blown out of the water, dragged to shore, and beaten to death now O_o

 

Why?  I have updated all my drivers, tested it on many computers (some of mine and my friends see the jump but others dont), updated the BIOS, tried all the samples I could think of and they still jumped, but appearently the more complicated the game gets, the less it jumps.  The sample I posted a few posts ago jumped worse than anything I have seen yet, but my space shooter game jumps very less, one of my bigger games jumps even less, netrumble barely jumps but I have noticed it, but appearently, NO 3D game from both XNA and professional never jump.  It should work the other way around, but its not.  I even bought a new video card and it still did it.  Bought a new computer and it STILL jumps.

Bapa you are not helping anything here...  if you don't want to contribute anything useful please don't post at all.

Whiplash the code you posted uses a fixed timestep.  This is going to cause jumping no matter what (unless the video device has a refresh rate of exactly 60).

I also see jumps in the 2D graphics demos posted here, both on my stationary and laptop. I havn't found any solution but I can add that I have been troubled with similar jumps coding in Java and OpenGL/C++ for simple graphics moving in a linear fashion. The thing I can add is that not everybody sees the same thing, I have pointed it out to others that are simply not able to see the small jitter in the animation.

Reminds me of when I watch DVDs I can see mpeg compression artifacts in fast moving scenes. Pointing it out to my friends just gives me blank stares :-)

So my question would be, has the same person seen the jitter on one computer and not on another for the same animation?

How about this. Download this game I wrote yesterday and tell me if you see any glitches? If you do then tell me are you staring at it intently or are you just playing the game? I'll be honest if I stare at a few pixels I might see a tiny hiccup once in a while, but if I'm actually playing the game, I never notice anything. Give it a shot: AlienAggressors.zip. (Edit: Game requires game pad. Sorry. Haven't gotten to caring about keyboard support yet).

I have downloaded and started your game but I am stuck at the first screen as the game does not seem to respond to any of my keyboard or mouse input...

Any suggestions? I have no gamepad hooked up to my PC.

In that source code sample you did I saw you were multiplying the velocity by -1. Maybe try multiplying it by -1f.

GucciHat:

I have downloaded and started your game but I am stuck at the first screen as the game does not seem to respond to any of my keyboard or mouse input...

Any suggestions? I have no gamepad hooked up to my PC.

Sorry, I don't have keyboard support in the game at this point. I'll likely add it later, but not now.

jjxtra:

In that source code sample you did I saw you were multiplying the velocity by -1. Maybe try multiplying it by -1f.

That won't change anything...  Only when dividing two integers to create a float do you need to add the 'f'.  ( 1/2 = 0, 1f/2f = 0.5f )

Nick Gravelyn:

GucciHat:

I have downloaded and started your game but I am stuck at the first screen as the game does not seem to respond to any of my keyboard or mouse input...

Any suggestions? I have no gamepad hooked up to my PC.

Sorry, I don't have keyboard support in the game at this point. I'll likely add it later, but not now.

Well I take that back. I just added keyboard support. You can use W/S or Up/Down arrows for the menu and use Enter or Space to make the selection. Then use either A/D or Left/Right arrows to move in game, Space to fire, Enter to pause, and Escape to quit.

Yes I do notice the jump.  It does not happen as often though.

Are you staring at it trying to see the jump or are you just enjoying the game? If you are staring at the screen trying to see it then you are not representing the average user's experience. When I am just playing the game I tend to not notice it. And even the few times I see it, it's not major and doesn't make me feel like the game is broken.

I should mention my game is fixed time step and never takes into account the elapsed game time for motion. It runs pretty well.

Im not looking for it, but I can tell when it jumps even when I am not looking for the jump.

Hmm maybe its my computer after all.  I downloaded some tv shows off iTunes and I notice the same jump when watching some of them.  It doesnt happen as often as the basic games, but I can tell when it jumps.

The behaviors you are seeing have been explained earlier in this thread, but for the sake of clarity I will repeat them one last time. Sorry if you don't like this explanation, but it does have the advantage of being true :-)

If your goal is to make a Windows game which updates the screen exactly once per monitor refresh, never dropping a single frame, and which will do so reliably on every machine, well, I'm sorry, but you are just plumb out of luck. That is impossible.

The PC is a general purpose platform, and it does not provide any kind of hard-realtime guarantees. In the absence of such guarantees, it is impossible to make sure your program will never drop a frame. There are just too many other programs, system services, and drivers, that might wake up and need to do some work of their own at an inconvenient moment. On some computers this will happen often, on others rarely, but it will always happen to some extent, and there is absolutely nothing you can do to prevent it.

You have exactly two ways to reduce the number of these dropped frames:

• Run on Xbox, which is not a general purpose platform, so does not have arbitrary other services and drivers running in the background.
• Run in fullscreen mode, which prevents your game having to share the GPU. This does not 100% remove dropped frames, but it can significantly reduce the number of them.

 

So, you have to accept that Windows games will always drop a frame every now and then. The next question is, what should your game do to recover when this happens? You have basically three options:

• Do nothing, and just loose some time. Not good, and very obvious to the player.
• In your next update, account for how much time has been lost, and move all your objects slightly further to compensate for it. This is the behavior you get if you set IsFixedTimestep = false. Trouble is, this accounting makes your update logic more complex.
• Use IsFixedTimestep = true, and don't write any special code in your update method. In this case the framework will keep track of how much time has been lost, and once that adds up to enough to make up a whole extra Update, we will call Update an extra time to catch up with where we ought to be.

 

Programmers will argue forever about which of fixed or variable timestep is best. Personally I prefer fixed timestep because it is easier to program with, but both methods work fine, and many quality professional games have been written using both methods. There isn't really a lot of visual difference between the two: in both cases you are losing time every now and then, then catching up to compensate for that: the difference is just in the details of how the catchup is implemented.

(that's assuming the variable timestep guys do this properly in their Update, of course: lots of beginner programmers try this, but get the math wrong, which makes their game less smooth than if they had used fixed timestep)

So why do you notice this glitching in simple tests, but not in more complex 2D games, 3D games, or commercial games?

Because of how the human eye works. The simpler your game, the more obvious the glitching will be. Top end commercial 3D games drop frames just as often (the exact same services are running in the background, after all!) but because they have so much more going on, people just don't notice. It's easy to look at simple 2D demo, where the dropped frames will be very obvious, and worry that this will ruin your game. Don't worry, just go ahead and finish the game. By the time you have inertia and acceleration and particles and effects and animation, people will have other stuff to look at so won't notice what used to be more obvious back when you just had a single sprite moving in fixed integer pixel units.

Shawn Hargreaves:

(that's assuming the variable timestep guys do this properly in their Update, of course: lots of beginner programmers try this, but get the math wrong, which makes their game less smooth than if they had used fixed timestep)

Slightly off topic:

I find fixed timestep more confusing.  With variable timestep, an object with a speed of 5 will move 5 world units per second (assuming you're using the elapsed seconds).  With fixed timestep, an object with a speed of 5 will move 5(60) = 300 world units per second.

Swordshock:

Shawn Hargreaves:

(that's assuming the variable timestep guys do this properly in their Update, of course: lots of beginner programmers try this, but get the math wrong, which makes their game less smooth than if they had used fixed timestep)

Slightly off topic:

I find fixed timestep more confusing.  With variable timestep, an object with a speed of 5 will move 5 world units per second (assuming you're using the elapsed seconds).  With fixed timestep, an object with a speed of 5 will move 5(60) = 300 world units per second.

You can have a fixed time step and still use the elapsed time to make an object move 5 units per second. I do it in some of my games as well to make it easier to work with. Just because it makes it easier to move your characters at units per frame doesn't mean you can't still do units per second.

Shawn Hargreaves:

The behaviors you are seeing have been explained earlier in this thread, but for the sake of clarity I will repeat them one last time. Sorry if you don't like this explanation, but it does have the advantage of being true :-)

........

 

I DID try everything you guys mentioned, and when I used isfixedtimestep = false, you said its not a good idea because it requires heavy calculus.  And I DID notice the jump still with isfixedtimestep = false; just not as much.  Also, I DID try using time to update my sprites, but it resulted in an even jumpier game than before.  I DID run it on the XBox and recieved the same jumping (on all small samples)

But what would cause SpaceWar to not jump AT ALL (even if I stick my face in the monitor and watch it there is absolutely no jumping) over NetRumble?  They both seem to have the same amount of complexity in the game.  The only difference is one is in 3D, so does that mean all 2D games will run like crap compared to an equal 3D game in complexity? 

 

Also off topic, I mentioned that iTunes jumps as well occasionally.  Does that mean its my comp's fault?  If so what would cause it to jump on 3 different computer configurations and tested on both XP and Vista on all three?  I guess I should just get a $8000 comp to runs things well without such jumping, even though the one I have now costed a lot to begin with. 

 

Sorry for sounding mad, its just no matter what I spend on a computer, I always have problems with performance. 

Off Topic post on Windows as a gaming platform moved to here http://forums.xna.com/thread/53642.aspx - please keep this thread on topic.

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

Anybody know?

I'm sure this never used to be the case on my PC (E6600, 2GB, NV 7950GT, dual screen at 1024x768, 60Hz), but for the last couple of days I've been trying to figure out why all XNA games have got the "infamous" stutter. I can see Shawn rolling his eyes already :P

So far, I've:
1. Unloaded absolutely everything I can, including unnecessary services.
2. Profiled and verify the GC isn't impacting things.
3. Made sure I'm running full screen.
4. Read and re-read everything on the forums.
5. Used Fraps to measure frame rates - typically between 57 and 59 Hz, never 60.

My current test case is the TiledSpritesSample, modified as follows:
1. Vary the resolution in the TileSpritesSample constructor to be either 640x480 or 800x600
2. Set graphics.IsFullScreen = true in the constructor.
3. Wrap the Draw code around a "if (gameTime.IsRunningSlowly == false)" check so that drawing only takes place if the game is not running slowly.

Any suggestions? I'm stumped. "What's changed" I hear you ask. Answer - I don't know. An Office 2003 service pack, some VS2005 updates, thats about it.

Edit: I downloaded the sample, re-compiled and still have the odd jerking at 57fps. Ignore my previous comments about IsRunningSlowly - it's late.

Good luck figuring it out. As I have written previously I see it also.

Yesterday I downloaded an XNA demo for my XBox360 and I saw the same jitter in the framerate. The link for the demo is http://www.pouet.net/prod.php?which=31583 . Its obviously complex 3d graphics going on so maybe they are hitting a performance barrier. However it is interesting that 1) Its stutter on the xbox on my TV, everyone should see the same 2) it has the same regular stutter frequency as what I have experienced with my own code, a small jump in the animation a bit less that a second apart. 3) It is VERY visible to me.

Please someone run the demo and report back.

Shawn has discussed the issue with it being close to 60 before as being linked to vsync.  Hardware vsync isn't dead accurate.  I never get 60, only about 57 to 59 (and my monitor is set to refresh at 59).    I cannot help but belive it (occasional stutters) is, as Shawn has discussed, just linked to windows and other things starting and going on that we cannot control. 

Windows will grab what it can get away with.  I run Vista, and if I turn OFF fixedtimestep, my game slows down and I lose Update calls.  So, when windows gets the chance to grab some time, it does.

Best,

Byron

We already have a VERY long thread for this issue making a new one will just cause people to repeat themselves http://forums.xna.com/thread/51942.aspx. Please read through this whole thread - it explains the situation very well.

Threads Merged....

 

If I may add to the discussion, I would like to say that I also have jumpy animation when moving a sprite at constant velocity (constant rate of pixels per second). I experienced the issue in particular with very simple moving-square type of examples (along with the Microsoft animated background code example, or any other sample).

I had the issue on both a Quad-core Q6600 with a Geforce 8800 GT and on my dual-core laptop with a joke of a video card.

On my quad, disabling fixed time step seems to fix the issue, but not on my laptop. Also, one of the symptoms of the jerkiness is that from time to time, I get a burst of short frames. For instance, on my laptop, I would get 200 frames at 30 Hz then all of a sudden 10 frames at ~60Hz. On my quad, I would get 60 Hz frames followed by extremely short frames (~0.001 s long).