9

Im creating a simple vehicle and projectile simulation game in WPF using C#. I need to have a constant frame rate (i.e. i need to know how much to move an object with a certain velocity in each frame). This way I could subscribe an event which calculates and updates positions according to the game's physics to the CompositionTarget.Rendering event.

CompositionTarget.Rendering += UpdatePositions;

I googled it a while, and found no answer. The fps in WPF seem to be arbitrary, and using a Stopwatch to know how much time elapsed between a frame and the previous one wouldn't be clean at all.

I thought also of creating my own frame rate, by calling UpdatePositions every some amount of milliseconds and hoping for the Rendering to occur accordingly and have a smooth animation. This seems like reinventing the wheel, and I cant think of a way of implementing this in a clean and simple manner.

Thanks!

Nicolas
  • 2,297
  • 3
  • 28
  • 40
  • 7
    Don't use WPF for anything but the most basic of game development. It really wasn't intended for that use. You should look into the XNA framework if you're looking to create a game using .NET. – dlev Oct 12 '11 at 00:30
  • I would think this is the most basic of game development, and i've already worked a lot so i really need to sort out my framerate issues... – Nicolas Oct 12 '11 at 00:39
  • "using a Stopwatch to know how much time elapsed between a frame and the previous one wouldn't be clean at all" - how so? – EboMike Oct 12 '11 at 00:42
  • 2
    Games driven by framerate are terrible. Never ever drive your motion with a framerate. What happens if a client can't keep up with the framerate you set? – Chris Eberle Oct 12 '11 at 00:45
  • Aside from whether or not you *should* be using WPF for this, you could use nowTime = DateTime.Now; TimeSpan delta = nowTime - lastDateTime (Gives you the elapsed interval). Then lastDateTime = nowTime; – Mranz Oct 12 '11 at 00:55
  • I might be wrong, but I would think that using events for this would add a significant overhead. – Tipx Oct 12 '11 at 01:06
  • As others have said, don't tie your timestep to framerate: http://gafferongames.com/game-physics/fix-your-timestep/ – jeffora Oct 12 '11 at 01:51

3 Answers3

9

It is impossible to get a constant framerate in WPF. WPF is based on the idea of dynamic frame rates and this makes it near useless for any game development.

Some related information:

Why is Frame Rate in WPF Irregular and Not Limited To Monitor Refresh?

http://rhnatiuk.wordpress.com/2008/12/21/wpf-video-playback-problems/

As others have pointed out the solution is, unfortunately, not to use WPF for game development.

I have worked with WPF animations extensively and it is an absolute pain to get anything to smoothly animate in WPF (if you do want to do this I've written down a few best practices here).

I am sure there are many other reasons why WPF is not good for game development. One example is that you cannot create a full screen application in WPF as WPF apps are always windowed. This means that you could not change the resolution for your game to make it smooth in full screen which effectively means that you could not create a full screen game in WPF and expect good results.

If you are serious about your game or game development in general and this is not just a prototype or just-for-fun then I recommend that you ditch WPF and use something else, otherwise you just set yourself up for disappointment and sub-par quality.

Community
  • 1
  • 1
Patrick Klug
  • 14,056
  • 13
  • 71
  • 118
  • in those best practices you say: "The CompositionTarget.Rendering event causes WPF to continuously animate. If you use this event, detach it at every opportunity.". What do you mean by detaching the event? Thanks – Nicolas Oct 12 '11 at 02:12
  • it just means that hooking up to CompositionTarget.Rendering is not optimal as it may impact performance even if you don't do anything in the event handler. MS recommends to detach/unsubscribe (CompositionTarget.Rendering-= Foo) whenever it isn't absolutely necessary to listen to the event. – Patrick Klug Oct 12 '11 at 02:24
  • this advice comes straight from MS: http://msdn.microsoft.com/en-us/library/bb613584.aspx – Patrick Klug Oct 12 '11 at 02:25
2

You can use WPF to draw the surrounding UI of your game and then use the DirectComposition API to have the Composition Engine (DWM) compose your swapchain directly on top of WPF's window.

I have uploaded a sample demonstrating this on github.

The UI would not have a constant frame rate, but your swapchain would. Hittesting would just fall through to the WPF window.

Tom Huntington
  • 2,260
  • 10
  • 20
2

Even if you don't want to go with XNA for game development consider reading on how time management is done there - fixed frame rate is not necessary equal or required to stable game time. Try to base your physics on game time (which may be the same as real time or computed based on real time delatas - i.e. if you want to have "fast forward" mode or pause the game) instead of frame rate.

Following 2 links discuss "game time", "real time" and related concepts: http://blogs.msdn.com/shawnhar/archive/2007/07/25/understanding-gametime.aspx, http://blogs.msdn.com/shawnhar/archive/2007/11/23/game-timing-in-xna-game-studio-2-0.aspx

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179