Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
In C# WinForms whenever making a small game here or there, I would write up a quick class that was a subclass to System.Windows.Forms.Panel and in the constructor, setting DoubleBuffered to true. Then you could override the OnPaint method to display game elements. I’ve done this for 2 or 3 years now, but I’m really trying to embrace WPF and XAML, I really like it for regular application layouts. What equivalent is there to doing this in WPF?
Not the answer you seek, but: you shouldn’t use WPF for games. Stick with Forms (which won’t be dumped by MS, since WPF isn’t superseding Forms) or try XNA if you want to go to the next level.
UPDATE: I answered the question very quickly yesterday, because I was in a hurry and because I also looked into WPF in order to do games, so I didn’t wanted to left the OP without the proper answer.
Here is the deal:
WPF goal is to simplify rich UI development. First, MS understood that Forms way of coding mix behavior with presentation. This is bad, both for application design as for maintainability. Besides, in Forms, everything has to be coded; The library itself does very little for the user. For example, if you want a button that has a different look, you have to override its
Drawmethod and then, somehow, draw whatever graphic that represents it.With WPF, behavior is separated from the presentation. For example, what is a button? In windows, we know it to be a box with rounded corners, but look around… your mouse scroll is also a button, even though it looks nothing like the Windows default button. Being a button means having a specific behavior (clicking, mostly), not looking like a box. With WPF, this is very simple. You define a button and then use, say, an image or a text, to present it to the user.
All this comes at a cost, of course; for example, WPF is slower than Forms. Games need to be quick and try not to waste resources. In games, every behavior tends to be coded (not the UI, of course), every presentation is customized (a 2D graphic or a 3D object), so you will have to do a lot of coding anyway. So you are using an expensive technology but throwing away most of its benefits.
But I’m no specialist. You can check this blog, where an ex-Microsoft employee tried, for almost two years, to use WPF for games. And he concludes:
From there I’ve drawn most of my conclusions.