[.net] XNA Performance

IsFixedTimeStep only affects Game.Update. Realistically there aren't many reasons I can think of why you wouldn't want to run the game logic you update inside that function at a fixed time step (I believe it defaults to 60hz), so I wouldn't unset that flag unless you have some specific reason.

As for rendering, if you are wanting to allow Game.Draw to present immediately and not wait for v-sync, you should set SynchronizeWithVerticalRetrace to false.

Regards,
ViLiO

Also, as anyone from the DirectX community would tell you, timing an empty game loop is quite pointless and won't give you even the slightest idea on how fast the system can perform.

I'd risk a bet and claim that you could rewrite DooM3 in C# / XNA and it would run within 10% tolerance of the original's speed. You mileage may vary with CPU-heavy things such as physics engines and AI, but performance should still be good enough to pull it off.

-Markus-

Quote:

Original post by ViLiO IsFixedTimeStep only affects Game.Update. Realistically there aren't many reasons I can think of why you wouldn't want to run the game logic you update inside that function at a fixed time step (I believe it defaults to 60hz), so I wouldn't unset that flag unless you have some specific reason. As for rendering, if you are wanting to allow Game.Draw to present immediately and not wait for v-sync, you should set SynchronizeWithVerticalRetrace to false. Regards, ViLiO

Well, first I unset this flag because I just want to see the real possible FPS on my machine.

The reason why I want to have higher FPS value is that I don't want the camera movements to look jerky. Let's say that the screen refresh rate is 75 and my app's FPS is just 65. In this case, while moving with a camera around the scene, the movements are jerky. And how about a situation when user's monitor has even higher screen refresh rate value?

So I want to increase my app's FPS to be sure that it is higher than screen refresh rate and there are none jerky movements (could changing something in PresentationInterval be a solution)?

As I said, IsFixedTimeStep only affects the frequency of Game.Update being called, so it will have no affect on your framerate.

Setting the flag SynchronizeWithVerticalRetrace to false will allow Game.Draw to present immediately and not wait for vertical synchronisation (ie, your framerate will not be limited to that of your monitor's refresh rate, which for you seems to be 65Hz).

If your camera movements are jerky, then I'd have a long look at your game logic, as you should really be able to handle smooth movements even with a low FPS.

Regards,
ViLiO

I have tried to run my app after setting graphics.SynchronizeWithVerticalRetrace to false, and I got that FPS is near 100.

One strange fact I have found out: if my screen refresh rate is 60, camera movements are very smooth. But if it is bigger, all the movements become really jerky. It says for me that possible problems in my camera class is not thee reason of jerky movements.

I'd guess that your camera code moves based on fixed values. If you make it move based on any given time interval, it should move the same regardless of your frame rate.

Right now your code is probably something like this:

position += deltaPosition

When it should be

position += (deltaPosition * time);

May want to look into this: Shawn Hargreaves - Understanding GameTime and IsFixedTimeStep.