Performance issues below 60fps

[Stevemata]

I'm using the CharacterControllerInput object.
I'm running my game on the xbox360
When my framerate drops below 60fps because of intense rendering the camera movement gets choppy, like I'm running closer to 4 or 5 fps. I have the simulation running on threads 1,3 and 5. I have used the configuration helper to apply default settings. I have a feeling this is a user error issue of some sort considering that my character controller and a low poly static mesh are the only objects.

[Norbo]

If there's only two objects in the simulation, the physics is probably not related to the slowdown.

It sounds like your game is using fixed time stepping. This means that the Game class will try to call Update a consistent number of times per second rather than using a Update-Draw-Update-Draw-Update-Draw flipflop approach regardless of framerate.

If some intense event happens and Update takes too long, the Game might not be able to perform enough updates to catch up with real time. It will still try, though. The result can be performing many (long) Updates between Draw calls, crushing FPS for the duration of the event.

To avoid this, either keep Updates consistently in budget, or switch over to a variable time step and handle the additional complexities or accept framerate dependent game speed.

[Stevemata]

I don't believe that I'm using fixed time steps. Where else should I look?

IsFixedTimeStep = false;

and I calculate time elapsed like this

Code: Select all

float dt = (float)gameTime.ElapsedGameTime.TotalSeconds;
character.Update(dt, previousKeyboardState, currentKeyboardState, lastGamepadState, currentGamepadState);
Camera.Update(dt, currentKeyboardState, currentGamepadState);
space.Update(dt);

[Norbo]

I can't provide much help because it doesn't sound like it's the physics, but I would recommend grabbing a profiler and checking to see where the time is being spent. Also, check to see where the bottleneck is (CPU/GPU/IO/etc.).

[Norbo]

By the way, passing in dt to the Space.Update method will make it use internal time stepping. This means it will take however many steps of length Space.TimeStepSettings.TimeStepDuration as necessary to keep up. If there's really only a character and mesh in the simulation, the speed of simulation is almost certainly not the issue (unless the Space.TimeStepSettings.TimeStepDuration is set to something like 1e-10 instead of the default 1/60f).

However, it's still possible to run into some unsmoothness when using internal time stepping, especially if things aren't handled consistently. The Space.Update method can do multiple timesteps in a single frame so not every frame will have the same amount of simulation advancement. This can manifest as frame-by-frame microjerkiness. It is eliminated by using interpolated states. More information about interpolated states can be found in the asynchronous updating documentation. (Note that you do not need to be updating asynchronously to use interpolated states; it's just a common use case.)

Unless there's a vicious spiral of updates happening that's killing performance, any unsmoothness should be very tiny and cannot explain the appearance of 4-5 FPS in camera updating in isolation.

[Stevemata]

The frame rate will stay at 50fps, but the camera's movement appears to be operating at around 4 to 5 frames per second.

[Norbo]

The physics engine has no concept of graphics/camera management, so I can't offer much advice if it's not performance related.